CDNI Working Group Xiaoyan.He Internet Draft Spencer.Dawkins Intended status: Standards Track Huawei Expires: September 2012 Ge.Chen China Telecom Yunfei.Zhang Wei.Ni China Mobile March 6, 2012 Capability Information Advertising for CDN Interconnection draft-he-cdni-cap-info-advertising-01.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the He et all Expires September 6, 2012 [Page 1] Internet-Draft cap-info-advertising March 2012 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 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. Abstract This document describes protocol for capability information advertising which is used to communicate capability and status information among interconnected Content Delivery Networks (CDNs). Table of Contents 1. Introduction ................................................ 3 1.1. Terminology ............................................ 3 1.2. Place of capability advertising in CDNI model ........... 3 2. Conventions used in this document ............................ 5 3. CDN selection criteria ...................................... 5 4. Description of information ................................... 6 4.1. General information .................................... 6 4.1.1. Service status .................................... 6 4.1.2. IP version ........................................ 7 4.2. Footprint .............................................. 7 4.3. Load status ............................................ 7 4.3.1. Basic serving indicator ............................ 8 4.3.2. Detailed resource status........................... 8 4.4. Cost preferences ....................................... 8 4.5. Authentication capability ............................... 9 4.6. Delivery service capability ............................ 10 5. Overview of the capability advertising protocol ............. 10 5.1. Transport mechansim of the protocol .................... 10 5.2. Opration mode of the protocol .......................... 10 5.3. Discovery of the protocol contact point ................ 11 6. Protocol Specification ..................................... 11 6.1. Encoding of downstream CDN information ................. 11 He et all Expires September 6, 2012 [Page 2] Internet-Draft cap-info-advertising March 2012 6.1.1. Load status object ................................ 11 6.1.2. Cost object ...................................... 12 6.1.3. Authenticity object ............................... 12 6.1.4. Footprint object .................................. 12 6.1.5. Encoding of general information ................... 13 6.2. Message description ................................... 13 6.2.1. Report mode ...................................... 13 6.2.2. Query mode ....................................... 14 6.3. Message examples ...................................... 14 6.3.1. Report mode ...................................... 14 6.3.2. Query mode ....................................... 16 7. Security Considerations .................................... 17 8. IANA Considerations ........................................ 17 9. References ................................................. 17 9.1. Normative References................................... 17 9.2. Informative References ................................. 18 10. Acknowledgments ........................................... 18 1. Introduction In the context of CDNI, the downstream CDN needs to advertise some of its information to the upstream CDN to facilitate the upstream CDN selecting an appropriate CDN as the target in request routing, such as downstream CDN capabilities, resources and affinities (i.e. Preferences or cost). This document focuses on defining the information needed to be exchanged in CDNI and the corresponding advertising protocol, which is one of the main components of CDNI. 1.1. Terminology This document reuses the terminology defined in [I-D.draft-cdni- problem-statement]. 1.2. Place of capability advertising in CDNI model Figure 1 from [I-D.draft-cdni-problem-statement] illustrating the CDNI model. The capability information advertising protocol is not He et all Expires September 6, 2012 [Page 3] Internet-Draft cap-info-advertising March 2012 explicitly shown. Although that might be changed later upon the working group's decision, but now it is thought that capability advertisement is part of the function of the Request Routing interface. -------- / \ | CSP | \ / -------- * * * /\ * / \ ---------------------- |CDNI| ---------------------- / Upstream CDN \ | | / Downstream CDN \ | +-------------+ | Control Interface| +-------------+ | |******* Control |<======|====|========>| Control *******| |* +------*----*-+ | | | | +-*----*------+ *| |* * * | | | | * * *| |* +------*------+ | Logging Interface| +------*------+ *| |* ***** Logging |<======|====|========>| Logging ***** *| |* * +-*-----------+ | | | | +-----------*-+ * *| |* * * * | Request Routing | * * * *| .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . . |* * * +-------------+.| | | | +-------------+ * * *| . . |* * * . CDNI Metadata | * * *| . . |* * * +-------------+ |. Interface | +-------------+ * * *| . . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . . |* * * | | | . \ / | | | * * *| . . |* * * |+---------+ | | . \/ | | +---------+| * * *| . . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . . |******* +---------+| | Acquisition | |+----------+ *******| . . | +-------------+ | | +-------*-----+ | . . \ / \ * / . . ---------------------- ---------*------------ . . * . . * Delivery . . * . . +--*---+ . ...............Request.............................| User |..Request.. | Agent| +------+ <==> interfaces inside the scope of CDNI He et all Expires September 6, 2012 [Page 4] Internet-Draft cap-info-advertising March 2012 **** interfaces outside the scope of CDNI .... interfaces outside the scope of CDNI Figure 1: CDNI Model 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. CDN selection criteria An upstream CDN may perform downstream CDN selection according to different kinds of filtering criteria deriving from CP's requirement and/or its local policy. One kind of criteria is derived from CP's requirement. Each CP is most likely to expect to control the distribution and delivery of its contents by its delegated CDN. To achieve that, CP reflects its requirements via metadata pertaining to the content and transfer the metadata to the CDN to enforce that. In the context of CDNI, this metadata should also be further transferred to a downstream CDN for the same purpose. Subsequently, while the upstream CDN receving a content request and intends to select an appropriate downstream CDN from multiple ones to redirect the request, it should filter the downstream CDNs according the metadata, e.g. in the metadata, it is required the content should be delivered via HTTP adaptive streaming service, a downstream CDN without the capability should not be selected. Therefore, the required capability contained in the metadata as a source of filtering criteria is needed for CDN selection and is to be advertised from a downstream CDN to an upstream CDN. Another kind of criteria is derived from upstream CDN's local policy. There are various kind of local poicy deployed, e.g. minimal load first, minimal expense first, optimal QoS preferred etc. To implement these policies, relative capability/status information of a downstream CDN should be advertised to its upstream CDN. In addition, general information like service status, IP version of downstream CDN should also be taken into account while making the CDN selection. Based on the above mentioned filtering criteria, we can list the He et all Expires September 6, 2012 [Page 5] Internet-Draft cap-info-advertising March 2012 corresponding capability and status information needed as followings: * General information like the service status, IP version of the downstream CDN is needed. * Footprint of the downstream CDN is needed if proximity is preferred while making routing decision. * Load status of resources is needed if minimal load is preferred while making routing decision. * Cost information of downstream CDN is needed if minimal cost is preferred while making routing decision. * Delivery capability information like delivery service type, user authentication method of downstream CDN is needed if CP's requirements contained in CDNI metadata is the main preference of routing decision. Note: The information needed to be advertised according to the CDNI metadata should be adjusted once protocol on that interface is finalized. 4. Description of information According to the CDN selection criteria listed in section 3, the relative capability and status information advertised from a dwonstream CDN to an interconnected upstream CDN is described in detail in the following clause. The information is considered all as mandatory unless otherwise state explicitly. 4.1. General information 4.1.1. Service status Service status is used to indicate that the downstream CDN is in service or out of service of CDNI. In service means that the downstream CDN's status is normal and it is willing to take requests from an upstream CDN. Out of service means that the downstream CDN can not take any requests from an upstream CDN due to some abnormal cases, e.g.: O Some kind of resource on the downstream CDN is exhausted. O Network link between the two connected CDNs is abnormal. He et all Expires September 6, 2012 [Page 6] Internet-Draft cap-info-advertising March 2012 O Downstream CDN is down. 4.1.2. IP version IP address version of which a downstream CDN can serve for endpoints. The value it takes could be "IPV4", "IPV6" and "IPV4&IPV6" the last one means that the downstream CDN can serve for both the types of endpoints. 4.2. Footprint Footprint indicates the geographic region for which a CDN can serve. It is identified by a set of country, state and city code combination as defined in ISO 3166-2 or a set of autonomous system number or a set of IP subnet. A downstream CDN may advertise its footprint in a macro level e.g. the country names of the serving regions belong to, it may also advertise its footprint in a granularity of subset of the macro level, e.g. detail state or city name of the serving regions. In the later case, if there are multiple regions belong to one country a downstream CDN can serve, then there will be multiple state or city footprint elements in one advertisement message. This finer granularity allows an upstream CDN understand the downstream CDN more precisely but puts more requirements on the downstream CDN. Therefore, it is up to the downstream CDN to determine to which granularity it should advertise to an upstream CDN. Upon each footprint, the other information like load status of resources, capability information described in the following part of this section are encapsulated to express the current status and capabilities associated to this specific region. 4.3. Load status Load status represents the status of resources assigned to an upstream CDN by a downstream CDN and their current usage. This information is important for the upstream CDN to implement the minimal load first local policy. It contains a mandatory binary serving indication to tell the upstream CDN whether the downstream CDN can or cannot serve end users on behalf of the upstream CDN from the perspective of resource load. It can optional contains the detailed contracted and current used value of a specific resource in case that the downstream CDN is willing to advertise such information to the upstream CDN. For example they belong to one group and have a strong trust relationship between them. He et all Expires September 6, 2012 [Page 7] Internet-Draft cap-info-advertising March 2012 4.3.1. Basic serving indicator Basic serving indicator is used to tell whether a downstream CDN has the ability to accept more additional requests from the upstream CDN or not from the perspective of its resource load status. 4.3.2. Detailed resource status Detailed resource status is used to advertise the maximum value of capacity the downstream CDN committed to the upstream CDN and the current assignments of it. This information can be leveraged by the upstream CDN to implement a more accurate CDN selection if there exists multiple candidate downstream CDNs through the previous basic serving indication. It is reflected through the following three category resource in detail: * Connection Allowed, Connection Assigned This information is used to indicate the maximum number of simultaneous TCP connections for HTTP of the downstream CDN committed to provide to the upstream CDN for content delivery and the current used number respectively. * Bandwidth Allowed, Bandwidth Consumed This information is used to indicate the maximum value of bandwidth for content delivery of the downstream CDN committed to provide to the upstream CDN and current used value respectively. Note: The value of "andwidth Allowed" and "Bandwidth Consumed" may be an absolute value taking only the physical bandwidth of the CDN into account or it may be a normalized value which may also consider the disk I/O capacity and CPU usage as a whole. This depends on the CDN specific implementation and is out of scope of CDNI. * Cached Assets Allowed, Cached Assets This information is used to indicate the maximum value of storage capacity of cache of the downstream CDN committed to provide to the upstream CDN and current used value respectively. 4.4. Cost preferences Cost preferences of the downstream CDN. Different downstream CDNs He et all Expires September 6, 2012 [Page 8] Internet-Draft cap-info-advertising March 2012 may characterize cost via various metrics e.g. hop-count, air-miles, or monetary cost. An upstream CDN can negotiate with a downstream CDN on how to characterize cost of CDNI via the attributes "cost type" and "cost mode". Note: The detailed mechanism that the two interconnected CDNs negotiating on the abstract cost assignment is out of scope of this draft. o type: identifies what the costs represent, e.g. hop-count, monetary cost etc; o mode: identifies how the costs should be interpreted. Specifically, the mode attribute indicates whether returned costs should be interpreted as numerical values or ordinal rankings. It is important to communicate such information to the upstream CDN, as certain operations may not be valid on certain costs returned by a downstream CDN. o cost: value of the cost corresponding to the selected type and mode. 4.5. Authentication capability Authentication capability describes the authentication type and relative parameters a downstream CDN supports to the clients. It provides information for content delivery such that the user agent can be authenticated as a client when requesting content from a downstream CDN. The authentication capability contains the following attributes: O type - a string indicating the authorization type "url-signing" or "url-token". The "url-signing" type refers to URL signing authorization. The "url-token" type refers to token-based authorization. O algorithm- a string containing the signature algorithm (e.g. "md5", "sha-1", etc.). He et all Expires September 6, 2012 [Page 9] Internet-Draft cap-info-advertising March 2012 O key type - a boolean if true, URL signing uses symmetric keys, otherwise asymmetric. 4.6. Delivery service capability Type of the delivery service a downstream CDN supports, e.g. Microsoft Smooth Streaming, Apple HTTP Live Streaming. It contains the following attributes: O service type- a string containing the type of the delivery service e.g. "HLS"and "DASH". 5. Overview of the capability advertising protocol 5.1. Transport mechansim of the protocol CDN capability is information coupling with a specified application (CDNI), it should be conveyed via an application layer protocol rather than any other underlying layer protocol e.g. IP layer protocol which should de-coupling with any application. In this document HTTP/1.1 protocol [RFC2616] is used as the transport mechanism for capability information advertising as its a natural choice for integration with existing applications and infrastructure. 5.2. Operation mode of the protocol The capability information advertising protocol takes two modes. One is report mode, where the downstream CDN advertises its capability information to the upstream CDN during at a periodic interval, e.g. every 5 minutes. The other one is query mode, where the upstream CDN acquires the capability information from the downstream CDN periodically, e.g. every 5 minutes. The upstream CDN utilizes the capability information to makes its routing decision upon receiving a content request from an end user. He et all Expires September 6, 2012 [Page 10] Internet-Draft cap-info-advertising March 2012 5.3. Discovery of the protocol contact point To enable communication over the capability information advertising protocol, the two interconnected CDNs need to know each other's contact address. The contact address may be statically pre- configured, dynamically discovered via control interface, or other means. However, they are not specified in this document, as this is considered not in the scope of the CDNI capability information advertising protocol. 6. Protocol Specification This section describes the details of the capability information advertising protocol. 6.1. Encoding of downstream CDN information 6.1.1. Load status object This object defines load status of resources of a downstream CDN described in section 4.3. Object{ JSONInteger ServeStatus; JSONInteger MaxConnection; JSONInteger CurrentConnection; JSONString MaxBandWidth; JSONString CurrentBandWidth; JSONString MaxCacheStorage; JSONString CurrentCacheStorage; }LoadStatus, He et all Expires September 6, 2012 [Page 11] Internet-Draft cap-info-advertising March 2012 6.1.2. Cost object Cost object defines cost preferences described in section 4.4. Object{ JSONString CostType; JSONString CostMode; JSONInteger CostValue; }Cost, 6.1.3. Authenticity object Authenticity object defines authentication capability of a downstream CDN described in section 4.5. Object{ JSONString [AuthType]<1..*>; JSONString [Algo]<1..*>; JSONInteger Symmetric; }Authenticity, 6.1.4. Footprint object Footprint object defines footprint and status, capability associated with the particular area the footprint identified. Footprint is described in section 4.2. Object{ JSONString Country; JSONString State; [OPTIONAL] JSONString City; [OPTIONAL] LoadStatus loadStatus; Cost cost; He et all Expires September 6, 2012 [Page 12] Internet-Draft cap-info-advertising March 2012 Authenticity authenticity; JSONString [DeliveryType]<1..*>; }FootPrint, 6.1.5. Encoding of general information { JSONString ServiceStatus; JSONString [IPVersion]<"IPV4","IPV6">; FootPrint [FootPrint]<0..*>; } 6.2. Message description The HTTP/1.1 protocol is used for capability advertising. The HTTP request is HTTP POST for Report mode and HTTP GET for Query mode respectively. The request URI in both modes conforms to [RFC3986]. The URI format in this document is as follows: HTTP:///, where the specifies a destination, and the conveys the message name. The message body representation specified in this document takeing JavaScript Object Notation(JSON) as example. However, other well- defined representations (e.g., XML) are also acceptable. 6.2.1. Report mode The Downstream CDN issues an HTTP POST message to the Upstream CDN to report its capability information. The message name in the request URI is "CdniCapReport". He et all Expires September 6, 2012 [Page 13] Internet-Draft cap-info-advertising March 2012 The Content-Type header field is "application/json". The message body includes capability information. Upon successful receipt of the POST request, the Upstream CDN responds with a 200 OK message. 6.2.2. Query mode The Upstream CDN issues a HTTP GET message to a Downstream CDN to query its capability information. The message name in the request URI is "CdniCapQuery". Upon successful receipt of the GET request, the Downstream CDN responds a 200 OK message with its capability information. The Content-Type header field for the response is "application/json". 6.3. Message examples This section gives some message examples for capability information advertising protocol. 6.3.1. Report mode The POST request and corresponding response are illustrated as below. Request example (Downstream CDN to Upstream CDN): POST http://contact-address.ucdn.example/CdniCapReport HTTP/1.1 Content-Type: application/json He et all Expires September 6, 2012 [Page 14] Internet-Draft cap-info-advertising March 2012 Content-Length: TBD { "ServiceStatus":"In", "IPVersion":["IPV4","IPV6"], "FootPrint":[ { "Country":"China", "State":"Beijing", "City":"", "LoadStatus":{ "ServeStatus":1, "MaxConnection":5000, "CurrentConnection":1000, "MaxBandWidth":"1500M", "CurrentBandWidth":"1000M", "MaxCacheStorage":"5000TB", "CurrentCacheStorage":"3000TB" }, "Cost":{ "CostType" :"monetary", "CostMode": "ordinal", "CostValue": "1" }, "Authenticity":{ "AuthType":["urlSigning","urlToken"], "Algo":["MD5"], "Symmetric":1 }, "DeliveryType":["HLS","HSS","HDS","RTSP"] },{ "Country":"China", "State":"Guangdong", "City":"", "LoadStatus":{ "ServeStatus":0, "MaxConnection":5000, "CurrentConnection":4900, "MaxBandWidth":"1500M", "CurrentBandWidth":"1450M", He et all Expires September 6, 2012 [Page 15] Internet-Draft cap-info-advertising March 2012 "MaxCacheStorage":"5000TB", "CurrentCacheStorage":"4990TB" }, "Cost":{ "CostType": "monetary", "CostMode": "numerical", "CostValue": "30" }, "Authenticity":{ "AuthType":["urlToken"], "Algo":["SHA1"], "Symmetric":1 }, "DeliveryType":["HLS","HSS","HDS","RTSP"] }] } Response example: HTTP/1.1 200 OK 6.3.2. Query mode The GET request and corresponding response are illustrated as below. Request example (Upstream CDN to Downstream CDN): GET http://contact-address.dcdn.example/CdniCapQuery HTTP/1.1 Response example: HTTP/1.1 200 OK Content-Type: application/json Content-Length: TBD He et all Expires September 6, 2012 [Page 16] Internet-Draft cap-info-advertising March 2012 The content of message body is the same as that of POST message illustrated in section 6.3.1. 7. Security Considerations Capability advertising is a main function which will affect the final routing decision of an upstream CDN, security threats on it include that any identity spoofing of the downstream CDN or changing of the capability advertising message with malicious intent which would cause the upstream CDN redirect an end user request to an inappropriate downstream CDN which possible cannot provide service to the end user. It is mentioned in section 8 of the requirement draft [I-D.draft- cdni-requirements], all the CDNI interface shall support secure operation over unsecured IP connectivity (e.g. The Internet). This includes authentication, confidentiality, integrity protection as well as protection against spoofing and replay. As this security requirement applies to all the CDNI interfaces and it is recommended that the working group addresses this issue and considers a consistent solution in another separate document later. 8. IANA Considerations If the approach described in this document is adopted, we would request that IANA allocate the message name "CdniCapReport" and CdniCapQuery" in the HTTP Parameters registry. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. He et all Expires September 6, 2012 [Page 17] Internet-Draft cap-info-advertising March 2012 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 3986, January 2005. 9.2. Informative References [I-D.draft-cdni-use-cases] "Use Cases for Content Delivery Network Interconnection", Gilles Bertrand, Stephan Emile, Grant Watson, Trevor Burbridge, Philip Eardley, Kevin Ma, 22-Sep-11, . [I-D.draft-cdni-problem-statement] "Content Distribution Network Interconnection (CDNI) Problem Statement", Ben Niven-Jenkins, Francois Faucheur, Nabil Bitar, 9-Sep-11, . [I-D.draft-cdni-requirements] "Content Distribution Network Interconnection (CDNI) Requirements", Kent Leung, Yiu Lee, 9-Sep-11, . [I-D.davie-cdni-framework] Davie, B. and L. Peterson, "Framework for CDN Interconnection", draft-davie-cdni-framework-01 (work in progress), July 2011. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-10 (work in progress), October 2011. [I-D.draft-caulfield-metadata] Caulfield and Leung, Ledraft-caulfield-cdni-metadata-core-00 "Content Distribution Network Interconnect (CDNI) Core Metadata", October 2011. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. The authors would like to thank Scott Wainner and Ben Niven-Jenkins for their review and comments. He et all Expires September 6, 2012 [Page 18] Internet-Draft cap-info-advertising March 2012 He et all Expires September 6, 2012 [Page 19] Internet-Draft cap-info-advertising March 2012 Authors' Addresses Xiaoyan He Huawei B2, Huawei Industrial Base, 518129 China Email: hexiaoyan@huawei.com Spencer Dawkins Huawei Email: spencer@wonderhamster.org Ge Chen China Telecom 109 West Zhongshan Ave,Tianhe District,Guangzhou,P.R.C Email: cheng@gsta.com Yunfei Zhang China Mobile Email: zhangyunfei@chinamobile.com Wei Ni China Mobile No.32 Xuanwumen West Street Xicheng District Beijing, 100053 China Email: niwei@chinamobile.com He et all Expires September 6, 2012 [Page 20]