Internet Draft B. Cain
Cereva Networks
O. Spatscheck
AT&T Labs
M. May
Activia Networks
A. Barbir
Nortel Networks
Expires July 2001
Request-Routing Requirements for Content Internetworking
draft-cain-request-routing-req-01.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) which 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 request-routing systems to
interconnect and exchange information such that requests can be
routed between CDNs. This document provides an overview of
request-routing systems and specifies the requirements to interconnect
request-routing systems.
Cain, et. al. Expires September 2001 ^L[Page 1]
Internet-Draft March 2001
1. Introduction
Request-routing systems (RRS) are components of Content Distribution
Networks which 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 a client request to a surrogate
that can "best" service the request [MODEL]. Request-routing
decisions are based on a set of metrics which 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
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 which is not exposed to other
interconnected networks.
5. Request-routing systems interconnect through Content Peering
Cain, et. al. Expires September 2001 ^L[Page 2]
Internet-Draft March 2001
Gateways (CPG) which implement standard 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 depicted. A request-
routing system consists of the following components: Content Topology
Exchange, Content Topology Database and Route Computation. A brief
summary of the 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
A request-routing system is used to direct client requests to
surrogates which are part of its own distribution system. When
request-routing systems are interconnected, a request-router has the
ability to redirect client requests to other CDNs. This is direction
of client requests potentially to other CDNs can be compared to
inter-domain IP routing. That is, when neighbor CDN has a better
metric it may be desirable to direct a client request to that
neighbor CDN. In order to determine which CDN may best serve a
request, one or more protocols may be required to exchange various
types of information.
Cain, et. al. Expires September 2001 ^L[Page 3]
Internet-Draft March 2001
This document describes both the components of a request-routing
system and the methods for interconnecting these systems. The
requirements for interconnecting these systems are also described.
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 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 which 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
Cain, et. al. Expires September 2001 ^L[Page 4]
Internet-Draft March 2001
limitations:
- The request-routing system knows only to the domain name of the
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.
One example of a redirection using DNS is through use of DNS CNAMEs.
In a CNAME based DNS request-routing system a clients DNS resolution
is redirected using a DNS CNAME record to another DNS-based request-
routing system until a surrogate is found which 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.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). When CPG-A
receives the 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 which 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 which 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 which 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.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 request-
Cain, et. al. Expires September 2001 ^L[Page 5]
Internet-Draft March 2001
routing system, 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".
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 router R is a request-router and
CPG for CDN-A. When a request from X is received, router R makes a
request-routing decision based on its internal routing database
constructed from information communicated from other CDNs. If router
R can serve the request as part of its own distribution system then a
request is made to a surrogate which is part of that system. If
router R's decision is to direct the client to another CDN, a
redirect can be 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 from 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
posseses 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].
Cain, et. al. Expires September 2001 ^L[Page 6]
Internet-Draft March 2001
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-
best RRS but expects an answer to return to the client. These two
methods are analogous to recursive vs. iterative DNS lookups.
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 which 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. Information related to aggregate network coverage, network
capacity, network health, and other related metrics. This type of
information is termed "area advertisements".
2. Information which describes content. This may be for example
per URL information and may include: content type, distribution
model, authoritative delivery root, etc. This type of information
is termed "content advertisements".
Request-routing information exchange follows the model of layer-3
Cain, et. al. Expires September 2001 ^L[Page 7]
Internet-Draft March 2001
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.
- Although routing decisions are independent, request-routing loops
are undesirable.
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.
- Protocol designs should be "Internet" scalable.
Cain, et. al. Expires September 2001 ^L[Page 8]
Internet-Draft March 2001
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 MUST support arbitrary direction
topologies; this means "peer-to-peer" design.
- Request-routing protocols SHOULD treat other networks as "black
boxes"; that is, a given CDN A does not normally posses direct
visibility into another neighbor CDN B. [note: possible MUST]
- Request-routing systems MUST be able to respond to a direction
request for content for which it is authoritative.
- Request-routing systems MUST be transparent to the end-user and
avoid violation of the end-to-end principles of the Internet
architecture.
3.2 Request-Routing Type Requirements
The following section describes the requirements that apply to both
DNS-based and in-line request-routing systems.
- Request-routing protocols MUST support DNS-based and in-line
request-routing systems.
- A request-routing system MUST be able to support at least one
common type of request-routing.
- Request-routing protocols MUST communicate their request-routing
type to neighbors.
- Request-routing systems MAY be able to utilize more than one type
of request-routing for a single piece of content.
- Common formats for content identification SHOULD exist such that
DNS direction may occur based on content type (e.g. streaming
content vs. static content has to be identifiable using the DNS
name alone). This may require standardization of DNS names in
URI/URLs (for content distributed on CDNs) such that content types
can be identified. [note: possible MUST]
3.2.1 DNS-Based Request-Routing Requirements
Cain, et. al. Expires September 2001 ^L[Page 9]
Internet-Draft March 2001
- CNAME based DNS request-routing MUST be supported by the request-
routing system.
- DNS-based request-routing MUST use domain names that provide the
capability to make a useful routing decision based on a DNS name
alone.
- DNS-based request-routing SHOULD use DNS names that allow content
types to be identified. [note: possible MUST]
3.2.2 In-Line Based Request-Routing Requirements
- Both HTTP and RTSP allow the redirection of clients on the
application layer. The protocols introduced by the request-routing
system MUST support the option of using this methods to redirect
clients to surrogates.
- Interception proxies are widely deployed in todays Internet and
MUST be supported by the request-routing protocol. To support
interception proxies the protocol MUST provide enough information
such that an interception element can decide if a particular
request should be intercepted. [note: disagreement on this point]
3.3 Request-Routing Interconnection Model Requirements
- Both iterative and recursive redirection models MUST be
supported.
- Each piece of content MUST have one authoritative request-routing
system.
- The authoritative request-routing system MAY make the entire
routing decision or use an iterative or recursive model to
determine the surrogate.
3.4 Request-Routing Capabilities Requirements
- A request-routing system SHOULD verify that neighbor CDNs have
the ability to delivery a given type of content before exchanging
any request-routing information regarding that content type.
- A request-routing system MUST be able to advertise which request-
routing system types it supports (e.g. DNS vs. in-line).
- A request-routing system MUST be able to advertise which content
types it supports (e.g. streaming vs. static).
- A request-routing system MUST be able to support generic
capability negotiation. [note: this may be simple advertisement or
more complex negotiation]
Cain, et. al. Expires September 2001 ^L[Page 10]
Internet-Draft March 2001
- A request-routing system MUST have the ability to diagnose
negotiation failures.
3.5 Request-Routing Information Exchange Requirements
3.5.1 General Information Exchange Requirements
- Information exchange protocols MUST define standardized methods
for identifying an atomic unit of content.
- Information exchange protocols MUST define standardized methods
for identifying distribution system capabilities (e.g. content
types, layer-3 coverage, etc).
- Information exchange protocol MUST not preclude request-routing
systems from implementing policy based routing decisions.
- Information exchange protocols MUST support the exchange of
multiple basic information types (e.g. area and content
advertisements).
- Information exchange protocols MUST be able to associate multiple
(and optional) metrics with each basic information types.
- Information exchange protocols MUST exchange information
sufficient to avoid looping of information advertisements.
- Information exchange protocols MUST exchange information
sufficient to prevent request-routing loops.
3.5.2 Specific Information Exchange Requirements
- Information exchange protocols MUST support the exchange of AREA
advertisements (e.g. IP prefixes) between request-routing systems.
- AREA advertisements MUST support the inclusion of multiple
capabilities and metrics (e.g. X Mbps, Y CIDR blocks, Z static
http).
- To increase the likelihood of interoperability between request-
routing systems, protocols SHOULD define a minimum set of metrics
for AREA advertisements which are required to conform to the
protocol specification.
- Information exchange protocols MUST support the exchange of
CONTENT UNIT advertisements (e.g. URIs) between request-routing
systems.
- CONTENT UNIT advertisements MUST support the inclusion of
multiple metrics.
Cain, et. al. Expires September 2001 ^L[Page 11]
Internet-Draft March 2001
- CONTENT UNIT advertisements MUST support the ability to advertise
the availability of content per particular distribution methods
(e.g. push).
- CONTENT UNIT advertisements MUST identify the authoritative
request-routing system.
- To increase the likelihood of interoperability between request-
routing systems, protocols SHOULD define a minimum set of metrics
for CONTENT UNIT advertisements which are required to conform to
the protocol specification.
- Information exchange protocols MUST accommodate hierarchy and
aggregation in CONTENT UNIT and AREA advertisements.
3.6 Request-Routing Decision and Policy Requirements
- Request-routing information exchange protocols MUST be "policy
friendly" (e.g. support additional neighbor-to-neighbor extensible
attributes).
- At a minimum the decision entity of a request-routing system MUST
guarantee that a neighbor CDN is capable to serve the content with
high probability before redirecting clients to the neighbor.
- Request-routing systems and protocols MUST provide methods to
avoid request-routing loops.
- Request-routing systems MAY use multiple metrics for the
direction decision 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 which
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.
- Information exchange protocols MUST include transit information
that allows to construct a graph of the connected CDNs. This graph
information MUST be used to prevent request-routing loops.
- Information exchange protocols SHOULD use a reliable transport
protocol.
- Information exchange protocols MUST support the use of IPSec or
similar security measures. Protocols SHOULD make use of existing
IETF developed security mechanisms for encryption and
authentication.
- Information exchange protocols SHOULD include error
Cain, et. al. Expires September 2001 ^L[Page 12]
Internet-Draft March 2001
notifications. For example, if a RRP station receives a ill-
formatted message, it will report the error to its neighbor by
sending a notification message.
- Information exchange protocols SHOULD be connection oriented.
- Information exchange protocols SHOULD support neighbor discovery.
[note: disagreement]
- Information exchange protocols MUST provide mechanisms to prevent
looping of advertisement information.
- Information exchange protocols for MUST have extensible packet
formats.
- Information exchange protocols SHOULD provide properly identify
neighbors.
- Information exchange protocols MUST scale to accommodate the
exchange of large sets of CONTENT and AREA advertisements.
- Information exchange protocols MUST support (at a minimum) a
simple capability exchange/advertisement.
- Information exchange protocols SHOULD NOT exchange policy
information.
- Information exchange 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.
[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-
Cain, et. al. Expires September 2001 ^L[Page 13]
Internet-Draft March 2001
peer-00.txt (work in progress), November 2000.
APPENDIX A. Open and Interesting Issues
In this section we present several open issues with respect to the
information exchange protocols. Note that many of these are
implementation specific.
- How should data be represented in the information exchange
protocols (e.g. XML vs. byte encoding)?
- How should the information exchange protocols support multiple
languages (e.g. per DNS and URIs)?
- How can large amounts of content specific information be
exchanged in a scalable fashion? Should compression and/or delta-
encoding techniques be used? Should hashing techniques be used?
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
12. 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.
Cain, et. al. Expires September 2001 ^L[Page 14]
Internet-Draft March 2001
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.
Cain, et. al. Expires September 2001 ^L[Page 15]