Internet Draft B. Cain Cereva Networks O. Spatscheck AT&T Labs M. May Activia Networks A. Barbir Nortel Networks July 2001 Request-Routing Requirements for Content Internetworking draft-cain-request-routing-req-02.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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract Request-routing systems (RRS) are components of Content Distribution Networks (CDNs) that direct client requests to an available copy of content based on one or more metrics. To enable the interconnection of CDNs [MODEL], it is necessary for their request-routing systems to interconnect and exchange information such that client requests can be routed between CDNs. This document provides an overview of request-routing systems and specifies the requirements for their interconnection. Cain, et. al. Expires January 2002 ^L[Page 1] Internet-Draft June 2001 1. Introduction Request-routing systems (RRS) are components of Content Distribution Networks that direct client requests to an available copy of content based on one or more metrics. In order too enable the interconnection of CDNs [MODEL], it is necessary for request-routing systems to interconnect and exchange information such that requests can be routed between domains. This document provides an overview of request-routing systems and specifies the requirements to interconnect request-routing systems. 1.1 Document Organization This document is organized as follows. Section 1 presents an introduction to request-routing systems. Section 2 presents the details of request-routing system components and protocols. Section 3 presents detailed requirements for each component, sub-component or protocol from sections 1 and 2. 1.2 Overview of Request-Routing Systems Request-routing systems (RRS) direct client requests to surrogates that can "best" service the request [MODEL]. Request-routing decisions are based on a set of metrics that may include for example network proximity and server load. The basic functionality of a request-routing system can be summarized by the following: 1. It directs clients to surrogates that are able to serve their requests. 2. It directs clients to surrogates that (per a set of metrics) are able to provide the "best" service. For the sake of clarity, we now reiterate several important assumptions from [ARCH] [MODEL]: 1. Each CDN is a "black box" to other networks to which it is interconnected. We use the term "neighbor" to refer to a directly interconnected CDN. 2. Content is served by surrogates that act on behalf of an origin server that holds the "master" or "authoritative" copy of content. Surrogates are part of a distribution system. 3. A request-routing system is responsible for directing/servicing requests for one or more distribution systems. 4. Each distribution system may have its own internal (or intra- domain) request-routing system that is not exposed to other interconnected networks. 5. Request-routing systems interconnect through Content Peering Cain, et. al. Expires January 2002 ^L[Page 2] Internet-Draft June 2001 Gateways (CPG) that implement standards based interconnection protocols. A CDN's CPG is the only "visible" element to other interconnected CDNs. 1.3 Generic Request-Routing System Architecture This section presents a generic architecture of a request-routing system to assist in understanding request-routing systems as well as the requirements for their interconnection. In Figure 1, a conceptual view of a request-routing system is presented; it consists of the following components: Content Topology Exchange, Content Topology Database and Route Computation. A brief summary of these components is provided below: ____________________________________________ | ___________ ________ ________ | | |Routing | |Content | |Content | | Request-Routing | |Computation| |Topology|<->|Topology| |<->Information | |___________| |Database| |Exchange| | Exchange | |________| |________| | Protocol |__________________________________________| Figure 1. 1. Routing Computation: Responsible for computing the content route based on information stored in the Content Topology Data Base, route computing algorithm and policies. This decision may be based on a variety of internal or external metrics. 2. Content Topology Database: The topology database includes detailed topology information received from neighbors and associated metrics exchanged during Content Information Exchange. 3. Content Information Exchange: This functional block is responsible for implementing the Information Exchange protocol. 4. Information Exchange Protocol: Protocol used to communicate capabilities, content advertisements, and network advertisements. 1.4 Interconnecting Request-Routing Systems Within a single CDN, a request-routing system is used to direct client requests to surrogates that are part of its own distribution system. However, when request-routing systems are interconnected, a request-router has the ability to redirect client requests to neighbor CDNs. That is, when neighbor CDN has a better set of metric for a set of client(s), it may be desirable to direct requests to that neighbor CDN. In order to determine which CDN may best serve a client request, one or more protocols may be required to exchange various types of information and associated metrics. This document describes the components of request-routing systems and Cain, et. al. Expires January 2002 ^L[Page 3] Internet-Draft June 2001 requirements for interconnecting them. 2. Overview of Request-Routing System Components and Protocols This section provides a detailed description of the basic components of a request-routing system. Section 3 provides a description of the specific requirements for each component. 2.1 Request-Routing System Types The methods in which a client request is directed may be different depending on the architecture of the request-routing system. Currently, there are two well-known types of request-routing systems. These two types are described below: 1. DNS-based Request-Routing Systems: The Domain Name System (DNS) is used for the direction of client requests. In this approach, one or more domain names are assigned to the request-routing system; these names are then used as part of a URI reference to direct client requests [DNSMAP]. The limitations of DNS-based systems are described [KNOWN_MECH] and in section 2.1.1. 2. "In-Line" Request-Routing Systems: These request-routing systems are "in-line" to client requests. Examples of in-line request-routing systems are those that may be implemented within a proxy or a layer-7 router. In-line request-routing systems have full visibility into content requests (e.g. full URL) as well as visibility of the client's IP address [note: this isn't always true if transparent proxies are in place]. The distinction between these request-routing system types is important because of the differences in: - The view of the content identifier (partial vs. whole). - The view of the client (e.g. client's IP vs. client's local DNS). - The implementation requirements of the two types (e.g. DNS caching). 2.1.1 DNS-Based Request-Routing Systems In DNS-based request-routing systems [ARCH] [DNSMAP], only aggregate sets of content may be "directed" because a domain name (e.g. images.blah.com) can only (reasonably) represent a larger set of content. A DNS request-routing system works well in scenarios where many surrogates share large sets of content. DNS-based request-routing systems suffer from the following limitations: - The request-routing system knows only the domain name of the Cain, et. al. Expires January 2002 ^L[Page 4] Internet-Draft June 2001 requested content. This precludes the RRS from knowing the full content path (e.g. URI) and the content type (e.g. HTTP, RTSP). - The request-routing system knows the client's local DNS server, not the client itself. - The request-routing system responses may be cached in DNS servers. The result is that a client request may not be individually directed by the request-routing system. 2.1.1.1 DNS Example CDN-A is authoritative for http://images.blah.com (or CNAMEs are used to ultimately force a resolution of this name to CDN A). Assume that DNS-based request-router R is part of CDN-A and is also a CPG-A for CDN-A. When R receives a client DNS request for images.blah.com, it makes a request-routing decision. This decision may be to direct the request to its own surrogates or to direct the request to another CDN. This decision is based on the routing computation by CPG-A that in turn is based on "area" and/or "content" advertisements received from neighbors. For example, CPG-A can make a request-routing decision based on the following: 1. Information contained in area advertisements that have been received from interconnected CDNs. An example may be an IP prefix advertised with an associated metric. 2. The ability of interconnected CDNs to support the (content) type of the request. 3. Information contained in content advertisements that may include: content metrics, availability of content, etc. With DNS- based request-routing systems, content specific information is only relevant to the DNS name (e.g. in a URI). 4. Local request-routing policy. If the choice is made to direct the request to another CDN, the appropriate CNAME is used to direct the client's DNS to the chosen neighbor CDN. The process then continues. 2.1.2 "In-Line" Request-Routing Systems A Layer-7 router or Proxy situated close to a client may be used as an "in-line" request-routing system. Such a RRS is capable of directing client requests based on individual full content requests. This is possible because layer-7 information (e.g. HTTP headers) is exposed to the layer-7 router or proxy. In this type of RRS, a surrogate can be chosen based on, for example, a full URL. Another example of in-line request-routing is when an origin server (or reverse proxy) performs a layer-7 redirection by "URL-rewriting". Cain, et. al. Expires January 2002 ^L[Page 5] Internet-Draft June 2001 There are three major differences between an "in-line" request- routing system and a DNS-based request-routing system. The first is that the full content request is exposed (e.g. a full URL). The second is that the content type of the request is exposed (again from the full URL). The third is that all client requests can be received by the request-routing system; this is in contrast to DNS-based systems where caching may prevent this. 2.1.2.1 "In-Line" Example Assume client X is configured to forward its requests to layer-7 router R.. Furthermore assume that CDN-A's request-router R is also a CPG for CDN-A. When a request from client X is received, request- router R makes a request-routing decision based on its internal routing database constructed from information communicated from other CDNs. If request-router R can serve the request as part of its own distribution system then a request is made to a surrogate that is part of that system. If router R's decides to direct the client to another CDN, a redirect is sent to the client to direct the cilent to another layer-7 router in a neighboring CDN. In summary, a request- routing decision is made based on the following: 1. Information contained in area advertisements that have been received from interconnected CDNs. An example may be an IP prefix advertised with an associated metric. 2. The ability of interconnected CDNs to support the content type of the request. An example may be a set of content types supported. 3. Information contained in content advertisements that may include: content metrics, availability of content, etc. For "in- line" request-routing systems this may include full URLs or URL sets. 4. Local request-routing policy. 2.2 Request-Routing Interconnection Model Request-routing systems present a "black-box" view of their associated distribution systems. Since in such an environment nobody possesses a global view of all networks, the request-routing system must also rely on a peer-to-peer model in which each request-routing system is only aware of its direct neighbor. [Note: A direct neighbor of the request-routing systems does not have to be a direct neighbor at Layer-3]. There are two methods for routing a request between two interconnected request-routing systems. The first method is an iterative method where a RRS directs the request to the next-best RRS. This continues until a surrogate is finally selected. The second method is recursive where a RRS directs a request to the next- Cain, et. al. Expires January 2002 ^L[Page 6] Internet-Draft June 2001 best RRS but expects an answer to return to the client. These two methods are analogous to recursive vs. iterative DNS lookups. An example of how requests can be directed between domains is through the use of DNS CNAMEs. When request-routing systems are interconnected using CNAMEs, a clients a clients DNS resolution is redirected using a DNS CNAME record to another DNS-based request- routing system until a surrogate is found that is appropriate (according to a set of metrics) to serve the content. The drawbacks of CNAME based request-routing are discussed in [KNOWN MECH]. 2.3 CDN Capabilities Request-routing systems are associated with one or more distribution systems. When a request-routing system directs a client request it must ensure that: 1. The client request type can be serviced by the distribution system (e.g. HTTP vs. RTSP). 2. The distribution system to which a client is directed has the capacity to service the request. In order to ensure that an interconnected (neighbor) CDN can service a request, a request-routing system is required to have the following information about neighbor CDNs: 1. Request-routing system types. 2. Content types that can be served by the CDN. 3. Sets of metrics that are used for direction. This information maybe obtained manually (off-line) or through the use of dynamic (on-line) information exchange protocols. 2.4 Request-Routing Information Exchange Interconnected request-routing systems need to exchange information in order to make direction (or content routing) decisions. The two request-routing system types presented in section 1.2 have slightly different requirements with respect to the types of information exchanged. In summary, interconnected request-routing systems need to exchange two basic types of information: 1. Area Advertisements: This type of information is related to aggregate network coverage, network capacity, network health, and other related metrics. 2. Content Advertisements: This type of information is related to content (e.g. URLs) and may include for example: content types, Cain, et. al. Expires January 2002 ^L[Page 7] Internet-Draft June 2001 distribution model, authoritative delivery root, etc. Request-routing information exchange follows the model of layer-3 routing protocols. That is, advertisements are sent to neighbors and each request-routing system makes its own decisions. The design of an information exchange protocol must take the following into consideration: - Information exchange may occur over highly unreliable networks. - Information exchange protocols may be required to exchange large sets of advertisement information. - Information exchange may occur over insecure networks. - Arbitrary meshed topologies may exist for information exchange protocols. 2.5 Request-Routing Decision Request-routing systems make decisions based on one or more advertisement types and their associated metrics. Both content advertisements and area advertisements may be used to construct a request-routing table. This table is used to determine how requests should be directed. The request-routing decision process is complex for the following reasons: - Content delivery networks are overlay networks which inherently makes decision processes more complex. - There are many possible metrics; if multiple metrics are exchanged, loop prevention may be difficult. - Request-routing systems may have specific policies with respect to direction. - Request-routing decisions are independent; therefore request- routing loops must be prevented. 2.6 Request-Routing Protocol Design Request-routing systems will require the use of protocols for the exchange of information. These protocols are designed to operate in an inter-domain context and therefore have the following considerations: - Protocol sessions will need to be debugged across CDN boundaries. - Large sets of information may be exchanged between CDNs. - Policy based request-routing is needed in many scenarios. Cain, et. al. Expires January 2002 ^L[Page 8] Internet-Draft June 2001 - Protocol designs should be "Internet" scalable. 3. Request-Routing System and Protocol Requirements 3.1 General Requirements In the following section we describe the general requirements for interconnection of request-routing systems. - Request-routing protocols MUST use an administrative identity to identify themselves in protocol exchanges. - Request-routing protocols SHOULD support arbitrary direction topologies; this means "peer-to-peer" design. - Request-routing protocols MUST treat other networks as "black boxes"; that is, a given CDN A does not normally posses direct visibility into another neighbor CDN B. - Request-routing protocols MUST support methods to determine the authoritative request-routing system for content. - Request-routing protocols SHOULD be compatible with existing applications and protocols. 3.2 Request-Routing System Type Requirements The following section describes the requirements that apply to both DNS-based and in-line request-routing systems. - Request-routing protocols SHOULD support DNS-based and in-line request-routing systems. - Request-routing protocols MUST communicate their request-routing system type to neighbors (e.g. DNS-based). - Request-routing protocols MAY allow for utilization of more than one request-routing system type for content. - Request-routing protocols MUST be able to identify content types for content. 3.2.1 DNS-Based Request-Routing Requirements The following section describes requirements that apply to DNS-based request-routing system types. - Request-routing protocols MUST support CNAME based DNS redirection. Cain, et. al. Expires January 2002 ^L[Page 9] Internet-Draft June 2001 - Request-routing protocols MUST be able to map content types to CNAMEs in order to make proper direction decisions. 3.2.2 In-Line Based Request-Routing Requirements The following section describes requirements that apply to in-line based request-routing system types. - Request-routing protocols MUST support application layer redirection (e.g. HTTP redirection). - Request-routing protocols SHOULD support explicitly configured application gateways and proxies. 3.3 Request-Routing Interconnection Model Requirements - Request-routing protocols MUST allow for delegation of requests to another request-routing system. - Request-routing protocols SHOULD support both iterative and recursive redirection models. - Request-routing protocols SHOULD require that content have only one authoritative request-routing system. - Request-routing protocols MUST verify that neighbor CDNs have the ability to deliver content before directing requests to that neighbor. 3.4 Request-Routing Capabilities Requirements - Request-routing protocols MUST support the advertisement of content type information between neighbors. - Request-routing protocols SHOULD have primitive methods for capability advertisement. 3.5 Request-Routing Information Exchange Requirements 3.5.1 General Information Exchange Requirements - Request-routing protocols MUST define standardized methods for identifying an atomic unit of content. - Request-routing protocols MUST define standardized methods for identifying distribution system capabilities (e.g. content types, layer-3 coverage, etc). Cain, et. al. Expires January 2002 ^L[Page 10] Internet-Draft June 2001 - Request-routing protocol MUST not preclude request-routing systems from implementing policy based routing decisions. - Request-routing protocols MUST support the exchange of multiple basic information types (e.g. area and content advertisements). - Request-routing protocols MUST be able to associate multiple (and optional) metrics with each basic information types. - Request-routing protocols MUST exchange information sufficient to avoid looping of information advertisements. - Request-routing protocols MAY exchange information sufficient to prevent request-routing loops. 3.5.2 Specific Information Exchange Requirements - Request-routing protocols MUST support the exchange of AREA advertisements (e.g. IP prefixes) between request-routing systems. - Request-routing protocol AREA advertisements MUST support the inclusion of multiple capabilities and metrics (e.g. X Mbps, Y CIDR blocks, Z static http). - Request-routing protocols SHOULD define a minimum set of metrics for AREA advertisements. - Request-routing protocols MUST support the exchange of CONTENT UNIT advertisements (e.g. URIs) between request-routing systems. - Request-routing protocol CONTENT UNIT advertisements MUST support the inclusion of multiple metrics. - Request-routing protocol CONTENT UNIT advertisements MUST support the ability to advertise the availability of content. - Request-routing protocol CONTENT UNIT advertisements SHOULD identify the authoritative request-routing system. - Request-routing protocols SHOULD define a minimum set of metrics for CONTENT UNIT advertisements. - Request-routing protocols MUST accommodate hierarchy and aggregation in CONTENT UNIT and AREA advertisements. 3.6 Request-Routing Decision and Policy Requirements - Request-routing protocols MUST be "policy friendly" (e.g. support additional neighbor-to-neighbor extensible attributes). - Request-routing protocols SHOULD support exchange of information sufficient to prevent routing loops. Cain, et. al. Expires January 2002 ^L[Page 11] Internet-Draft June 2001 - Request-routing protocols MAY support multiple metrics for direction decisions as long as routing decisions can be guaranteed loop free. 3.7 Request-Routing Information Exchange Protocol Design Requirements This section describes several specific protocol requirements that have been identified for an inter-domain request-routing exchange protocol. Note that some of these requirements are redundant with other sections; we repeat them here for organization. - Request-routing protocols MUST use a reliable transport protocol. - Request-routing protocols MUST make use of existing IETF developed security mechanisms for encryption and authentication. - Request-routing protocols MUST include protocol notifications for protocol error conditions. - Request-routing protocols SHOULD be connection oriented. - Request-routing protocols MUST provide mechanisms to prevent looping of advertisement information. - Request-routing protocols MUST have extensible packet formats. - Request-routing protocols MUST properly identify neighbors. - Request-routing protocols MUST properly authenticate neighbors. - Request-routing protocols MUST scale to accommodate the exchange of large sets of CONTENT and AREA advertisements. - Request-routing protocols MUST support (at a minimum) a simple capability exchange/advertisement. - Request-routing protocols MUST NOT exchange policy information. - Request-routing protocols MUST accommodate policy based request- routing systems. 4. Security Considerations TBD 5. References [MODEL] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering", draft-day-cdnp-model-03.txt (work in progress), November 2000. Cain, et. al. Expires January 2002 ^L[Page 12] Internet-Draft June 2001 [KNOWN MECH] Cain, B., Douglis, F., Green, M., Hofmann, M., Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request-Routing Mechanisms", draft-cain-cdnp-known-req-route-00.txt (work in progress), November 2000. [ARCH] Green, M., Cain, B. and G. Tomlinson, "CDN Peering Architectural Overview", draft-green-cdnp-gen-arch-02.txt (work in progress), November 2000. [DNSMAP] Deleuze, C., Gautier, L., and M. Hallgren, "A DNS Based Mapping Peering System for Peering CDNs", draft-deleuze-cdnp-dnsmap- peer-00.txt (work in progress), November 2000. 6. Author's Address: Brad Cain Cereva Networks bcain@cereva.com Oliver Spatscheck AT&T Labs spatsch@research.att.com Martin May Activia Networks Martin.May@activia.net Abbie Barbir Nortel Networks abbieb@nortelnetworks.com 7. Acknowledgements Thanks to the following people for their contributions: John Martin, Nalin Mistry, Mark Day, Stephen Thomas, Hillary Orman, Phil Rzewski, and Fred Douglis. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. Cain, et. al. Expires January 2002 ^L[Page 13] Internet-Draft June 2001 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. Cain, et. al. Expires January 2002 ^L[Page 14]