ATIS 0200003-2011 CDN Interconnection Use Case Specification and High Level Requirements.pdf

1、 TECHNICAL REPORT ATIS-0200003 CDN INTERCONNECTION USE CASE SPECIFICATION AND HIGH LEVEL REQUIREMENTS ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communicati

2、ons industry. More than 200 companies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging

3、 Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd

4、Generation Partnership Project (3GPP), 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). ATIS is accredited by the American National Standards Institute

5、 (ANSI). For more information, please visit . Notice of Disclaimer 2. Provide applications with appropriate network QoS guarantees for inter-application communication and for communication between the application(s) and the end user(s); and 3. Provide for application placement strategies to enable d

6、ependable compute and storage environments. When regional cloud infrastructures are deployed by network service providers, these network service providers can monetize networking resources for differentiated cloud services. By combining their networking resources with compute and storage offerings,

7、the network service providers can offer end-to-end service SLAs with higher quality than Internet-based connectivity; can reduce, control, and/or ATIS-0200003 5 delay network-capacity upgrades; and/or can control the costs for transmitting data between network service providers (i.e., peering costs)

8、 to support distributed and networked applications. For regional clouds (operated by network service providers) to be positioned more attractively to global or multi-regional subscribers, a federation of multiple clouds with (potentially) global reach becomes interesting, especially when considering

9、 their large, user base. In this architecture, regional cloud providers leverage their storage-, computing-, networking resources; peering relationships; policies with respect to application and/or content delivery as set forth by the AP and/or CP; and jointly offer an attractive cloud solution when

10、 compared to more traditional “over-the-top” cloud providers. On one hand, a federated cloud combines resources managed by regional cloud providers to create a (potentially) global compute solution and, on the other hand, enables regional cloud providers to share revenue earned and expenses incurred

11、 to operate those joint resources. Applications run on and resources managed by a federated cloud are, by their nature, dynamic and the resource availability changes over time. It is thus required that the federated cloud operating model exploits the dynamicity of application demand and resource ava

12、ilability to enable efficient and/or even optimal application-hosting decisions. This places particular demands on the federated management of said resources. A federated cloud also requires a system to settle charges between regional cloud partners and end users. Billing strategies akin those defin

13、ed by other standardization organizations may be applicable as a method to combine delivery of paid applications and/or content from a federated cloud towards the end users and to settle charges between regional-cloud providers organized in a federated cloud. Lastly and moreover, any application tha

14、t is to be hosted on a federated cloud consists of the application itself; the information on which it operates (i.e., storage); an application management function that activates, controls, and stops application instances, and manages the associated storage, networking, and CPU resources; and reques

15、t-routing functions directing end users to the appropriate application instances. While the overall goal of ATIS Cloud Services Forum (CSF) addresses a standard for federated clouds, it was decided to standardize an interconnected Content Distribution Network (CDN) application as a first example and

16、 stepping stone towards federated clouds. The reason for this is that many of the challenges of a federated cloud are yet unknown, and understanding the intricacies of interconnecting a relatively simple cloud application such as a peer-peer CDN will help to understand the issues and challenges of a

17、 federated cloud. Fundamentally, there is no difference between a distributed application provided for by an AP and a CDN application used for distributing content for CPs across a network. In both cases, end users connect to an application instance that executes on some data center, connected by so

18、me network and may use request-routing functions to find the appropriate application instance. The difference is that in the case of a CP, the application is fixed: the CDN distributed application. For the purposes of this work, we further narrow the scope to a Primary CDN (P-CDN) operator and one S

19、upporting CDN (S-CDN) operator, with the primary focus being a joint CDN application. This application caches content for CPs, and can be disseminated to the federated clouds end users. The purpose of this ATIS Standard/Technical Report is to lay the initial groundwork and foundation upon which solu

20、tions to the above questions can be satisfactorily derived in future documents. Accordingly, the remaining scope of this document is limited to the following: 1. Development of a set of use cases describing the life cycle interactions between: a. CPs and P-CDN providers. ATIS-0200003 6 b. One P-CDN

21、and one S-CDN Provider. 2. Deriving a set of requirements that focus on the interaction between the P-CDN and the S-CDN in support of the use cases 3. Examine the life cycle development by utilizing a relatively “simple” form of content distribution that is limited to software downloads. The assumpt

22、ion is that such types of content delivery may not require extensive authentication and authorization processes between the P-CDN and S-CDNs. And yet, it is expected that the vast majority of useful interaction requirements can be derived from this limited set of content delivery. Specific aspects o

23、f more complex types of content will be addressed in future documents. 4. The type of content delivery is limited to the use of caches within the respective CDNs this is referred to as the cache model. Other types of content delivery mechanisms (e.g., multicast model which is applicable for delivery

24、 of live streaming content) will be pursued in later documents. This ATIS Standard/Technical Report thus provides the basis for a CDN application in a federated cloud between one P-CDN and one S-CDN. Future documents extend the interaction requirements to multiple regional cloud providers operating

25、within a federated cloud offering a joint CDN application. In doing so, relevant work from other Standards Development Organizations (SDOs) are folded into ATIS work as appropriate. 2 REFERENCES 2.1 Normative References The following standards contain provisions which, through reference in this text

26、, constitute provisions of this ATIS Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this ATIS Standard are encouraged to investigate the possibility of applying the most recent editions of the standar

27、ds indicated below. RFC 2168 IETF RFC 2168, Resolution of Uniform Resource Identifiers using the Domain Name System (1997).1RFC 2616 IETF RFC 2616, Hypertext Transfer Protocol HTTP/1.1 (1999).12.2 Informative References Global Global Content Delivery Market to Reach $4.7B by 2015 (June 2011), Global

