< draft-kiesel-alto-3pdisc-02.txt		draft-kiesel-alto-3pdisc-03.txt >
	ALTO S. Kiesel		ALTO S. Kiesel
	Internet-Draft University of Stuttgart		Internet-Draft University of Stuttgart
	Intended status: Informational M. Tomsu		Intended status: Informational M. Tomsu
	Expires: September 9, 2010 N. Schwan		Expires: January 10, 2011 N. Schwan
	M. Scharf		M. Scharf
	Alcatel-Lucent Bell Labs		Alcatel-Lucent Bell Labs
	March 8, 2010		M. Stiemerling
			NEC Europe Ltd.
			July 9, 2010
	Third-party ALTO server discovery		Third-party ALTO server discovery
	draft-kiesel-alto-3pdisc-02		draft-kiesel-alto-3pdisc-03
	Abstract		Abstract
	The goal of Application-Layer Traffic Optimization (ALTO) is to		The goal of Application-Layer Traffic Optimization (ALTO) is to
	provide guidance to applications, which have to select one or several		provide guidance to applications, which have to select one or several
	hosts from a set of candidates that are able to provide a desired		hosts from a set of candidates that are able to provide a desired
	resource.		resource.
	This document describes why a third-party ALTO server discovery		Entities seeking guidance need to discover and possibly select an
	mechanism is required for an important class of applications, namely		ALTO server to ask. This is called ALTO server discovery. This memo
	tracker-based P2P applications. Several solution approaches are		describes an ALTO server discovery mechanism based on DNS SRV
	classified and evaluated. The conclusion is that further work is		records.
	required to standardize a protocol and procedures that follow one
	specific approach.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 10, 2011.
	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 September 9, 2010.
	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 BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4		2. DNS-based ALTO Server Discovery . . . . . . . . . . . . . . . 5
	2.1. The need for third-party ALTO queries . . . . . . . . . . 4		2.1. DNS SRV record definition . . . . . . . . . . . . . . . . 5
	2.2. The need for third-party ALTO server discovery . . . . . . 6		2.2. DNS SRV record lookup procedure . . . . . . . . . . . . . 6
	3. Peer-to-peer application scenario . . . . . . . . . . . . . . 8		2.2.1. Step 1: Finding the IP address . . . . . . . . . . . . 6
	4. Classification of solution approaches . . . . . . . . . . . . 10		2.2.2. Step 2: Determining the DNS suffix . . . . . . . . . . 6
	4.1. Solutions that do not require an update of the		2.2.3. Step 3: Lookup SRV record . . . . . . . . . . . . . . 7
	application protocol . . . . . . . . . . . . . . . . . . . 10		2.2.4. Step 4: Final lookup . . . . . . . . . . . . . . . . . 8
	4.2. Solutions that do require an update of the application		3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
	protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.1. Applicability for third party server discovery . . . . . . 9
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16		3.2. Applicability for resource consumer server discovery . . . 9
	5.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 16		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 16		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	5.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 16		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 17		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 17		7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	5.6. Approach #6 . . . . . . . . . . . . . . . . . . . . . . . 17		7.2. Informative References . . . . . . . . . . . . . . . . . . 14
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	The goal of Application-Layer Traffic Optimization (ALTO) is to		The goal of Application-Layer Traffic Optimization (ALTO) is to
	provide guidance to applications, which have to select one or several		provide guidance to applications, which have to select one or several
	hosts from a set of candidates, that are able to provide a desired		hosts from a set of candidates, that are able to provide a desired
	resource. ALTO is realized by a client-server protocol. ALTO		resource[RFC5693]. The requirements for ALTO are itemized in
	clients send queries to ALTO servers, in order to solicit guidance.		[I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol.
	The ALTO client can be embedded in the resource consumer, which will		ALTO clients send queries to ALTO servers, in order to solicit
	eventually access the desired resource. As an alternative, the ALTO		guidance.
	client can be embedded in a resource directory, which assists
	resource consumers in finding appropriate resource providers. In
	some specific peer-to-peer application protocols these resource
	directories are called "trackers". ALTO queries, which are issued by
	a resource directory on behalf of a resource consumer, will be
	referred to as third-party ALTO queries.
	The challenge for third-party ALTO queries is that they have to be
	answered by the "right" ALTO server, i.e., the ALTO server which has
	the knowledge to give guidance to the resource consumer on behalf of
	which the query is sent.
	This document uses the terminology introduced in [RFC5693] and it
	investigates solution approaches that fulfill the requirements for
	ALTO server discovery documented in [I-D.ietf-alto-reqs].
	Comments and discussions about this document should be directed to
	the ALTO working group: alto@ietf.org.
	2. Problem statement
	2.1. The need for third-party ALTO queries
	The scope of this document is the interaction of peer-to-peer
	applications that use a centralized resource directory ("tracker"),
	with the ALTO service. In this scenario, the resource consumer
	("peer") asks the resource directory for a list of candidate resource
	providers, which can provide the desired resource. Usually, only a
	subset of all resource providers known to the resource directory will
	eventually be contacted by the resource consumer for accessing the
	resource. The purpose of ALTO is giving guidance on this peer
	selection, which is supposed to yield better-than-random results.
	Several ALTO client protocol proposals exist (e.g.,
	[I-D.ietf-alto-protocol], [I-D.kiesel-alto-h12]), which specify how
	an ALTO client can query an ALTO server for guiding information and
	receive the corresponding replies. However, in the considered
	scenario of a tracker-based P2P application, there are two
	fundamentally different possibilities where to place the ALTO client:
	1. ALTO client in the resource consumer ("peer")
	2. ALTO client in the resource directory ("tracker")
	In the following, both scenarios are compared in order to explain the
	need for third-party ALTO queries.
	In the first scenario (see Figure 1), the resource consumer queries
	the resource directory for the desired resource (F1). The resource
	directory returns a list of potential resource providers without
	considering ALTO (F2). It is then the duty of the resource consumer
	to invoke ALTO (F3/F4), in order to solicit guidance regarding this
	list.
	In the second scenario (see Figure 2), the resource directory has an
	embedded ALTO client, which we will refer to as RDAC in this
	document. After receiving a query for a given resource (F1) the
	resource directory invokes the RDAC to evaluate all resource
	providers it knows (F2/F3). Then it returns a, possibly shortened,
	list containing the "best" resource providers to the resource
	consumer (F4).
	Peer w. ALTO cli. Tracker ALTO Server
	--------+-------- --------+-------- --------+--------
	| F1 Tracker query | |
	|======================>| |
	| F2 Tracker reply | |
	|<======================| |
	| F3 ALTO client protocol query |
	|---------------------------------------------->|
	| F4 ALTO client protocol reply |
	|<----------------------------------------------|
	| | |
	==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol
	Figure 1: Basic message sequence chart for resource consumer-
	initiated ALTO query
	Peer Tracker w. RDAC ALTO Server
	--------+-------- --------+-------- --------+--------
	| F1 Tracker query | |
	|======================>| |
	| | F2 ALTO cli. p. query |
	| |---------------------->|
	| | F3 ALTO cli. p. reply |
	| |<----------------------|
	| F4 Tracker reply | |
	|<======================| |
	| | |
	==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol
	Figure 2: Basic message sequence chart for third-party ALTO query
	Note: the message sequences depicted in Figure 1 and Figure 2 may
	occur both in the target-aware and the target-independent query mode
	(c.f. [I-D.ietf-alto-reqs]). In the target-independent query mode
	no message exchange with the ALTO server might be needed after the
	tracker query, because the candidate resource providers could be
	evaluated using a locally cached "map", which has been retrieved from
	the ALTO server some time ago.
	The problem with the first approach is, that while the resource
	directory might know thousands of peers taking part in a swarm, the
	list returned to the resource consumer is usually shortened for
	efficiency reasons. Therefore, the "best" (in the sense of ALTO)
	potential resource providers might not be contained in that list
	anymore, even before ALTO can consider them.
	For example, consider a swarm with 10,000 peers known to the tracker.
	A new peer wants to join the swarm and therefore asks the tracker for
	a list of peers. For simplicity, we assume that 100 peers would be
	desirable neighbors for the new peer (in the sense of better-than-
	random peer selection) while the other 9,900 are less favorable.
	Assume that the tracker randomly selects 100 peers out of the 10,000
	known peers and returns them to the new peer. With a probability of
	approx. 36% this list does not contain a single favorable peer, and
	with 99% probability there are only four or less of the favorable
	peers on the list. Processing this list with the guiding ALTO
	information will ensure that the few favorable peers are ranked to
	the top of the list; however, the benefit is rather limited as the
	number of favorable peers in the list is just too small. Much better
	traffic optimization could be achieved if the tracker would evaluate
	all 10,000 peers using ALTO, and return a list of 100 peers
	afterwards. This list would then include a significantly higher
	fraction of favorable peers. (Note, that if the tracker returned
	favorable peers only, there would be a risk that the swarm might
	disconnect and split into several partitions. However, finding the
	right mix of ALTO-biased and random peer selection is out of the
	scope of this document.)
	Therefore, from an overall optimization perspective, the second
	scenario with the ALTO client embedded in the resource directory is
	advantageous, because it is ensured that the addresses of the "best"
	resource providers are actually delivered to the resource consumer.
	2.2. The need for third-party ALTO server discovery
	The previous section has shown why it is advantageous that entities
	such as resource directories can perform ALTO queries on behalf of
	resource consumers. We will refer to this kind of ALTO query as
	"third-party ALTO query". ALTO queries are sent to ALTO servers,
	which have knowledge of network topology and other information on
	which the ALTO guidance is based.
	The challenge for third-party ALTO queries is that they have to be
	answered by the "right" ALTO server, i.e., the ALTO server which has
	the knowledge to give guidance to the resource consumer on behalf of
	which the query is sent.
	One potential deployment scenario for ALTO is to establish a group of
	centralized ALTO servers which have complete knowledge and therefore
	can evaluate any pair of resource consumers and providers,
	respectively. Directing a third-party ALTO query to one of these
	servers would be a rather simple task.
	However, it is likely that there will be deployment scenarios with
	many ALTO servers, each having only partial knowledge and therefore
	being able to give guidance regarding only a defined group of
	resource consumers (e.g., those in its topological vicinity, or those
	connected to the same network operator). The reasons for
	partitioning the overall knowledge include scalability and separate
	administrative responsibilities. For the remainder of this document,
	we assume that the second scenario has to be supported. The first
	scenario can be seen as special case of it, i.e., a solution that
	supports the second scenario will support the first scenario as well.
	We will identify and assess several approaches for finding the
	"right" ALTO server, which has the knowledge to give guidance to the
	resource consumer on behalf of which a third-party ALTO query is to
	be sent.
	3. Peer-to-peer application scenario
	For illustration purposes the following chapters provide several
	examples, which all refer to the scenario presented in Figure 3.
	However, the evaluations and conclusions presented in this document
	do not only consider this scenario, but they are much more general.
	+------+ +---------+		ALTO clients have to discover suitable ALTO servers. Therefore the
	| ALTO |---+---| Tracker |		ALTO discovery client tells the ALTO client which ALTO servers to
	| Srv3 | | +---------+		send the queries to. The ALTO discovery client and the ALTO client
	+------+ |		can be embedded in the resource consumer, which will eventually
	|RTR| ISP 3		access the desired resource. As an alternative, they can be embedded
	|		in a resource directory, which assists resource consumers in finding
	**** | ***********		appropriate resource providers. In some specific peer-to-peer
	*** ********************** *******		application protocols these resource directories are called
	* Internet Backbone Networks *		"trackers". Finally the ALTO discovery client can be embedded in the
	*************** ******************		resource consumer, whereas the ALTO client is embedded in the
	| ****** ** |		resource directory. ALTO queries, which are issued by a resource
	|RTR| ISP 1 ****** |RTR| ISP 2		directory on behalf of a resource consumer, are referred to as third-
	| | +------+		party ALTO queries. The various possibilities to place ALTO servers
	+-------+ | +------+ +--------| ALTO |		and the placement of ALTO clients is discussed in
	|Peer 1a|----+---| ALTO | | | Srv2 |		[I-D.stiemerling-alto-deployments].
	+-------+ | | Srv1 | |NAT| +------+
	| +------+ |
	+-------+ | +-------+ | +---------+
	|Peer 1b|----+ |Peer 2a|----+------|ConfigSrv|
	+-------+ | +-------+ | +---------+
	|RTR| |
	+-------+ | +-------+ | +-------+
	|Peer 1c|----+ |Peer 2b|----+-|RTR|--|Peer 2c|
	+-------+ +-------+ +-------+
	Figure 3: ALTO scenario		No matter where ALTO server and client are located, clients have to
			first find out if there is an ALTO server deployed that is in charge
			for them and second to get the contact information of that server,
			i.e., the IP address, port number, and probably transport protocol
			(which defaults to TCP for [I-D.ietf-alto-protocol]).
	Figure 3 shows three networks with connected end hosts, which are		There exists a number of service location protocols, such as SLP
	operated by different Internet Service Provides, identified as ISP1,		[RFC2608] or DHCP [RFC2131][RFC3315], which could in principle be
	ISP2, and ISP3, respectively. These networks are interconnected by		used for ALTO discovery. However, SLP is not widely deployed or used
	Internet backbone networks.		within the Internet. DHCP is widely deployed but has several
			limitations:
	ISP1's network connects to (amongst others) three hosts that run the		o Though widely deployed DHCP is not in use everywhere. For
	peers of a P2P application, identified as peers 1a, 1b, and 1c,		important scenarios, such as PPPoE based DSL access networks one
	respectively. Peers 1a and 1b are in topological vicinity, while 1c		would have to specify another mechanism.
	is more distant from them, because of the additional router (RTR) in
	between. ISP1 operates an ALTO server, identified as ALTO Srv1,
	which can give guidance to resource consumers in ISP1's network,
	i.e., to peers 1a, 1b, and 1c.
	ISP2's network has a very similar structure as described above, and		o A DHCP-based discovery mechanism will always yield the addresses
	it contains peers 2a, 2b, and 2c, as well as ALTO Srv2. The main		of the ALTO servers that are provided by the network operator.
	difference to ISP1's network is that ISP2 uses a carrier grade NAT		The user cannot influence the discovery and, e.g., select an
	device, in order to masquerade peers 2a, 2b, and 2c "behind" one		alternative ALTO service from an "independent" ALTO operator.
	single "external" (globally unique) IPv4 address. ALTO server 2 is
	assumed to have a globally unique IPv4 address, i.e., it can be
	queried from other hosts in the Internet without any special NAT
	traversal mechanisms.
	ISP3's network contains a resource directory ("tracker") for a		o There are problems with residential gateways or broadband routers
	tracker-based P2P application. ISP3 operates ALTO Srv3, which is		with NAT. If the network operator gives information about ALTO
	populated with information that could be used for giving guidance to		serves to the residential gateway via DHCP, the residential
	resource consumers in ISP3's network.		gateway would have to forward this information to the hosts with
			the (P2P) applications within the local network. This is not
			supported by any of the already deployed residential gateways.
	We assume that the tracker already knows that peers 1b, 1c, 2b, and		o DHCP poorly supports third-party ALTO server discovery, i.e., in
	2c are taking part in a specific P2P overlay. If peer 1a wishes to		scenarios where the ALTO client is co-located with a resource
	join the overlay, it sends an application protocol specific message		directory ("tracker"), which is located in a different
	to the tracker, asking for other peer's addresses. Because of the		administrative domain than the client which will eventually access
	reasons outlined in Section 2.1 the tracker should ask ALTO for		the ressource.
	guidance prior to replying. More specifically, it should query ALTO
	server 1, because this ALTO server can give guidance to peer 1a.
	Analogical to that, if peer 2a sends a query to the tracker, the
	tracker needs to ask ALTO server 2 for guidance. The procedures for
	identifying this ALTO server and conveying the guiding information to
	the tracker are the scope of this document.
	4. Classification of solution approaches		The goal of this memo is to propose a uniform mechanism for all types
			of ALTO client deployments that is implementable and deployable at a
			fast pace, i.e., without creating other deployment dependecies for
			ALTO. One way of fulfilling the previous mentioned requirements is
			using the Service Records (SRV) of the Domain Name System (DNS), as
			described in [RFC2782]. DNS SRVs have been defined and are used for
			a number of protocols, such as SIP and XMPP.
	There are several approaches for directing a third-party ALTO query		Comments and discussions about this memo should be directed to the
	from the RDAC to the "right" ALTO server. The selection of the		ALTO working group: alto@ietf.org.
	"right" ALTO server needs to consider the resource consumer on behalf
	of which the query will be performed. The set of available options
	therefore depends on the available information about the resource
	consumer,
	The primary criterion in the following classification is whether ALTO		2. DNS-based ALTO Server Discovery
	must work together with all existing (P2P) application protocols, or
	whether we can assume that these protocols can be augmented with new
	ALTO-specific information fields.
	4.1. Solutions that do not require an update of the application		2.1. DNS SRV record definition
	protocol
	If we do not want to make specific assumptions on the (P2P)		We define a new service record for ALTO servers according to
	application protocol, we cannot assume that there are any other peer		[RFC2782]. The general format of the SRV RR, whose DNS type code is
	identifiers apart from IP addresses. Therefore, we assume that the		33, is
	only information identifying the resource consumer is the source IP
	address of messages sent from the resource consumer to the resource
	directory. This address may be the (public) IP address of the
	resource consumer, or it may be the external address of the last NAT
	on the path between resource consumer and resource directory.
	The RDAC that wants to perform the third-party ALTO query has two		_Service._Proto.Name TTL Class SRV Priority Weight Port Target
	options:
	o Approach #1: The RDAC invokes a discovery mechanism external to		Where for the ALTO server discovery, we define:
	the ALTO client protocol, in order to map from the resource
	consumer's IP address to the "right" ALTO server. The ALTO query
	will then be sent there directly (see Figure 4).
	o Approach #2: Independent of the resource consumer's identity, the		Service alto
	RDAC uses the ALTO client protocol to send the ALTO query to one
	preconfigured ALTO server. The resource consumer's IP address is
	included in the query message. Based on this IP address and using
	mechanisms of the ALTO client protocol the first ALTO server
	forwards (see Figure 5) or redirects (see Figure 6) the query to
	the "right" ALTO server. This implies that ALTO servers must know
	each other, based on some discovery mechanism or manual
	configuration.
	Peer 1a Tracker ALTO Srv1 DNS		Proto tcp
	----+---- ----+---- ----+---- ----+----
	| | | |
	| F1 Tracker Q | | |
	|==============>| F2 ALTO disc. Q (peer1a) |
	| |******************************>|
	| | F3 ALTO disc. R: ALTO Srv1 |
	| |<******************************|
	| | F4 ALTO cp Q | |
	| |-------------->| |
	| | F5 ALTO cp R | |
	| F6 Tracker R |<--------------| |
	|<==============| | |
	| | | |
	==== Application protocol (i.e., tracker-based P2P app protocol)		Name "The domain this RR refers to. The SRV RR is unique in that
	---- ALTO client protocol		the name one searches for is not this name; the example near the
	**** ALTO discovery protocol (e.g., based on DNS queries)		end shows this clearly."[RFC2782]
	Figure 4: Message sequence chart for Approach 1		TTL Standard DNS meaning [RFC2782]
	Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3		Class Standard DNS meaning[RFC2782]
	----+---- ----+---- ----+---- ----+---- ----+----
	| | | F1/2 HELLO | |
	| | |<###########>| F3/4 HELLO |
	| | | F5/6 HELLO |<###########>|
	| | |<#########################>|
	| F7 Tracker Q | | | |
	|==============>| | | |
	| | F8 ALTO cp Q | | |
	| |------------------------------------------>|
	| | | F9 ALTO cp Q |
	| | |<--------------------------|
	| | | F10 ALTO cp R |
	| | |-------------------------->|
	| | F11 ALTO cp R | | |
	| F12 Tracker R |<------------------------------------------|
	|<==============| | | |
	| | | | |
	==== Application protocol (i.e., tracker-based P2P app protocol)		Priority "The priority of this target host. A client MUST attempt
	---- ALTO client protocol		to contact the target host with the lowest-numbered priority it
	#### Inter-ALTO server protocol		can reach; target hosts with the same priority SHOULD be tried in
			an order defined by the weight field. The range is 0-65535. This
			is a 16 bit unsigned integer in network byte order." [RFC2782]
	Figure 5: Message sequence chart for Approach 2 (query forwarding)		Weight "A server selection mechanism. The weight field specifies a
	Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3		relative weight for entries with the same priority. Larger
	----+---- ----+---- ----+---- ----+---- ----+----		weights SHOULD be given a proportionately higher probability of
	| | | F1/2 HELLO | |		being selected. The range of this number is 0-65535. This is a
	| | |<###########>| F3/4 HELLO |		16 bit unsigned integer in network byte order. Domain
	| | | F5/6 HELLO |<###########>|		administrators SHOULD use Weight 0 when there isn't any server
	| | |<#########################>|		selection to do, to make the RR easier to read for humans (less
	| F7 Tracker Q | | | |		noisy). In the presence of records containing weights greater
	|==============>| | | |		than 0, records with weight 0 should have a very small chance of
	| | F8 ALTO cp Q | | |		being selected.[...]" [RFC2782]
	| |------------------------------------------>|
	| | F9 ALTO cp redirect | |
	| |<------------------------------------------|
	| | F10 ALTO cp Q | | |
	| |-------------->| | |
	| | F11 ALTO cp R | | |
	| F12 Tracker R |<--------------| | |
	|<==============| | | |
	| | | | |
	==== Application protocol (i.e., tracker-based P2P app protocol)		Port "The port on this target host of this service. The range is 0-
	---- ALTO client protocol		65535. This is a 16 bit unsigned integer in network byte order.
	#### Inter-ALTO server protocol		This is often as specified in Assigned Numbers but need not
			be."[RFC2782] It will be set to 80, if the standard TCP port for
			HTTP is used, but this also allows to run the service on any other
			port.
	Figure 6: Message sequence chart for Approach 2 (query redirection)		Target "The domain name of the target host. There MUST be one or
			more address records for this name, the name MUST NOT be an alias
			(in the sense of RFC 1034 or RFC 2181). Implementors are urged,
			but not required, to return the address record(s) in the
			Additional Data section. Unless and until permitted by future
			standards action, name compression is not to be used for this
			field. A Target of "." means that the service is decidedly not
			available at this domain. "[RFC2782]
	4.2. Solutions that do require an update of the application protocol		An example for querying for such an ALTO service record running in
			the domain myisp.net:
	If we assume that applications can be upgraded in order to support		_alto._tcp.example.com IN SRV 1 0 80 alto-srv01.myisp.net
	ALTO, the resource consumer can provide additional information to the
	RDAC in order to assist the process of ALTO server discovery.
	o Approach #3: Using the extended application protocol, the resource		2.2. DNS SRV record lookup procedure
	consumer sends an additional peer-ID, which can be understood by
	ALTO, to the resource directory. This peer-ID could be used to
	uniquely identify resource consumers and providers located behind
	NATs. The RDAC uses this peer-ID in addition to or instead of the
	resource consumer's IP address (see Figure 7). In all other
	aspects this approach is identical to approach #1.
	o Approach #4: This approach is identical to approach #2, except		This section describes the algorithm that is applied to discover the
	that the peer-ID is used instead of the IP address, as described		ALTO server. We differentiate between two use cases: In use case (a)
	in approach #3.		the user has no specific wish which ALTO service instance to use.
			Here the ALTO service instance is provided by default by the user's
			access network provider, thus the ALTO discovery client needs to
			determine the correct domain name automatically. In case (b) the
			user configures a specific ALTO service instance that he wants to
			use. Here the ALTO discovery client already has the information
			about which DNS suffix to use.
	o Approach #5: The resource consumer discovers its ALTO server on		2.2.1. Step 1: Finding the IP address
	its own (i.e., not a third-party discovery). Using the extended
	application protocol it sends the ALTO server's address to the
	RDAC. The RDAC can use it for sending third-party ALTO queries
	there.
	o Approach #6: The resource consumer retrieves guiding information		The first step for the ALTO discovery client is to determine the IP
	on its own, e.g., by discovering and querying an ALTO server or by		address or IP addresses of the resource consumer. The resource
	doing measurements. Using the extended application protocol it		consumer may have private IP addresses and public IP addresses and
	sends this information to the tracker, which can perform peer		depending on the deployment it might be necessary to determine for
	selection based on it.		all IP addresses the ALTO server in charge of. To determine its
			public IP address the resource consumer may need to use STUN[RFC5389]
			or BEP24[bep24]. For the following example we assume that the IP
			address of the resource consumer is a.b.c.d
	Peer 2a ConfigSrv Tracker ALTO Srv2 DNS		2.2.2. Step 2: Determining the DNS suffix
	----+---- ----+---- ----+---- ----+---- ----+---
	| F1 Config Q | | | |
	|;;;;;;;;;;;;;;>| | | |
	| | | | |
	| F2 Config R | | | |
	| + LocalID LID | | | |
	|<;;;;;;;;;;;;;;| | | |
	| | | | |
	| F3 Tracker Q (LID) | | |
	|===========================>| F4 ALTO disc. Q (ext.IP+LID) |
	| | |******************************>|
	| | | F5 ALTO disc. R: ALTO Srv2 |
	| | |<******************************|
	| | | F6 ALTO cp Q | |
	| | |-------------->| |
	| | | F7 ALTO cp R | |
	| F8 Tracker R | |<--------------| |
	|<===========================| | |
	| | | | |
	;;;; Configuration protocol (e.g., DHCP)		To get the DNS suffix in case (a) the ALTO discovery uses a DNS PTR
	==== Application protocol (i.e., tracker-based P2P app protocol)		query for the IP address of the resource consumer as determined in
	---- ALTO client protocol		step 1. The local DNS server resolves the IP address to the FQDN
	**** ALTO discovery protocol (e.g., based on DNS queries)		that also contains the DNS suffix for the respective IP address. A
			possible answer for a PTR lookup for d.c.b.a.in-addr.apra might be,
			for example:
	Figure 7: Message sequence chart for Approach 3		d-c-b-a.dsl.westcoast.myisp.net
	Peer 2a ConfigSrv Tracker ALTO Srv2		In case (b) The user specifies the DNS suffix on its own, for example
	----+---- ----+---- ----+---- ----+----		in a config file option. Here the user wants to use an ALTO service
	| F1 Config Q | | |		instance which is operated by a third party as for example the
	|;;;;;;;;;;;;;;>| | |		tracker operator. A possible DNS suffix entered by the user may be:
	| | | |
	| F2 Config R | | |
	| + Addr. of ALTO Srv2 | |
	|<;;;;;;;;;;;;;;| | |
	| | | |
	| F3 Tracker Q (Addr. of ALTO Srv2) |
	|==============================>| |
	| | | F4 ALTO cp Q |
	| | |-------------->|
	| | | F5 ALTO cp R |
	| F6 Tracker R | |<--------------|
	|<==============================| |
	| | | |
	;;;; Configuration protocol (e.g., DHCP)		myaltoprovider.org
	==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol
	Figure 8: Message sequence chart for Approach 5		2.2.3. Step 3: Lookup SRV record
	Peer 2a ConfigSrv Tracker ALTO Srv2		In step 3 the ALTO discovery client uses the information that has
	----+---- ----+---- ----+---- ----+----		been determined in the previous steps to composes the domain name
	| F1 Config Q | | |		that is used for the SRV queries. As the suffix part in not obvious
	|;;;;;;;;;;;;;;>| | |		in all cases e.g., it can be for the above example
	| | | |		"westcoast.myisp.net" or "myisp.net", the ALTO discovery client might
	| F2 Config R | | |		need to perform multiple SRV lookups until it gets a PTR reply.
	| + Addr. of ALTO Srv2 | |
	|<;;;;;;;;;;;;;;| | |
	| | | |
	| F3 ALTO cp Q | | |
	|---------------------------------------------->|
	| F4 ALTO cp R | | |
	|<----------------------------------------------|
	optional: perform | | |
	measurements | | |
	| | | |
	| F5 Tracker Q (Info from ALTO reply + meas'mt.)|
	|==============================>| |
	| F6 Tracker R | | |
	|<==============================| |
	| | | |
	;;;; Configuration protocol (e.g., DHCP)		In case (a) the ALTO discovery client composes the domain name as
	==== Application protocol (i.e., tracker-based P2P app protocol)		described in Section 2. If there is no response to the lookup the
	---- ALTO client protocol		DNS suffix is shortened by one part for the succeeding lookup. The
			domain names used for the example as described above are:
	Figure 9: Message sequence chart for Approach 6		_alto._tcp.d-c-b-a.dsl.westcoast.myisp.net.
	5. Discussion		_alto._tcp.dsl.westcoast.myisp.net.
	This section assesses and compares the different approaches		_alto._tcp.westcoast.myisp.net.
	introduced above, regarding trust, scalability, integration into
	existing ISP infrastructure and management processes, modification of
	existing applications, and ongoing ALTO architecture specification
	works.
	5.1. Approach #1		_alto._tcp.myisp.net.
	The existence of a mechanism according to approach #1 is assumed by		For case (b) the ALTO discovery client extends the DNS suffix by the
	[I-D.ietf-alto-protocol].		IP address of the resource consumer in reverse order to compose the
			domain name. This is needed for the third party ALTO service
			instance to direct the ALTO client to the ALTO server closest to the
			client in case there are multiple ALTO servers deployed. The suffix
			is then shortened as described before until a lookup is successful,
			as for example
	This approach does not require any changes of existing (P2P)		_alto._tcp.d.c.b.a.myaltoprovider.org.
	application protocols. However, the RDAC needs to implement an
	additional protocol for performing third-party ALTO server discovery.
	One possible way of implementing this approach would be based on DNS,		_alto._tcp.c.b.a.myaltoprovider.org.
	providing a mapping from the resource consumer's IP address to the IP
	address of the corresponding "right" ALTO server. DNS is proven to
	be scalable and has well-understood mechanisms for delegating
	authority. Network operators are used to DNS management.
	This approach does not support intra-domain traffic optimization for		_alto._tcp.b.a.myaltoprovider.org.
	large domains behind a NAT.
	5.2. Approach #2		_alto._tcp.a.myaltoprovider.org.
	This approach does not require any changes of existing (P2P)		_alto._tcp.myaltoprovider.org.
	application protocols.
	Furthermore, the RDAC does not need to implement an additional		2.2.4. Step 4: Final lookup
	protocol besides the ALTO client protocol. However, this approach
	relocates the discovery problem from the RDAC to the first ALTO
	server.
	This first ALTO server, when preconfigured in the RDAC of a large		After step 3 has been completed the ALTO discovery client processes
	resource directory, would raise serious concerns about scalability		the PTR records and performs the final DNS lookup on the A record.
	and trust/security issues.		It then forwards the contact information to the ALTO client, which
			can now contact the ALTO server to perform ALTO queries.
	This approach does not support intra-domain traffic optimization for		3. Applicability
	large domains behind a NAT.
	5.3. Approach #3		This section discusses the applicability of the proposed solution
			with respect to the third party and the resource consumer server
			discovery deployment scenarios. Each section discusses the proposed
			steps that are needed to create the right domain name for the final
			DNS lookup.
	This approach requires changes to all existing (P2P) application		3.1. Applicability for third party server discovery
	protocols that want to benefit from ALTO.
	This approach supports intra-domain traffic optimization for large		In case of the third party server discovery deployment scenario the
	domains behind a NAT.		ALTO discovery client is a different entity than the resource
			consumer. Typically the resource consumer is a peer wehereas the
			ALTO (discovery) client is a resource directory which seeks for ALTO
			guidance on behalf of the peer. Another use case for the third party
			discovery is an application that looks for ALTO guidance
			transparently to the resource consumer, for example a CDN.
	Except for the above mentioned statements, the same results as for		Here the ALTO discovery client already knows the IP address of the
	approach #1 apply.		resource consumer which was used to establish the initial connection.
			In general this IP address is a public address, either of the
			resource consumer or of the last NAT on the path to the ALTO client.
			This makes the IP address a good candidate for the next steps. In
			case the resource consumer needs guidance for a different IP address,
			for example one from a private network, we propose that the resource
			consumer does the server discovery by itself and forwards the ALTO
			server contact information directly to the ALTO client which in turn
			can then do the third party ALTO query.
	5.4. Approach #4		To determine the DNS suffix the ALTO discovery client uses a DNS PTR
			query. As here the IP address is public we expect that the DNS query
			will be successfully resolved to the FQDN of the domain where the
			resource consumer is registered in.
	This approach requires changes to all existing (P2P) application		To compose the right domain name from the FQDN the ALTO discovery
	protocols that want to benefit from ALTO.		client follows the mechansims as described in Section 2.2.3.
			Additionally the ALTO discovery client can cache domain names and
			contact details of already discovered ALTO servers and compare them
			with the FQDN by a longest suffix matching. If successful the client
			can use the contact information and skip the final discovery step.
	This approach supports intra-domain traffic optimization for large		The fourth step of the procedure can be applied as described.
	domains behind a NAT.
	Except for the above mentioned statements, the same results as for		3.2. Applicability for resource consumer server discovery
	approach #2 apply.
	5.5. Approach #5		In this scenario the ALTO discovery client that performs the
			discovery is also the resource consumer, for example a peer in a P2P
			system. After the discovery the peer does the ALTO query on its own,
			or it might share the ALTO server contact information with a third
			party, for example a tracker, which then does the ALTO query on
			behalf of the peer.
	This approach requires changes to all existing (P2P) application		DNS SRV records can be used for resource consumer discovery, too.
	protocols that want to benefit from ALTO.		Depending on the deployment scenario the resource consumer will have
			multiple IP addresses which are possible candidates for a reverse
			lookup to determine the FQDN in step 2. Usually the ALTO server is
			responsible for a set of public IP addresses, thus in case the
			resource consumer is behind a NAT or a residential gateway it needs
			to determine the public IP address assigned to it. As discussed in
			Section 2.2.1 this can be done by the use of STUN[RFC5389] or
			BEP24[bep24].
	This approach does not need a mechanism for third-party ALTO server		In other deployment scenarios where internal guidance for a large
	discovery, as the ALTO server is discovered by the resource consumer.		private domain is desired the ALTO server might be inside the same
	However, a mechanism for this kind of discovery is needed, see, e.g.,		private domain as the resource consumer. In this case the resource
	[I-D.song-alto-server-discovery].		consumer can either use a private IP address or it needs to find a
			STUN server that is also inside the private domain in order to find
			the right IP address.
	Unlike approaches #1 .. #4 this approach supports scenarios, in which		To determine the DNS suffix for a public IP address the procedure is
	there is not exactly one "right" ALTO server for any given resource		as described in the respective section. In case of a private IP
	consumer. Instead of sending the address of the ALTO server		address it has to be ensured that the DNS server that is used by the
	provisioned by the ISP, the resource consumer can also send the		discovery client is a local one that is capable of resolving the
	address of another ALTO server of its choice to the RDAC.		private IP address.
	5.6. Approach #6		The third and fourth step of the procedure can be applied as
			described.
	This approach requires changes to all existing (P2P) application		4. IANA Considerations
	protocols that want to benefit from ALTO.
	This approach does not need a mechanism for third-party ALTO server		This document does not mandate any immediate IANA actions. However,
	discovery, as the ALTO server is discovered by the resource consumer.		such IANA considerations may arise from future ALTO discovery
	However, a mechanism for this kind of discovery is needed, see, e.g.,		specification documents which try to meet the requirements given
	[I-D.song-alto-server-discovery].		here.
	Unlike approaches #1 .. #4 this approach supports scenarios, in which		5. Security Considerations
	there is not exactly one "right" ALTO server for any given resource
	consumer. Instead of querying the ALTO server provisioned by the ISP
	and forwarding that information to the resource directory, the
	resource consumer can also query any other ALTO server of its choice.
	This approach allows the resource consumer to augment the ALTO		This early version of this memo does not yet have any security
	server's reply with local preferences (e.g., from measurements). It		considerations, but they will be added in future revision.
	is also possible not to query an ALTO server at all.
	6. Conclusion		6. Conclusion
	This document describes why a third-party ALTO server discovery		This document describes a general DNS SRV queries based ALTO server
	mechanism is required for an important class of applications, namely		discovery mechanism and discusses how ALTO discovery clients can find
	tracker-based P2P applications. Several solution approaches are		the right domain name which has to be used for the query. In
	classified and evaluated. Assuming that ALTO should work together		addition this document discusses the applicability of the described
	with already deployed application protocols, "Approach #1" seems to		mechanism for the third party as well as the resource consumer
	be most promising. In this approach, the resource directory invokes		discovery.
	a discovery mechanism external to the ALTO client protocol, in order
	to map from the resource consumer's IP address to the "right" ALTO
	server.
	The existence of such a mechanism according to "Approach #1" is
	assumed by [I-D.ietf-alto-protocol].
	Further action is required to standardize a protocol and procedures		7. References
	according to "Approach #1".
	7. IANA Considerations		7.1. Normative References
	This document does not mandate any immediate IANA actions. However,		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	such IANA considerations may arise from future ALTO discovery		Requirement Levels", BCP 14, RFC 2119, March 1997.
	specification documents which try to meet the requirements given
	here.
	8. Security Considerations		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
			specifying the location of services (DNS SRV)", RFC 2782,
			February 2000.
	This early version of this memo does not yet have any security		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	considerations, but they will be added in future revision.		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
			October 2008.
	9. References		7.2. Informative References
	[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-02 (work in progress),		draft-ietf-alto-protocol-04 (work in progress), May 2010.
	March 2010.
	[I-D.ietf-alto-reqs]		[I-D.ietf-alto-reqs]
	Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.		Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
	Yang, "Application-Layer Traffic Optimization (ALTO)		Y. Yang, "Application-Layer Traffic Optimization (ALTO)
	Requirements", draft-ietf-alto-reqs-03 (work in progress),		Requirements", draft-ietf-alto-reqs-05 (work in progress),
	February 2010.		June 2010.
	[I-D.kiesel-alto-h12]		[I-D.kiesel-alto-3pdisc]
	Kiesel, S. and M. Stiemerling, "ALTO H12",		Kiesel, S., Tomsu, M., Schwan, N., and M. Scharf, "Third-
	draft-kiesel-alto-h12-01 (work in progress), March 2010.		party ALTO server discovery", draft-kiesel-alto-3pdisc-02
			(work in progress), March 2010.
	[I-D.song-alto-server-discovery]		[I-D.stiemerling-alto-deployments]
	Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual,		Stiemerling, M. and S. Kiesel, "ALTO Deployment
	"ALTO Service Discovery",		Considerations", draft-stiemerling-alto-deployments-03
	draft-song-alto-server-discovery-01 (work in progress),		(work in progress), June 2010.
	July 2009.
			[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
			RFC 2131, March 1997.
			[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
			"Service Location Protocol, Version 2", RFC 2608,
			June 1999.
			[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
			and M. Carney, "Dynamic Host Configuration Protocol for
			IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic		[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
	Optimization (ALTO) Problem Statement", RFC 5693,		Optimization (ALTO) Problem Statement", RFC 5693,
	October 2009.		October 2009.
			[bep22] Harrison, D., Shalunov, S., and G. Greg Hazel, "BitTorrent
			Local Tracker Discovery Protocol",
			BEP http://bittorrent.org/beps/bep_0022.html.
			[bep24] Harrison, D., "Tracker Returns External IP",
			BEP http://bittorrent.org/beps/bep_0024.html.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The authors would like to thank Haibin Song, Richard Alimi, and Roni		The authors would like to thank Haibin Song, Richard Alimi, and Roni
	Even for fruitful discussions during the 75th IETF meeting.		Even for fruitful discussions during the 75th IETF meeting.
	Marco Tomsu and Nico Schwan are partially supported by the ENVISION		Marco Tomsu and Nico Schwan are partially supported by the ENVISION
	project (http://www.envision-project.org), a research project		project (http://www.envision-project.org), a research project
	supported by the European Commission under its 7th Framework Program		supported by the European Commission under its 7th Framework Program
	(contract no. 248565). The views and conclusions contained herein		(contract no. 248565). The views and conclusions contained herein
	are those of the authors and should not be interpreted as necessarily		are those of the authors and should not be interpreted as necessarily
	representing the official policies or endorsements, either expressed		representing the official policies or endorsements, either expressed
	or implied, of the ENVISION project or the European Commission.		or implied, of the ENVISION project or the European Commission.
	Michael Scharf is supported by the German-Lab project		Michael Scharf is supported by the German-Lab project
	(http://www.german-lab.de) funded by the German Federal Ministry of		(http://www.german-lab.de) funded by the German Federal Ministry of
	Education and Research (BMBF).		Education and Research (BMBF).
			Martin Stiemerling is partially supported by the NAPA-WINE project
			(Network-Aware P2P-TV Application over Wise Networks,
			http://www.napa-wine.org), a research project supported by the
			European Commission under its 7th Framework Program (contract no.
			214412). The views and conclusions contained herein are those of the
			authors and should not be interpreted as necessarily representing the
			official policies or endorsements, either expressed or implied, of
			the NAPA-WINE project or the European Commission.
	Authors' Addresses		Authors' Addresses
	Sebastian Kiesel		Sebastian Kiesel
	University of Stuttgart Computing Center		University of Stuttgart Computing Center
	Allmandring 30		Allmandring 30
	Stuttgart 70550		Stuttgart 70550
	Germany		Germany
	Email: ietf-alto@skiesel.de		Email: ietf-alto@skiesel.de
	URI: http://www.rus.uni-stuttgart.de/nks/		URI: http://www.rus.uni-stuttgart.de/nks/
	skipping to change at line 783 ¶		skipping to change at page 18, line 4 ¶
	URI: www.alcatel-lucent.com/bell-labs		URI: www.alcatel-lucent.com/bell-labs
	Michael Scharf		Michael Scharf
	Alcatel-Lucent Bell Labs		Alcatel-Lucent Bell Labs
	Lorenzstrasse 10		Lorenzstrasse 10
	Stuttgart 70435		Stuttgart 70435
	Germany		Germany
	Email: michael.scharf@alcatel-lucent.com		Email: michael.scharf@alcatel-lucent.com
	URI: www.alcatel-lucent.com/bell-labs		URI: www.alcatel-lucent.com/bell-labs
			Martin Stiemerling
			NEC Laboratories Europe/University of Goettingen
			Kurfuerstenanlage 36
			Heidelberg 69115
			Germany
			Phone: +49 6221 4342 113
			Email: martin.stiemerling@neclab.eu
			URI: http://ietf.stiemerling.org
End of changes. 91 change blocks.
	588 lines changed or deleted		328 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/