< draft-penno-alto-cdn-00.txt		draft-penno-alto-cdn-01.txt >
	Network Working Group R. Penno		Network Working Group R. Penno
	Internet-Draft S. Raghunath		Internet-Draft S. Raghunath
	Intended status: Experimental J. Medved		Intended status: Experimental J. Medved
	Expires: December 6, 2010 M. Bakshi		Expires: January 13, 2011 M. Bakshi
	Juniper Networks		Juniper Networks
	R. Alimi		R. Alimi
	Yale University		Yale University
	S. Previdi		S. Previdi
	Cisco Systems		Cisco Systems
	June 04, 2010		July 12, 2010
	ALTO and Content Delivery Networks		ALTO and Content Delivery Networks
	draft-penno-alto-cdn-00		draft-penno-alto-cdn-01
	Abstract		Abstract
	Networking applications can request through the ALTO protocol		Networking applications can request through the ALTO protocol
	information about the underlying network topology from the ISP or		information about the underlying network topology from the ISP or
	Content Provider (henceforth referred as Provider) point of view. In		Content Provider (henceforth referred as Provider) point of view. In
	other words, what a Provider prefers in terms of traffic optimization		other words, what a Provider prefers in terms of traffic optimization
	-- and a way to distribute it. The ALTO Service provides information		-- and a way to distribute it. The ALTO Service provides information
	such as preferences of network resources with the goal of modifying		such as preferences of network resources with the goal of modifying
	network resource consumption patterns while maintaining or improving		network resource consumption patterns while maintaining or improving
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	case of CDNs.		case of CDNs.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that
	working documents as Internet-Drafts. The list of current Internet-		other groups may also distribute working documents as Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts.
	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 December 6, 2010.		The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt.
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
			This Internet-Draft will expire on January 13, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Content Location Selection . . . . . . . . . . . . . . . . . . 5
	4.1. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 7		4.1. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. CDN Node Discovery and Status . . . . . . . . . . . . . . 7		4.1.1. The Map Service . . . . . . . . . . . . . . . . . . . 6
	4.3. CDN Node Status Updates received by HTTP Redirector . . . 7		4.1.2. The Endpoint Cost Service . . . . . . . . . . . . . . 7
	4.4. CDN Node Status Updates received by ALTO Server . . . . . 8		4.1.3. CDN Node Discovery and Status . . . . . . . . . . . . 7
	5. DNS Integration . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. DNS Integration . . . . . . . . . . . . . . . . . . . . . 10
	6. Administrative domains and ALTO . . . . . . . . . . . . . . . 11		4.3. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 11
	6.1. CDN nodes in the ISP administrative domain . . . . . . . . 11		5. Administrative domains and ALTO . . . . . . . . . . . . . . . 11
	6.2. CDN nodes in a separate administrative domain from		5.1. CDN nodes in the ISP administrative domain . . . . . . . . 11
			5.2. CDN nodes in a separate administrative domain from
	that of ISP . . . . . . . . . . . . . . . . . . . . . . . 12		that of ISP . . . . . . . . . . . . . . . . . . . . . . . 12
	6.3. Integrating with managed DNS service . . . . . . . . . . . 14		5.3. Integrating with managed DNS service . . . . . . . . . . . 15
	6.3.1. Managed DNS resolver used to redirect to local		5.3.1. Managed DNS resolver used to redirect to local
	cache . . . . . . . . . . . . . . . . . . . . . . . . 14		cache . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.3.2. Managed DNS resolver used with multiple CDN vendors . 16		5.3.2. Managed DNS resolver used with multiple CDN vendors . 17
	7. Tracker Integration . . . . . . . . . . . . . . . . . . . . . 16		6. Tracker Integration . . . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Content Delivery Networks are becoming increasingly important in the		Content Delivery Networks are becoming increasingly important in the
	Internet [ARBOR] and many CDNs today already use some form of		Internet [ARBOR] and many CDNs today already use some form of
	application proximity through geolocation. But in many cases the		proximity through geolocation. But in many cases the content
	content provider and the Service Provider are disjoint and even if		provider/distributor and the Internet Service Provider are disjoint
	content servers are co-located into the ISP's networks, there is no		and even if content servers are co-located into the ISP's networks,
	standardized way to share information. Therefore a natural step		there is no standardized way to share information. Therefore a
	forward would be to use ALTO for full integration.		natural step forward would be to use ALTO to share information.
	Another key aspect of ALTO in the context of CDNs deployments is that		Another key aspect of ALTO in the context of CDNs deployments is that
	there is an expectation that no changes to the hosts are needed (or		it is desirable that no changes to the hosts are needed (or would be
	would be transparent to the user). In other words, a traditional web		transparent to the user). In other words, a traditional web browser
	browser is all there is needed to take advantage of ALTO information.		is all there is needed to take advantage of ALTO information. This
	This is significant difference from the P2P file sharing case where a		is a significant difference from the P2P applications where a special
	special client is needed and ALTO is normally used as a way to reduce		client is typically needed and ALTO is normally used as a way to
	operational expense.		reduce operational expense.
	2. Scope		2. Scope
	This document discusses how Content Delivery Networks can benefit		This document discusses how Content Delivery Networks can benefit
	from ALTO through integration of the ALTO Service with the main		from ALTO through integration of the ALTO Service with the main
	request routing techniques. Whenever a gap in protocol functionality		request routing techniques. Whenever a gap in protocol functionality
	is identified to achieve such integration, it will be enumerated with		is identified to achieve such integration, it will be enumerated with
	'GAP-<N>'. Each gap is documented in a section of their own in order		'GAP-<N>'. Each gap is documented in a section of its own in order
	to foster parallel discussion and possible adoption.		to foster parallel discussions and possible adoption.
	3. Terminology		3. Terminology
	Content-aware Proximity Redirector: The Redirector knows about		Content-aware Proximity Redirector: The Redirector knows about
	locations and presence of content & media objects in the network.		locations and presence of content & media objects in the network.
	Therefore the redirection to a CDN node is made based on		Therefore the redirection to a CDN node is made based on
	availability of content or content-type in that CDN node and the		availability of content or content-type in that CDN node and the
	proximity of the CDN node to the user.		proximity of the CDN node to the user.
	Service-aware Proximity Redirector: The Redirector knows about		Service-aware Proximity Redirector: The Redirector knows about
	locations of CDN nodes in the network and redirects user to the		locations of CDN nodes in the network and redirects user to the
	closest CDN node. The redirection made irrespective of content		closest CDN node. A redirection is made irrespective of content
	presence in the CDN Node; if content not present, the cache will		presence in the CDN node; if content is not present, the node will
	be populated with the content before or when the content is served		be populated with the content before or when the content is served
	to the user.		to the user.
	HTTP Redirector: a Content-Aware or Service Aware Proximity		HTTP Redirector: a Content-aware or Service-aware Proximity
	Redirector for HTTP. It embeds an HTTP Server that performs HTTP		Redirector for HTTP. It embeds an HTTP Server that performs HTTP
	Redirects, an ALTO client that retrieves network mapping from the		Redirects, an ALTO client that retrieves network mapping from the
	ALTO Server and a Location Database which stores network mappings		ALTO Server and a Location Database which stores network mappings
	received from the ALTO Client. The HTTP Server consults the		received from the ALTO Client. The HTTP Server consults the
	Location Database when making redirection decisions.		Location Database when making redirection decisions.
	4. HTTP Redirect		4. Content Location Selection
			There are multiple mechanisms that ISPs and CDNs can use to select
			the location from which content is served to a particular host, where
			information from one or more ALTO Servers can be used to improve or
			optimize the selection. In particular, two commonly used location
			selection mechanisms are HTTP Redirect and DNS name resolution.
			Thus, we focus on these two mechanisms.
			4.1. HTTP Redirect
	In this case an HTTP GET request from a host is received by an HTTP		In this case an HTTP GET request from a host is received by an HTTP
	Redirector which sends back an HTTP responses with Status-Code 302		Redirector which sends back an HTTP responses with Status-Code 302
	(Redirect) informing the host of the best location to fetch the		(Redirect) informing the host of the most optimal location to fetch
	content. The HTTP Redirection method is already commonly used in		the content. The HTTP Redirection method is already commonly used in
	production CDNs as described in RFC3568 [RFC3568]. ALTO integration		production CDNs as described in RFC3568 [RFC3568]. ALTO integration
	provides localization services where the device that performs the		provides localization services where the device that performs the
	redirection becomes an ALTO client.		redirection becomes an ALTO client.
	The ALTO client embedded in the HTTP Redirector fetches the cost and		Usage of the ALTO Server with HTTP Redirects is shown in the
	network map from the ALTO Server and provides that information to the		following figure. Either the Map Service or the Endpoint Cost
	HTTP Server. When the HTTP Redirector intercepts an HTTP GET request		Service can be used by the ALTO client embedded in the HTTP
	(1), it looks up the source IP address on the GET request, consults		Redirector entity.
	the Location Database and returns an HTTP redirect with the URL of
	the best CDN node from which to service the host. The URL in 302
	Redirect may contain the IP address of the selected CDN node or a
	domain name instead of IP address due to virtual hosting. Therefore
	the IP addresses contained in the cost maps may need to be correlated
	to domain names a priori.
	+-----------------+		+-----------------+
	| HTTP Redirector |		| HTTP Redirector |
	+------+ 1 | +-------------+ |		+------+ 1 | +-------------+ |
	| |--------------> | | HTTP Server | |		| |--------------> | | HTTP Server | |
	| Host |<-------------- | +-------------+ |		| Host |<-------------- | +-------------+ |
	+------+ 2 | ^ |		+------+ 2 | ^ |
	| | |		| | |
	| +-------------+ |		| +-------------+ |
	| | Location DB | |
	| +-------------+ |
	| ^ |
	| | |
	| +-------------+ |
	| | ALTO Client | |		| | ALTO Client | |
	| +-------------+ |		| +-------------+ |
	+-----------------+		+-----------------+
	| ^		| ^
	| | ALTO Protocol		| | ALTO Protocol
	| | (Map Service)
	v |		v |
	+-----------------+		+-----------------+
	| ALTO Server |		| ALTO Server |
	+-----------------+		+-----------------+
	Figure 1: HTTP Redirector		Figure 1: HTTP Redirector
			4.1.1. The Map Service
			The ALTO client embedded in the HTTP Redirector fetches the Network
			and Cost Maps from the ALTO Server and provides that information to
			the HTTP Redirector. As an illustrative example, a simple Redirector
			may be given (from an external source) the list of available CDN
			nodes. The Redirector precomputes a redirection table indexed by
			source PID with values being the closest CDN nodes. This redirection
			table can be built based on information from Network and Cost Maps.
			Then when it receives an HTTP GET request (1), it looks up the PID of
			the source IP address on the GET request, indexes the redirection
			table using the request PID to select a CDN node, and finally returns
			an HTTP redirect with the URL of the selected CDN node. In practice,
			the redirection table may be indexed by both source and content to
			provide better redirection.
			The URL in 302 Redirect may contain the IP address of the selected
			CDN node or a domain name instead of IP address due to virtual
			hosting. Therefore the IP addresses contained in the cost maps may
			need to be correlated to domain names a priori.
	The Network Maps generated by the ALTO server contain Host PIDs and		The Network Maps generated by the ALTO server contain Host PIDs and
	CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN PIDs contain		CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN PIDs contain
	IP addresses of available CDN nodes. Cost Maps contain only cost		IP addresses of available CDN nodes. Cost Maps contain only cost
	from each host PID to each CDN PID and not the full matrix across all		from each host PID to each CDN PID and not the full matrix across all
	PIDs. The reason is that the HTTP Redirector can only redirect a		PIDs. The reason is that the HTTP Redirector can only redirect a
	host to a CDN node, not to another host as in the P2P case.		host to a CDN node, not to another host as in the P2P case.
	Moreover, there is no generic way to disambiguate PIDs containing		Moreover, there is no generic way to disambiguate PIDs containing
	only hosts from PIDs containing CDN nodes (GAP).		only hosts from PIDs containing CDN nodes (GAP).
	The cost for CDN PID to CDN PID and from between host PIDs are		The cost for CDN PID to CDN PID and between host PIDs are assumed to
	assumed to be infinity (GAP). The HTTP Redirector looks up the		be infinity (GAP). The HTTP Redirector looks up the source address
	source address on the HTTP GET request, and uses the cost map to		on the HTTP GET request, and uses the cost map to select the best CDN
	select the best CDN PID and a CDN node from it. The CDN node		PID and a CDN node from it. The CDN node selection method can be
	selection method can be random, round-robin, or the HTTP Redirector		random, round-robin, or the HTTP Redirector can use some level of
	can use some level of content awareness (i.e. send requests for the		content awareness (i.e. send requests for the same content (URL) to
	same content (URL) to the same CDN node.		the same CDN node.
	GAP-1 (PID Attributes): In order to disambiguate between PIDs that		GAP-1 (PID Attributes): In order to disambiguate between PIDs that
	contain endpoints of a specific class, a PID property is needed.		contain endpoints of a specific class, a PID property is needed.
	A PID can be classified as containing "CDN nodes", "Mobile Hosts",		A PID can be classified as containing "CDN nodes", "Mobile Hosts",
	"Wireline Hosts", etc.		"Wireline Hosts", etc. Note that the Alto Server will have to be
			told which subnets belong to hosts and which subnets belong to CDN
			Nodes.
	GAP-2 (PID Attributes and Query): PID attributes can be used by		GAP-2 (PID Attributes and Query): PID attributes can be used by
	the Client to select a appropriate host and also passed as a		the ALTO Client to select an appropriate CDN Node and also passed
	constraint in the map filtering service.		as a constraint in the map filtering service.
	GAP-3 (Default Cost): The issue of default cost if one of		GAP-3 (Default Cost): The issue of default cost is one of
	importance. Without a default PID with endpoint '0.0.0.0/0', what		importance. Without a default PID with endpoint '0.0.0.0/0', what
	should be the cost between two PIDs? Moreover, if the default PID		should be the cost between two PIDs? Moreover, is the default PID
	mandatory in the protocol?		mandatory in the protocol?
	A future revision will incorporate analysis of ALTO Server - HTTP		4.1.2. The Endpoint Cost Service
	Redirector interaction with Endpoint Cost Service
	4.1. ALTO Server Discovery		Alternatively, ALTO client embedded in the HTTP Redirector, requests
			the endpoint cost service from the ALTO client.
	4.2. CDN Node Discovery and Status		The Redirector knows the IP address of the user (content requester)
			and the different content locations. It then requests the Endpoint
			Cost Service in order to rank/rate the content locations (i.e., IP
			addresses of CDN nodes) based on their distance/cost (by default the
			Endpoint Cost Service operates based on Routing Distance) from/to the
			user address.
	The method of discovering available caches and their locations is not		Note that the mechanisms through which the CDN acquires the IP
	specified. We assume the CDN nodes are discovered in some way. It		addresses of the content locations (i.e.: how to locate the requested
	is desirable that not only CDN node locations, but also real-time		content) are part of the CDN implementation and their description is
	status (like health, load, cache utilization, CPU, etc.) is		outside the scope of this document.
	communicated either to the HTTP Redirector or to the ALTO Server.
			Once the Redirector obtained from the ALTO server the ranked list of
			locations (for the specific user) it can incorporate this information
			into its selection mechanisms in order to point the user to the most
			appropriate location.
			4.1.3. CDN Node Discovery and Status
			The method of discovering available caches and their locations is
			outside the scope of this document. We assume the CDN nodes are
			discovered in some way. It is desirable that not only CDN node
			locations, but also real-time status (like health, load, cache
			utilization, CPU, etc.) is communicated either to the HTTP Redirector
			or to the ALTO Server.
	CDN node status can be retrieved from the existing Load Balancer		CDN node status can be retrieved from the existing Load Balancer
	infrastructure. Most Load Balancers today have mechanisms to poll		infrastructure. Most Load Balancers today have mechanisms to poll
	caches/servers via ping, HTTP Get, traceroute, etc. Most LBs have		caches/servers via ping, HTTP Get, traceroute, etc. Most LBs have
	SNMP trap capabilities to let other devices know about these		SNMP trap capabilities to let other devices know about these
	thresholds. The HTTP Redirector or the ALTO Server can implement an		thresholds. The HTTP Redirector or the ALTO Server can implement an
	SNMP agent and get to know whatever is needed. For greenfield		SNMP agent and get to know whatever is needed. For greenfield
	installations, the ALTO Server could also provide an API (for		installations, the ALTO Server could also provide an API (for
	example, a Web Service or XMPP-based API) that could be used by CDN		example, a Web Service or XMPP-based API) that could be used by CDN
	nodes to communicate their status to the ALTO server directly.		nodes to communicate their status to the ALTO server directly.
	4.3. CDN Node Status Updates received by HTTP Redirector		In addition to the CDN node status, network status can also be
			retrieved from TE/RP databases.
			4.1.3.1. CDN Node Status Updates received by HTTP Redirector
	In this use case the HTTP Redirector receives CDN Status updates.		In this use case the HTTP Redirector receives CDN Status updates.
	+-----------------+		+-----------------+
	| HTTP Redirector |		| HTTP Redirector |
	+------+ 1 | +-------------+ |		+------+ 1 | +-------------+ |
	| |--------------> | | HTTP Server | |		| |--------------> | | HTTP Server | |
	| Host |<-------------- | +-------------+ |		| Host |<-------------- | +-------------+ |
	+------+ 2 | ^ |		+------+ 2 | ^ |<--- Real-time CDN
	| | |		| | | status updates
	| +-------------+ |
	| | Location DB | |<--- Real-time CDN
	| +-------------+ | status updates
	| ^ |
	| | |
	| +-------------+ |		| +-------------+ |
	| | ALTO Client | |		| | ALTO Client | |
	| +-------------+ |		| +-------------+ |
	+-----------------+		+-----------------+
	| ^		| ^
	| | ALTO Protocol		| | ALTO Protocol
	| | (Map Service)
	v |		v |
	+-----------------+		+-----------------+
	| ALTO Server |		| ALTO Server |
	+-----------------+		+-----------------+
	Figure 2: RT CDN Updates to HTTP Redirector		Figure 2: RT CDN Updates to HTTP Redirector
	4.4. CDN Node Status Updates received by ALTO Server		4.1.3.2. CDN Node Status Updates received by ALTO Server
	This model generally simplifies the HTTP Redirector. It allows an		This model generally simplifies the HTTP Redirector. It allows an
	easier distribution of the HTTP Redirector, and to keep real time CDN		easier distribution of the HTTP Redirector, and to keep real time CDN
	status data updates in a logically centralized ALTO Server or in an		status data updates in a logically centralized ALTO Server or in an
	ALTO Server Cluster. It allows for the HTTP Redirector and the ALTO		ALTO Server Cluster. It allows for the HTTP Redirector and the ALTO
	Server to be in different administrative domains. For example, the		Server to be in different administrative domains. For example, the
	HTTP Redirector can be in a Content Provider's domain, the ALTO		HTTP Redirector can be in a Content Provider's domain, the ALTO
	Server and CDN Nodes in a Network Service Provider's domain.		Server and CDN Nodes in a Network Service Provider's domain.
	+-----------------+		+-----------------+
	| HTTP Redirector |		| HTTP Redirector |
	+------+ 1 | +-------------+ |		+------+ 1 | +-------------+ |
	| |--------------> | | HTTP Server | |		| |--------------> | | HTTP Server | |
	| Host |<-------------- | +-------------+ |		| Host |<-------------- | +-------------+ |
	+------+ 2 | ^ |		+------+ 2 | ^ |
	| | |		| | |
	| +-------------+ |		| +-------------+ |
	| | Location DB | |
	| +-------------+ |
	| ^ |
	| | |
	| +-------------+ |
	| | ALTO Client | |		| | ALTO Client | |
	| +-------------+ |		| +-------------+ |
	+-----------------+		+-----------------+
	| ^		| ^
	| | ALTO Protocol		| | ALTO Protocol
	| | (Map Service)
	v |		v |
	+-----------------+		+-----------------+
	| ALTO Server |<--- Real-time CDN		| ALTO Server |<--- Real-time CDN
	+-----------------+ status updates		+-----------------+ status updates
	Figure 3: RT CDN Updates to ALTO Server		Figure 3: RT CDN Updates to ALTO Server
	In this model it is recommended that a given HTTP Redirector may be		In this model it is recommended that a given HTTP Redirector may be
	designated as being responsible for a fixed set of Host PIDs. This		designated as being responsible for a fixed set of Host PIDs. This
	information can be made available to the HTTP Redirector before it		information can be made available to the HTTP Redirector before it
	receives requests from clients. If the set of Host PIDs is not known		receives requests from hosts. If the set of Host PIDs is not known
	ahead of time, the latency for serving requests will be impacted by		ahead of time, the latency for serving requests will be impacted by
	the capabilities of the ALTO server. With such information ahead of		the capabilities of the ALTO server.
	time, the HTTP Redirector may pre-download the network map for the
			With such information ahead of time, an HTTP Redirector that uses the
			Network Maps Service may pre-download the network map for the
	interesting Host PIDs and the CDN PIDs. It can also start		interesting Host PIDs and the CDN PIDs. It can also start
	periodically pulling cost maps for relevant PID 2-tuples.		periodically pulling cost maps for relevant PID 2-tuples.
			An HTTP Redirector that uses the Endpoint Cost Service may query the
			ALTO Server for rankings of CDN Node IP addresses for each
			interesting Host and cache the results for later usage.
	The HTTP Redirector can rely on the ALTO Server generated Cache-		The HTTP Redirector can rely on the ALTO Server generated Cache-
	Control headers to decide how often to fetch CDN PID network map and		Control headers to decide how often to fetch CDN PID network map and
	Host PID network maps. In order to better deal with outages of		Host PID network maps. In order to better deal with outages of
	caches or changes to CDN PIDs, a push mechanism from ALTO server to		caches or changes to CDN PIDs, a push mechanism from ALTO server to
	ALTO client would be needed (GAP-4). In the general P2P scenario		ALTO client would be needed (GAP-4). In the general P2P scenario
	this may not make sense, but with content delivery this may be		this may not make sense, but with content delivery this may be
	important from a service continuity perspective.		important from a service continuity perspective.
	If the maps are large and change often a natural extension to the		If the maps are large and change often a natural extension to the
	protocol is to allow incremental Map Updates (GAP-5). This		protocol is to allow incremental Map Updates (GAP-5). This
	requirement becomes more emphasized when the ALTO Server is the		requirement becomes more emphasized when the ALTO Server is the
	recipient of CDN nodes' status updates, because their load/status		recipient of CDN nodes' status updates, because their load/status
	changes are typically more frequent than topology changes in the		changes are typically more frequent than topology changes in the
	network.		network.
	GAP-4 (Push Mechanism): It is important for the ALTO Service		GAP-4 (Push Mechanism): It is important for the ALTO Service
	through the ALTO protocol or a companion protocol to provide a		through the ALTO protocol or a companion protocol to provide a
	push mechanism from server to client. The push mechanism can be a		push mechanism from server to client. The push mechanism can be a
	notification that new data is vailable or the data itself.		notification that new data is available or the data itself.
	GAP-5 (Incremental Map Updates): A natural evolution to the		GAP-5 (Incremental Map Updates): A natural evolution to the
	protocol if maps are large and change often is to allow for		protocol if maps are large and change often is to allow for
	incremental map updates. In this sense the map contained in the		incremental map updates. In this sense the map contained in the
	reply would be considered the delta from the previous version.		reply would be considered the delta from the previous version.
	5. DNS Integration		4.2. DNS Integration
	In the case of DNS request routing, the DNS server handling client		In the case of DNS request routing, the DNS server handling host
	requests is integrated with an ALTO client. When the host performs a		requests is integrated with an ALTO client. When the host performs a
	DNS query lookup, the IP address contained in the response are		DNS query/lookup, the IP address contained in the response is already
	already optimal for that query. As in the previous example, no		optimal for that query. As in the previous example, no changes in
	changes in the host are needed.		the host are needed.
	DNS queries can be either iterative or recursive. Iterative queries		DNS queries can be either iterative or recursive. Iterative queries
	can be used with ALTO if the client itself queries the DNS Servers,		can be used with ALTO if the host itself queries the DNS Servers, or
	or if the DNS Proxy used by the host is topologically close to the		if the DNS Proxy used by the host is topologically close to the host.
	host. If the Host queries the DNS Servers, the authoritative DNS		If the Host queries the DNS Servers, the authoritative DNS Server can
	Server can see directly the host's IP address. If the the DNS		see directly the host's IP address. If the the DNS Proxy's is
	Proxy's is topologically close to the Host, its IP address is a good		topologically close to the Host, its IP address is a good
	approximation for the host's location. In recursive queries, the		approximation for the host's location. In recursive queries, the
	authoritative DNS Server sees the IP address of the previous DNS		authoritative DNS Server sees the IP address of the previous DNS
	Server in the resolution chain, and the IP address of the host is		Server in the resolution chain, and the IP address of the host is
	unknown. DNS-based request routing does not work with recursive DNS		unknown. DNS-based request routing does not work with recursive DNS
	queries.		queries.
	In an iterative DNS lookup with DNS Proxy, as shown in examples in		In an iterative DNS lookup with DNS Proxy, as shown in examples in
	the next section, the host queries the Proxy, which in turn first		the next section, the host queries the Proxy, which in turn first
	queries one of the root servers to find the server authoritative for		queries one of the root servers to find the server authoritative for
	the top-level domain (com in our example). The Proxy then queries		the top-level domain (com in our example). The Proxy then queries
	the obtained top-level-domain DNS server for the address of the DNS		the obtained top-level-domain DNS server for the address of the DNS
	server authoritative for the cdn domain. Finally, the Proxy queries		server authoritative for the CDN domain. Finally, the Proxy queries
	the DNS server that is authoritative for the cdn.com domain. The		the DNS server that is authoritative for the cdn.com domain. The
	authoritative DNS Server for the cdn.com will perform the request		authoritative DNS Server for the cdn.com will perform the request
	routing to the most appropriate CDN node, based on the source IP		routing to the most appropriate CDN node, based on the source IP
	address of the requestor. The client will then request the content		address of the requestor. The host will then request the content
	directly from the CDN Node.		directly from the CDN Node.
	6. Administrative domains and ALTO		4.3. ALTO Server Discovery
			5. Administrative domains and ALTO
	With DNS-based redirection, among others, there are two models that		With DNS-based redirection, among others, there are two models that
	are worth further study - one, where the CDN nodes are in the		are worth further study - one, where the CDN nodes are in the
	administrative domain of the ISP and two, where CDN nodes are part of		administrative domain of the ISP and two, where CDN nodes are part of
	a separate domain from that of the ISP. In the first use case, the		a separate domain from that of the ISP. In the first use case, the
	Host, the CDN Nodes, the ALTO Server and the Authoritative DNS Server		Host, the CDN Nodes, the ALTO Server and the Authoritative DNS Server
	for the CDN domain are in the same administrative domain. In the		for the CDN domain are in the same administrative domain. In the
	second use case, Hosts and CDN Nodes are in different administrative		second use case, Hosts and CDN Nodes are in different administrative
	domains.		domains.
	6.1. CDN nodes in the ISP administrative domain		5.1. CDN nodes in the ISP administrative domain
	When the CDN nodes are within the ISP's administrative domain, the		When the CDN nodes are within the ISP's administrative domain, the
	DNS server with the ALTO client is under the ISP's management. As		DNS server with the ALTO client is under the ISP's management. A
	described earlier, the best CDN node is picked by performing an ALTO		best CDN nodes can be picked by performing ALTO query on the source
	query on the source IP address of the DNS request.		IP address (and the target domain name) of the DNS request.
	2 +----------------+		2 +----------------+
	+------------------> | root |		+------------------> | root |
	| +----------------- | Name Server | +----------+		| +----------------- | Name Server | +----------+
	| | 3 +----------------+ | Content |		| | 3 +----------------+ | Content |
	| | | Provider |		| | | Provider |
	| | 4 +----------------+ +----------+		| | 4 +----------------+ +----------+
	| | +------------> | com |		| | +------------> | com |
	| | | +----------- | Name Server |		| | | +----------- | Name Server |
	| | | | 5 +----------------+		| | | | 5 +----------------+
	skipping to change at page 12, line 26 ¶		skipping to change at page 12, line 26 ¶
	: +---------+ +----------------+ :		: +---------+ +----------------+ :
	: | DNS |---------> | cdn.com | :		: | DNS |---------> | cdn.com | :
	: | Proxy |<--------- | Name Server | :		: | Proxy |<--------- | Name Server | :
	: +---------+ 7 | | :		: +---------+ 7 | | :
	: ^ | | +------------+ | :		: ^ | | +------------+ | :
	: 1 | | 8 | |ALTO Client | | :		: 1 | | 8 | |ALTO Client | | :
	: | V | +------------+ | :		: | V | +------------+ | :
	: +---------+ +----------------+ :		: +---------+ +----------------+ :
	: | Host | | ^ :		: | Host | | ^ :
	: +---------+ | | ALTO Protocol :		: +---------+ | | ALTO Protocol :
	: | | | (Map Service) :		: | | | :
	: | V | :		: | V | :
	: V +----------------+ :		: V +----------------+ :
	: CDN Node | ALTO Server | :		: CDN Node | ALTO Server | :
	: +----------------+ :		: +----------------+ :
	: :		: :
	: NSP/CDN Administrative Domain :		: NSP/CDN Administrative Domain :
	:.............................................................:		:.............................................................:
	Figure 4: DNS Resolution with single admin domain		Figure 4: DNS Resolution with single admin domain
	6.2. CDN nodes in a separate administrative domain from that of ISP		5.2. CDN nodes in a separate administrative domain from that of ISP
	In many situations, the CDN nodes are in a separate network managed		In many situations, the CDN nodes are in a separate network managed
	by an entity that is distinct from the ISP. Consequently, the CDN		by an entity that is distinct from the ISP. Consequently, the CDN
	nodes belong to a network with its own ALTO server that is distinct		nodes belong to a network with its own ALTO server that is distinct
	from the ALTO server of the ISP where the subscriber belongs.		from the ALTO server of the ISP where the subscriber belongs.
	.................................		.................................
	: +-----------------+ :		: +-----------------+ :
	: | cdn.com | :		: | cdn.com | :
	: | Name Server | :		: | Name Server | :
	skipping to change at page 14, line 8 ¶		skipping to change at page 14, line 8 ¶
	The ALTO server in the CDN provider network is assumed to be		The ALTO server in the CDN provider network is assumed to be
	initialized with information about the ISP networks it serves. For		initialized with information about the ISP networks it serves. For
	every such ISP network, it consults the routing plane to find the set		every such ISP network, it consults the routing plane to find the set
	of Border routers. The CDN network ALTO server computes the cost of		of Border routers. The CDN network ALTO server computes the cost of
	reaching each Border router from every CDN node (say, C_cdn).		reaching each Border router from every CDN node (say, C_cdn).
	Next, the CDN ALTO server contacts the ISP network's ALTO server and		Next, the CDN ALTO server contacts the ISP network's ALTO server and
	downloads the network map. In order to help the CDN ALTO server		downloads the network map. In order to help the CDN ALTO server
	compute the cost from a CDN node to a subscriber's PID, we break it		compute the cost from a CDN node to a subscriber's PID, we break it
	down into two parts - the cost from the CDN node to the Border router		down into two parts - the cost from the CDN node to the Border Router
	(C_cdn) and the cost from the Border router to the subscriber's PID		(C_cdn) and the cost from the Border Router to the subscriber's PID
	(say, C_isp). Note that, this implies that each Border router is a		(say, C_isp). Note that for any chosen exit point, C_cdn may be
	PID in itself to accommodate this cost computation. Hence the cost		computed locally by the CDN ALTO Server. However, the fundamental
	map at the ISP's ALTO server has the costs between every pair of		issue is that C_isp depends on the exit point (Border outer) chosen
	subscriber PID and Border router PID.		by the CDN. There are multiple ways for the CDN ALTO Server to
			compute C_isp given the Network Map and Cost Map from the ISP's ALTO
			Server.
	With the network map and the cost map from the ISP ALTO server, the		One possibility is for the ISP ALTO Server to define a special Border
	CDN ALTO server now computes the cost of reaching each subscriber PID		Router PID (denoted by a PID attribute) which also indicates the
	from a given CDN node as: C_cdn(CDN Node, Border router) +		corresponding Border Router PID in the CDN. The attributes and
	C_isp(Border router, Subscriber PID). In this computation, the		values may be agreed-upon by the ISP and CDN when the ALTO Services
	Border router is the one that is on the best path from the CDN node		are configured. For example, in the example shown in Figure 5, the
	to the Subscriber PID.		ISP ALTO Server indicates that its PID4 and PID5 are Border PIDs,
			with corresponding PIDs in the CDN as PID6, and PID7, respectively.
			Then, CDN ALTO Server can locally compute C_isp = cost(ISP Border
			Router PID, Subscriber PID).
			A second possibility for computing C_isp is to make use of Border
			Router IP addresses. The CDN's Border Router can locally determine
			the IP address of the connected border router in the ISP. In this
			approach, neither the CDN ALTO Server nor the ISP ALTO Server define
			PID attributes. The ISP ALTO Server is not required to define
			special PIDs for Border Routers - it only needs to ensure that Border
			Router IP addresses are aggregated appropriately in its Network Map.
			Specifically, we identify two scenarios for the CDN ALTO Server to
			compute C_isp and C_cdn.
			In the first scenario, the CDN does not conduct CDN-level multi-path
			routing from the CDN nodes to the subscriber hosts. Thus, the
			routing path from a CDN IP address to a subscriber host IP address is
			typically uniquely (if no ECMP) determined by the network routing
			system. In this scenario, for a given CDN node IP address to a
			subscriber host IP address, the CDN ALTO Server uses the routing
			system to compute the Border Egress router inside the CDN, and the
			corresponding Border Ingress router inside the ISP. Then the CDN
			ALTO Server has C_cdn(CDN node IP, Border Egress router IP inside the
			CDN), and C_isp(Border Ingress router IP inside the ISP, Subscriber
			IP). The computation of C_cdn and C_isp can be done using ALTO in
			the traditional way through either the Network Map and Cost Map or
			the Endpoint Cost Service.
			In the second scenario, the CDN may support CDN-level multi-path
			routing from the CDN nodes to the subscriber hosts. In particular,
			from each CDN node, the CDN has a capability (e.g., through
			tunneling) to send to a subscriber host IP through multiple Border
			Egress routers (e.g., through any Egress router that receives an
			announcement from the ISP of the subscriber host IP). In this case,
			the cost of reaching a host PID from a given CDN node is then
			determined as the minimum cost among all possible intermediate Border
			Routers.
			If the network is homogeneous, then a good approximation of the cost
			between each host PID and a given CDN node can be given as: C_cdn(CDN
			Node, Border router) + C_isp(Border router, Subscriber PID). In this
			computation, the Border Router is the one that is on the best path
			from the CDN node to the Subscriber PID.
	The CDN ALTO server now has a cost map that provides the cost from		The CDN ALTO server now has a cost map that provides the cost from
	each CDN node to all known Subscriber PIDs. The ALTO client in the		each CDN node to all known Subscriber PIDs. The ALTO client in the
	CDN DNS server downloads this cost map in preparation for subscriber		CDN DNS server downloads this cost map in preparation for subscriber
	DNS requests.		DNS requests.
	When a subscriber DNS request arrives at the CDN provider's DNS		When a subscriber DNS request arrives at the CDN provider's DNS
	server, it looks up the network map and maps the source IP address to		server, it looks up the network map and maps the source IP address to
	a Subscriber PID. It then uses the cost map to pick the best CDN		a Subscriber PID. It then uses the cost map to pick the best CDN
	node for this Subscriber PID.		node for this Subscriber PID.
	GAP-6: Federation of ALTO servers: There is a need to define how		GAP-6: Federation of ALTO servers: There is a need to define how
	ALTO servers may communicate with each other in a federated model.		ALTO servers may communicate with each other in a federated model.
	GAP-7: ALTO Border Router PID attribute: In order for		GAP-7: ALTO Border Router PID attribute: In order for
	administrative domains to collate costs across domain boundaries,		administrative domains to collate costs across domain boundaries,
	the border routers may be placed in their own PIDs. Such PIDs may		the border routers may be placed in their own PIDs. Such PIDs may
	be identified by a Border Router attribute.		be identified by a Border Router attribute.
	6.3. Integrating with managed DNS service		5.3. Integrating with managed DNS service
	Many organizations / content providers outsource DNS management to		Many organizations / content providers outsource DNS management to
	the external vendors for various reasons like reliability,		the external vendors for various reasons like reliability,
	performance improvement, DNS security etc. Managed DNS service could		performance improvement, DNS security etc. Managed DNS service could
	be used either with caches owned by the organization itself (section		be used either with caches owned by the organization itself (section
	6.3.1) OR with external CDNs (section 6.3.2)		6.3.1) OR with external CDNs (section 6.3.2)
	6.3.1. Managed DNS resolver used to redirect to local cache		5.3.1. Managed DNS resolver used to redirect to local cache
	One of the common functions offered by managed DNS service vendor is		One of the common functions offered by managed DNS service vendor is
	DNS traffic management where DNS resolver can load balance traffic		DNS traffic management where DNS resolver can load balance traffic
	dynamically across content servers.		dynamically across content servers.
	Typically managed DNS service provider has DNS resolvers spread		Typically managed DNS service provider has DNS resolvers spread
	across geographical locations to improve performance. This also		across geographical locations to improve performance. This also
	makes easier for DNS resolver to redirect host to the nearest cache.		makes easier for DNS resolver to redirect host to the nearest cache.
	Such a DNS resolver would be an ideal candidate to implement ALTO		Such a DNS resolver would be an ideal candidate to implement ALTO
	client where it can fetch network map and cost map from ALTO servers		client where it can fetch network map and cost map from ALTO servers
	skipping to change at page 16, line 6 ¶		skipping to change at page 17, line 5 ¶
	`-----------------'		`-----------------'
	In the figure above, there exists 2 possibilities:		In the figure above, there exists 2 possibilities:
	Case 1: Domain 1 and Domain 2 are connected to the same service		Case 1: Domain 1 and Domain 2 are connected to the same service
	provider network. This case is similar to section 6.1		provider network. This case is similar to section 6.1
	Case 2: Domain 1 and Domain 2 are connected to different service		Case 2: Domain 1 and Domain 2 are connected to different service
	provider network. This case is similar to section 6.2		provider network. This case is similar to section 6.2
	6.3.2. Managed DNS resolver used with multiple CDN vendors		5.3.2. Managed DNS resolver used with multiple CDN vendors
	In this Model, Managed DNS service can be used along with multiple		In this Model, Managed DNS service can be used along with multiple
	CDN vendors where DNS resolver can redirect to different caches		CDN vendors where DNS resolver can redirect to different caches
	depending on the subdomain e.g. DNS resolver could have below		depending on the subdomain e.g. DNS resolver could have below
	records		records
	subdomain1.xyz.com CNAME cdn1.com		subdomain1.xyz.com CNAME cdn1.com
	subdomain2.xyz.com CNAME cdn2.com		subdomain2.xyz.com CNAME cdn2.com
	In this case CDN DNS resolver needs to be an ALTO client. This		In this case CDN DNS resolver needs to be an ALTO client. This
	deployment will be similar to ones described in section 6.1 and		deployment will be similar to ones described in section 6.1 and
	section 6.2 earlier.		section 6.2 earlier.
	7. Tracker Integration		6. Tracker Integration
	In the case of P2P CDNs, the application tracker takes the role of		In the case of P2P CDNs, the application tracker takes the role of
	the ALTO Client, fetching the map from the ALTO Server and		the ALTO Client, fetching the map from the ALTO Server and
	integrating it its peer database. The result is a peer database		integrating it its peer database. The result is a peer database
	taking into account current metrics such as peer availability,		taking into account current metrics such as peer availability,
	content availability and also localization. This architecture in the		content availability and also localization. This architecture in the
	context of file sharing was extensively studied and trialed by ISPs		context of file sharing was extensively studied and trialed by ISPs
	such as Comcast [RFC5632] under the P4P [P4P] protocol.		such as Comcast [RFC5632] under the P4P [P4P] protocol.
	8. IANA Considerations		7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	9. Security Considerations		8. Security Considerations
	When the ALTO Server and Client are operated by different entities		When the ALTO Server and Client are operated by different entities
	the issue of trust and security comes forward. The exchange of		the issue of trust and security comes forward. The exchange of
	information could be done using the encryption methods already		information could be done using the encryption methods already
	present in HTTP but preventing unauthorized redistribution comes into		present in HTTP but preventing unauthorized redistribution comes into
	play. A further issue is if the ALTO information information is		play. A further issue is if the ALTO information information is
	transitive, which modifications are allowed.		transitive, which modifications are allowed.
	10. Acknowledgements		9. Acknowledgements
	TBD		We would like to thank Richard Yang for valuable input and
			contributions to this draft. We would also like to thank Nabil
			Bitar, Manish Bhardwaj, Michael Korolyov, Steven Luong and Ferry
			Sutanto for their comments.
	11. References		10. References
	11.1. Normative References		10.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		10.2. Informative References
	[ARBOR] Labovitz, "Internet Traffic and Content Consolidation",		[ARBOR] Labovitz, "Internet Traffic and Content Consolidation",
	2009, <http://www.ietf.org/proceedings/10mar/slides/		2009, <http://www.ietf.org/proceedings/10mar/slides/
	plenaryt-4.pdf>.		plenaryt-4.pdf>.
	[I-D.ietf-alto-protocol]		[I-D.ietf-alto-protocol]
	Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",		Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
	draft-ietf-alto-protocol-03 (work in progress),		draft-ietf-alto-protocol-03 (work in progress),
	March 2010.		March 2010.
	skipping to change at page 17, line 44 ¶		skipping to change at page 18, line 43 ¶
	[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and		[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
	Y. Yang, "Comcast's ISP Experiences in a Proactive Network		Y. Yang, "Comcast's ISP Experiences in a Proactive Network
	Provider Participation for P2P (P4P) Technical Trial",		Provider Participation for P2P (P4P) Technical Trial",
	RFC 5632, September 2009.		RFC 5632, September 2009.
	Authors' Addresses		Authors' Addresses
	Reinaldo Penno		Reinaldo Penno
	Juniper Networks		Juniper Networks
	1194 N Mathilda Avenue
	Sunnyvale
	USA
	Email: rpenno@juniper.net		Email: rpenno@juniper.net
	Satish Raghunath		Satish Raghunath
	Juniper Networks		Juniper Networks
	1194 N Mathilda Avenue
	Sunnyvale
	USA
	Email: satishr@juniper.net		Email: satishr@juniper.net
	Jan Medved		Jan Medved
	Juniper Networks		Juniper Networks
	1194 N Mathilda Avenue
	Sunnyvale
	USA
	Email: jmedved@juniper.net		Email: jmedved@juniper.net
	Mayuresh Bakshi		Mayuresh Bakshi
	Juniper Networks		Juniper Networks
	1194 N Mathilda Avenue
	Sunnyvale
	USA
	Email: mbakshi@juniper.net		Email: mbakshi@juniper.net
	Richard Alimi		Richard Alimi
	Yale University		Yale University
	Email: richard.alimi@yale.edu		Email: richard.alimi@yale.edu
	Stefano Previdi		Stefano Previdi
	Cisco Systems		Cisco Systems
End of changes. 67 change blocks.
	160 lines changed or deleted		241 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/