IETF cdni Zhou Internet-Draft Huawei Technologies, Inc. Intended status: Informational Jul 04, 2011 Expires: January 5, 2012 CDNI use case draft-zhou-cdni-use-case-00 Abstract Industry needs the CDN interconnection to provide the CDN service that may cover a wider geographical area and a better service quality. In the real pragmatic operation, the relationship between two CDNs should concern many factors(for instance, CDN or CP may select the downstream CDN based on some principals or conditions or service authorizations), hence the CDN interconnection is defacto a sort of constrained interconnection. This document will give the use cases to indicate the models of how the CDN interconnection may be used and the associated examples for the use cases will be listed subsequently. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Zhou Expires January 5, 2012 [Page 1] Internet-Draft CDNI use case Jul 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture for CDN-I Service . . . . . . . . . . . . . . . . 3 4. Operating Requirements on CDN Interconnection . . . . . . . . . 3 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. CDN authorization . . . . . . . . . . . . . . . . . . . . . 4 5.2. Constraint for Content . . . . . . . . . . . . . . . . . . 6 5.3. Content Adaptation . . . . . . . . . . . . . . . . . . . . 6 6. Application Example . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Zhou Expires January 5, 2012 [Page 2] Internet-Draft CDNI use case Jul 2011 1. Introduction [I- D.bertrand-cdni-use-cases] has provided some basic use cases for CDN Interconnection. While it has not talked about how CDN-A may interconnect CDN-B as its downstream CDN(e.g. How the downstream CDN is selected; what operation rule(business rule) should be taken into account on service of CDN interconnection). This draft gives some use cases concerning the operation of multiple CDN federation and as a result some examples are provides. 2. Terminology Roughly, this document may refer the terminology defined in section 1.1 of [I-D.jenkins-cdni-problem-statement] and [I-D.bertrand-cdni- use-cases]. . 3. Architecture for CDN-I Service Following, a general service architecture of CDN interconnection is listed as Figure 1: +-------+ +-------+ +-------+ +-------+ | CSP |-------| CDN-A |------| CDN-B |------| UE | +-------+ | +-------+ +-------+ +-------+ | \______________/ | | / \ | | +-------+ +-------+ | |___| CDN-C |______| CDN-D |__________| +-------+ +-------+ Figure 1. Typical Architecture for CDN interconnection This is just a typical architecture of CDN interconnection. The CSP may connect multiple CDNs and a upstream CDN may connect multiple downstream CDNs(such as CDN-A may connect either CDN-B or CDN-D; similarly to CDN-C) This figure is used for the following discussion of use cases while in reality it may be possible that the CSP only select one delegate CDN or a upstream CDN may only have one downstream CDN. 4. Operating Requirements on CDN Interconnection In the real operation, some basic requirements of CDN-I service based Zhou Expires January 5, 2012 [Page 3] Internet-Draft CDNI use case Jul 2011 on service operating should be abided, including: Authorization area for CDN provider: the CDN provider may only provide CDN service in a specific area, such as CDN-A may only serve in Beijing and CDN-B may only serve in Shanghai. Such authorization may be determined by CSP or by upstream CDN for the downstream CDN. And such authorization is because of the business model(for example to protect the business of authorized CDN service provider). Therefore the associated policy should be supported in the CDN interconnection. Constraint of service by content: the access area or access period of specific content may be constrained in content service. For example the movie in a Chinese video website may only be accessed by the terminals located in China mainland and if being overseas the request for the movie service will be rejected. The rule in this use case comes from the content rights operation and should be conducted by the CDN service provider. Content adaptation: the fromat of content service may be converted according to the terminal's capability or consumer's application. For example converting multicast (or unicast) RTP streams to HTTP streaming and then delivering the adaptive stream to terminals( refer to MCD CDN-I use case and requirement). For implementation of CDN service, it is optimum maintaining and delivering one format of content within CDN system while providing the adaptive streaming service on the interface between CDN and terminals. The content adaptation may be deployed on a node of the CDN or CDN-I system as a functionality. Totally the requirements above are usual rules of content service operating and are also applicable for CDN-I use cases. 5. Use Cases In this section, three Use Cases to realize the requirements are described along with examples. 5.1. CDN authorization In this use case, the CP may make a list of pairs of CDN and its authorized service area. For example: Zhou Expires January 5, 2012 [Page 4] Internet-Draft CDNI use case Jul 2011 _____________________________ | CDN Provider | Service Area | |______________|______________| | CDN-A | Beijing | |______________|______________| | CDN-B | Shanghai | |______________|______________| | CDN-C | Guangdong | |______________|______________| | .... | .... | |______________|______________| | CDN-Z | Tianjing | |______________|______________| | CDN-HK | Hongkong | |______________|______________| Figure 2: Example List of CDN Authorization Areas The list of CDN authorization areas may be created by the CP and be kept by all CDNs. When delivering content, CDN may refer to this list to determine with which CDN it has to connect. Here gives two sub-cases: Sub-Case one: for the unicast service, when the CP receives a content request from a UE located in Beijing, CP will redirect that request to CDN-A. CDN-A then will check whether the requested content is available locally. If yes, then provide the content to the requesting UE, else if the content at that time is only stored in Tianjing and Guangdong, CDN-A will contact CDN-Z or CDN-C getting that content and at last issue that content to the UE. Sub-Case two: for the broadcast service, the content broadcast route may be designed based on the geographical relationship of each area. For example Tianjing is very near to Beijing. If the CP is also located in Beijing, for the content broadcast, the content may be delivered from CP to CDN-A first and CDN-A will then forward the content to CDN-Z. In the same way, the content to CDN-HK may be forwarded from CDN-C since Hongkong is near to Guangdong. To design such transport route should consider the transport efficiency, neither overlap nor neglect an area. Further, if concern there are possibly multiple CDNs in an area, for example CDN-Ax and CDN-Ay both serve in Beijing, there should be an entity coordinating these two CDNs(CDN-Ax and CDN-Ay) and contacting other CDNs outside of Beijing. Or probably each CDN in the same area is responsible for different services, e.g. CDN-Ax serves for Mobile request and CDN-Bx serves for request of IPTV service. Zhou Expires January 5, 2012 [Page 5] Internet-Draft CDNI use case Jul 2011 The arrangement above may be seen as a typical deployment policy( may be benefical for both efficienty and business cooperation). The core issue is to keep all CDNs complying with the same policy. 5.2. Constraint for Content The arrangement of content publishing/content service is another typical policy controlled by CP. For example, the rights of OlympicGame in 2008 for live broadcast in China Mainland was purchased by CCTV and all related content may only be accessed in China Mainland. Hereby a terminal from outside Mainland of China such as Hongkong is prohibited to access the live Olympic broadcast or video on demand issued from CCTV during Olympic period(Hongkong users may access Olympic content from another content provider locally in Hongkong). Hence for all the CDNs within China during Olympic period, the content forward should abide this constriction. If broadcast both Movie-A and OlympicGame B, CDN-C should deliver content of Movie-A to CDN-HK but should not deliver content of OlympicGame B to CDN-HK. ________________________________________________ | Content Name | Service Area | Service Period | |______________|______________|__________________| | Movie-A | China | 2009.01--2009.12 | |______________|______________|__________________| |OlympicGame B |China Mainland| 2008.08--2008.10 | |______________|______________|__________________| Figure 3: Example List of Constraint for Content When the service period expires, the CDNs should remove the related content. This constraint in fact has controlled the broadcast service as a limited broadcast. This is another typical use case of broadcast or multicast over CDN interconnection. 5.3. Content Adaptation To support the diversity of terminals and the fluctuant network band width, adaptation measures may be conducted for the content services. While for the CDN operator, it is better only to maintain minimum(only one) content format(s). So, one solution is to transform the content format prior to delivery. It means the content forwarded between CDNs may be RTP streams of best quality( e.g. HD video and Hi-Fi audio) while the RTP stream may be transformed to adaptive streaming to serve for user. One possible realization is that the delivering CDN which is nearest to the UE performs such delivery format adaptation according to the UE's capabilities. The Zhou Expires January 5, 2012 [Page 6] Internet-Draft CDNI use case Jul 2011 adaptation may include, but is not limited to, conversion to adaptive streaming, the transport format conversion, codec type conversion, content encapsulation conversion and content metadata conversion (e.g. content description, program information, etc). For example, content is delivered from Content Provider through CDN-A to CDN-B in the form of normal RTP streams. The delivering CDN, CDN-B, determines that a UE requires the content to be delivered using adaptive HTTP streaming, CDN-B now transforms the RTP streams to an adaptive HTTP stream that can be delivered to the UE. See as figure 4: +-------+ RTP Streams +-------+ RTP Streams +-------+ | CSP |------------>| CDN-A |------------>| CDN-B | +-------+ +-------+ +-------+ |Converted to |HTTP Streaming | +-------+ -------------->| UE | +-------+ Figure 4. Example of Content Adaptation This use case is applicable for either broadcase or unicast service. 6. Application Example Taking TISPAN CDN architecture as example in this section, a full implementary instance for broadcast service performing the operating requirements is given as below: +------------+ +-------------+ | ALF/CDN-A |--------- | ALF /CDN-Z | +------------+ +-------------+ | | | | +-------+ 1) +-----------+ 4) +-----------+ | CSP |-------|CDNCF/CDN-A|-----------|CDNCF/CDN-Z| +-------+ +-----------+ +-----------+ | \ 2)| 5)| | 3)\ +-------------+ 6) +-------------+ | \___ |CLUSTER/CDN-A|-------- |CLUSTER/CDN-Z| 7)| +-------------+ +-------------+ | | +-------+ 8) | | UE |------------------------------------- +-------+ Figure 5: Example of Broadcast Service via CDN Interconnection Zhou Expires January 5, 2012 [Page 7] Internet-Draft CDNI use case Jul 2011 Execution steps for this procedure may be as following: step 1: CSP informs to broadcast the content. step 2: CDNCF in CDN-A informs its clusters to receive/get the content( sports game with HD video format). step 3: Cluster in CDN-A receives/gets the content from CSP. step 4: CDNCF in CDN-A informs another CDNCF in CDN-Z to receive/get the content from the cluster in CDN-A. step 5: CDNCF in CDN-Z informs its clusters to receive/get the content from CDN-A. step 6: cluster in CDN-Z receives/gets the content from cluster in CDN-A. step 7: A UE in Tianjing subscribes the broadcast service. Through a general CDN procedure, the UE is informed the address of cluster under CDN-Z where UE may receive the broadcast content. Additionally, CDN-Z may provide HTTP adaptive streaming and the content received from CDN-A is transformed in adaptive streaming for the UE. step 8: UE receives the broadcast service from CDN-Z. 7. Security Considerations The involved service information should be guaranteed unchanged. More detail may be provided later. 8. IANA Considerations This document requires no actions from IANA. 9. Acknowledgements Many thanks to all the members of Huawei Software CDN project team and all the friends met in the CDN standard meetings. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Zhou Expires January 5, 2012 [Page 8] Internet-Draft CDNI use case Jul 2011 Requirement Levels", BCP 14, RFC 2119, March 1997. [TISPAN] ETSI TISPAN, "CDN Architecture(ETSI TS 182 019)". [MCD] ETSI MCD, "Media CDN Interconnection, use cases and requirements(ETSI TS 102 990)". [IETF-CDNI] IETF CDNI, "[Draft-bertrand-cdni-use-cases]". Author's Address Zhipeng Zhou Huawei Technologies, Inc. No.101, Software Avenue,Yuhuatai District Nanjing 210012 P.R.China Phone: +86-25-56620690 Email: zhouzp@huawei.com Zhou Expires January 5, 2012 [Page 9]