draft-ietf-cdni-use-cases-00.txt		draft-ietf-cdni-use-cases-01.txt
	Internet Engineering Task Force G. Bertrand, Ed.		Internet Engineering Task Force G. Bertrand, Ed.
	Internet-Draft E. Stephan		Internet-Draft E. Stephan
	Intended status: Informational France Telecom - Orange		Intended status: Informational France Telecom - Orange
	Expires: March 25, 2012 G. Watson		Expires: June 23, 2012 G. Watson
	T. Burbridge		T. Burbridge
	P. Eardley		P. Eardley
	BT		BT
	K. Ma		K. Ma
	Azuki Systems		Azuki Systems
	September 22, 2011		December 21, 2011
	Use Cases for Content Delivery Network Interconnection		Use Cases for Content Delivery Network Interconnection
	draft-ietf-cdni-use-cases-00		draft-ietf-cdni-use-cases-01
	Abstract		Abstract
	Content Delivery Networks (CDNs) are commonly used for improving the		Content Delivery Networks (CDNs) are commonly used for improving the
	footprint and the end-user experience of a content delivery service,		End User experience of a content delivery service, at a reasonable
	at a reasonable cost. This document outlines real world use-cases		cost. This document outlines real world use cases (not technical
	(not technical solutions) for interconnecting CDNs. It can be used		solutions) for interconnecting CDNs. It can be used to provide
	to provide guidance to the CDNI WG about the interconnection		guidance to the CDNI WG about the interconnection arrangements to be
	arrangements to be supported and to validate the requirements of the		supported and to validate the requirements of the various CDNI
	various CDNI interfaces.		interfaces.
	This document describes a number of use cases that motivate CDN
	Interconnection. It represents a work in progress and may be
	extended later to cover additional use-cases.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 25, 2012.		This Internet-Draft will expire on June 23, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	skipping to change at page 3, line 9		skipping to change at page 3, line 9
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5		1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5
	1.4. The Need for CDNI Standards . . . . . . . . . . . . . . . 7		1.4. The Need for CDN Interconnection Standards . . . . . . . . 6
	2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7		2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7
	2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7		2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7
	2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8		2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8
	2.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8		2.3. Mastering Incoming Traffic . . . . . . . . . . . . . . . . 8
	3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 8		2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 8		3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 10
	3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 10
	3.2.1. Failure of Content Delivery Resources . . . . . . . . 9		3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.2. Failure of Content Acquisition . . . . . . . . . . . . 9		3.2.1. Failure of Content Delivery Resources . . . . . . . . 10
	4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 9		3.2.2. Content Acquisition Resiliency . . . . . . . . . . . . 10
	4.1. Device and Network Technology Extension . . . . . . . . . 10		4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 11
	4.2. Technology and Vendor Interoperability . . . . . . . . . . 10		4.1. Device and Network Technology Extension . . . . . . . . . 11
	4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 11		4.2. Technology and Vendor Interoperability . . . . . . . . . . 12
	5. Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 11		4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12
	5.1. Content Availability . . . . . . . . . . . . . . . . . . . 11		5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 13
	5.1.1. Geo-location Restrictions . . . . . . . . . . . . . . 11		5.1. Content Availability . . . . . . . . . . . . . . . . . . . 13
	5.1.2. Temporal Restrictions . . . . . . . . . . . . . . . . 12
	5.1.3. Content Encoding Restrictions . . . . . . . . . . . . 12
	5.2. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.2. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Secure Access . . . . . . . . . . . . . . . . . . . . . . 13		5.3. Secure Access . . . . . . . . . . . . . . . . . . . . . . 14
	6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Content Delivery Networks (CDNs) are commonly used for improving the		Content Delivery Networks (CDNs) are commonly used for improving the
	footprint and the end-user experience of a content delivery service,		End User experience of a content delivery service, at a reasonable
	at a reasonable cost. This document outlines real world use-cases		cost. This document outlines real world use cases (not technical
	(not technical solutions) for interconnecting CDNs. It can be used		solutions) for interconnecting CDNs. It can be used to provide
	to provide guidance to the CDNI WG about the interconnection		guidance to the CDNI WG about the interconnection arrangements to be
	arrangements to be supported and to validate the requirements of the		supported and to validate the requirements of the various CDNI
	various CDNI interfaces.		interfaces.
	This document describes a number of use cases that motivate CDN
	Interconnection. It represents a work in progress and may be
	extended later to cover additional use-cases.
	This document identifies the main motivations for a CDN Provider to		This document identifies the main motivations for a CDN Provider to
	interconnect its CDN:		interconnect its CDN:
	o CDN Footprint Extension Use Cases (Section 2)		o CDN Footprint Extension Use Cases (Section 2)
	o CDN Offload Use Cases (Section 3)		o CDN Offload Use Cases (Section 3)
	o CDN Capability Use Cases (Section 4)		o CDN Capability Use Cases (Section 4)
	Then, the document highlights the need for interoperability to		Then, the document highlights the need for interoperability to
	exchange and enforce content delivery policies (Section 5).		exchange and enforce content delivery policies (Section 5).
	1.1. Terminology		1.1. Terminology
	We adopt the terminology described in		We adopt the terminology described in
	[I-D.ietf-cdni-problem-statement], [RFC3466], and [RFC3568], except		[I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework],
	for the terms defined below.		[RFC3466], and [RFC3568].
	Authoritative CDN (aCDN):
	A CDN provider contracted by the CSP for delivery of content by its
	CDN or by its downstream CDNs.
	Access CDN:		Access CDN:
	A CDN that is connected to the end-user's access and has information		A CDN that is directly connected to the End User's access. An Access
	about the end-user's profile and access capabilities.		CDN may have specific information about the End User and the network,
			for instance, End User's profile and access capabilities.
	Delivering CDN:		Delivering CDN:
	The CDN that delivers the requested content asset to the end-user.		The CDN that delivers the requested piece of content to the End User.
	In particular, the delivering CDN can be an access CDN.		In particular, the delivering CDN can be an Access CDN.
	[Ed. Note: Definition of recursive and iterative request routing
	should be added to [I-D.davie-cdni-framework].]
	CDN Interconnection:
	Relationship between two CDNs that enables a CDN to provide content
	delivery services on behalf of another CDN. It relies on a set of
	interfaces over which two CDNs communicate in order to achieve the
	delivery of content to end-users by one CDN (the downstream CDN) on
	behalf of another CDN (the upstream CDN).
	CDN peering: A business relation between two CDN providers based on
	one or more CDN Interconnections.
	1.2. Abbreviations		1.2. Abbreviations
	[Ed. Note: List of abbreviations to be updated later]		o CDN: Content Delivery Network also known as Content Distribution
			Network
	o CSP: Content Service Provider		o CSP: Content Service Provider
	o dCDN: downstream CDN		o dCDN: downstream CDN
			o DNS: Domain Name System
			o DRM: Digital Rights Management
			o EU: End User
			o ISP: Internet Service Provider
	o NSP: Network Service Provider		o NSP: Network Service Provider
	o QoE: Quality of Experience		o QoE: Quality of Experience
	o QoS: Quality of Service		o QoS: Quality of Service
	o SLA: Service Level Agreement
	o uCDN: upstream CDN		o uCDN: upstream CDN
	o UA: User Agent		o URL: Uniform Resource Locator
	o UE: User Equipment
	o VoD: Video on Demand
	o WiFi: Wireless Fidelity		o WiFi: Wireless Fidelity
	1.3. Rationale for Multi-CDN Systems		1.3. Rationale for Multi-CDN Systems
	Content Delivery Networks (CDNs) are used to deliver content because		Content Delivery Networks (CDNs) are used to deliver content because
	they can:		they can:
	o improve the experience for the End User; for instance delivery has		o improve the experience for the End User; for instance delivery has
	lower latency and better robustness,		lower latency (decreased round-trip-time between the user and the
			delivery server) and better robustness,
	o reduce the operator's costs; for instance lower delivery cost		o reduce the network operator's costs; for instance, lower delivery
	(reduced bandwidth usage) for cacheable content,		cost (reduced bandwidth usage) for cacheable content,
	o reduce the Content Service Provider costs, such as datacenter		o reduce the Content Service Provider's (CSP) costs, such as
	capacity, space, and electricity consumption.		datacenter capacity, space, and electricity consumption, as
			popular content is delivered through the CDN rather than through
			the CSP's servers.
	Indeed, many network service providers and enterprise service		Indeed, many Network Service Providers (NSPs) and enterprise service
	providers are deploying or have deployed their own CDNs. Despite the		providers are deploying or have deployed their own CDNs. Despite the
	potential benefits of interconnecting CDNs, today each CDN is a		potential benefits of interconnecting CDNs, today each CDN is a
	standalone network. The objective of CDN interconnection is to		standalone network. The objective of CDN Interconnection is to
	overcome this restriction: the interconnected CDNs should be able to		overcome this restriction: the interconnected CDNs should be able to
	collectively behave as a single delivery infrastructure.		collectively behave as a single delivery infrastructure.
	Let's take an example, as depicted in Figure 1. Two CDN Providers		An example is depicted in Figure 1. Two CDN Providers establish a
	establish a CDN Interconnection. The Content Service Provider CSP-1		CDN Interconnection. The Content Service Provider CSP-1 reaches an
	reaches an agreement with CDN Provider A for the delivery of its		agreement with CDN Provider 'A' for the delivery of its content. CDN
	content. CDN Provider A and CDN Provider B agree to interconnect		Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.
	their CDNs. When a User Agent that is connected to CDN Provider B's
	network requests Content from CSP-1, the Content is actually
	delivered from CDN-B, because handling of requests for CSP-1's
	Content has been delegated as part of the CDN Interconnection
	agreement. The End User benefits through a better quality of
	experience, because the Content is delivered from a nearby Surrogate.
	CDN Provider A benefits because it doesn't need to deploy such an
	extensive CDN, whilst CDN Provider B receives some compensation for
	the delivery. CSP-1 benefits because it only needs to make one
	business agreement and one physical connection, with CDN Provider A,
	but its End Users get a service quality as though CSP-1 had also gone
	to the trouble of making a business agreement with CDN Provider B.
	+-------+ +-------+		When a User Agent requests content from CSP-1, CDN-A considers that
	| CSP-1 | | CSP-2 |		delivery by CDN-B is appropriate, for instance, because CDN-B is an
	+-------+ +-------+		Access CDN and the user is directly attached to it. CDN-A has
	| |		delegated the handling of requests for CSP-1's content through the
	,--,--,--. ,--,--,--.		CDN Interconnection agreement, thus, the content is actually
	,-' `-. ,-' `-.		delivered from CDN-B.
	( CDN Provider A )=====( CDN Provider B )
	`-. (CDN-A) ,-' `-. (CDN-B) ,-'		The End User benefits from this arrangement through a better Quality
	`--'--'--' `--'--'--'		of Experience (QoE), because the content is delivered from a nearby
	|		Surrogate. CDN Provider 'A' benefits because it does not need to
	+------------+		deploy such an extensive CDN, whilst CDN Provider 'B' may receive
	| User Agent |		some compensation for the delivery. CSP-1 benefits because it only
	+------------+		needs to make one business agreement and one physical connection,
			with CDN Provider 'A', but its End Users get a service quality as
			though CSP-1 had also gone to the trouble of making a business
			agreement with CDN Provider 'B'.
			+-------+ +-------+
			| CSP-1 | | CSP-2 |
			+-------+ +-------+
			| |
			,--,--,--./ ,--,--,--.
			,-' `-. ,-' `-.
			(CDN Provider 'A')=====(CDN Provider 'B')
			`-. (CDN-A) ,-' `-. (CDN-B) ,-'
			`--'--'--' `--'--'--'
			|
			+------------+
			| User Agent |
			+------------+
	=== CDN Interconnection		=== CDN Interconnection
	Figure 1		Figure 1
	To extend the example, another Content Service Provider, CSP-3, may		To extend the example, another Content Service Provider, CSP-2, may
	also reach an agreement with CDN Provider A. But it does not want its		also reach an agreement with CDN Provider 'A'. But it does not want
	Content to be distributed by CDN Provider B, for example, CSP-3 may		its content to be distributed by CDN Provider B; for example, CSP-2
	not have distribution rights in the country where CDN Provider B		may not have distribution rights in the country where CDN Provider
	operates. This example illustrates that policy considerations are an		'B' operates. This example illustrates that policy considerations
	important part of CDNI.		are an important part of CDNI.
	1.4. The Need for CDNI Standards		1.4. The Need for CDN Interconnection Standards
			The problem statement draft [I-D.ietf-cdni-problem-statement]
			describes extensively the CDNI problem space and explains why CDNI
			standards are required.
	Existing CDN interfaces are proprietary and have often been designed		Existing CDN interfaces are proprietary and have often been designed
	for intra-CDN/intra-domain operations. So an external CDN typically		for intra-CDN/intra-domain operations. Consequently, an external CDN
	cannot use them, especially if the two CDNs rely on different		typically cannot use these interfaces, especially if the two CDNs to
	implementations. Nevertheless, [I-D.bertrand-cdni-experiments] shows		be interconnected rely on different implementations. Nevertheless,
	that some level of CDN interconnection can be achieved experimentally		[I-D.bertrand-cdni-experiments] shows that some level of CDN
	without standardized interfaces between the CDNs. However, the		Interconnection can be achieved experimentally without standardized
	methods used in these experiments are hardly usable in an operational		interfaces between the CDNs. However, the methods used in these
	context, because they suffer from several limitations in terms of		experiments are hardly usable in an operational context, because they
	functionalities, scalability, and security level.		suffer from several limitations in terms of functionalities,
			scalability, and security level.
	The aim of IETF CDNI WG's solution is therefore to overcome such		The aim of IETF CDNI WG's solution is, therefore, to overcome such
	shortcomings; a full list of requirements is being developed in		shortcomings; a full list of requirements is being developed in
	[I-D.ietf-cdni-requirements].		[I-D.ietf-cdni-requirements].
	2. Footprint Extension Use Cases		2. Footprint Extension Use Cases
	Footprint extension is expected to be a major use case for CDN		Footprint extension is expected to be the major use case for CDN
	interconnection.		Interconnection.
	2.1. Geographic Extension		2.1. Geographic Extension
	In this use case, the CDN Provider wants to extend the geographic		In this use case, the CDN Provider wants to extend the geographic
	distribution that it can offer to its CSPs:		distribution that it can offer to its CSPs:
	o without compromising the quality of delivery,		o without compromising the quality of delivery,
	o without incurring additional transit and other network costs that		o without incurring additional transit and other network costs that
	would result from serving content from geographically or		would result from serving content from geographically or
	topologically remote surrogates.		topologically remote Surrogates.
	If there are several CDN Providers that have a geographically limited		If there are several CDN Providers that have a geographically limited
	footprint (e.g., restricted to one country), or do not serve all end-		footprint (e.g., restricted to one country), or do not serve all End
	users in a geographic area, then interconnecting their CDNs enables		Users in a geographic area, then interconnecting their CDNs enables
	CDN Providers to provide their services beyond their own footprint.		these CDN Providers to provide their services beyond their own
			footprint.
	As an example, suppose a French CSP wants to distribute its TV		As an example, suppose a French CSP wants to distribute its TV
	programs to End Users located in France and various countries in		programs to End Users located in France and various countries in
	North Africa. It asks a French CDN Provider to deliver the content.		North Africa. It asks a French CDN Provider to deliver the content.
	The French CDN Provider's network only covers France, so it makes an		The French CDN Provider's network only covers France, so it makes an
	agreement with another CDN Provider that covers North Africa.		agreement with another CDN Provider that covers North Africa.
	Overall, from the CSP's perspective the French CDN Provider provides		Overall, from the CSP's perspective the French CDN Provider provides
	a CDN service for both France and North Africa.		a CDN service for both France and North Africa.
	In addition to video, this use case applies to other types of content		In addition to video, this use case applies to other types of content
	such as automatic software updates (browser updates, operating system		such as automatic software updates (browser updates, operating system
	patches, virus database update, etc).		patches, virus database update, etc).
	2.2. Inter-Affiliates Interconnection		2.2. Inter-Affiliates Interconnection
	skipping to change at page 8, line 22		skipping to change at page 8, line 14
	patches, virus database update, etc).		patches, virus database update, etc).
	2.2. Inter-Affiliates Interconnection		2.2. Inter-Affiliates Interconnection
	In the previous section, we have described the case of geographic		In the previous section, we have described the case of geographic
	extension between CDNs operated by different entities. A large CDN		extension between CDNs operated by different entities. A large CDN
	Provider may also operate CDNs from several subsidiaries (which may		Provider may also operate CDNs from several subsidiaries (which may
	rely on different CDN solutions, see Section 4.2). In certain		rely on different CDN solutions, see Section 4.2). In certain
	circumstances, the CDN Provider needs to make its CDNs interoperate		circumstances, the CDN Provider needs to make its CDNs interoperate
	to provide a consistent service to its customers on its whole		to provide a consistent service to its customers on its whole
	footprint.		footprint. For example, the CDN Provider might want to expose a
			single set of interfaces to the CSPs.
	2.3. Nomadic Users		2.3. Mastering Incoming Traffic
	In this scenario a CSP wishes to allow users who move to other		Consider an ISP carrying to its subscribers a lot of content that
	geographic regions to continue to access their content. The		comes from a third party CSP and that is injected into the access
	motivation in this case is to allow nomadic users to maintain access		network by an Authoritative CDN Provider. There are mutual benefits
	with consistent quality of experience, rather than to allow all		to the Access CDN, the Authoritative CDN, and the CSP that would make
	residents within a region access to the content.		a case for establishing a CDNI agreement. For example:
	[Ed. Note: expand on which CDNs need to be interconnected to address		o Allow the CSP to offer improved QoE and QoE services to
	the use case (ie with CDN of "home NSP" interconnected to CDN of		subscribers, for example, QoS and reduced round trip time.
	visited NSP). Add a picture for clarifying the text. Use the term
	"TV everywhere"?]
	This use case covers situations like users moving between different		o Allow the Authoritative CDN to reduce hardware capacity and
	CDN Providers within the same geographic region, or users switching		footprint, by using the ISP caching and delivery capacity.
	between different devices, as discussed in Section 4.
			o Allow the ISP to reduce traffic load on some segments of the
			network by caching inside of the ISP network.
			o Allow the ISP to influence and/or control the traffic ingestion
			points.
			o Allow the ISP to derive some incremental revenue for transport of
			the traffic and to monetize QoE services.
			2.4. Nomadic Users
			In this scenario, a CSP wishes to allow End Users who move between
			CDNs to continue to access their content. The motivation of this
			case is to allow nomadic End Users to maintain access to content with
			a consistent QoE, across a range of devices and/or geographic
			regions.
			This use case covers situations like:
			o End Users moving between different CDN Providers, which may reside
			within the same geographic region or different geographic regions,
			o End Users switching between different devices or delivery
			technologies, as discussed in Section 4.
			The term "Nomadic" does not necessarily relate to geographic roaming.
			Consider the following example, illustrated in Figure 2: End User A
			has subscription to a broadband service from NSP A, her "home NSP".
			NSP A hosts CDN-A. Ordinarily, when End User A accesses content via
			NSP A (her "home NSP") the content is delivered from CDN-A, which in
			this example is within NSP A's network.
			However, while End User A is not connected to NSP A's network, for
			example, because it is connected to a WiFi provider or mobile
			network, End User A can also access the same content. In this case,
			End User A may benefit from accessing the same content but delivered
			by an alternate CDN (CDN-B), in this case, hosted in the network of
			the WiFi or mobile provider, rather than from CDN-A in NSP A's
			network.
			+-------+
			|Content|
			+-------+
			|
			,--,--,--. ,--,--,--.
			,-' NSP A `-. ,-' NSP B `-.
			( (CDN-A) )=====( (CDN-B) )
			`-. ,-' `-. ,-'
			`--'--'--' `--'--'--'
			| |
			+------------+ +---------------+
			+ EU A (home)| | EU A (nomadic)|
			+------------+ +---------------+
			=== CDN Interconnection
			Figure 2
			The alternate CDN (CDN-B) is allowed to distribute the content of CSP
			A to End User A; however, no other End Users in the region of CDN B
			are allowed to retrieve the content unless they too have such an
			agreement for nomadic access to content.
			Depending on CSP's content delivery policies (see Section 5.1), a
			user moving to a different geographic region may be subject to geo-
			blocking content delivery restrictions. In this case, he/she may not
			be allowed to access some pieces of content.
	3. Offload Use Cases		3. Offload Use Cases
	3.1. Overload Handling and Dimensioning		3.1. Overload Handling and Dimensioning
	A CDN is likely to be dimensioned to support the prime-time traffic.		A CDN is likely to be dimensioned to support an expected maximum
	However, unexpected spikes in content popularity may drive load		traffic load. However, unexpected spikes in content popularity
	beyond the expected peak. The prime recurrent time peaks of content		(flash crowd) may drive load beyond the expected peak. The prime
	distribution may differ between two CDNs. Taking advantage of the		recurrent time peaks of content distribution may differ between two
	different traffic peak times, a CDN may interconnect with another CDN		CDNs. Taking advantage of the different traffic peak times, a CDN
	to increase its effective capacity during the peak of traffic. This		may interconnect with another CDN to increase its effective capacity
	brings dimensioning savings to the CDNs as they can use the resources		during the peak of traffic. This brings dimensioning savings to the
	of each other during their respective peaks of activity..		CDNs as they can use the resources of each other during their
			respective peaks of activity.
	Offload also applies to planned situations where a CDN Provider needs		Offload also applies to planned situations where a CDN Provider needs
	CDN capacities in a particular region during a short period of time.		CDN capacities in a particular region during a short period of time.
	For example, a CDN can offload traffic to another CDN during a		For example, a CDN can offload traffic to another CDN during a
	specific maintenance operation or for covering the distribution of a		specific maintenance operation or for covering the distribution of a
	special event. For instance, consider a TV-channel which has		special event. For instance, consider a TV-channel which has
	exclusive distribution rights on a major event, such as a		exclusive distribution rights on a major event, such as a
	celebrities' wedding, or a major sport competitions. The CDNs that		celebrities' wedding, or a major sport competition. The CDNs that
	the TV-channel uses for delivering the content related to this event		the TV-channel uses for delivering the content related to this event
	are likely to experience a flash crowd during the event and to need		are likely to experience a flash crowd during the event and to need
	offloading traffic, while other CDNs will support a more usual		offloading traffic, while other CDNs will support a more usual
	traffic load and be able to handle the offloaded traffic load.		traffic load and be able to handle the offloaded traffic.
			In this use case, the Delivering CDN on which requests are offloaded
			should be able to handle the offloaded requests. Therefore, the uCDN
			might require information on the dCDNs to be aware of the amount of
			traffic it can offload to every dCDN.
	3.2. Resiliency		3.2. Resiliency
	3.2.1. Failure of Content Delivery Resources		3.2.1. Failure of Content Delivery Resources
	It is important for CDNs to be able to guarantee service continuity		It is important for CDNs to be able to guarantee service continuity
	during partial failures (e.g., failure of some Surrogates). In		during partial failures (e.g., failure of some Surrogates). In
	partial failure scenarios, a CDN Provider could redirect some		partial failure scenarios, a CDN Provider has at least two options:
	requests towards another CDN, which must be able to serve the		(1) depending on traffic management policies, forward some requests
	redirected requests or, depending on traffic management policies, to		to the CSP's origin servers, and (2) redirect some requests toward
	forward these requests to the CSP's origin server.		another CDN, which must be able to serve the redirected requests.
	3.2.2. Failure of Content Acquisition		3.2.2. Content Acquisition Resiliency
	Source content acquisition is typically handled in one of two ways:		Source content acquisition may be handled in one of two ways:
	o CDN origin, where a downstream CDN acquires content from an		o CSP origin, where a CDN acquires content directly from the CSP's
	upstream CDN, and the authoritative CDN acquires content from an		origin server, or
	origin server of the CSP, or
	o Other origin, where the CDNs acquire content directly from an		o CDN origin, where a downstream CDN acquires content from a
	origin server outside the uCDN.		Surrogate within an upstream CDN.
	Resiliency may be required against failure to ingest content. If a		The ability to support content acquisition resiliency, is an
	CDN is unable to retrieve the content, it may be that the CSP's		important use case for interconnected CDNs. When the content
	origin server is inaccessible to only this CDN, in which case		acquisition source fails, the CDN might switch to another content
	redirection of the end-users to an alternative CDN may circumvent the		acquisition source. Similarly, when several content acquisition
	problem. A CSP may also choose to specify one or more backup origin		sources are available, a CDN might balance the load between these
	servers.		multiple sources.
			Though other server and/or DNS load balancing techniques may be
			employed in the network, interconnected CDNs may have a better
			understanding of origin server availability and be better equipped to
			both distribute load between origin servers and attempt content
			acquisition from alternate origin servers when acquisition failures
			occur. When normal content acquisition fails, a CDN may need to try
			other origin server options, e.g.:
			o an upstream CDN may acquire content from an alternate CSP origin
			server,
			o a downstream CDN may acquire content from an alternate Surrogate
			within an upstream CDN, as directed by the upstream CDN's request
			routing interface,
			o a downstream CDN may acquire content from an alternate upstream
			CDN, or
			o a downstream CDN may acquire content directly from the CSP's
			origin server.
			Though content acquisition protocols are beyond the scope of CDNI,
			the selection of content acquisition sources should be considered.
	4. CDN Capability Use Cases		4. CDN Capability Use Cases
	4.1. Device and Network Technology Extension		4.1. Device and Network Technology Extension
	In this use case, the CDN Provider may have the right geographic		In this use case, the CDN Provider may have the right geographic
	footprint, but may wish to extend the supported range of devices and		footprint, but may wish to extend the supported range of devices and
	User Agents or the range of supported delivery technologies. In this		User Agents or the supported range of delivery technologies. In this
	case, a CDN Provider may interconnect with a CDN that offers		case, a CDN Provider may interconnect with a CDN that offers
	services:		services:
	o that its own CDN is not able to support or,		o that the CDN Provider is not willing to provide or,
			o that its own CDN is not able to support
	o that the CDN provider is not willing to provide.
	The following examples illustrate this use case:		The following examples illustrate this use case:
	1. CDN-A cannot support a specific delivery protocol. For instance,		1. CDN-A cannot support a specific delivery protocol. For instance,
	CDN-A may interconnect with CDN-B to serve a proportion of its		CDN-A may interconnect with CDN-B to serve a proportion of its
	traffic that requires HTTPS. CDN-A may use CDN-B's footprint		traffic that requires HTTPS. CDN-A may use CDN-B's footprint
	(which may overlap with its own) to deliver HTTPS without needing		(which may overlap with its own) to deliver HTTPS without needing
	to deploy its own infrastructure. This case could also be true		to deploy its own infrastructure. This case could also be true
	of other formats, delivery protocols (RTMP, RTSP, etc.) and		of other formats, delivery protocols (RTMP, RTSP, etc.) and
	features (specific forms of tokenization, per session encryption,		features (specific forms of authorization such as tokens, per
	etc.).		session encryption, etc.).
	2. CDN-A has footprint covering traditional fixed line broadband and		2. CDN-A has footprint covering traditional fixed line broadband and
	wants to extend coverage to mobile devices. In this case, CDN-A		wants to extend coverage to mobile devices. In this case, CDN-A
	may contract and interconnect with CDN-B who has both:		may contract and interconnect with CDN-B who has both:
	* physical footprint inside the mobile network,		* physical footprint inside the mobile network,
	* the ability to deliver content over a protocol that is		* the ability to deliver content over a protocol that is
	required by specific mobile devices and not supported by		required by specific mobile devices.
	CDN-A.
	In this case also it may be that CDN-B provides other features
	related to adapting the content.
	These cases can apply to many CDN features that a given CDN provider		These cases can apply to many CDN features that a given CDN Provider
	may not be able to support or not be willing to invest in, and thus,		may not be able to support or not be willing to invest in, and thus,
	that the CDN provider would delegate to another CDN.		that the CDN Provider would delegate to another CDN.
	4.2. Technology and Vendor Interoperability		4.2. Technology and Vendor Interoperability
	A CDN Provider may deploy a new CDN to run alongside its existing		A CDN Provider may deploy a new CDN to run alongside its existing
	CDN, as a simple way of migrating its CDN service to a new		CDN, as a simple way of migrating its CDN service to a new
	technology. A CDN Provider may have a multi-vendor strategy for its		technology. In addition, a CDN Provider may have a multi-vendor
	CDN deployment. A CDN Provider may want to deploy a separate CDN for		strategy for its CDN deployment. Finally, a CDN Provider may want to
	a particular CSP or a specific network. In all these circumstances,		deploy a separate CDN for a particular CSP or a specific network. In
	CDNI benefits the CDN Provider, as it simplifies or automates some		all these circumstances, CDNI benefits the CDN Provider, as it
	inter-CDN operations (e.g., migrating the request routing function		simplifies or automates some inter-CDN operations (e.g., migrating
	progressively).		the request routing function progressively).
	4.3. QoE and QoS Improvement		4.3. QoE and QoS Improvement
	Some CSPs are willing to pay a premium for enhanced delivery of		Some CSPs are willing to pay a premium for enhanced delivery of
	Content to their End Users. In some cases, even if the CDN Provider		content to their End Users. In some cases, even if the CDN Provider
	could deliver the content to the end users, it cannot meet the CSP's		could deliver the content to the End Users, it cannot meet the CSP's
	service level requirements. So, it makes a CDN Interconnection		service level requirements. As a result, the CDN Provider may
	agreement with another CDN Provider that can provide the expected		establish a CDN Interconnection agreement with another CDN Provider
	quality of experience to the end-user, for instance an Access CDN		that can provide the expected QoE to the End User, e.g., via an
	able to deliver content from Surrogates located closer to the end-		Access CDN able to deliver content from Surrogates located closer to
	user.		the End User and with the required service level.
	5. Policy Enforcement		5. Enforcement of Content Delivery Policy
	For the interconnection use cases described in previous sections, the		CSPs commonly require the ability to place delivery restriction on
	delegation of content delivery may be dependent upon the ability to		sets of content, which are provided by existing CDNs. The ability to
	delegate delivery policy enforcement as well. CSPs may rely on the		support such delivery restrictions across interconnected CDNs is
	ability to place delivery restriction on sets of content, which are		desirable, but depends on the capabilities of the involved CDNs.
	provided by existing CDNs. While the ability to support these		Thus, it is important to be able to detect and define when these
	features across interconnected CDNs is desirable, that may not always		features cannot be enforced.
	be feasible. It is important to be able to detect or define when
	these features cannot be enforced.
	5.1. Content Availability		5.1. Content Availability
	The content distribution policies that a CSP attaches to a content		The content distribution policies that a CSP attaches to a piece of
	asset depend on many criteria. For instance, distribution policies		content depend on many criteria. For instance, distribution policies
	for audiovisual content often combine:		for audiovisual content often combine:
	o temporal constraints (e.g., available for 24 hours, available 28		o temporal constraints (e.g., available for 24 hours, available 28
	days after DVD release, etc.),		days after DVD release, etc.),
	o resolution-based constraints (e.g., high definition vs. standard		o resolution-based constraints (e.g., high definition vs. standard
	definition), and		definition), and
	o geolocation-based constraints (e.g., per country).		o geolocation-based constraints (e.g., per country).
	5.1.1. Geo-location Restrictions		CSPs may require from their CDN Providers that they translate some of
			the above requirements into content delivery policies for their CDNs.
	"Geo-blocking" rules may specify:		For instance, CDNs might implement "geo-blocking" rules specifying:
	o the geographic regions where content can be delivered from (i.e.		o the geographic regions from where content can be delivered (i.e.,
	the location of the Surrogates), or		the location of the Surrogates), or
	o geographic locations where content can be delivered to (i.e., the		o geographic locations to which content can be delivered (i.e., the
	location of the End Users).		location of the End Users).
	If a default value of "geo-blocking rules not supported" is set, the		Similarly, an uCDN might implement some temporal constraints on
	CSP may wish to deny all access to the content, or blacklist specific		content availability. For example, it could restrict access to pre-
	dCDNs which lack support for these features.		positioned content prior to the opening of the availability window or
			disable the delivery of content from the dCDNs (e.g., through
	5.1.2. Temporal Restrictions		purging) after the availability window has closed.
	Time-based rules may specify:
	o an activation time (i.e., the time when the content should become
	available for delivery),
	o a deactivation time (i.e., time after which the content should no
	longer be delivered), or
	o an expiration time (i.e., the time at which the content files
	should be expunged from all CDN storage).
	If a default value of "time-based rules not supported" is set, the
	CSP may wish to deny all access to the content, or blacklist specific
	dCDNs which lack support for these features.
	5.1.3. Content Encoding Restrictions
	[Ed. Note: Section to be removed? reworded?]
	Encoding-based rules may specify:
	o a subset of encodings deliverable to specific devices,
	o a subset of encodings deliverable though a specific NSP, or
	o a subset of encodings deliverable to users based on a subscription
	or quality of service levels.
	[Ed. Note: FLF The first bullet only makes sense if the solution
	supports transcoding/transrating, which I don't know if it will be
	supported in Initial scope. The last bullet does not make sense to
	me as we do not want the CDNs to be aware of any user subscription
	levels (ie only CSP is aware of user subscription level)."]
	If a default value of "encoding-based rules not supported" is set,
	the CSP may wish to deny all access to the content, or blacklist
	specific dCDNs which lack support for these features.
	5.2. Branding		5.2. Branding
	There are situations where one CDN Provider cannot or does not want		Preserving the branding of the CSP throughout delivery is often
	to operate all the functions of a uCDN, e.g., a CDN exchange, which		important to the CSP. CSPs may desire to offer content services
	handles request routing (and possibly log retrieval) but delegates		under their own name, even when the associated CDN service involves
	all content delivery to the surrogates of other dCDNs. Preserving		other CDN Providers. The CSP may request that the name of the CDN
	the branding of the CSP throughout delivery is often important to the		Providers does not appear in the URLs and may wish to specify a
	CSP. CSPs may desire to offer content services under their own name,		specific brand related tag to appear in the URLs. The CSP may wish
	even when the associated CDN service involves other CDSPs. The CSP		to forbid the delivery of its content by specific dCDNs that lack
	may request that the name of the CDSPs does not appear in the URLs		support for such branding preservation features.
	and may wish to specify a specific brand related tag to appear in the
	URLs. Similarly, in offload situations, the uCDN might want to offer
	CDN services under its own branding.
	If a default value of "branding rules not supported" is set, the CSP		Similar restrictions may exist when the uCDN wants to offer CDN
	may wish to deny all access to the content, or blacklist specific		services under its own branding even if dCDNs are involved.
	dCDNs which lack support for these features.		Conversely, a CDN Provider might not want the brand of a CDN Exchange
			to be visible, even if the CDN Exchange is involved in the content
			delivery call flow.
	5.3. Secure Access		5.3. Secure Access
	Many protocols exist for delivering content to End Users. CSPs may		Many protocols exist for delivering content to End Users. CSPs may
	often wish to dictate a specific protocol or set of protocols which		often wish to dictate a specific protocol or set of protocols which
	are acceptable for delivery of their content, especially in the case		are acceptable for delivery of their content, especially in the case
	where content protection or user authentication is required (e.g.,		where content protection or user authentication is required (e.g.,
	must use HTTPS and not HTTP, or must use URL hashing, etc.).		must use HTTPS, or must use URL hashing, etc.).
	If a default value of "secure access rules not supported" is set, the		The CSP may wish to blacklist specific dCDNs which lack support for
	CSP may wish to deny all access to the content, or blacklist specific		these secure access features.
	dCDNs which lack support for these features.
	6. Open issues		6. Acknowledgments
	The section about nomadic users must be clarified		The authors would like to thank Kent Leung, Francois Le Faucheur, Ben
			Niven-Jenkins, and Scott Wainner for lively discussions, as well as
			for their reviews and comments on the mailing list.
	The section about Content Encoding Restrictions requires a		They also thank the contributors of the EU FP7 OCEAN and ETICS
	discussion: must the CDN enforce such restrictions?		projects for valuable inputs.
	7. Contributors		7. IANA Considerations
	[Ed. Note: long list of co-authors. As per current practice, you		This memo includes no request to IANA.
	would want to split that into "editors" and "contributors".]
	The following people have strongly contributed to this		8. Security Considerations
	specification's content:
	8. Acknowledgments		CDN Interconnection, as described in this document, has a wide
			variety of security issues that should be considered.
	The authors would like to thank Kent Leung, Francois Le Faucheur and		In addition to the security considerations within the uCDN and dCDN,
	Ben Niven-Jenkins for lively discussions, as well as for their		four contexts involve security and trust issues:
	reviews and comments on the mailing list.
	They also thank the contributors of the EU FP7 OCEAN and ETICS		a. The relationship between the CSP and the uCDN: the main contract
	projects for valuable inputs.		arrangement for distribution, which authorizes the uCDN to
			acquire content on CSP's origin servers and to deliver it,
			potentially with content delivery restrictions.
	9. IANA Considerations		b. The relationship between the uCDN and dCDN: the transitive trust
			relationship that extends the contract defined in (a) above and
			that authorizes the dCDN to acquire content on uCDN's or CSP's
			origin servers and to deliver it, potentially with content
			delivery restrictions.
	This memo includes no request to IANA.		c. The relationship between the End User and dCDN: the recognition
			of right to download predicated on (b) above.
	10. Security Considerations		d. The relationship between the End User and the CSP: the contract
			that authorizes the End User to access to the content.
	CDN Interconnection, as described in this document, has a wide		CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to
	variety of security issues that should be considered. The security		negotiate a security method or a method for confirming authorization
	issues fall into three general categories:		along the chain of trust (CSP -> uCDN -> dCDN -> End User).
			The security issues fall into three general categories:
	o CSP Trust: where the CSP may have negotiated service level		o CSP Trust: where the CSP may have negotiated service level
	agreements for delivery quality of service with the uCDN, and/or		agreements for delivery quality of service with the uCDN, and/or
	configured distribution policies (e.g., geo-restrictions,		configured distribution policies (e.g., geo-restrictions,
	availability windows, or other licensing restrictions), which it		availability windows, or other licensing restrictions), which it
	assumes will be upheld by dCDNs to which the uCDN delegates		assumes will be upheld by dCDNs to which the uCDN delegates
	requests. Furthermore, billing and accounting information must be		requests. Furthermore, billing and accounting information must be
	aggregated from dCDNs with which the CSP may have no direct		aggregated from dCDNs with which the CSP may have no direct
	business relationship. These situations where trust is delegated		business relationship. These situations where trust is delegated
	must be handled in a secure fashion to ensure CSP confidence in		must be handled in a secure fashion to ensure CSP confidence in
	skipping to change at page 14, line 47		skipping to change at page 15, line 46
	its existing security and DRM protocols (e.g., cookies,		its existing security and DRM protocols (e.g., cookies,
	certificate-based authentication, custom DRM protocols, URL		certificate-based authentication, custom DRM protocols, URL
	signing algorithms, etc.) in a transparent fashion.		signing algorithms, etc.) in a transparent fashion.
	o CDN Infrastructure Protection: where the dCDNs must be able to		o CDN Infrastructure Protection: where the dCDNs must be able to
	identify and validate delegated requests, in order to prevent		identify and validate delegated requests, in order to prevent
	unauthorized use of the network and to be able to properly bill		unauthorized use of the network and to be able to properly bill
	for delivered content. A dCDN may not wish to advertise that it		for delivered content. A dCDN may not wish to advertise that it
	has access to or is carrying content for the uCDN or CSP,		has access to or is carrying content for the uCDN or CSP,
	especially if that information may be used to enhance denial of		especially if that information may be used to enhance denial of
	service attacks. In general, CDNI interfaces and protocols should		service attacks. CDNI interfaces and protocols should attempt to
	minimize overhead for dCDNs.		minimize overhead for dCDNs.
	This document focuses on the motivational use cases for CDN		This document focuses on the motivational use cases for CDN
	Interconnection, and does not analyze these threats in detail.		Interconnection, and does not analyze these threats in detail.
	11. References		9. References
	11.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	11.2. Informative References		9.2. Informative References
	[I-D.bertrand-cdni-experiments]		[I-D.bertrand-cdni-experiments]
	Bertrand, G., Faucheur, F., and L. Peterson, "Content		Bertrand, G., Faucheur, F., and L. Peterson, "Content
	Distribution Network Interconnection (CDNI) Experiments",		Distribution Network Interconnection (CDNI) Experiments",
	draft-bertrand-cdni-experiments-01 (work in progress),		draft-bertrand-cdni-experiments-01 (work in progress),
	August 2011.		August 2011.
	[I-D.davie-cdni-framework]		[I-D.davie-cdni-framework]
	Davie, B. and L. Peterson, "Framework for CDN		Davie, B. and L. Peterson, "Framework for CDN
	Interconnection", draft-davie-cdni-framework-00 (work in		Interconnection", draft-davie-cdni-framework-01 (work in
	progress), July 2011.		progress), October 2011.
	[I-D.ietf-cdni-problem-statement]		[I-D.ietf-cdni-problem-statement]
	Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content		Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
	Distribution Network Interconnection (CDNI) Problem		Distribution Network Interconnection (CDNI) Problem
	Statement", draft-ietf-cdni-problem-statement-00 (work in		Statement", draft-ietf-cdni-problem-statement-01 (work in
	progress), September 2011.		progress), October 2011.
	[I-D.ietf-cdni-requirements]		[I-D.ietf-cdni-requirements]
	Leung, K. and Y. Lee, "Content Distribution Network		Leung, K. and Y. Lee, "Content Distribution Network
	Interconnection (CDNI) Requirements",		Interconnection (CDNI) Requirements",
	draft-ietf-cdni-requirements-00 (work in progress),		draft-ietf-cdni-requirements-02 (work in progress),
	September 2011.		December 2011.
	[I-D.ma-cdni-publisher-use-cases]
	Nair, R. and K. Ma, "Content Distribution Network
	Interconnection (CDNI) Publisher Use",
	draft-ma-cdni-publisher-use-cases-00 (work in progress),
	March 2011.
	[I-D.watson-cdni-use-cases]
	Watson, G., "CDN Interconnect Use Cases",
	draft-watson-cdni-use-cases-00 (work in progress),
	January 2011.
	[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model		[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
	for Content Internetworking (CDI)", RFC 3466,		for Content Internetworking (CDI)", RFC 3466,
	February 2003.		February 2003.
	[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known		[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
	Content Network (CN) Request-Routing Mechanisms",		Content Network (CN) Request-Routing Mechanisms",
	RFC 3568, July 2003.		RFC 3568, July 2003.
	Authors' Addresses		Authors' Addresses
End of changes. 87 change blocks.
	328 lines changed or deleted		362 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/