< draft-randriamasy-alto-multi-cost-03.txt		draft-randriamasy-alto-multi-cost-05.txt >
	Network Working Group S. Randriamasy, Ed.		Network Working Group S. Randriamasy, Ed.
	Internet-Draft Alcatel-Lucent Bell Labs		Internet-Draft N. Schwan
	Intended status: Experimental N. Schwan		Intended status: Experimental Alcatel-Lucent Bell Labs
	Expires: January 12, 2012 July 11, 2011		Expires: May 3, 2012 October 31, 2011
	Multi-Cost ALTO		Multi-Cost ALTO
	draft-randriamasy-alto-multi-cost-03		draft-randriamasy-alto-multi-cost-05
	Abstract		Abstract
	IETF is designing a new service called ALTO (Application Layer		IETF is designing a new service called ALTO (Application Layer
	traffic Optimization) that includes a "Network Map Service", an		traffic Optimization) that includes a "Network Map Service", an
	"Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and		"Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and
	thus incentives for application clients to connect to ISP preferred		thus incentives for application clients to connect to ISP preferred
	Endpoints. These services provide a view of the Network Provider		Endpoints. These services provide a view of the Network Provider
	(NP) topology to overlay clients.		(NP) topology to overlay clients.
	The present draft proposes a light way to extend the information		The present draft proposes a light way to extend the information
	provided by the current ALTO protocol. The purpose is to broaden the		provided by the current ALTO protocol. The purpose is to broaden the
	possibilities of the Application Clients in two ways: firstly by		possibilities of the Application Clients in two ways. Firstly it
	providing a better mapping of the Selected Endpoints to needs of the		proposes to include information on multiple cost types in a single
	growing diversity of Content Networking Applications and to the		ALTO transaction, providing a better mapping of the Selected
	network conditions, secondly by producing a more robust choice of		Endpoints to needs of the growing diversity of Content Networking
	multiple Endpoints, helping thus out for efficient Multi-Path		Applications and to the network conditions. Secondly it proposes new
	transfer.		cost types, that are an abstraction of time-sensitive network
			information as viewed by the Network Provider. All this also helps
			producing a more robust choice when multiple Endpoints must be
			selected.
	There are 2 parts in this draft: the first part initiates protocol		There are 2 parts in this draft: the first part initiates protocol
	extensions to support requests on multiple Cost Types in one single		extensions to support requests on multiple Cost Types in one single
	transaction. These first extensions also integrate the discussions		transaction. These first extensions also integrate the discussions
	within the ALTO Working Group and focus on the Endpoint Cost Service.		within the ALTO Working Group. The second part proposes use cases
	The second part proposes two use cases motivating further definitions		motivating further definitions of additional CostTypes and Cost
	of additional CostTypes and Cost Attributes related to timeframe and		related attributes and capabilities.
	validity period.
	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 in full conformance with the
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 15 ¶
	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 January 12, 2012.		This Internet-Draft will expire on May 3, 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
	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 Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Proposed ALTO protocol updates for multi-cost transactions . . 6		4. Proposed ALTO protocol updates for multi-cost transactions . . 7
	4.1. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 6		4.1. Information Resources Directory . . . . . . . . . . . . . 8
	4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 6		4.1.1. Example Multi-Cost specific resources . . . . . . . . 8
	4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7		4.2. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 10
	4.1.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7		4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 10
	4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 7		4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 10
	4.1.5. Response . . . . . . . . . . . . . . . . . . . . . . . 7		4.2.3. Input Parameters . . . . . . . . . . . . . . . . . . . 10
	4.1.6. Example . . . . . . . . . . . . . . . . . . . . . . . 7		4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 10
	4.2. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 7		4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . 11
	4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 7		4.2.6. Example . . . . . . . . . . . . . . . . . . . . . . . 13
	4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7		4.3. Filtered Multi-Cost Map . . . . . . . . . . . . . . . . . 13
	4.2.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7		4.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 14
	4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 8		4.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 14
	4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . 8		4.3.3. Input Parameters . . . . . . . . . . . . . . . . . . . 14
	4.2.6. Example . . . . . . . . . . . . . . . . . . . . . . . 8		4.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 16
	4.3. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 8		4.3.5. Response . . . . . . . . . . . . . . . . . . . . . . . 16
	5. Use cases for further Cost Types and Endpoint Properties . . . 8		4.3.6. Example . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. Delay Sensitive Overlay Applications . . . . . . . . . . . 9		4.4. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 17
	5.2. CDN Surrogate Selection . . . . . . . . . . . . . . . . . 10		4.4.1. Endpoint Multi-Cost . . . . . . . . . . . . . . . . . 18
	6. Proposed additional Properties and Costs . . . . . . . . . . . 10		4.4.2. Media Type . . . . . . . . . . . . . . . . . . . . . . 18
	6.1. Scoping ALTO information . . . . . . . . . . . . . . . . . 10		4.4.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		4.4.4. Input Parameters . . . . . . . . . . . . . . . . . . . 18
	7.1. Information for IANA on proposed Cost Types . . . . . . . 11		4.4.5. Capabilities . . . . . . . . . . . . . . . . . . . . . 19
	7.2. Information for IANA on proposed Endpoint Propeeries . . . 11		4.4.6. Response . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		4.4.7. Example . . . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.5. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 12		5. Use cases for further Cost Types and Endpoint Properties . . . 22
	9.2. Informative References . . . . . . . . . . . . . . . . . . 12		5.1. Delay Sensitive Overlay Applications . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		5.2. CDN Surrogate Selection . . . . . . . . . . . . . . . . . 23
			5.3. Bulk Data Transfer scheduling . . . . . . . . . . . . . . 24
			6. Proposed additional Properties and Costs . . . . . . . . . . . 25
			6.1. For further extensions: dynamic Costs . . . . . . . . . . 25
			6.1.1. Path Occupation Cost and Endpointoccupationcost . . . 26
			6.1.2. Dynamic Cost Attributes . . . . . . . . . . . . . . . 26
			6.1.2.1. The dynamic Cost Mode . . . . . . . . . . . . . . 26
			6.1.3. Proposed dynamic Cost Scope capability . . . . . . . 27
			6.1.3.1. Example of time scope for a dynamic cost . . . . . 27
			6.1.4. Example of dynamic information resources in the IRD . 27
			6.1.4.1. Example of response with a "dynamic" cost . . . . 28
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
			7.1. Information for IANA on proposed Cost Types . . . . . . . 30
			7.2. Information for IANA on proposed Endpoint Propeeries . . . 30
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
			9.2. Informative References . . . . . . . . . . . . . . . . . . 31
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	IETF is designing a new service called ALTO that provides guidance to		IETF is designing a new service called ALTO that provides guidance to
	P2P applications, which have to select one or several hosts from a		P2P applications, which have to select one or several hosts from a
	set of candidates that are able to provide a desired resource. This		set of candidates that are able to provide a desired resource. This
	guidance shall be based on parameters that affect performance and		guidance shall be based on parameters that affect performance and
	efficiency of the data transmission between the hosts, e.g., the		efficiency of the data transmission between the hosts, e.g., the
	topological distance. The ultimate goal is to improve Quality of		topological distance. The ultimate goal is to improve Quality of
	Experience (QoE) in the application while reducing resource		Experience (QoE) in the application while reducing resource
	skipping to change at page 4, line 27 ¶		skipping to change at page 5, line 27 ¶
	System (AS). Together with this Network Map, it provides the		System (AS). Together with this Network Map, it provides the
	Provider determined Cost Map between locations of the Network Map.		Provider determined Cost Map between locations of the Network Map.
	Last, it provides the Ranking of Endpoints w.r.t. their routing cost.		Last, it provides the Ranking of Endpoints w.r.t. their routing cost.
	The term Network Provider in this document includes both ISPs, who		The term Network Provider in this document includes both ISPs, who
	provide means to transport the data and Content Delivery Network		provide means to transport the data and Content Delivery Network
	(CDN) operators who care for the dissemination, persistent storage		(CDN) operators who care for the dissemination, persistent storage
	and possibly identification of the best/closest content copy.		and possibly identification of the best/closest content copy.
	The last ALTO protocol draft see [ID-alto-protocol], gives the		The last ALTO protocol draft see [ID-alto-protocol], gives the
	possibility to query multiple Endpoint properties at once (see		possibility to query multiple Endpoint properties at once. On the
	S.7.7.4.1). However section 7.7.3.2 on Cost Map states about both		other hand, the Endpoint Cost service in its input specification
	parameters Cost Type and Cost Mode that: "This parameter MUST NOT be		allows only one Cost Type and Cost mode per request. The ALTO
	specified multiple times". The ALTO requirements draft, see		requirements draft, see [ID-ALTO-Requirements7] states in REQ.
	[ID-ALTO-Requirements7] also states in REQ. ARv05-14: "The ALTO		ARv05-14: "The ALTO client protocol MUST support the usage of several
	client protocol MUST support the usage of several different rating		different rating criteria types". In the current protocol draft,
	criteria types". In the current protocol draft, there is no		there is no specified way to get values for several Cost Types
	specified way to get values for several Cost Types altogether.		simultaneously. Currently, the costs are provided in a scalar form,
	Currently, the costs are provided in a scalar form, one by one. So		one by one. So that an ALTO Client wanting information for several
	that an ALTO Client wanting information for several Cost Types must		Cost Types must request and receive a response as many times as
	place a request and receive a response as many times as desired Cost		desired Cost Types.
	Types. However, vector costs provide a robust and natural input to
	multi-path connections and getting all costs in one single query/		Getting all costs in one single query/response transaction saves time
	response transaction saves time and ALTO traffic, thus ressources,		and ALTO traffic load, thus ressources, thus energy. Besides, vector
	thus energy.		costs provide a robust and natural input to multi-variate path
			computation as well as robust multi-variate selection multiple
			Endpoints. Other savings in resources can be obtained by gathering
			multiple Cost Types in the Cost map and Filtered Cost Map services.
			Indeed, one Cost Map reporting on N Cost Types is less bulky than N
			Cost Maps containing one Cost Type each. This is valuable for both
			the storage of these maps and their transfer. Last, as it is most
			likely that nowadays applications need information on several cost
			types, having them gathered in one map will save time.
	The ALTO Problem Statement, see [RFC5693] and the ALTO requirements		The ALTO Problem Statement, see [RFC5693] and the ALTO requirements
	draft, see [RFC5693] stress that: "information that can change very		draft, see [RFC5693] stress that: "information that can change very
	rapidly, such as transport-layer congestion, is out of scope for an		rapidly, such as transport-layer congestion, is out of scope for an
	ALTO service. Such information is better suited to be transferred		ALTO service. Such information is better suited to be transferred
	through an in-band technique at the transport layer instead", as		through an in-band technique at the transport layer instead", as
	"ALTO is not an admission control system "and does not necessarily		"ALTO is not an admission control system "and does not necessarily
	know about the instant load of endpoints and links. However, longer		know about the instant load of endpoints and links. However, non-
	term statistics or empirical ratings on performance oriented		real time abstraction of performance oriented information is useful
	information may still be useful for a reliable choice of candidate		for a reliable choice of candidate endpoints. In addition, given the
	endpoints. In addition, given the QoE requirements of nowadays and		QoE requirements of nowadays and future Internet applications, more
	future Internet applications, more and more NPs compute and store		and more NPs compute and store such information to optimize their
	such information to optimize their traffic. Last, specific ALTO		traffic. Besides specific ALTO servers can be specified for small
	servers can be specified for mobile core networks, which have a		networks including mobile core networks, which have a smaller scale
	smaller scale and can afford and take advantage of using smaller		and can afford and take advantage of using small time-scale network
	time-scale network information.		information. Adding QoE-enabling metrics to the Network Provider
			established routing cost could meet the interests of both the end
	Adding QoE-enabling metrics to the Network Provider established		users and the Providers.
	routing cost could meet the interests of both the end users and the
	Providers. Besides, keeping the shortest or cheapest possible path,
	in addition, saves resources, time and energy.
	2. Scope		2. Scope
	This draft generalizes the case of a P2P client to include the case		This draft generalizes the case of a P2P client to include the case
	of a CDN client, a GRID application client and any Client having the		of a CDN client, a GRID application client and any Client having the
	choice in several connection points for data or resource exchange.		choice in several connection points for data or resource exchange.
	To do so, it uses the term "Application Client" (AC).		To do so, it uses the term "Application Client" (AC).
	This draft focuses on the use case where the ALTO client is embedded		This draft focuses on the use case where the ALTO client is embedded
	in the Application Client. For P2P applications, the use case where		in the Application Client or in some Application Endpoint tracker in
	the ALTO Client is embedded in the P2P tracker is also applicable.		the network, such as a P2P tracker, a CDN location tracker or a cloud
			computing orchestration system implemented in a logically centralized
			management system.
	It is assumed that Applications likely to use the ALTO service have a		It is assumed that Applications likely to use the ALTO service have a
	choice in connection endpoints as it is the case for most of them.		choice in connection endpoints as it is the case for most of them.
	The ALTO service is managed by the Network Provider and reflects its		The ALTO service is managed by the Network Provider and reflects its
	preferences for the choice of endpoints. The NP defines in		preferences for the choice of endpoints. The NP defines in
	particular the network map, the routing cost among Network Locations,		particular the network map, the routing cost among Network Locations,
	and which ALTO services are available at a given ALTO server.		and which ALTO services are available at a given ALTO server.
	The solution proposed in this draft is applicable to fixed networks.
	It is also meant for smaller networks such as mobile networks.
	3. Terminology		3. Terminology
	Endpoint (EP): can be a Peer, a CDN storage location, a Party in a		Endpoint (EP): can be a Peer, a CDN storage location, a Party in a
	resource sharing swarm such as a computation Grid or an online multi-		resource sharing swarm such as a computation Grid or an online multi-
	party game.		party game.
	Endpoint Discovery (EP Discovery) : this term covers the different		Endpoint Discovery (EP Discovery) : this term covers the different
	types of processes used to discover different types of endpoints.		types of processes used to discover different types of endpoints.
	Network Service Provider: includes both ISPs, who provide means to		Network Service Provider (NSP): includes both ISPs, who provide means
	transport the data and Content Delivery Network (CDN) who care for		to transport the data and Content Delivery Network (CDN) who care for
	the dissemination, persistent storage and possibly identification of		the dissemination, persistent storage and possibly identification of
	the best/closest content copy.		the best/closest content copy.
			ALTO transaction: a request/response exchange between an ALTO Client
			and an ALTO Server.
	Application Client (AC): this term generalizes the case of a P2P		Application Client (AC): this term generalizes the case of a P2P
	client to include the case of a CDN client and of any Client having		client to include the case of a CDN client and of any Client having
	the choice in several connection points for data or resource		the choice in several connection points for data or resource
	exchange.		exchange.
	4. Proposed ALTO protocol updates for multi-cost transactions		4. Proposed ALTO protocol updates for multi-cost transactions
	This section is to be completed and proposes first updates of the		This section proposes updates of the ALTO protocol to support Multi
	ALTO protocol to support Multi Cost ALTO Services or provide		Cost ALTO Services or provide additional ALTO information. It
	additional ALTO information. It integrates discussions on he ALTO		integrates discussions on the ALTO mailing list.
	mailing list and its goal is to initiate further discussions and
	protocol update proposals.
	If an ALTO client desires several Cost Types, instead of placing as		If an ALTO client desires several Cost Types, instead of placing as
	many requests as costs, it may request and receive all the desired		many requests as costs, it may request and receive all the desired
	cost types in one single transaction. The correspondence between the		cost types in one single transaction.
	components and the cost types MUST be indicated in the ALTO request.
	The ALTO server then, provided it supports the desired cost, and		The ALTO server then, provided it supports the requested Cost Types,
	provided it supports multi-cost ALTO transactions, sends one single		and provided it supports multi-cost ALTO transactions, sends one
	response where for each {source, destination} pair. The cost values		single response where for each {source, destination} pair, the cost
	are arranged in a vector, whose component each corresponds to a		values are arranged in a vector, where each component corresponds to
	specified Cost Type. The correspondence between the components and		a specified Cost Type. The correspondence between the components and
	the cost types MUST be indicated either in the ALTO response or		the cost types MUST be indicated either in the ALTO response or
	available via the resource directory.		available via the resource directory.
	The ALTO services impacted by the Multi-Cost extensions are:		The following ALTO services get corresponding services with Multi-
			Cost extensions:
	o Information Resources Directory,		o Information Resources Directory: extended with multi-cost related
			URIs and associated capabilities.
	o Cost Map Service,		o Cost Map Service: extended with the Multi-Cost Map Service,
	o Cost Map Filtering Service,		o Cost Map Filtering Service: extended with the Multi-Cost Map
			Filtering Service,
	o Endpoint Cost Lookup Service.		o Endpoint Cost Lookup Service: extended with the Endpoint Multi-
			Cost Lookup Service.
	This draft focuses on the case of the Endpoint Cost Lookup Service		4.1. Information Resources Directory
	4.1. Multi-Cost Map Service		When the ALTO server supports the provision of information on
			multiple costs in a single transactions, the Information Resources
			will list the corresponding resources. The media type and encoding
			specificarions remain the same as in the current ALTO protocol.
	To be completed		4.1.1. Example Multi-Cost specific resources
	4.1.1. Media Type		The following is an example Information Resource Directory returned
	4.1.2. HTTP Method		by an ALTO Server and containing Multi-Cost specific services: the
			Multi-Cost Map Service, Filtered Multi-Cost Map and the Endpoint
			Multi-Cost Service. It is assumed that the IRD contains usual ALTO
			Services as described in the example IRD of the current ALTO
			protocol. In this example, the ALTO Server provides additional
			Multi-Cost Services in a specific folder of "alto.example.com" called
			"multi". This folder contains the Multi-Cost Maps, Filtered Multi-
			Cost Maps as well as the Endpoint Multi-Cost Service.
	This resource is requested using the HTTP POST method		GET /directory HTTP/1.1
			Host: alto.example.com
			Accept: application/alto-directory+json,application/alto-error+json
	4.1.3. Input Parameters		HTTP/1.1 200 OK
			Content-Length: [TODO]
			Content-Type: application/alto-directory+json
	4.1.4. Capabilities		{
			"resources" : [
			{
			.....
			Usual ALTO "single-cost" Services as described in ALTO Protocol
			.....
			}, {
			"uri" : "http://alto.example.com/multi/maps",
			"media-types" : ["application/alto-multicostmap+json"],
			"accepts" : ["application/alto-multicostmapfilter+json"],
			"capabilities" : {
			"cost-constraints" : true,
			"cost-types" : [ "routingcost", "hopcount" ],
			"cost-modes" : [ "numerical", "numerical" ]
			}
			}, {
			"uri" : "http://alto.example.com/multi/endpointmulticost/lookup",
			"media-types" : [ "application/alto-endpointmulticost+json" ],
			"accepts" : [ "application/alto-endpointmulticostparams+json" ],
			"capabilities" : {
			"cost-constraints" : true,
			"cost-types" : [ "routingcost", "hopcount" ],
			"cost-modes" : [ "numerical", "numerical" ]
			}
			}, {
			"uri" : "http://custom.alto.example.com/multi/endpointmulticost/lookup",
			"media-types" : [ "application/alto-endpointmulticost+json" ],
			"accepts" : [ "application/alto-endpointmulticostparams+json" ],
			}
			]
			}
	4.1.5. Response		4.2. Multi-Cost Map Service
	4.1.6. Example		This section introduces a new media-type for the Multi-Cost map. For
			each source/destination pair of PIDs, it provides the value of the
			different Cost Type supported for the Multi-cost map, in the same
			order as in the list of cost-types specified in the capabilities.
	4.2. Endpoint Multi-Cost Service		A Multi-Cost Map MAY be provided by an ALTO Server.
			This resource MUST be provided for at least the 'routingcost' Cost
			Type with the 'numerical' Cost Mode. It is assumed that an ALTO
			Server supporting multi-cost maps supports the 'numerical' Cost Mode
			for all Cost Types encoded in the 'JSONnumber' type.
			Note that the capabilities specify implicitly the order in which the
			different Cost Type values will be listed in the Cost Map.
			The Cost Type values in the responses are encoded in with a JSONArray
			of cost values for the different required cost types.
			Note also that contrary to the Cost Map service, the returned Multi
			Cost Map is not required to include the required Path Costs for each
			pair of Source and Destination PID known to the ALTO Server. The
			reason is that for a given source/destination pair, the ALTO Server
			may not have the information on certain Cost Types. As a
			consequence, contrary to the Cost Map service, the Multi-Cost Map
			service introduces a particular value that unambiguously indicates
			that the information is not available. This way, the order in which
			the cost values are provided for a source/destination pair is
			unambiguous.
	4.2.1. Media Type		4.2.1. Media Type
			The media type is "application/alto-multicostmap+json".
	4.2.2. HTTP Method		4.2.2. HTTP Method
	This resource is requested using the HTTP POST method		This resource is requested using the HTTP GET method.
	4.2.3. Input Parameters		4.2.3. Input Parameters
	Input parameters are supplied in the entity body of the POST request.		None.
	This document specifies input parameters with a data format indicated
	by media type "application/alto-endpointcostparams+json", which is a		4.2.4. Capabilities
	JSON Object of type ReqEndpointCostMap:
			This resource may be defined for multiple Cost Types and Cost Modes.
			The capabilities of an ALTO Server URI providing this resource are
			defined by a JSON Object of type MultiCostMapCapability:
	object {		object {
			CostType cost-types<1..*>;
			CostMode cost-modes<0..*>;
			} MultiCostMapCapability;
	TypedEndpointAddr srcs<0..*>; [OPTIONAL]		with members
	TypedEndpointAddr dsts<1..*>;		cost-types The Cost Types ( Section 5.1.1) supported by the
			corresponding URI. This member MUST at least include the
			type 'routingcost'. The order in which the Cost Type values
			for a source/destination pair will be listed in the Multi-Cost
			Map provided to an ALTO Client MUST be the order in which these
			Cost Types are listed in this member.
	} EndpointFilter;		cost-modes The Cost Mode ( Section 5.1.2) supported for each of
			the supported Cost Types listed in the "cost-types".
			For Cost types encoded with the 'JSONnumber' type, the
			Cost Mode MUST be numerical. It will be interpreted as such
			if this member is not present.
			An ALTO Server MUST support all of the Cost Types listed here for
			each of the listed Cost Modes. Note that an ALTO Server may provide
			multiple Cost Map Information Resources, each with different
			capabilities.
			An ALTO Server supporting the Multi-Cost Map service, MUST support
			the Cost mode 'numerical' for all supported Cost Types encoded with
			the 'JSONnumber' type. It also MUST list the Cost Type values
			associated to a source/destination pair in the same order as in the
			"cost-types" member of the capabilities specified the Multi-Cost Map
			resource.
			4.2.5. Response
			The returned InfoResourceEntity object has "data" member of type
			InfoResourceMultiCostMap:
			object DstMultiCosts {
			JSONArray [PIDName];
			...
			};
	object {		object {
			DstMultiCosts [PIDName]<0..*>;
			...
			} MultiCostMapData;
	CostMode cost-mode;		object {
			CostType cost-type<1..*>;
			CostMode cost-mode<1..*>;
			JSONString map-vtag;
			MultiCostMapData map;
			} InfoResourceMultiCostMap;
	CostType cost-type<1..*>;		with members:
	JSONString constraints; [OPTIONAL]		cost-mode Cost Mode (Section 5.1.2) used in the Cost Map where each
			member of the cost-mode list is the Cost Mode provided for the
			Cost Type at the same place in the list.
	EndpointFilter endpoints;		cost-type Cost Type (Section 5.1.1) used in the Multi Cost Map.
	} ReqEndpointCostMap;		map-vtag The Version Tag (Section 5.3) of the Network Map used to
			generate the Cost Map.
			map The Multi Cost Map data itself.
			MultiCostMapData is a JSON object with each member representing a single
			Source PID; the name for a member is the PIDName string identifying
			the corresponding Source PID. For each Source PID, a DstMultiCosts
			object denotes the associated multiple costs to a set of destination
			PIDs (Section 5.2); the name for each member in the object is the PIDName
			string identifying the corresponding Destination PID. DstMultiCosts are
			listed in the same order as in the 'cost-type' array.
			The returned Cost Map MUST include the required Path Costs for each
			pair of Source and Destination PID for which this information is
			available.
			The members cost-mode and cost-type MUST be arrays with the same
			number of elements.
			Note also that the Multi-Cost Map service needs a particular value
			that unambiguously indicates that the information is not available.
			As an example this value is referred here to as NAv for "Not
			available". Note that the type of NAv still needs to be specified:
			preferably a numerical value for numerical costs that unambiguously
			means: "not available" and can distiguished from "infinite" or
			"invalid something" or any "pathological" value.
			4.2.6. Example
			This example illustrates a 'static' multi-cost' ALTO trasaction,
			where the utilized cost-types all have 'static' values. We assume
			here that the Cost Types available at the ALTO Server are
			"routingcost" and "hopcount" and the 'numerical' mode is available
			for both of them. The "routingcost" may be based on monetary
			considerations where as the "hopcount" is used to account on the path
			delay.
			GET /multicostmap/num HTTP/1.1
			Host: alto.example.com
			Accept: application/alto-multicostmap+json,application/alto-error+json
			HTTP/1.1 200 OK
			Content-Length: [TODO]
			Content-Type: application/alto-multicostmap+json
			{
			"meta" : {},
			"data" : {
			"cost-mode" : ["numerical", "numerical"]
			"cost-type" : ["routingcost", "hopcount"]
			"map-vtag" : "1266506139",
			"map" : {
			"PID1": { "PID1": [1,6], "PID2": [5,23], "PID3": [10,5] },
			"PID2": { "PID1": [5,5], "PID2": [1,11], "PID3": [15,9] },
			"PID3": { "PID1": [20,12], "PID2": [15,1], "PID3": [1,18] }
			}
			}
			}
			4.3. Filtered Multi-Cost Map
			A Multi-Cost Map may reach a huge volume and also, an Application
			Client assisted by the ALTO Client does not necessarily need
			information on all the Cost Types for all the source/destination
			pairs of PIDs.
			Therefore, applications may more likely use Cost Map information
			filtered w.r.t. the Cost types as well as the source/destination
			pairs of PIDs. This section specifies filtered Multi-Cost Maps.
			A Filtered Cost Map is a Cost Map Information Resource (Section
			7.7.2.2) for which an ALTO Client may supply additional parameters
			limiting the scope of the resulting Cost Map. A Filtered Cost Map MAY
			be provided by an ALTO Server.
			4.3.1. Media Type
			The media type is "application/alto-multicostmap+json", see Section
			4.2.1 of this draft.
			4.3.2. HTTP Method
			This resource is requested using the HTTP POST method
			4.3.3. Input Parameters
			Input parameters are supplied in the entity body of the POST request.
			This document specifies the input parameters with a data format
			indicated by the media type "application/
			alto-multicostmapfilter+json", which is a JSON Object of type
			ReqFilteredCostMap, where:
			object {
			PIDName srcs<0..*>;
			PIDName dsts<0..*>;
			} PIDFilter;
			object {
			CostType cost-type<0..*>;
			CostMode cost-mode<0..*>;
			JSONString constraints<0..*>; [OPTIONAL]
			PIDFilter pids; [OPTIONAL]
			} ReqFilteredMultiCostMap;
	with members:		with members:
	cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs.		cost-type The Cost Type ( Section 5.1.1) for the returned costs.
	For Multi-Cost requests this Cost Mode SHOULD be numerical.		Each listed cost-type MUST be one of the supported Cost Types indicated
			in this resource's capabilities ( Section 7.7.3.2.4).
	cost-type The Cost Type ( Section 5.1.1) to use for returned costs.		cost-mode The Cost Mode ( Section 5.1.2) for each of the returned cost-types.
	All the listed the Cost Types MUST be indicated in this resource's		For Cost types encoded with the 'JSONnumber' type, the
	capabilities ( Section 7.7.5.1.4).		Cost Mode MUST be numerical. It will be interpreted as such
			if this member is not present.
	constraints Defined equivalently to the "constraints" input parameter		constraints Defines a list of additional constraints on which
	of a Filtered Cost Map (see Section 7.7.3.2).		elements of the Cost Map are returned. This parameter MUST NOT be
			specified if this resource's capabilities ( Section 7.7.3.2.4)
			indicate that constraint support is not available. A constraint
			contains two entities separated by whitespace: (1) an operator
			either 'gt' for greater than or 'lt' for less than (2) a target
			numerical cost. The numerical cost is a number that MUST be
			defined in the same units as the Cost Type indicated by the cost-
			type parameter. ALTO Servers SHOULD use at least IEEE 754 double-
			precision floating point [IEEE.754.2008] to store the numerical
			cost, and SHOULD perform internal computations using double-
			precision floating-point arithmetic. If multiple 'constraint'
			parameters are specified, they are interpreted as being related to
			each other with a logical AND.
	endpoints A list of Source Endpoints and Destination Endpoints for		pids A list of Source PIDs and a list of Destination PIDs for which
	which Path Costs are to be returned. If the list of Source Endpoints		Path Costs are to be returned. If a list is empty, the ALTO
	is empty (or not included), the ALTO Server MUST interpret it as if		Server MUST interpret it as the full set of currently-defined
	it contained the Endpoint Address corresponding Alimi, et al.		PIDs. The ALTO Server MUST interpret entries appearing in a list
	Expires December 29, 2011 [Page 50] Internet-Draft ALTO Protocol June		multiple times as if they appeared only once. If the "pids"
	2011 to the client IP address from the incoming connection (see		member is not present, both lists MUST be interpreted by the ALTO
	Section 10.3 for discussion and considerations regarding this mode).		Server as containing the full set of currently-defined PIDs.
	The list of destination Endpoints MUST NOT be empty. The ALTO Server
	MUST interpret entries appearing multiple times in a list as if they
	appeared only once.
	4.2.4. Capabilities		4.3.4. Capabilities
	4.2.5. Response		The URI providing this resource supports all capabilities documented
			in Section 7.7.2.2.4 (with identical semantics), plus additional
			capabilities. In particular, the capabilities are defined by a JSON
			object of type FilteredMultiCostMapCapability:
	4.2.6. Example		object {
			CostMode cost-modes<0..*>;
			CostType cost-types<0..*>;
			JSONBool cost-constraints;
			} FilteredMultiCostMapCapability;
	4.3. ALTO Status Codes for Multi-Cost ALTO		with members:
			cost-modes See Section 4.2.5 of this MC draft
			cost-types See Section 4.2.5 of this MC draft
			cost-constraints If true, then the ALTO Server allows cost
			constraints to be included in requests to the corresponding URI.
			If not present, this member MUST be interpreted as if it specified
			false.
			4.3.5. Response
			See Section of this draft for the format. The returned Cost Map MUST
			NOT contain any source/destination pair that was not indicated
			(implicitly or explicitly) in the input parameters. If the input
			parameters contain a PID name that is not currently defined by the
			ALTO Server, the ALTO Server MUST behave as if the PID did not appear
			in the input parameters. If any constraints are specified, Source/
			Destination pairs that do for which the Path Costs do not meet the
			constraints MUST NOT be included in the returned Cost Map. If no
			constraints were specified, then all Path Costs are assumed to meet
			the constraints.
			4.3.6. Example
			POST multi/multicostmap/filtered HTTP/1.1
			Host: alto.example.com
			Content-Type: application/alto-multicostmapfilter+json
			Accept: application/alto-multicostmap+json,application/alto-error+json
			{
			"cost-mode" : "numerical", "numerical"],
			"cost-type" : "routingcost", "hopcount"],
			"pids" : {
			"srcs" : [ "PID1" ],
			"dsts" : [ "PID1", "PID2", "PID3" ]
			}
			}
			HTTP/1.1 200 OK
			Content-Length: [TODO]
			Content-Type: application/alto-costmap+json
			{
			"meta" : {},
			"data" : {
			"cost-mode" : ["numerical", "numerical"],
			"cost-type" : ["routingcost", "hopcount"],
			"map-vtag" : "1266506139",
			"map" : {
			"PID1": { "PID1": [1,6], "PID2": [5,23], "PID3": [10,5] }
			}
			}
			}
			4.4. Endpoint Multi-Cost Service
			The Endpoint Multi-Cost Service provides information about several
			costs between individual Endpoints.
			This service does not allow lists of Endpoint prefixes (and
			addresses, as a special case) to be ranked (ordered) by an ALTO
			Server, as firstly the costs encoded with the JSONnumber 'type' are
			provided in the numerical Mode and secondly the choice among various
			existing methods to rank Endpoints upon multiple costs (criteria) is
			out of scope of this protocol and in the responsability of the
			Application Client using the ALTO Endpoint Multi-Cost information.
			However common sense lead to warn that a necessary condition for
			methods that rank vectors to be reliable is that the components
			(costs) of the processed vectors be numerical Cost Mode.
			This Service introduces a new media type to define the service and
			the input parameters.
			4.4.1. Endpoint Multi-Cost
			The Endpoint Multi-Cost resource provides information about multiple
			costs between individual endpoints.
			This service MAY be provided by an ALTO Server. If it is provided.
			It is important to note that although this resource allows an ALTO
			Server to reveal costs between individual endpoints, an ALTO Server
			is not required to do so. A simple alternative would be to compute
			the cost between two endpoints as the cost between the PIDs
			corresponding to the endpoints +++ if this service is available for
			the requested Cost Types +++ . See Section 12.1 for additional
			details.
			4.4.2. Media Type
			The media type is "application/alto-endpointmulticost+json".
			4.4.3. HTTP Method
			This resource is requested using the HTTP POST method
			4.4.4. Input Parameters
			Input parameters are supplied in the entity body of the POST request.
			This document specifies input parameters with a data format indicated
			by media type "application/alto-endpointmulticostparams+json", which
			is a JSON Object of type ReqEndpointMultiCostMap:
			object {
			TypedEndpointAddr srcs<0..*>; [OPTIONAL]
			TypedEndpointAddr dsts<1..*>;
			} EndpointFilter;
			object{
			CostType cost-type<0..*>;
			CostMode cost-mode<0..*>;
			JSONString constraints; [OPTIONAL]
			EndpointFilter endpoints;
			} ReqEndpointMultiCostMap;
			with members:
			cost-mode The Cost Mode ( Section 5.1.2) to use for returne costs that
			are encoded with the 'JSONnumber' type. For Multi-Cost requests
			this Cost Mode MUST be numerical for any Cost Type encoded with
			the 'JSONnumber' type, provided that the Cost Mode 'numerical'
			is available for this Cost Type. Remember (Section 5.1.2) that
			ALTO Clients SHOULD be cognizant of operations applicable to different
			Cost Modes.
			cost-type The Cost Type ( Section 5.1.1) to use for returned costs.
			All the listed the Cost Types MUST be indicated in this
			resource's capabilities ( Section 7.7.5.1.4).
			constraints Defined equivalently to the "constraints" input parameter
			of a Filtered Multi Cost Map (see Section 7.7.3.2).
			endpoints A list of Source Endpoints and Destination Endpoints for
			which Path Costs are to be returned. If the list of Source Endpoints
			is empty (or not included), the ALTO Server MUST interpret it as if
			it contained the Endpoint Address corresponding to the client IP
			address from the incoming connection (see Section 10.3 for discussion
			and considerations regarding this mode). The list of destination
			Endpoints MUST NOT be empty. The ALTO Server MUST interpret entries
			appearing multiple times in a list as if they appeared only once.
			4.4.5. Capabilities
			See section 4.3.4 of this draft.
			4.4.6. Response
			The returned InfoResourceEntity object has "data" member equal to
			InfoResourceEndpointMultiCostMap, where:
			object EndpointDstMultiCosts {
			JSONArray [TypedEndpointAddr];
			...
			};
			object {
			EndpointDstMultiCosts [TypedEndpointAddr]<0..*>;
			...
			} EndpointMultiCostMapData;
			object {
			CostMode cost-mode<0..*>;
			CostType cost-type<0..*>;
			EndpointMultiCostMapData map;
			} InfoResourceEndpointMultiCostMap;
			InfoResourceEndpointMultiCostMap has members:
			cost-type<0..*> The Cost Types used in the returned Cost Map.
			cost-mode<0..*> The Cost Mode for each of the Cost Types used in the returned Cost Map.
			map The Endpoint Multi-Cost Map data itself.
			EndpointMultiCostMapData is a JSON object with each member representing a
			single Source Endpoint specified in the input parameters; the name
			for a member is the TypedEndpointAddr string identifying the
			corresponding Source Endpoint. For each Source Endpoint, a
			EndpointDstMultiCosts object denotes the cost vector associated to each
			Destination Endpoint specified in the input parameters; the name for
			each member in the object is the TypedEndpointAddr string identifying
			the corresponding Destination Endpoint.
			4.4.7. Example
			POST /endpointcost/lookup HTTP/1.1
			Host: alto.example.com
			Content-Length: [TODO]
			Content-Type: application/alto-endpointmulticostparams+json
			Accept: application/alto-endpointmulticost+json,application/alto-error+json
			{
			"cost-type" : ["routingcost", "hopcount"],
			"cost-mode" : ["numerical", "numerical"],
			"endpoints" : {
			"srcs": [ "ipv4:192.0.2.2" ],
			"dsts": [
			"ipv4:192.0.2.89",
			"ipv4:198.51.100.34",
			"ipv4:203.0.113.45"
			]
			}
			}
			HTTP/1.1 200 OK
			Content-Length: [TODO]
			Content-Type: application/alto-endpointmulticost+json
			{
			"meta" : {},
			"data" : {
			"cost-type" : ["routingcost", "hopcount"],
			"cost-mode" : ["numerical", "numerical"],
			"map" : {
			"ipv4:192.0.2.2": {
			"ipv4:192.0.2.89" : [1, 7],
			"ipv4:198.51.100.34" : [2, 4],
			"ipv4:203.0.113.45" : [3, 2]
			}
			}
			}
			}
			4.5. ALTO Status Codes for Multi-Cost ALTO
	If the Multi-cost Service is not supported for either the Cost Map or		If the Multi-cost Service is not supported for either the Cost Map or
	the Endpoint Service, then the ALTO server sends an ALTO status code		the Endpoint Service, then the ALTO server sends an ALTO status code
	7 corresponding to HTTP status code 501 indicating "Invalid cost		7 corresponding to HTTP status code 501 indicating "Invalid cost
	structure". The ALTO client may then needs to place as many requests		structure". The ALTO client may then needs to place as many requests
	as needed Cost Types, and the ALTO server sends as many cost maps or		as needed Cost Types, and the ALTO server sends as many cost maps or
	EP cost as needed.		EP cost as needed.
	To the attribute Cost Mode in S.5.1 should be associated a rule		To the attribute Cost Mode in S.5.1 should be associated a rule
	stipulating that when multiple cost types are requested, then the		stipulating that when multiple cost types are requested, then the
	skipping to change at page 9, line 6 ¶		skipping to change at page 22, line 19 ¶
	5. Use cases for further Cost Types and Endpoint Properties		5. Use cases for further Cost Types and Endpoint Properties
	The current ALTO protocol [ID-alto-protocol] specification requests		The current ALTO protocol [ID-alto-protocol] specification requests
	the creation of two registries maintained by IANA. The ALTO Cost		the creation of two registries maintained by IANA. The ALTO Cost
	Type registry ensures that the Cost Types that are represented by an		Type registry ensures that the Cost Types that are represented by an
	ALTO Cost Map are unique identifiers, and it further contains		ALTO Cost Map are unique identifiers, and it further contains
	references to the semantics of the Cost Type. The current		references to the semantics of the Cost Type. The current
	specification registers 'routingcost' as a generic measure for		specification registers 'routingcost' as a generic measure for
	routing traffic from a source to a destination. In a similar way the		routing traffic from a source to a destination. In a similar way the
	ALTO Endpoint Property Registry ensures uniquenes of ALTO Endpoint		ALTO Endpoint Property Registry ensures uniqueness of ALTO Endpoint
	Property identifiers and provides references to particular semantics		Property identifiers and provides references to particular semantics
	of the allocated Enpoint Properties. Currently the 'pid' identifier		of the allocated Enpoint Properties. Currently the 'pid' identifier
	is registered, which serves as an identifier that allows aggregation		is registered, which serves as an identifier that allows aggregation
	of network endpoints into network regions. Both registries accept		of network endpoints into network regions. Both registries accept
	new entries after Expert Review [[ID-alto-protocol]]. New entries		new entries after Expert Review [[ID-alto-protocol]]. New entries
	are requested to be conform to the respective syntactical		are requested to be conform to the respective syntactical
	requirements, and must include information about the new identifier,		requirements, and must include information about the new identifier,
	the intended semantics as well as security considerations.		the intended semantics as well as security considerations.
	The current protocol specification concentrates on the basic use case		The current protocol specification concentrates on the basic use case
	skipping to change at page 9, line 29 ¶		skipping to change at page 22, line 42 ¶
	Properties. The goal of this section is to describe further forward		Properties. The goal of this section is to describe further forward
	looking use case scenarios that are likely to benefit from ALTO, and,		looking use case scenarios that are likely to benefit from ALTO, and,
	in future iterations, to convey new Cost Types and Endpoint		in future iterations, to convey new Cost Types and Endpoint
	Properties that are likely to be beneficial for ALTO clients in these		Properties that are likely to be beneficial for ALTO clients in these
	scenarios.		scenarios.
	5.1. Delay Sensitive Overlay Applications		5.1. Delay Sensitive Overlay Applications
	The ALTO working group has been created to allow P2P applications and		The ALTO working group has been created to allow P2P applications and
	NSPs a mutual cooperation, in particular because P2P bulk file-		NSPs a mutual cooperation, in particular because P2P bulk file-
	transfer applications have created a huge amount of intra-domain		transfer applications have created a huge amount of intra-domain and
	traffic. By aligning overlay topologies according to the		congestion on low-speed uplink traffic. By aligning overlay
	'routingcost' of the underlying network both layers are expected to		topologies according to the 'routingcost' of the underlying network
	benefit in terms of reduced costs and improved Quality-of-Experience.		both layers are expected to benefit in terms of reduced costs and
			improved Quality-of-Experience.
	However other types of overlay applications might benefit from a		However other types of overlay applications might benefit from a
	different set of path metrics. In particular for real-time sensitive		different set of path metrics. In particular for real-time sensitive
	applications, such as gaming, interactive video conferencing or		applications, such as gaming, interactive video conferencing or
	medical services, creating an overlay topology with respect to a		medical services, creating an overlay topology with respect to a
	minimized delay is preferable. However it is very hard for a NSP to		minimized delay is preferable. However it is very hard for a NSP to
	give accurate guidance for this kind of realtime information, instead		give accurate guidance for this kind of realtime information, instead
	probing through end-to-end measurements on the application layer has		probing through end-to-end measurements on the application layer has
	proven to be the superior mechanism. Still, a NSP might give some		proven to be the superior mechanism. Still, a NSP might give some
	guidance to the overlay application, for example by providing		guidance to the overlay application, for example by providing
	statisically preferable paths with respect to the time of a day.		statistically preferable paths with respect to the time of a day.
	Also static information like hopcount can be seen as an indicator for		Also static information like hopcount can be seen as an indicator for
	the delay that can be expected. In the following iterations this		the delay that can be expected. In the following iterations this
	draft will thus analyse which metrics can realisticaly be provided		draft will thus analyse which metrics can realistically be provided
	through ALTO to give delay sensitive applications guidance for peer		through ALTO to give delay sensitive applications guidance for peer
	selection.		selection.
	5.2. CDN Surrogate Selection		5.2. CDN Surrogate Selection
	A second use case is motivated through draft		A second use case is motivated through draft
	[draft-jenkins-alto-cdn-use-cases-01]. The request router in today's		[draft-jenkins-alto-cdn-use-cases-01]. The request router in today's
	CDNs makes a decision about to which surrogate or cache node a		CDNs makes a decision about to which surrogate or cache node a
	content request should be forwarded to. Typically this decision is		content request should be forwarded to. Typically this decision is
	based on locality aspects, i.e. the surrogate node which is closest		based on locality aspects, i.e. the surrogate node which is closest
	to the client is preferred by the request router. An ALTO server		to the client is preferred by the request router. An ALTO server
	hereby is one promising option to allow NSPs to give guidance to the		hereby is one promising option to allow NSPs to give guidance to the
	CDN about which cache node would be preferable according to the view		CDN about which cache node would be preferable according to the view
	of the network by the 'routingcost' Cost Type. Providing this kind		of the network by the 'routingcost' Cost Type. Providing this kind
	of information is in particular important as one trend is to place		of information is in particular important as one trend is to place
	cache nodes deeper into the network, which results in the need for		cache nodes deeper into the network (i.e., closer to the end user),
	finer grained information.		which results in the need for finer grained information.
	While distance today is the predominant metric used for routing		While distance today is the predominant metric used for routing
	decisions, other metrics might allow sophisticated request routing		decisions, other metrics might allow sophisticated request routing
	strategies. For example the load a cache node sees in terms of CPU		strategies. For example the load a cache node sees in terms of CPU
	utilization, memory usage or bandwidth utilization might influence		utilization, memory usage or bandwidth utilization might influence
	routing decisions for load-balancing reasons. There exist numerous		routing decisions for load-balancing reasons. There exist numerous
	ways of gathering and feeding this kind of information into the		ways of gathering and feeding this kind of information into the
	request routing mechanism. As ALTO is likely to become a		request routing mechanism.
	standardized interface to provide network topology information, for
	simplicity other information that is used by a request router could		Typically, information reporting on the occupation of a cache could
	be provided by the ALTO server as well. In the next iterations of		be based on:
	this draft we will analyse which of these metrics is suitable to be
	provided as Cost Type or Endpoint Property for the use case of CDN		o an Endpoint Property called : "EPCapacity" and reflecting the
	Surrogate Selection and propose to register them in the respective		nominal capacity of this endpoint. This capacity could be
	registries.		splitted in:
			* EP Nominal Memory : denoting the nominal storage capacity
			* EP Nominal Bandwidth: denoting the computation resources of the
			Endpoint.
			o an Endpoint Cost called: "EP occupied Capacity" and reflecting the
			currently available resources wrt their nominal capacity and
			splitted in the same way as for the EP Capacity:
			* EP Occupied Memory: denoting the remaining storage capacity,
			* EP Occupied Bandwidth: denoting the remaining computation
			resources.
			As ALTO is likely to become a standardized interface to provide
			network topology information, for simplicity other information that
			is used by a request router could be provided by the ALTO server as
			well. In the next iterations of this draft we will analyse which of
			these metrics is suitable to be provided as Cost Type or Endpoint
			Property for the use case of CDN Surrogate Selection and propose to
			register them in the respective registries.
			5.3. Bulk Data Transfer scheduling
			Applications like Facebook or YouTube rely on data replication across
			multiple sites for several reasons, such as offloading the core
			network or increasing user experience through short latency.
			As content is generated constantly data also needs to be replicated
			across the various locations of a CDN provider, leading to bulk data
			transfers between datacenters. Scheduling these data transfers is a
			non-trivial task as the transfer should not infer with the user peak
			demand to avoid degradation of user experience and to decrease
			billing costs for the datacenter operator by leveraging off-peak
			hours for the transfer. This peak demand typically follows a diurnal
			pattern according to the geographic region of the datacenter. One
			precondition to schedule transfers however is to have a good
			knowledge about the demand and link utilization patterns between the
			different datacenters and networks. Provisioning this data gets
			increasingly complex with the number of CDN nodes and in particular
			the number of datacenter operators that are involved. ALTO can
			provide time sensitive utilization maps through a dedicated service
			to allow CDN operators a mutual scheduling of such data transfers
			across administrative domains, which becomes even more significant
			through the CDNi protocol.
			Another use case that stresses the need for multi-timeframe
			information is the one of private users or user groups having
			limitations in their connectivity either in time or resources or
			both. These kind of users definitely need to plan their data
			transfers to and from various locations an be sure to optimize for
			example the 'routingcost' jointly with some 'pathoccupationcost' and
			possibly the 'hopcount'. These users often have very poor means to
			have any information on the network that may provide them some
			guidance and the ALTO protocol could greatly help them while
			optimizing traffic on networks that face continuous resources and/or
			connectivity challenges.
			In the next iteration of this draft we plan specify a multi-timeframe
			map service for ALTO to allow the targeted scheduling of data
			transfers between datacenter locations or other types of locations.
	6. Proposed additional Properties and Costs		6. Proposed additional Properties and Costs
	To be further specified		This section proposes further extensions on new Costs Types, to be
			discussed in the WG.
	6.1. Scoping ALTO information		6.1. For further extensions: dynamic Costs
			It is agreed in the ALTO requirements that: "information that can
			change very rapidly, such as transport-layer congestion, is out of
			scope for an ALTO service. Such information is better suited to be
			transferred through an in-band technique at the transport layer
			instead". However NP managing ALTO Servers as well as Application
			Client using ALTO information have common interests to use some
			information on time (or space) varying information that is not
			provided in real time, which is neither desirable nor feasible, but
			rather a synthetis of such information. Such information is made
			available for ALTO Servers in order to reflect how the NP wishes the
			information to be used by the Applicaton Client.
			One example of such information is the path bandwidth. This can be
			captured in real time by end systems, in terms of transmission rate.
			On the other hand, the NSP can formulate preferences on given paths,
			at given time periods on given time scales.
	One way for the NSP to provide guidance on highly dynamic network		One way for the NSP to provide guidance on highly dynamic network
	state information such as delay and load is to provide them in the		state information such as delay and load while preserving
	form of statistics or as a numerical coarse grain indicator. It is		confidentiality and moderating processing load, is to provide them in
	important to have the possibility to reflect that the provided values		a synthetic or abstract form, for example as a numerical indicator.
	are applicable for a given time period, for example business hours,		It is important to have the possibility to reflect that the provided
	and are subject to changes over time.		values are applicable for a given time period, for example busy hours
			or days, and are subject to changes over time. Also, how the NP has
			evaluated the cost associated to a given network state information is
			out of scope ot the ALTO protocol.
	The following attributes can be associated to the applicable ALTO		The usage of a time related cost is more proactive in that it can be
	information:		used like a "time table" to figure out the best time to schedule data
			transfer and also anticipate predictable events including predictable
			flash crowds. The time-related information is not necessarily
			historical and statistic. This is why the proposed time-sensitive
			Costs should be viewed as synthetic or as abstraction of real
			measurements rather than as statistics.
	o an age attribute indicating when the information was generated.		6.1.1. Path Occupation Cost and Endpointoccupationcost
	o for statistical costs a time period attribute indicating over		The 'pathoccupationcost' can be used to reflect the NP view on the
	which duration the statistics were collected.		utilized path bandwidth at given time slots of given timeframes. For
			example, during daytime in the PC time zone, or between hh/mm and
			hh/mm in another time zone.
	o a validity attribute indicating when the provided values should be		A Cost metric called 'endpointoccupationcost' and that accounts for
	refreshed. By defaut, this parameter can be set to infinity.		the computation resources usage can be provided with the "dynamic"
			mode as well with a similar time scope updated for example with the
			knowledge of the NSP operating the CDN.
			Both of these metrics are encoded with the 'JSONNumber' type.
			Their optimal value is their minimal value.
			They should also be provided in the numerical mode, that is as one
			single value, if requested so by the ALTO Client. This could be the
			case for an ALTO Server providing values at a short time scale (e.g.
			some minutes), or in the opposite, providing a timeless cost.
			6.1.2. Dynamic Cost Attributes
			For further extensions, specifications around "dynamic" costs are
			proposed and will be completed in further versions of this draft.
			6.1.2.1. The dynamic Cost Mode
			The "dynamic" mode applies to Costs that are eligible for the
			"numerical" Cost Mode and can also be expressed as such. In that
			sense, the "dynamic" mode is an extension of the "numerical" mode.
			Example are "pathoccupationcost" and "pathlosscost" that respectively
			report on the occupied bandwidth and packet loss on a path.
			Other Cost Types such as JSONBool could also claim the "dynamic"
			mode, as states may be "true" or "false" depending on given periods.
			To stick to the target usage of Costs which is to be integrated in
			some evaluation process, an alternative could be to assign a
			numerical value to boolean costs and carefully map "true" and "false"
			with values '0' and '1'.
			6.1.3. Proposed dynamic Cost Scope capability
			To ensure that the Application Client uses the NP provided
			information on dynamic Costs in an inambuguous way, a capability
			called Cost Scope is introduced here, to report on the validity of
			the "dynamic" cost values. This draft focuses on the time related
			scope. Indeed, one may as well imagine some costs proposed in the
			future that could also be scoped w.r.t. space.
			o Unit: ranging from "seconds" to "year", expresses the granularity
			of the information,
			o Size: the scope of the dynamic cost, that is the number of units
			of the dynamic cost sample,
			o Reference time zone,
			o Begin: the index of the first unit in the sample,
			o Next update: the date at which the sample will be re-computed,
			o Last update: the last re-computation day.
			Attributes 'Last update 'and 'Next update' report on the update
			frequency and age of the information.
			6.1.3.1. Example of time scope for a dynamic cost
			An example is: a metric called 'pathoccupationcost' (POC for short)
			is computed with a granularity of 2 hours, starting a 0h00, for 24
			hours, with reference time GMT. The goal is to enable applications
			to see which time intervals in a day are the most favorable to
			operate.
			6.1.4. Example of dynamic information resources in the IRD
			The example IRD given in Section 4.1.1 includes an URI called
			"http://custom.alto.example.com/multi/endpointmulticost/lookup", in
			which the ALTO Server provides additional Mutliple Endpoint Costs
			including a Cost called "pathoccupationcost" for which the Cost Mode
			is "dynamic". This resource is accessible with other costs, via a
			separate subdomain called "custom.alto.example.com". The Endpoint
			Costs available via this subdomain are the "hopcount", "routingcost"
			and "pathoccupationcost" Cost Types, with the two first ones in the
			"numerical" Cost Mode and "pathoccupationcost" in the "dynamic" cost
			mode.
			An ALTO Client can discover the services available by
			"custom.alto.example.com" by successfully performing an OPTIONS
			request to "http://custom.alto.example.com/multi/endpointmulticost".
			OPTIONS /multi/endpointmulticost HTTP/1.1
			Host: custom.alto.example.com
			Accept: application/alto-directory+json,application/alto-error+json
			HTTP/1.1 200 OK
			Content-Length: [TODO]
			Content-Type: application/alto-directory+json
			{
			"resources" : [
			{
			"uri" : "http://custom.alto.example.com/multi/endpointmulticost",
			"media-types" : [ "application/alto-endpointmulticost+json" ],
			"accepts" : [ "application/alto-endpointmulticostparams+json" ],
			"capabilities" : {
			"cost-constraints" : true,
			"cost-modes" : [ "numerical", "numerical", "dynamic" ],
			"cost-types" : [ "routingcost", "hopcount", "pathoccupationcost" ],
			"cost-scope": [ "permanent", "permanent",
			{"unit": "hour", "size": 24, "begin": 0,
			"time zone": "GMT",
			"lastupdate": mm/hh/dd/mm/yyyy,
			"nextupdate": mm/hh/dd/mm/yyyy}
			]
			}
			}
			]
			}
			6.1.4.1. Example of response with a "dynamic" cost
			To be completed
			POST /endpointcost/lookup HTTP/1.1
			Host: alto.example.com
			Content-Length: [TODO]
			Content-Type: application/alto-endpointmulticostparams+json
			Accept: application/alto-endpointmulticost+json,application/alto-error+json
			{
			"cost-type" : ["routingcost", "pathoccupationcost"],
			"cost-mode" : ["numerical", "dynamic"],
			"endpoints" : {
			"srcs": [ "ipv4:192.0.2.2" ],
			"dsts": [
			"ipv4:192.0.2.89",
			"ipv4:198.51.100.34",
			"ipv4:203.0.113.45"
			]
			}
			}
			HTTP/1.1 200 OK
			Content-Length: [TODO]
			Content-Type: application/alto-endpointmulticost+json
			{
			"meta" : {},
			"data" : {
			"cost-type" : ["routingcost", "pathoccupationcost"],
			"cost-mode" : ["numerical", "dynamic"],
			"map" : {
			"ipv4:192.0.2.2": {
			"ipv4:192.0.2.89" : [1, [7, ..., 24 values]],
			"ipv4:198.51.100.34" : [2, [4, ..., 24 values]],
			"ipv4:203.0.113.45" : [3, [2, ..., 24 values]]
			}
			}
			}
			}
	7. IANA Considerations		7. IANA Considerations
	Information for the ALTO Endpoint property registry maintained by the		Information for the ALTO Endpoint property registry maintained by the
	IANA and related to the new Endpoints supported by the acting ALTO		IANA and related to the new Endpoints supported by the acting ALTO
	server. These definitions will be formulated according to the syntax		server. These definitions will be formulated according to the syntax
	defined in Section on "ALTO Endpoint Property Registry" of		defined in Section on "ALTO Endpoint Property Registry" of
	[ID-alto-protocol],		[ID-alto-protocol],
	Information for the ALTO Cost Type Registry maintained by the IANA		Information for the ALTO Cost Type Registry maintained by the IANA
	and related to the new Cost Types supported by the acting ALTO		and related to the new Cost Types supported by the acting ALTO
	server. These definitions will be formulated according to the syntax		server. These definitions will be formulated according to the syntax
	defined in Section on "ALTO Cost Type Registry" of		defined in Section on "ALTO Cost Type Registry" of
	[ID-alto-protocol],		[ID-alto-protocol],
	7.1. Information for IANA on proposed Cost Types		7.1. Information for IANA on proposed Cost Types
	skipping to change at page 11, line 42 ¶		skipping to change at page 30, line 28 ¶
	Semantics, Security Considerations.		Semantics, Security Considerations.
	7.2. Information for IANA on proposed Endpoint Propeeries		7.2. Information for IANA on proposed Endpoint Propeeries
	Likewise, an ALTO Endpoint Property Registry could serve the same		Likewise, an ALTO Endpoint Property Registry could serve the same
	purposes as the ALTO Cost Type registry. Application to IANA		purposes as the ALTO Cost Type registry. Application to IANA
	registration for Endpoint Properties would follow a similar process.		registration for Endpoint Properties would follow a similar process.
	8. Acknowledgements		8. Acknowledgements
			Thank you to Dave Mac Dysan (Verizon) for fruitful discussions and
			comments on the last draft.
	Sabine Randriamasy is partially supported by the MEDIEVAL project		Sabine Randriamasy is partially supported by the MEDIEVAL project
	(http://www.ict-medieval.eu/), a research project supported by the		(http://www.ict-medieval.eu/), a research project supported by the
	European Commission under its 7th Framework Program (contract no.		European Commission under its 7th Framework Program (contract no.
	248565). The views and conclusions contained herein are those of the		248565). The views and conclusions contained herein are those of the
	authors and should not be interpreted as necessarily representing the		authors and should not be interpreted as necessarily representing the
	official policies or endorsements, either expressed or implied, of		official policies or endorsements, either expressed or implied, of
	the MEDIEVAL project or the European Commission.		the MEDIEVAL project or the European Commission.
	Nico Schwan is partially supported by the ENVISION project		Nico Schwan is partially supported by the ENVISION project
	(http://www.envision-project.org), a research project supported by		(http://www.envision-project.org), a research project supported by
	skipping to change at page 13, line 4 ¶		skipping to change at page 31, line 34 ¶
	Authors' Addresses		Authors' Addresses
	Sabine Randriamasy (editor)		Sabine Randriamasy (editor)
	Alcatel-Lucent Bell Labs		Alcatel-Lucent Bell Labs
	Route de Villejust		Route de Villejust
	NOZAY 91460		NOZAY 91460
	FRANCE		FRANCE
	Email: Sabine.Randriamasy@alcatel-lucent.com		Email: Sabine.Randriamasy@alcatel-lucent.com
	Nico Schwan		Nico Schwan
			Alcatel-Lucent Bell Labs
			Lorenzstrasse 10
			STUTTGART 70435
			GERMANY
	Phone:		Email: Nico.Schwan@alcatel-lucent.com
	Fax:
	Email:
	URI:
End of changes. 69 change blocks.
	176 lines changed or deleted		920 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/