Network Working Group Xiaoyan He Internet Draft Jincheng Li Intended status: Informational Spencer Dawkins Expires: December 2011 Huawei Ge Chen China Telecom June 30, 2011 Request Routing for CDN Interconnection draft-xiaoyan-cdni-requestrouting-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 December 31, 2011. 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 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 XiaoyanHe, et al. Expires December 31, 2011 [Page 1] Internet-Draft CDNI Request Routing June 2011 Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes recursive request routing procedures for CDN interconnection, it also describes content acquisition procedure using the HTTP protocol when cache miss occurs. The goal of the present document is to spur discussion about these procedures and to achieve a consensus on request routing procedures of CDNI. Table of Contents 1. Introduction................................................2 2. Conventions used in this document............................4 3. Request routing.............................................4 3.1. Scope definition........................................4 3.2. Protocol considerations on routing procedure............5 3.3. Domain Name examples....................................5 3.4. Operation codes considerations..........................5 3.5. Client location's availability..........................6 4. Configuration summary........................................6 5. Request routing approaches...................................7 5.1. First approach.........................................7 5.2. Second approach.........................................9 6. Conclusions................................................10 7. Security Considerations.....................................10 8. IANA Considerations........................................10 9. References.................................................10 9.1. Normative References...................................10 9.2. Informative References.................................11 1. Introduction CDNI request routing includes the following two scenarios: Scenario A: request routing for user initiated requests, where once the upstream CDN receives the user request (DNS or HTTP), upstream CDN communicates with a downstream CDN to get the address of a delivery node to serve the user. Scenario B: request routing for content acquisition, where the selected delivery node in downstream CDN receives the XiaoyanHe, et al. Expires December 31, 2011 [Page 2] Internet-Draft CDNI Request Routing June 2011 user's request and encounters a cache miss, and communicates with upstream CDN to select a delivery node to acquire the content. From procedure perspective, both iterative and recursive request routing are to be supported by CDNI solution as per requirement draft [I-D.draft-lefaucheur-cdni-requirements] (requirements R33 and R34 in version -01). From protocol perspective, either DNS or HTTP[RFC2616] can be used for request routing. Therefore, we can have four solution combinations for each scenario, see table below. +---------+-------+----+----+----+-----+---------+ | | Protocol | Procedure | + Case No.+-------+----+----+----+-----+---------+ | | DNS | HTTP | Iterative|Recursive| +---------+-------+----+----+----+-----+---------+ | 1 | Y | | Y | | +---------+-------+----+----+----+-----+---------+ | 2 | Y | | | Y | +---------+-------+----+----+----+-----+---------+ | 3 | | Y | Y | | +---------+-------+----+----+----+-----+---------+ | 4 | | Y | | Y | +---------+-------+----+----+----+-----+---------+ Table 1: solution combinations for CDNI scenarios Document [I-D.draft-peterson-cdni-strawman] gives a discussion on iterative routing using DNS. The present document discusses recursive request routing procedures using DNS or HTTP. Note: According to the proposed charter and current (individual) requirement document for CDNI, interfaces inside CDN are out of scope of CDNI, i.e. interactions XiaoyanHe, et al. Expires December 31, 2011 [Page 3] Internet-Draft CDNI Request Routing June 2011 between a delivery node and RR in the downstream CDN during content acquisition should not be specified in CDNI; hence this document does not describe that interface in detail. 2. Conventions used in this document The two terms "Iterative CDNI request routing" and "Recursive CDNI request routing" in this document are to be interpreted as defined in [I-D .draft-lefaucheur-cdni-requirements]. 3. Request routing 3.1. Scope definition This document focuses on Recursive CDNI request routing. For convenience, definition for recursive CDNI request routing from [I-D .draft-lefaucheur-cdni-requirements] is copied as below. o Recursive CDNI request routing: When an Upstream CDN elects to redirect a request towards a Downstream CDN, the Upstream CDN can query the Downstream CDN Request Routing system via the CDNI Request Routing protocol (or use information cached from earlier similar queries) to find out how the Downstream CDN wants the request to be redirected, which allows the Upstream CDN to factor in the Downstream CDN response when redirecting the user agent. This approach is referred to as "recursive" CDNI request routing. Note that the Downstream CDN may elect to have the request redirected directly to a Surrogate inside the Downstream CDN, to the Request-Routing System of the Downstream CDN, to another CDN, or to any other system that the Downstream CDN sees as fit for handling the redirected request. Other "recursive" mechanisms also utilized in CDNI, but not for interactions of RRs during request routing procedures such as the local DNS's role in DNS lookup, are not in the scope of this document. XiaoyanHe, et al. Expires December 31, 2011 [Page 4] Internet-Draft CDNI Request Routing June 2011 3.2. Protocol considerations on routing procedure Two main protocols can be used for CDNI recursive request routing, i.e. HTTP or DNS. The present document obeys a principle that the protocol utilized between two RR systems keeps same as that utilized between the end user and the first touched RR to simplify the RR implementation. 3.3. Domain Name examples There are several domain names involved in this document, below are their examples and explanations. 1. video.cp.example In this document, a content provider with domain name cp.example contracts with a CDN provider. Domain name video.cp.example represents the specific sub domain to be accelerated by the contracted CDN. Generally, the authoritative DNS server of domain video.cp.example has a record pointing to a domain of the contracted CDN,in order to direct the relevant DNS requests to that CDN. A contractual CDN may ingest content from the contracted content provider in advance or dynamically. However, the ingestion procedures are out of scope of CDNI and therefore not described in this draft. 2. cdn.op-x.example Operator X with domain name op-x.example provides CDN services using sub domain name cdn.op-x.example. This CDN-domain augmented with a prefix "peer" used to identify the request it received is from a peer CDN rather than from end users. 3.4. Operation codes considerations In case of HTTP signaling used between RRs of connected CDNs, as one CDN may act as a downstream peer and an upstream peer for different CPs at the same time, it's possible that a CDN receives requests from other interconnected CDNs for different purposes. e.g.selecting a delivery node for an end user or selecting a delivery node holding the content for a downstream peer. Therefore the CDN needs to distinguish these requests to act correspondingly. Operation code "CDNIRoutereq" and "CDNIContentlocate" contained in the URL of HTTP requests is used for this purpose in the present document. XiaoyanHe, et al. Expires December 31, 2011 [Page 5] Internet-Draft CDNI Request Routing June 2011 3.5. Client location's availability To select the most appropriate delivery node ultimately to serve for an end user, usually the user's location is taken into account by the downstream CDN. Therefore, the user's IP address or FQDN should be conveyed to the downstream CDN from the upstream peer during CDNI request routing. In case of HTTP redirection, the upstream CDN can get the specific IP address of the end user. It is proposed the upstream CDN convey this IP address or construct a FQDN to the downstream CDN for optimal routing decision. In case of DNS redirection, the upstream CDN may obtain the end user's IP address through the DNS client subnet extension or by embedding the client IP address in the DNS name [I-D.vandergaast-edns-client-subnet]. It is proposed that the upstream CDN forwards this info to the downstream CDN directly for optimal routing decision. If the UE does not support this DNS extension, the upstream CDN therefore will not convey sort of this extension to its down peer. It is proposed that the downstream CDN returns the request router's address. After that the specific HTTP request for content will be sent to the request router,at this point, the request router can elect a more accurate delivery node for the user based on its IP address. 4. Configuration summary Interconnection CDNs must exchange the following information to peer with each other: o The IP address of the entry point of the CDN or distinguished CDN domain name; and o Set of IP prefixes for which the CDN is prepared to deliver to end-users. o Set of CP domain names for which the CDN is served. When a Request Router in an upstream sees an end-user IP address best served by a downstream peer, upstream CDNs needs to forward the request to the configured entry point of the downstream peer, or to result of DNS lookup for the configured downstream CDN's domain name. When a delivery node in a downstream receives content requests from end users and result in cache miss, it verifies that the CP domain XiaoyanHe, et al. Expires December 31, 2011 [Page 6] Internet-Draft CDNI Request Routing June 2011 contained in the URL is served by a known CDN peer based on configuration, and if so, issues a content acquisition request to that peer. 5. Request routing approaches 5.1. First approach This alternative utilizes HTTP redirection between the end user and the upstream CDN. On reception of HTTP request, the upstream CDN communicates directly with selected downstream CDN to get a delivery node. End-User CDN B CDN A |DNS video.cp.example | | |-------------------------------------------------->| | | | (1) |IPaddr of A's Request Router | |<--------------------------------------------------| |HTTP GET video.cp.example| | |-------------------------------------------------->| | HTTP POST peer.cdn.op-b.example/CDNIRoutereq| (2) | |<------------------------| | 200 Hostname of B's Delivery Node | |------------------------>| (3) | 302 Hostname of B's Delivery Node | |<--------------------------------------------------| HTTP GET Hostname/video.cp.example |HTTP POST peer.cdn.op-a.example |------------------------>| /CDNILocatecontent | (4) | |------------------------>| | 200 Hostname of A's Delivery Node (5) | |<------------------------| | HTTP GET Hostname of A'DN/rest of url| | |------------------------>| (6) | |Data | |Data |<------------------------| |<------------------------| | | | | | | | Figure 1: Request routing for approach one 1. A Request Router of CDN A processes the DNS request for its customer and recognizes that the end-user is best served by another CDN. CDN A returns the IP address of its Request Router to get the HTTP request of the user. XiaoyanHe, et al. Expires December 31, 2011 [Page 7] Internet-Draft CDNI Request Routing June 2011 Note: The domain name in step1 of the CP e.g.video.cp.example should be changed to the CDN A's when the request is redirected to CDN A. For simplicity, this is not shown in the figure. 2. A Request Router of CDN A processes the HTTP request and again recognizes that the end-user is best served by another CDN, so based on the configuration and result of a potential DNS lookup, CDN A issues an HTTP POST to CDN B's Request Router, with the distinguished CDN b's domain name and a command code "CDNIRoutreq" contained in the URL. The command code is used to explicitly indicate this is a request from a peer for delivery node selection. Other parameters e.g.the end user's IP address and the CP's domain name shall be included in the body of the HTTP POST. 3. CDN B's Request Router recognizes the request is from a peer CDN, if the end user's IP is included, it selects and returns a suitable delivery node for the user based on its location. The address of this node is returned to the end user via CDN A. Based on local policy, CDN B may return the request router's address instead of that of a delivery node. 4. The end-user requests the content from CDN B's delivery node, potentially resulting in a cache miss. From the URL CDN B verifies that this CP-domain served by a known peer. It then sends a HTTP POST with a command code "CDNILocatecontent" and CDN A's distinguished domain name contained in the URL to CDN A's Request Router. Other parameters such as playback URL of the content shall be included in the body of the HTTP POST. If the CDN B's Request Router address is returned in step 3, the content request will first arrive at CDN B's Request Router and a 302 response with the address of the selected delivery node will be sent back to the end user. 5. CDN A recognizes that the HTTP request is from a peer CDN rather than an end-user based on the command code and so returns address of a delivery node. 6. CDN A serves content for the requested CDN-domain. XiaoyanHe, et al. Expires December 31, 2011 [Page 8] Internet-Draft CDNI Request Routing June 2011 5.2. Second approach This approach utilizes DNS redirection between an end user and the upstream CDN. On reception of DNS lookup request, the upstream CDN communicates directly with the selected downstream CDN to locate delivery node. End-User CDN B CDN A |DNS video.cp.example | | |-------------------------------------------------->| | |DNS peer.cdn.op-b.example| (1) | |<------------------------| | |IPaddr of B's Delivery Node | |------------------------>| | IPaddr of B's Delivery Node | (2) |<--------------------------------------------------| |HTTP GET video.cp.example|HTTP POST peer.cdn.op-a.example |------------------------>|/CDNILocatecontent |(3) | |------------------------>| | |200 HostName of A's Delivery Node | |<------------------------| | HTTP GET Hostname of A'DN/rest of url| (4) | |------------------------>| | |Data | |Data |<------------------------| (5) |<------------------------| | Figure 2: Request routing for approach two 1. A Request Router of CDN A processes the DNS request for its customer and recognizes that the end-user is best served by another CDN. The client IP used in this determination is obtained either through the DNS client subnet extension or by embedding the client IP in the DNS name [I-D.vandergaast-edns-client-subnet]. Based on configuration, the Request Router changes the domain name to CDN B's distinguished name and forwards the DNS request to CDN B's Request Router. 2. CDN B's Request Router recognizes the request is from a peer CDN based on the distinguished domain name, it returns a suitable delivery node. The address of this node is returned to the end user via CDN A. Or based on local policy or CDN B did not get the address of the client in step 1, CDN B may return the address of the Request Router. XiaoyanHe, et al. Expires December 31, 2011 [Page 9] Internet-Draft CDNI Request Routing June 2011 3. The end-user requests the content from CDN B's delivery node, potentially resulting in a cache miss. From the URL CDN B verifies that this CP is served by a known peer. It then issues an HTTP POST with command code "CDNILocatecontent" and CDN A's distinguished domain name contained in the URL to CDN A's Request Router. Other parameters such as playback URL of the content shall be included in the body of the HTTP POST. If the CDN B's Request Router address is returned in step2, the content request will first arrive at CDN B's Request Router and a 302 response with the address of selected delivery node will be sent back to the end user. 4. CDN A recognizes that the HTTP request is from a peer CDN rather than an end-user from the command code and so returns the address of a delivery node. 5. CDN A serves content for the requested CDN-domain. 6. Conclusions Priorities for proposed approaches in present document will be worked out later based on discussion on the email list. 7. Security Considerations For the recursive request routing approach described in Section 5.2, the user agent may determine to convey its IP address to the CDN by including its IP address in the DNS client subnet extension or embedding the IP address in the DNS name [I-D.vandergaast-edns-client-subnet] for optimizing the routing. In case of CDNI, if [RFC1918] address space is utilized by the end user, the [RFC1918] IP address should not be paased across the addressing boundary to the downstream CDN, for several reasons,which include the possibility that the downstream CDN might also use overlapping [RFC1918] address space. A possible approach for this is that when the upstream CDN recognizes that an [RFC1918] address is used by the user agent, it shall change this address to the global unique IP address of the local DNS for the end user from the IP packet header and transfer this address to the downstream peer. The downstream CDN then may select a delivery node for the user based on the local DNS's address or just return the RR's address to the upstream CDN. XiaoyanHe, et al. Expires December 31, 2011 [Page 10] Internet-Draft CDNI Request Routing June 2011 8. IANA Considerations If the approach described in this document is adopted, we would request that IANA allocate the command codes "CDNIRoutereq" and "CDNIContentlocate" in the HTTP Parameters registry. 9. References 9.1. Normative References [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. [RFC1918] "Address Allocation for Private Internets", Y.Rekhter, B.Moskowitz,D.Karrenberg, G.J.de Groot,E.Lear, February 1996. [I-D.draft-lefaucheur-cdni-requirements] "Content Distribution Network Interconnection (CDNI) Requirements", Francois Le Faucheur, Mahesh Viveganandhan, Grant Watson, Yiu Lee, 14-Mar-11, [I-D.draft-peterson-cdni-strawman] "A Simple Approach to CDN Interconnection", Larry Peterson, John Hartman, 18-May-11, [I-D.vandergaast-edns-client-subnet] Contavalli, C., van der Gaast, W., Leach, S., and D. Rodden, "Client subnet in DNS requests", January 2011. 9.2. Informative References Authors' Addresses XiaoyanHe, et al. Expires December 31, 2011 [Page 11] Internet-Draft CDNI Request Routing June 2011 Xiaoyan He Huawei B2, Huawei Industrial Base, 518129 China Phone: +86 158 2938 5137 Email: hexiaoyan@huawei.com Jincheng Li Huawei B2, Huawei Industrial Base, 518129 China Phone: +86 139 9195 3074 Email: lijincheng@huawei.com Spencer Dawkins Huawei 1700 Alma Drive,Suite 100 Plano,TX 75075 USA Phone: +1 469 229 5397 Email: spencer@wonderhamster.org Ge Chen China Telecom 109 West Zhongshan Ave,Tianhe District,Guangzhou,P.R.C Phone: +86 133 1609 0408 Email: cheng@gsta.com XiaoyanHe, et al. Expires December 31, 2011 [Page 12]