ATIS 0200010-2012 CDN Interconnection Use Cases And Requirements In A Multi-Party Federation Environment.pdf

《ATIS 0200010-2012 CDN Interconnection Use Cases And Requirements In A Multi-Party Federation Environment.pdf》由会员分享，可在线阅读，更多相关《ATIS 0200010-2012 CDN Interconnection Use Cases And Requirements In A Multi-Party Federation Environment.pdf（76页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-0200010 ATIS Standard on - CDN INTERCONNECTION USE CASES AND REQUIREMENTS IN A MULTI-PARTY FEDERATION ENVIRONMENT As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priorities. Throug

2、h ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lifecycle from

3、design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for the 3rd Gen

4、eration Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit . Notice

5、 of Disclaimer in effect, they band together to form a single large CDN spanning the regions of all the individual SP domains. CDN Federation members are interconnected for this purpose via open interfaces and act as a multi-footprint logical CDN with consistent business arrangements. CDN Federation

6、 members are governed by the rules of the Federation, which stipulate the method by which content delivery requests are handled between members, the logs members need to keep, the method for sharing logs between members, and how requests are metered and represented in the logs. The simplest Federati

7、on concept envisions a fully meshed set of interconnections between all CDN Provider members with bi-lateral agreements between individual member pairs resulting in n x (n 1) agreements in a Federation of n members (Figure 1). These agreements stipulate how settlements (if any) are organized based o

8、n the CDN transfer logs and business agreements define how to interpret those logs for settlements. ATIS-0200010 5 CDN 1 CDN 2CDN 3 CDN 4Figure 1 - Fully Meshed Multi-Party CDN Other configurations are also being contemplated most notably, a Federation having a centralized third party broker or exch

9、ange involved in some of the content distribution functionality (Figure 2). ATIS-0200010 6 CDN 1 CDN 2CDN 3 CDN 43rdParty EntityFigure 2 - Multi-Party CDN Federation with a Third Party Exchange The role of a third party may be that of an exchange whereby each SP/CDN engages in a relationship only wi

10、th the exchange for the purpose of content delivery rather than having bi-lateral agreements with each other. Alternately, the third party may be that of a broker acting as a proxy for determining where best to obtain content when requested by EUs and assign the responsible CDNs for completing that

11、request. The scope of this document is restricted to the fully meshed Multi-Party CDN Federation only. Other forms including possible third party arrangements are for further study. The roles of CDN Providers as either Primary CDN (P-CDN) or Supporting CDN (S-CDN) were described in a two-party envir

12、onment in ATIS-0200003. The roles in a fully meshed Multi-Party Federation are described in the following figure. ATIS-0200010 7 CDN 1 CDN 2CDN 3 CDN 4CP 1CP 3CP 2CP 4EU 1 EU 2EU 3 EU 4Figure 3 - Roles of CDN Providers There are four CDN Providers depicted here with a fully meshed set of interconnec

13、tions in this Federation assumed to represent four different geographic regions. Each CDN is contracted by one CP for the purpose of delivering that CPs content whenever and wherever requested (CP i CDNi, i = 1, 2, 3, 4). One EU is also depicted in each region: EU i Region i, i = 1, 2, 3, 4. The rol

14、e played by a CDN as either a P-CDN or S-CDN depends entirely on the nature of the content request generated by any of the EUs. The following scenarios illustrate the role of the CDNs. Scenario 1 EU 4 in Region 4 requests content from the website of CP 1 in Region 1. CP 1 has a relationship establis

15、hed with CDN 1 for the purpose of distributing content to EUs. CP 1 passes the request for delivery to CDN 1. CDN 1 therefore plays the role of P-CDN for this specific content delivery request. As the P-CDN, CDN 1 determines that EU 4 is in Region 4 and hence, determines that the most convenient met

16、hod for delivering content would be to pass the request on the CDN 4. CDN 4 thus plays the role of S-CDN. In this role, CDN 4 completes the request by delivering the content to EU 4. The method of delivery could be either: o Cache/Unicast Content is assumed to be transferred from CP 1 origin to CDN