28、 Industry Analysts Inc., http:/ 1This document is available from the Internet Engineering Task Force (IETF). ATIS-0200003 7 3 DEFINITIONS Content: Information (video, audio, images, hypertext, graphics, data sets, etc.), software, and related metadata stored and delivered digitally to End Users. Con

29、tent Vault: The source of record within the content providers environment for content files and metadata. Content Cache Front End: A node within the network that brokers incoming content requests to either the Content Vault or Content Cache. Content Cache: A node within the network that delivers rep

30、licated content to the end user. Content Provider (CP): The entity that owns or is licensed to distribute and/or sell content or content assets. Although the relevant CDN Provider (Primary or Supporting) delivers content to End Users, a direct logical information flow may be set up between Content P

31、rovider and End User - e.g., for rights management and protection or purchasing content. CDN Interconnection: An established relationship between two CDN providers that covers aspects like network connectivity, content provisioning, content distribution, service assurance, billing, and agreements. E

32、nd Users: Any person or device that is retrieving content from CDN. Retrieval may occur using a variety of devices and access technologies. Federated Cloud Infrastructure: An infrastructure that comprises all physical resources in terms of data centers (compute, storage, connectivity), and wide-area

33、 networking, owned and operated by a plurality of entities and integrated into a single logically interconnected compute and storage substrate, combined with (distributed) operational, administrative, and management functions and additional software assets to provide secure and dependable compute an

34、d storage solutions for end users and/or enterprises (“subscribers”). Primary CDN Provider: A CDN Provider that has an agreement with a CP to store and deliver content to End Users on the CPs behalf. The Primary CDN delivery system usually is composed of access networks and core or backbone networks

35、, using a variety of network technologies. Supporting CDN Provider: A Service Provider who partners with a Primary CDN Provider, to store and distribute content to End Users on behalf of the Primary CDN Provider. The Supporting CDN Provider may, for example, have a different geographic footprint tha

36、n the Primary. 4 ACRONYMS or the end user could be physically attached to an access network that is distinct from but connected to the S-CDN; or there could be a series of entities involved in a string of content licensing agreements. Multiple roles could be performed by the same business entity. Wh

37、at is important to appreciate is that some of the needs of the CP influence the nature of the P-CDN S-CDN interconnection. For example, the following as agreed in an SLA between the CP and P-CDN must also be reflected in the P-CDN S-CDN relationship. QoS conditions of delivery. Restrictions on distr

38、ibution - e.g., based on User location or date/time (no earlier/later than). Means by which the CP can validate that rules/conditions it specifies are being followed. Rights for redistribution. Rules for authentication and authorization. ATIS-0200003 13 There are many elements of CDN that apply in a

39、 broader way to Cloud based services. The SPI model has Infrastructure as a Services (IaaS) as a foundation, Platform as a Service (PaaS), which then establishes a development platform and structure for the deployment of Software as a Service (SaaS). An SaaS application expects to be able to signal

40、to the “network” and ask for a number of key information elements to arrive at the optimal user experience. CDN establishes a foundation for the use of content routing, application and content proximity, and signaling of other services from the “network” to the application and PaaS to insure that fi

41、rst the network can deliver the service and second, when the service is delivered, it is measured, requested, delivered, and operated optimally due to signaling and smart interaction from network visibility, control, and optimization. 6 CDN DELIVERY BETWEEN CARRIERS 6.1 Current Mode of Operations Th

42、e current mode of operations does not involve interconnections between CDN providers. End Users desiring content are directed to the CDN Provider that hosts the content regardless of proximity to their geographical location or whether the CDN serves as their access provider or not. The process is as

43、 follows: CDN Provider-1s users go to CDN Provider-2 to get the content hosted by CDN Provider-2s CDN. Similarly CDN Provider-2s users go to CDN Provider-1 to get the content hosted by CDN Provider-1s CDN. The content is delivered from a distant node and must traverse both carriers network. Each use

44、r gets its own copy even if content is the same as another user. The disadvantages of the current mode of operations thus involve significant inefficiencies as follows: Network build out cost: o User content data must traverse both carriers network. o Each user gets his/her own copy of data. o Very

45、high cost for network connectivity in some parts of the world. Network capacity: o Network can run out of capacity for unexpected load events. o Undersea capacity can severely limit the CDN capacity in the event of failures for most of the world. Higher delays: o The data is delivered from a distanc

46、e node. Peering imbalance: o Significant peering imbalance can exist depending on the number of users and hosted content free peering model becomes an issue. ATIS-0200003 14 6.2 CDN Interconnection between Carriers Cache Model The inefficiencies as described in section 6.1 are primarily due to the f

47、act that End Users have to obtain content from CDN Providers who are not their primary network access providers. Geographic proximity is the main cause. These inefficiencies can be significantly reduced when CDN Providers form interconnection relationships which can be either Peer-Peer between two C

48、DNs or in a multiple CN-I relationship involving multiple CNs offering CDN as an application. The basic method of interconnection involves use of Cache servers shown in Figure 4 below. Figure 4: Peer-Peer Interconnection Between 2 CDNs The interconnection permits End Users to receive content as foll

49、ows: Users wishing to obtain content address the local CDN service operating in the providers CN. Supporting CDN Providers nodes (e.g., CDN Provider-2s nodes) retrieves the content from the origin servers hosted by the Primary CDN Provider (e.g., CDN Provider-1) if the content is not in cache. Once received, the Supporting CDN Provider stores the content in cache further diminishing need for repeated requests. Alternately, Supporting CDN Provider