Network Working Group C. Deleuze Internet-Draft L. Gautier Expires: May 21, 2001 ActiVia Networks M. Hallgren Teleglobe France November 20, 2000 A DNS Based Mapping Peering System for Peering CDNs draft-deleuze-cdnp-dnsmap-peer-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 May 21, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Discussion List & Archives This document and related documents are discussed on the cdn mailing list. To join the list, send mail to cdn-request@ops.ietf.org. To contribute to the discussion, send mail to cdn@ops.ietf.org. The archives are at ftp://ops.ietf.org/pub/lists/cdn.*. Abstract There is an increasing interest in interconnecting Content Delivery Networks (CDNs) via peering systems. This memo proposes a DNS-based solution for peering request mapping systems. This solution uses Deleuze, et. al. Expires May 21, 2001 [Page 1] Internet-Draft CDNP DNS mapping November 2000 delivery-aware domain names under the current DNS. It describes an architecture for peering delivery-aware CDNs. This affects the methods used to interconnect multiple CDNs. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 3. Mapping System . . . . . . . . . . . . . . . . . . . . . . 5 4. Mapping Peering System . . . . . . . . . . . . . . . . . . 6 4.1 Basic Peering Mechanism . . . . . . . . . . . . . . . . . 6 4.2 Delivery-Aware Peering Mechanism . . . . . . . . . . . . . 7 4.3 External Naming Issues . . . . . . . . . . . . . . . . . . 8 5. Delivery Awareness Criteria . . . . . . . . . . . . . . . 10 5.1 Criteria Examples . . . . . . . . . . . . . . . . . . . . 10 5.1.1 Publisher criteria . . . . . . . . . . . . . . . . . . . . 10 5.1.1.1 Delivery Service . . . . . . . . . . . . . . . . . . . . . 10 5.1.1.2 Delivery Cost . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1.3 Delivery Delay . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1.4 Delivery Footprint . . . . . . . . . . . . . . . . . . . . 11 5.1.2 Delivery Criteria . . . . . . . . . . . . . . . . . . . . 11 5.2 Default Delivery Names . . . . . . . . . . . . . . . . . . 11 5.2.1 Delivery Name Key . . . . . . . . . . . . . . . . . . . . 12 5.2.2 Delivery Name Example . . . . . . . . . . . . . . . . . . 13 5.2.2.1 Publisher Delivery Name . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . 19 Deleuze, et. al. Expires May 21, 2001 [Page 2] Internet-Draft CDNP DNS mapping November 2000 1. Conventions This memo assumes that the reader is familiar with DNS concepts [1] and specifications [2]. Following practice in the CDNP mailing list, we use the term "DNS name" rather than "domain name". "tld" stands for "top level domain". "Delivery-aware" is used here to indicate that there are multiple possibilities to deliver content depending on a variety of criteria. For example, consider the footprint criteria, the content must be delivered only to a subset of peered CDN surrogates. "DNS-MS" stands for DNS-based Mapping System. "PMT" stands for "Peering Mapping Table", i.e. the set of DNS records involved in the DNS-MS peering process. "PMT Manager" stands for the peering mechanism that builds the PMT (either an administrator or a protocol). Deleuze, et. al. Expires May 21, 2001 [Page 3] Internet-Draft CDNP DNS mapping November 2000 2. Introduction The Domain Name System (DNS) was designed primarily to identify network resources. Today, many CDNs use the current DNS to map a request to the suitable surrogate [4]. During the DNS mapping process only the DNS names are visible to the DNS mapping system. A problem occurs when a CDN wants to publish content on a specific delivery area. This area can be a subset of CDN servers running a specific application, or servers that cover only a part of the total CDN footprint. To make this delivery information available to the mapping process, it has to be coded in the DNS name space. The need for delivery awareness can easily be shown with this example: A Microsoft Windows Media Stream is published with an URI such as: "mms://foo.bar.com/file.foo". This URI is interpreted at the user agent and is not visible for the mapping system. The only part of the URI that can be used for request mapping is the DNS name. Hence, all relevant information for the mapping decision has to be encoded in the DNS name. Since only DNS names are visible during the DNS-based peering, information about a desired footprint, delivery area or similar information has to be integrated in the DNS name. To peer with a limited zone inside a CDN, this zone has to be defined between the peering partners and encoded in the DNS name. For example, this is already used by CNN with its "www.cnn.com" and "europe.cnn.com" DNS names. This memo addresses specifically the issues raised in the context of CDN peering. The scope of this work is limited to DNS-based peering, but does not restrict the mapping mechanisms inside each individual CDN. For the purpose of this document we consider the internal mapping mechanisms of CDNs as black boxes (e.g., a CDN can use URI-based mapping internally). This memo presents a solution for delivery aware mapping. At the core of this solution is the use of the delivery-aware naming at the DNS level. Consult [5] for a description of object coding in the DNS name space. The present memo proposes a more general approach towards DNS-based request mapping using delivery-aware DNS names. Deleuze, et. al. Expires May 21, 2001 [Page 4] Internet-Draft CDNP DNS mapping November 2000 3. Mapping System The component of a CDN that maps user requests to an appropriate surrogate is called the "mapping system". Similarly to the routing of IP datagrams, it actually contains two distinct processes: o "forwarding" is the process that uses the "routing table" to determine the next hop to the appropriate surrogate. o "routing" is the process that builds the routing table according to various metrics and policies. In this memo, only the "forwarding" part is addressed. Conceptually, mapping systems can make use of three (possibly combined) categories of mechanisms (see [5] for details): o DNS-based o transport-layer o application-layer (URI-based) DNS-based mapping is always available whatever the content (it does not require usage of proxies or application level redirection mechanisms). The interpretation of an URI is hierarchical: first, the DNS name is resolved, then a protocol is chosen according to the scheme and a connection is established; URI pathname and arguments are made available to the server which processes them. Hence, DNS-based mapping can always be used as the first step of a general URI based mapping mechanism. Other motivations for the use of DNS-based mapping are the following: o Independence of the application-level protocols: The DNS-based mapping acts before these protocols so that they are not aware of the mapping. o Compatibility with whatever URI utilization: The DNS-based mapping does not rely on URI analysis, so URI can be used exclusively on user agents, encrypted over the network or used many times after the mapping (as HTTP1.1 [3] recommends). Deleuze, et. al. Expires May 21, 2001 [Page 5] Internet-Draft CDNP DNS mapping November 2000 4. Mapping Peering System In the case of peering CDNs, mapping systems must be tied together by mapping CPGs (content peering gateways) to form a hierarchical mapping peering system [6]. Each CDN has only one mapping system. A parent mapping system is a mapping system, authoritative or not, which decides that a child mapping system can handle the user request or can delegate the mapping to a lower mapping system in the hierarchy, in order to find the best suitable surrogate among each peering CDN surrogates. The first step of the URI mapping mechanism is the DNS-based mapping as explained above. It is handled by a DNS based Mapping System (DNS-MS). The most common mechanisms used for DNS redirection are based on NS and CNAME records [5]. The DNS-MS described below is based on CNAME records, but can be adapted to one using NS records, with the known drawbacks described in [5]. The set of CNAME records involved in the DNS-MS peering process is defined as the peering mapping table (PMT). This table contains one CNAME record per entry. The PMT is built by the Peering Mapping Table Manager (PMT Manager). This entity can be a DNS-MS administrator which manually updates the table, or a peering protocol (not addressed here) that performs this task automatically. 4.1 Basic Peering Mechanism Here, each DNS-MS is described by only one DNS name. Therefore, the peering mechanism is not delivery-aware. For the sake of clarity, the unique DNS name of a DNS-MS "X" can be seen as: ".X_domain.tld". When a parent DNS-MS decides to delegate the current resolution of a name ".parent_domain.tld" to a child DNS-MS, it replies to the user's DNS server the only CNAME record with the new DNS name ".child_domain.tld". The user's DNS server then queries the child DNS-MS to resolve this new DNS name. The PMT manager makes the association (i.e. adds the CNAME entry in the PMT) between ".parent_domain.tld" and ".child_domain.tld". This association does not depend on any content or delivery criteria. If the child CDN is not able to distribute the content, the association is suppressed and the peered content distribution is stopped. Since the parent has a unique delivery name, the PMT contains one unique entry per peer DNS-MS. Deleuze, et. al. Expires May 21, 2001 [Page 6] Internet-Draft CDNP DNS mapping November 2000 4.2 Delivery-Aware Peering Mechanism The CDN peering architecture [6] defines one mapping tree for each publisher URI. The aggregation of the mapping trees whose URIs use the same publisher DNS name defines a global delivery tree. Each DNS-MS defines its internal delivery trees with the delivery criteria as presented in Section 5. An internal delivery tree is defined by a delivery name. This delivery name is a DNS name ".domain.tld" under the DNS authority of the CDN. This is the name used by the DNS-MS. Other DNS names of the internal delivery tree (used by the internal mapping system) are not exported outside the DNS-MS. As seen before, the basic mechanism implies that each CDN has only one internal delivery tree. All internal delivery trees, one per CDN, build one unique global delivery tree that covers all peering CDNs . Also, parent DNS-MSs have only one CNAME record pointing to the delivery name of the child DNS-MS they are peering with. The delivery-aware mechanism implies that each CDN has one or more internal delivery trees. When multiple CDNs are tied together, all internal delivery trees build several global delivery trees. In order to peer with a given child DNS-MS, the parent DNS-MS uses one CNAME record for each of its internal delivery trees. The general DNS-MS peering architecture is defined as follows. The publisher delegates one of its DNS names to the authoritative DNS-MS via a publisher delivery name. Then, the authoritative DNS-MS links this delivery name to one delivery name in each child DNS-MS. This procedure is repeated recursively between peered DNS-MSs. Therefore, the peering process is defined as follows. When a parent DNS-MS decides to delegate the current resolution of a delivery name ".parent_domain.tld" to a child DNS-MS, the parent replies to the user's DNS server a CNAME record with the new delivery name ".child_domain.tld". The user's DNS server then queries the child DNS-MS to resolve this new delivery name. The PMT manager make the association between ".parent_domain.tld" and ".child_domain.tld". This association must be done accordingly to criteria as presented in Section 5. The PMT contains one set of CNAME records per parent DNS-MS delivery name. A set contains one CNAME record per peer DNS-MS for the delivery name. Note that the PMT manager can change the PMT depending on network measurements or surrogate feedback. Deleuze, et. al. Expires May 21, 2001 [Page 7] Internet-Draft CDNP DNS mapping November 2000 Several parent internal delivery trees may be linked to one child internal delivery tree, which becomes a multiplexed delivery tree. However, this kind of internal delivery tree cannot be demultiplexed. For example, if a multiplexed internal delivery tree is composed of HTTP and RTSP delivery, it is not possible to redirect HTTP related DNS requests to one child and RTSP requests to another child (or to another tree in the same child). Therefore, the more internal delivery trees in a CDN, the more it is able to peer with other CDNs in a delivery aware way. 4.3 External Naming Issues In our model, a CDN can provide several delivery services (through distinct delivery trees) that are selected through an appropriate DNS name. This memo described how to use those names for CDN peering. Each peering CDN knows how to address the delivery trees of its peering CDNs. Those names are used only between pairs of peering CDNs and are neither visible to users nor to publishers. This section discusses the special case of "peering" between the origin server of the publisher and the authoritative mapping system. The publisher delivery name must match the delivery tree corresponding to the service the publisher bought from the CDN. Let's take the example of the European 'Foo' company, which has a web site in English with parts of it in French. This example is based on footprints, but any other criteria can be used. "Foo" wants the English parts of its web site to be CDN-delivered throughout Europe, and the French parts only in France. Thus, it is necessary that the English parts are associated to a delivery tree providing a European footprint and the French parts are associated to another delivery tree providing a French footprint. Since delivery trees are selected by a DNS name, the parts of the web site need to be identified in the DNS name, e.g. www.foo.com for English parts and www1.foo.com for French parts. This may be achieved by URI rewriting: Static rewriting: It requires the reorganization of the "Foo" web site. Dynamic rewriting: It is performed on the fly, as a document is fetched from the origin server. Note that in this context, URI rewriting does not raise the problems described in [5] (Section 4.2.2.3): 1. Rewriting is not client dependent. Deleuze, et. al. Expires May 21, 2001 [Page 8] Internet-Draft CDNP DNS mapping November 2000 2. The new DNS name points to a delivery tree, which will then be DNS-based mapped, not a surrogate. 3. Rewritten content can be cached in surrogates. The impact on the distribution system of such a scheme is not addressed here. Deleuze, et. al. Expires May 21, 2001 [Page 9] Internet-Draft CDNP DNS mapping November 2000 5. Delivery Awareness Criteria In the delivery-aware peering mechanism, the PMT manager make use of a variety of delivery criteria for create/remove/update the CNAME records of the PMT. A set of delivery criteria is associated with each parent and child delivery name. A set of publisher criteria is also associated to the publisher delivery names. Therefore, the PMT manager can decide, on the basis of the criteria sets, which CNAME entry to create/remove/update in the PMT. As mentioned above, the publisher may have to modify its delivery names, in order to match the delivery services needs, possibly using a URI rewriting system. In addition, the PMT manager has to create new delivery names (and corresponding internal delivery trees) to match the need of the publisher or of a peer DNS-MS. Note that it is not mandatory to have one delivery name for each possible combination of criteria. Note also that some of these criteria may not be used in the delivery-aware DNS mapping process described above. However, they can be used in other mapping processes. 5.1 Criteria Examples 5.1.1 Publisher criteria The following lists are not exhaustive and might grow. In this section, these criteria are presented from a publisher point of view. The DNS-MS point of view is also mentioned when the publisher and delivery criteria differs. 5.1.1.1 Delivery Service A publisher may need to deliver different kind of services or sub-services: o web pages * static web pages * dynamically generated web pages (asp, cgi-bin, ...) * web embedded objects (like images) o standard encoded streams o proprietary encoded streams, which can be derived for each Deleuze, et. al. Expires May 21, 2001 [Page 10] Internet-Draft CDNP DNS mapping November 2000 encoding 5.1.1.2 Delivery Cost The publisher may specify a maximum cost for the delivery. The DNS-MS may specify a cost for the usage of its infrastructure. The definition of these cost criteria depends on business models that are not addressed here. 5.1.1.3 Delivery Delay Some contents or type of contents may need to be delivered within a delay bound. For example, this criterion can exclude the use of satellite links. 5.1.1.4 Delivery Footprint Contents may require delivery to specific geographical zones: o World o Continents o Countries o States/regions o Cities o Districts o Internet Point of Presence (PoP) or any combination of those. 5.1.2 Delivery Criteria Each publisher criteria is also a delivery criteria. In addition, varieties of metrics based on network measurements, DNS-MS feedback or surrogate feedback are added. These metrics are discussed in [5]. 5.2 Default Delivery Names One or more delivery criteria must be encoded in a delivery name to define it uniquely. E.g., the web and RTSP service types can be encoded as follows: o www.domain.tld for static html pages Deleuze, et. al. Expires May 21, 2001 [Page 11] Internet-Draft CDNP DNS mapping November 2000 o rtsp.domain.tld for RTSP compatible stream content or with a unique identifier (which may be a hash key) o one.domain.tld o two.domain.tld This section gives some recommendations to create delivery names but does not intend to impose a unique delivery name space. The delivery trees start with the delivery names of the publisher. Hence, one publisher delivery name has to be defined for each delivery tree required either by the publisher or by the global DNS mapping system. As seen before, the publisher delivery names can be created with URI rewriting systems. Since the publisher delivery names may be visible to the users, they should be expressed with understandable names. 5.2.1 Delivery Name Key The publisher delivery name should be composed of a delivery key followed by the publisher domain or subdomain referred as "domain.tld". The delivery key is composed of one or more DNS labels. The publisher may choose the delivery key. The recommended delivery key is composed of only one DNS label: ::= [ ] ::= | ::= | ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case ::= any one of the ten digits 0 through 9 Note that while upper and lower case letters are allowed in delivery key, no significance is attached to the case. This is, two delivery keys with the same spelling but different case are to be treated as if identical. Since delivery keys are DNS labels, they must be 63 characters or less. Moreover, since CNAME records are appended during DNS resolution, it is wise to choose short delivery names in order to fit the whole answer in a single UDP DNS message. If this is not the case, the requests would be be restarted with TCP, impacting Deleuze, et. al. Expires May 21, 2001 [Page 12] Internet-Draft CDNP DNS mapping November 2000 performance. The text label represents one or more delivery services. The following are defined, others may be used: o "www" for web pages o "ftp" for ftp delivery service o "rtsp" for standard stream delivery o "mms" for Microsoft Windows Media delivery The key label is used to differentiate delivery keys having the same text label. If only one delivery key uses a text label, it does not contain a key label. When several delivery keys use the same text label, the most used (from a user point of view) do not contain a key label. Hence, the web service may have a "www" delivery key and the associated "www.domain.tld" delivery name which is already commonly used. Other delivery keys having the same text label must have a delivery key numbered incrementally and consecutively from 1. 5.2.2 Delivery Name Example A publisher "domain.com" has three delivery requirements, R1 to R3: o R1 criteria: * service: dynamically generated web (HTML and images) * footprint: World o R2 criteria: * service: dynamically generated web (HTML and images) * footprint: France and Germany o R3 criteria: * service: RTSP streaming * footprint: France and Germany Deleuze, et. al. Expires May 21, 2001 [Page 13] Internet-Draft CDNP DNS mapping November 2000 5.2.2.1 Publisher Delivery Name The publisher delivery names would be the following. R1 and R2 have the same delivery service: www. The publisher delivery names have to be identified with key labels. As R1 is the primary requirement of the publisher, the delivery key has no key-label field. It is "www.domain.com". Contrary, R2 needs a key label to be differentiated from R1. It is "www1.domain.com". R2 and R3 have the same delivery footprint, but different delivery service. Thus, R3 is differentiated from R2 by the delivery service. The naming is then: "rtsp.domain.com". Deleuze, et. al. Expires May 21, 2001 [Page 14] Internet-Draft CDNP DNS mapping November 2000 6. Security Considerations Specific security issues will be considered later. However, the architecture will use and adopt existing DNS security standards [7]. Deleuze, et. al. Expires May 21, 2001 [Page 15] Internet-Draft CDNP DNS mapping November 2000 7. Acknowledgements Deleuze, et. al. Expires May 21, 2001 [Page 16] Internet-Draft CDNP DNS mapping November 2000 References [1] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [2] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering", Internet draft, draft-day-cdnp-model-03.txt (work in progress), November 2000. [5] Cain, B., Douglis, F., Green, M., Hofmann, M., Nair, R. and D. Potter, "Known CDN Request Mapping Mechanisms", Internet draft, draft-cain-cdnp-known-req-map-00.txt (work in progress), November 2000. [6] Green, M., Cain, B. and G. Tomlinson, "CDN Peering Architectural Overview", Internet draft, draft-green-cdnp-gen-arch-01.txt (work in progress), October 2000. [7] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. Authors' Addresses Christophe L. Deleuze ActiVia Networks Space Antipolis 5 Parc de Sophia Antipolis 2323 Chemin St Bernard 06225 Vallauris, Cedex FRANCE Phone: +33 4 97 23 46 66 EMail: Christophe.Deleuze@activia.net URI: http://www.activia.net/ Deleuze, et. al. Expires May 21, 2001 [Page 17] Internet-Draft CDNP DNS mapping November 2000 Laurent G. Gautier ActiVia Networks Space Antipolis 5 Parc de Sophia Antipolis 2323 Chemin St Bernard 06225 Vallauris, Cedex FRANCE Phone: +33 4 97 23 46 46 EMail: Laurent.Gautier@activia.net URI: http://www.activia.net/ Michael Hallgren Teleglobe France Washington Plaza 44, rue Washington 75408 PARIS, FRANCE Phone: +33 1 56 59 87 44 EMail: michael.hallgren@teleglobe.com URI: http://www.teleglobe.com/ Deleuze, et. al. Expires May 21, 2001 [Page 18] Internet-Draft CDNP DNS mapping November 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Deleuze, et. al. Expires May 21, 2001 [Page 19]