1 / 8

draft-tarapore-mbone-multicast-cdni-0 4

draft-tarapore-mbone-multicast-cdni-0 4. Percy S. Tarapore, AT&T Robert Sayko, AT&T Greg Shepherd, Cisco Toerless Eckert, Cisco Ram Krishnan, Brocade. Scope of Document.

beyla
Download Presentation

draft-tarapore-mbone-multicast-cdni-0 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-tarapore-mbone-multicast-cdni-04 Percy S. Tarapore, AT&T Robert Sayko, AT&T Greg Shepherd, Cisco Toerless Eckert, Cisco Ram Krishnan, Brocade

  2. Scope of Document • Develop Best Current Practice (BCP) for Multicast Delivery of Applications Across Peering Point Between Two Administrative Domains (AD): • Describe Process & Establish Guidelines for Enabling Process • Catalog Required Information Exchange Between AD’s to Support Multicast Delivery • Limit Discussion to “Popular Protocols” (PIM-SSM, IGMPv3, MLD) • Identify “Gaps” (if any) that may Hinder Such a Process • Gap Rectification (e.g., New Protocol Extensions) is Beyond the Scope of this BCP Document IETF 88 – Vancouver, BC

  3. Revision History • Vancouver 2012 - Revision 0 Proposed as a BCP for Content Delivery via Multicast Across CDN Interconnections. • Feedback Received: • Specific case for CDNi only & Would Require Descriptions of CDN Interconnection Architectures • Possible Conflict with CDNi WG • Atlanta 2012 – Revision 1 Preempted due to Hurricane Sandy • Orlando 2013 – Revision 2 Proposed as General Case for Multicast Delivery of Any Application Across two AD’s: • CDNi Case is One Example of this General Scenario • Berlin 2013 – Revision 3 provides detailed text for Use Cases in section 3 Accepted as Working Group Draft. • Vancouver 2013 – Revision 4 Changes: • New Use Case added (Section 3.5) • Requirements in all Use Cases rewritten as Guidelines IETF 88 – Vancouver, BC

  4. Chained AMT Tunnels in AD-2(New Use Case - Section 3.5) • Motivation for New Use Case is based on Use Case 4: • AD-1 is Multicast Enabled • AD-2 is Not Multicast Enabled • Long AMT Tunnel setup between AMT Gateway in EU device & AMT Relay in AD-1 • Implications: • “Long” AMT Tunnel traverses across entire AD-2 domain • Multiple AMT Tunnels across peering point could create bandwidth utilization issues IETF 88 – Vancouver, BC

  5. Chained AMT Tunnels in AD-2 Observation: This diagram is MUCH NICER than figure in the I-D End User AD-1 (Multicast Enabled) AD-2 (Non-Multicast Enabled) End User Source AMT Relay End User AMT GW in App AMT Tunneled Multicast AMT GW/Relay IETF 88 – Vancouver, BC

  6. Chained AMT Tunnels in AD-2 • AMT Tunnel Chains: • Single AMT Tunnel across peering point between AD-1 AMT Relay & AD-2 AMT GW/Relay • AMT Tunnels between AD-2 peering point AMT GW/Relay & other AMT GW/Relay locations on AD-2 Domain Edge • Short AMT Tunnels between Edge AMT GW/Relays & EU devices • Advantages: • Bandwidth utilization improvement across peering point (single stream in AMT tunnel) • Significant bandwidth resource utilization improvement within AD-2 due to fewer AMT tunnels. • Implications– Need an efficient capability for determining “optimal” AMT Gateway  Relay pairs for establishing Chained Tunnels  draft-nortz-mboned-amt-dns-00.txt IETF 88 – Vancouver, BC

  7. Use Case Guidelines • Revision 3: • Requirements listed with Each Use Case for successful implementation of Use Case architecture. • Input Received: Requirements are “HARD” rules – Suitable for RFCs. • Given that this is a BCP document, it would be better to describe “SOFT” guidelines. • Revision 4 – Requirements are replaced with Guidelines. IETF 88 – Vancouver, BC

  8. Next Steps • Complete Section 4 – Supporting Functionality Best Practices • Request Comments on New Draft Text Thank You IETF 88 – Vancouver, BC

More Related