17、1 (serving as P-CDN) origin/cache to CDN 4 (serving as S-CDN) origin/cache and finally to EU 4. The Cache/Unicast delivery process is described in section 7 and the routing process is described in section 9. o Multicast Content is assumed to be transferred to the Multicast source in CDN 1 (serving a

18、s P-CDN). From there, the content is transported via Multicast means through the interconnection between CDN 1 and CDN 4 (serving here as S-CDN) and eventually delivered to EU 4. The precise nature of Multicast may be end-to-end Native Multicast or via the use of Automatic ATIS-0200010 8 Multicast T

19、unnels (AMT) as appropriate. The Multicast process is described in section 8 and section 9. Scenario 2 EU 1 in Region 1 requests content from the website of CP 2 in Region 2. CP 2 has a relationship established with CDN 2 for the purpose of distributing content to EUs. CP 2 passes the request for de

20、livery to CDN 2. CDN 2 therefore plays the role of P-CDN for this specific content delivery request. As the P-CDN, CDN 2 determines that EU 1 is in Region 1 and hence, determines that the most convenient method for delivering content would be to pass the request on the CDN 1. CDN 1 thus plays the ro

21、le of S-CDN. In this role, CDN 1 completes the request by delivering the content to EU 1. In the above two scenarios, CDN 1 plays the role of P-CDN in the first content request and then plays the role of S-CDN for the second content request. The Primary or Supporting role for a CDN is thus determine

22、d by the nature of individual EU requests and the relationship of the corresponding CP from whom the content s requested with members of the CDN Federation. For the purpose of this document, the basic assumptions for SPs banding together as CDN members in a fully meshed CDN Federation are stated as

23、follows: The general structure of agreements between individual members is assumed to have common elements for the purpose of interconnecting CDN members tasked with distributing content to EUs. However, each pair of CDN members in the Federation may introduce specific aspects that are unique for th

24、e purpose of content delivery. At least one method of content delivery Cache/Unicast or Multicast is assumed to be available for all members of the CDN Federation. Information to be shared between pairs of CDN members in the Federation is assumed to be limited to facilitate content delivery between

25、them and to maintain proper interconnections for this purpose. It is also assumed that other types of information deemed to be beneficial to Federation members (e.g., security monitoring updates about cyber attacks) may also be shared as appropriate. Information that is proprietary and not pertinent

26、 for content delivery (SP network operations, general resource planning, and implementation) does not have to be shared or exposed. Resource planning and decision making to facilitate and improve content delivery is assumed to be “localized” between pairs of CDN Federation members. Each CDN Provider

27、 may engage with other members of the Federation to ensure that sufficient resources are available for efficient delivery of content requests. The knowledge of such planning is assumed to be “localized” to the impacted CDN members and is thus not considered to be available to all members of the CDN

28、Federation. Thus, a truly globalized optimization of resource planning and decision making supporting content delivery over the entire CDN Federation may not be feasible for this fully meshed Multi-Party environment. A global optimization may become feasible if resource needs/requests/inputs from al

29、l Federation members can be received and processed either through a third party entity such as a Broker/Exchange or some other means. Methods for achieving globally optimized CDN Federation processes are for further study. Section 6 provides an overview of the entire Life Cycle of activity within a

30、Multi-Party CDN environment. Cache/Unicast and Multicast delivery mode discussions are provided in sections 7 and 8. Finally, the descriptions and requirements supporting the interconnection functionality between pairs of CDN Providers are described in section 9. Note that the protocol development w

31、ork to support the CDN interconnection functionality is being developed in the IETF a brief summary is provided in Appendix A. 6 Life Cycle Use Cases/Requirements in Multi-Party Environment Life cycle Use Cases and Requirements were initially provided in: ATIS-0200003 This document was developed wit

32、h a narrow focus limited to Cache-based distribution of Software Download as a content type. The Use Cases in ATIS-0200003 reflected this limited scope. ATIS-0200010 9 ATIS-0200004 This document was focused on multicast-based content delivery. The Use Cases in ATIS-0200004 were strictly limited to m

33、ulticast issues. The Use Cases described in this section are based on the original set from ATIS-0200003 see Figure 4. However they have been generalized from a delivery mode perspective they apply equally towards Cache as well as Multicast delivery modes. They have also been generalized to apply to

