1 / 8

draft-tarapore-mbone-multicast-cdni-0 6

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

tawny
Download Presentation

draft-tarapore-mbone-multicast-cdni-0 6

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-06 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 90 – Toronto, Canada

  3. Revision History • Vancouver 2012 - Revision 0 Proposed as a BCP for Content Delivery via Multicast Across CDN Interconnections. • 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 added new use (section 3.5) & proposed guidelines for each use case in section 3. • London 2014 – Revision 5 added sections 4.1 (Transport & Security) & 4.2 (Routing) Guidelines. • Toronto 2014 – Revision 6 added text in section 4.3 Back-Office Functions: • Guidelines for Provisioning, Accounting & Billing, Logging, & Settlements IETF 90 – Toronto, Canada

  4. Provisioning Guidelines (Section 4.3.1) Recommends Provisioning Support for Multicast Delivery across Peering Points: • Sufficient Capacity over Peering Points • Sufficient Capacity for Connectivity to all Supporting Back Offices • Availability of All Required Protocols • If AD-2 is Not Multicast Enabled (Use Cases 3.4 & 3.5): • EU must have Multicast Client (supplied by AD-1, AD-2, or Application Source) • All AD-2 AMT Relays must have all {S, G} addresses for all relevant Multicast streams • DNS across each AD should enable client GW to locate Optimal AMT Relay (Need to Progress DNS Based AMT Location I-D). IETF 90 – Toronto, Canada

  5. Billing Guidelines (Section 4.3.2) All Multicast Delivery between Pairs of Ads are Associated with the Application Accounts. Supporting Guidelines: • Each Application is Identified via a Unique Identifier • Sharing Customer Accounts between Ads: • AD-2 sets up accounts for its customers • Protected by Login/Password credentials • Information made available to AD-1 for Proper Billing IETF 90 – Toronto, Canada

  6. Logging Guidelines (Section 4.33) Appropriate Logging Information will be Shared between ADs as follows: • Usage Logs per Application (Can be Aggregated per Group – E.g., Videos, Web Pages, Sets of Software) • Security Logs: • Per Security Event (E.g., Cyber Attack) • Aggregated and/or Summarized per Event • Other Relevant Logs: • Access Logs • Application Logs • Syslogs IETF 90 – Toronto, Canada

  7. Settlement Guidelines (Section 4.3.4) Settlements between ADs Relate to: • Aggregation, Collection, & Transport of Data • Billing and Reimbursement Supporting Guidelines: • Settlement Usage Collection may be done: • Per End User • Per Application and/or Application Provider • Aggregated Basis • AD-2 Collects all Relevant Data & Submits Invoices to AD-1 • AD-1 Collects all Relevant Data & Submits Invoices to Application Providers • Rule changes for Charging Values may be done via agreement between ADs. IETF 90 – Toronto, Canada

  8. Next Steps • Complete Section 4 • Request Comments on New Draft Text • Goal – Complete BCP by 1Q15 Need Guidance on Compliance with IETF BCP Formats Thank You IETF 90 – Toronto, Canada

More Related