34、wards all types of content (in addition to Software Download). However, the specific Use Cases for Multicast-based Life Cycle operations based on ATIS-0200004 have been retained and are described in Section 8. CDN Life Cycle Use Case AreasOn BoardingTerminationCertification, capabilities, etc.Load f

35、eedback, log, new capabilities, capacity, price actions, operations outages, notification, etc.Purge, settlementsActive/interconnected EnvironmentPre-salePost-saleContent Delivery End ContractPostmortemCapabilities, reservation, trialOn-boarding, TestingAdditional however, the change is not actually

36、 realized. Failure RecoveryP-CDN resubmits change request. : RequirementsR1: P-CDNs shall specify constraints of distribution for each content item: : Geographic. Jurisdictional. No earlier than, no later than a point in time agreed to per agreement. R2: P-CDNs shall submit to all S-CDNs content upd

37、ates either singularly or in batch mode. R3: P-CDNs shall provide the following information for each added or modified content item to all S-CDNs: url associated with a server from which the content may be fetched. url for, or direct specification of, service-level delivery constraints (these constr

38、aints may include TTL information). url for, or direct specification of, network-level delivery constraints. Specified date/time by which the S-CDN shall fetch the content. Specified date/time at a new url or current url by which the S-CDN shall check for updated version of content. A ”label” associ

39、ated with the content item. R4: All S-CDNs shall authenticate constraints referred to by url (or multiple urls). All S-CDNs shall deliver the content on the combined rule set (e.g., rules from the Content Provider, rules from the Content Owner, rules from the P-CDN). R5: All relevant P-CDNs shall re

40、quest to S-CDN partners for suspension of delivery or deletion of content items or replacement of content items either singularly or in batch mode. Suspension of delivery or deletion or replacement shall include data elements for: Indicating by when suspension/deletion/replacement must occur. Option

41、ally, a ”label” value or values associated with content items that are to be deleted. ATIS-0200010 19 R6: All relevant P-CDNs shall indicate to S-CDN partners, limits on delivery capacity across a collection of content items: The number of simultaneous downloads. The total byte rate across content i

42、tems averaged over some period of time. R7: All relevant P-CDNs shall request or modify storage capacity reservation expressed in bytes to S-CDN partners. It is up to the P-CDN and S-CDN agreement to define what this capacity reservation refers to: Only the origin/master copies in the S-CDN. Origin/

43、master copies and additionally cached copies in the S-CDN. Optionally, geographic constraints may be taken into account based per agreement. R8: For any request from a P-CDN, all partnering S-CDNs shall immediately acknowledge the request and subsequently inform the P-CDN when the action is complete

44、d or provide cause information in the case of unsuccessful completion. R9: An S-CDN fetching of specific content (per R4 above) from a P-CDN server shall not interfere with activity over any of the other interfaces (e.g., content delivery requests, logging, etc.). R10: All requests for change shall

45、have a transaction identifier. R11: Under failure recovery, the request process shall point to the transaction identifier of the original request. R12: Change requests may allow for specification of date/time for request implementation. 6.2.4 Content Delivery to End User NOTE: Specific aspects relat

46、ed to Multicast based content delivery are provided in section 8.1. Actors: End User, Content Provider, and Primary and Supporting CDN Providers. Goals: Deliver content to End User as a result of EU request to the CP. Assumptions1. The Content Provider has established an agreement for content distri

47、bution with one or more Primary CDN Providers. : 2. End User requests content from CP. 3. The content delivery can be done via Cache/Unicast (see section 7) or Multicast modes (see section 8). 4. S-CDN will collect content delivery information in appropriate logs. Success ScenarioContent is successf

48、ully delivered via Cache/Unicast (section 7) or Multicast (section 8) modes. The S-CDN also logs information on the content delivery attempt. : Failure ConditionsExactly what “failure” means with respect to content delivery is left up to individual P-CDN - S-CDN agreements. The intent here is to add

49、ress ultimate inability of the S-CDN to deliver a particular content item as requested by a particular end user. Before failure is determined, it may be that the end user has made multiple requests for the same delivery, and/or the S-CDN has tried multiple delivery options. Such delivery attempts may even involve subordinate S-CDNs, in which case content distribution rights must still be honored, and other constraints observed (e.g., a limit on the number of CDN application level “hops”) as per t