< draft-kiesel-alto-3pdisc-05.txt   draft-ietf-alto-server-discovery-01.txt >
ALTO S. Kiesel ALTO S. Kiesel
Internet-Draft University of Stuttgart Internet-Draft University of Stuttgart
Intended status: Standards Track M. Stiemerling Intended status: Standards Track M. Stiemerling
Expires: September 15, 2011 NEC Europe Ltd. Expires: January 12, 2012 NEC Europe Ltd.
N. Schwan N. Schwan
M. Scharf M. Scharf
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
M. Tomsu
Alcatel-Lucent
H. Song H. Song
Huawei Huawei
March 14, 2011 July 11, 2011
ALTO Server Discovery Protocol ALTO Server Discovery
draft-kiesel-alto-3pdisc-05 draft-ietf-alto-server-discovery-01
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.
Entities seeking guidance need to discover and possibly select an Entities seeking guidance need to discover and possibly select an
ALTO server to ask. This is called ALTO server discovery. This memo ALTO server to ask. This is called ALTO server discovery. This memo
skipping to change at page 1, line 47 skipping to change at page 1, line 45
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 September 15, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 22 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 4 1.2. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 4
1.2.1. ALTO Server Discovery by Resource Consumers . . . . . 4 1.2.1. ALTO Server Discovery by Resource Consumers . . . . . 5
1.2.2. ALTO Server Discovery by a Third Party . . . . . . . . 5 1.2.2. ALTO Server Discovery by a Third Party . . . . . . . . 5
1.3. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 10 3. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 10
3.1. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 10 3.1. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 10
3.2. Retrieving the Domain Name . . . . . . . . . . . . . . . . 10 3.2. Retrieving the Domain Name . . . . . . . . . . . . . . . . 10
3.2.1. Option 1: User input . . . . . . . . . . . . . . . . . 11 3.2.1. Option 1: User input . . . . . . . . . . . . . . . . . 11
3.2.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 12 3.2.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 12
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Applicability for Resource Consumer Server Discovery . . . 13 4.1. Applicability for Resource Consumer Server Discovery . . . 13
4.2. Applicability for Third Party Server Discovery . . . . . . 13 4.2. Applicability for Third Party Server Discovery . . . . . . 14
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
5.1. Private customers or very small businesses . . . . . . . . 15 5.1. Reverse DNS Lookup . . . . . . . . . . . . . . . . . . . . 15
5.2. Medium-size customer networks . . . . . . . . . . . . . . 15 5.1.1. Private customers or very small businesses . . . . . . 15
5.3. Large Customers . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Medium-size customer networks . . . . . . . . . . . . 15
5.1.3. Large Customers . . . . . . . . . . . . . . . . . . . 16
5.2. DHCP option for DNS Suffix . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. For U-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. For U-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 18
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Contributors List and Acknowledgments . . . . . . . . 24
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 [RFC5693]. The requirements for ALTO are itemized in resource [RFC5693]. The requirements for ALTO are itemized in
[I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol. [I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol.
ALTO clients send queries to ALTO servers, in order to solicit ALTO clients send queries to ALTO servers, in order to solicit
guidance. guidance.
ALTO clients have to discover suitable ALTO servers. Therefore the ALTO clients have to discover suitable ALTO servers. Therefore the
output of the herein defined ALTO discovery procedure tells the ALTO output of the herein defined ALTO discovery procedure tells the ALTO
client which ALTO servers to send the queries to. The ALTO discovery client which ALTO servers to send the queries to. The ALTO discovery
procedure, as part of the the ALTO client, can be embedded in the procedure, as part of the ALTO client, can be embedded in the
resource consumer, which will eventually access the desired resource. resource consumer, which will eventually access the desired resource.
As an alternative, they can be embedded in a resource directory, As an alternative, they can be embedded in a resource directory,
which assists resource consumers in finding appropriate resource which assists resource consumers in finding appropriate resource
providers. In some specific peer-to-peer application protocols these providers. In some specific peer-to-peer application protocols these
resource directories are called "trackers". Finally the ALTO server resource directories are called "trackers". Finally the ALTO server
discovery procedure can be embedded in the resource consumer, whereas discovery procedure can be embedded in the resource consumer, whereas
the ALTO client is embedded in the resource directory. ALTO queries, the ALTO client is embedded in the resource directory. ALTO queries,
which are issued by a resource directory on behalf of a resource which are issued by a resource directory on behalf of a resource
consumer, are referred to as third-party ALTO queries. The various consumer, are referred to as third-party ALTO queries. The various
possibilities to place ALTO servers and the placement of ALTO clients possibilities to place ALTO servers and the placement of ALTO clients
is discussed in [I-D.stiemerling-alto-deployments]. is discussed in [I-D.ietf-alto-deployments].
No matter where ALTO server and client are located, clients have to 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 first find out if there is an ALTO server deployed that is in charge
for them, and second they have to get the contact information of that for them, and second they have to get the contact information of that
server, i.e., the IP address, port number, and probably transport server, i.e., the IP address, port number, and probably transport
protocol (which defaults to TCP for [I-D.ietf-alto-protocol]). protocol (which defaults to TCP for the ALTO protocol specification
[I-D.ietf-alto-protocol]).
The goal of this memo is to propose a uniform mechanism for all types 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 of ALTO client deployments that is implementable and deployable at a
fast pace, i.e., without creating other deployment dependecies for fast pace, i.e., without creating other deployment dependencies for
ALTO. We propose to use a combination of DHCP and DNS to retrieve ALTO. We propose a schema which employs the UNAPTR mechanism
the URL of the resposnsible ALTO server. [RFC4848] to determine the URI of the ALTO server and where mutliple
input methods to the UNAPTR process can be used.
Comments and discussions about this memo should be directed to the Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org. ALTO working group: alto@ietf.org.
1.1. History 1.1. History
[RFC editor's note: Please remove this section before publication.]
This document represents a merge of features from two previous This document represents a merge of features from two previous
drafts: drafts:
o draft-kiesel-alto-3pdisc-04 o draft-kiesel-alto-3pdisc-04
o draft-song-alto-server-discovery-03 o draft-song-alto-server-discovery-03
1.2. Discovery Scenarios 1.2. Discovery Scenarios
Figure 1 below shows an overview on the different entities of a Figure 1 below shows an overview on the different entities of a
generic ALTO framework. The ALTO Server discovery mechanism is used generic ALTO framework. The ALTO Server discovery mechanism is used
by the p2p application in order retrieve the point of contact of the by the peer-to-peer (P2P) application in order retrieve the point of
ALTO Service. contact of the ALTO Service.
+------+ +------+
+-----+ | Peers +-----+ | Peers
+-----+ +------+ +=====| |--+-oo +-----+ +------+ +=====| |--+-oo
| |......| |====+ oo+--*--+ o | |......| |====+ oo+--*--+ o
+-----+ +------+ | o * ooooooo +-----+ +------+ | o * ooooooo
Source of ALTO | o * Source of ALTO | o *
Topological Service | o +--*--+ Topological Service | o +--*--+
information +===o=| | Tracker information +===o=| | Tracker
o +-----+ /Super-peer o +-----+ /Super-peer
skipping to change at page 4, line 35 skipping to change at page 4, line 39
| |oooooooooo | |oooooooooo
+------+ +------+
Legend: Legend:
=== ALTO query protocol === ALTO query protocol
ooo ALTO service discovery protocol ooo ALTO service discovery protocol
*** Application protocol (out of scope) *** Application protocol (out of scope)
... Provisioning or initialization (out of scope) ... Provisioning or initialization (out of scope)
Figure 1: ALTO Discovery Overview Figure 1: ALTO Discovery Overview
Hereby the ALTO service discovery scenarios are classified into two Hereby the ALTO service discovery scenarios are classified into two
types: one is the ALTO server discovery by the resource consumer, and types: one is the ALTO server discovery by the resource consumer, and
the other is the ALTO server discovery by a third party, such as the other is the ALTO server discovery by a third party, such as
application trackers. Before the specification of the discovery application trackers. Before the specification of the discovery
mechanism the following section illustrates and discusses both mechanism the following section illustrates and discusses both
scenarios. scenarios.
1.2.1. ALTO Server Discovery by Resource Consumers 1.2.1. ALTO Server Discovery by Resource Consumers
The ALTO service discovery in some scenarios needs to be performed by The ALTO service discovery in some scenarios needs to be performed by
the resource consumer itself. In particular in p2p applications the resource consumer itself. In particular in P2P applications
without a tracker like DHTs and other conventional client/server without a tracker like DHTs and other conventional client/server
applications. applications.
In addition also p2p application which are tracker based may embed In addition also P2P application which are tracker based may embed
the ALTO client into the resurce consumer to allow peers a peer the ALTO client into the resource consumer to allow peers a selection
selection after retrieving peer list from the application tracker. of peers after retrieving the peer list from the application tracker.
Another option is that the reource consumer peer sends its ALTO Another option is that the resource consumer peer sends its ALTO
server address information to the application tracker or any other server address information to the application tracker or any other
third party entity, which in turn will contact the specific ALTO third party entity, which in turn will contact the specific ALTO
server and in order to retrieve ALTO guidance on behalf of the server in order to retrieve ALTO guidance on behalf of the resource
resource consumer. consumer.
The following figure illustrates this scenario, showing the The following figure illustrates this scenario, showing the
relationship between the different entities as discussed before. relationship between the different entities as discussed before.
+---------------+ +---------------+
| ALTO Server | | ALTO Server |
+---------------+ +---------------+
^ ^ +-----------+ ^ ^ +-----------+
| | | ALTO | | | | ALTO |
| +---+---+ | Service | | +---+---+ | Service |
skipping to change at page 5, line 36 skipping to change at page 5, line 43
+------------+--+ | o o +------------+--+ | o o
|P2P Application|ooooo|oooooooooooo o |P2P Application|ooooo|oooooooooooo o
| Client A | | o | Client A | | o
+---------------+ | o +---------------+ | o
| o | o
+--+-------------+ o +--+-------------+ o
| P2P Application|oooooo | P2P Application|oooooo
| Client B | | Client B |
+----------------+ +----------------+
Figure 2: Resource Consumer ALTO Server Discovery (Example) Figure 2: Resource Consumer ALTO Server Discovery (Example)
1.2.2. ALTO Server Discovery by a Third Party 1.2.2. ALTO Server Discovery by a Third Party
Some p2p applications have trackers, and these applications might not Some P2P applications have trackers, and these applications might not
need to have their clients looking for the ALTO server guidance. In need to have their clients looking for the ALTO server guidance. In
these scenarios trackers query the ALTO servers for guidance these scenarios trackers query the ALTO servers for guidance
themselves, and then return the final ranked result to the themselves, and then return the final ranked result to the
application clients. However, application clients are distributed application clients. However, application clients are distributed
among different network operators and autonomous systems. Trackers among different network operators and autonomous systems. Trackers
thus need to find different ALTO servers for the clients located in thus need to find different ALTO servers for the clients located in
different operator networks or autonomous systems. In such scenarios different operator networks or autonomous systems. In such scenarios
the discuvery is thus not performed by the resource consumer, but a the discovery is thus not performed by the resource consumer, but a
third party entity on behalf of the resource consumer. third party entity on behalf of the resource consumer.
Figure 3 shows an example for a third party ALTO server discovery. Figure 3 shows an example for a third party ALTO server discovery.
For client 1, the tracker has not cached yet the mapping between For Client1 (1), the tracker has not cached yet the mapping between
client 1's network operator and its ALTO server address, so it Client1's network operator and its ALTO server address, so it uses
queries the DNS server for the ALTO server address in that operator's the ALTO Discovery Service to determine the address of the ALTO
domain. And then the tracker interacts with the ALTO server on server in that operator's domain (2). Then the tracker interacts
behalf of client 1(to get the network map and cost map), finally, the with ALTO Server1 (3)(4) on behalf of Client1 (to get the network map
ranked list is sent back to client 1. For client 2, the tracker has and cost map), finally, the ranked list is sent back to Client1 (5).
cached the mapping between client 2's network operator and its ALTO For Client2, the tracker has cached the mapping between Client2's
server address, so it does not need to query the DNS for the address network operator and ALTO Server2's address, so it does not need to
of ALTO server 2. If the Application tracker already has the network perform the discovery process (which are the labels (a),(b), (c), and
map and cost map from ALTO Server2, then it does not to query the (d)). If the application tracker already has the network map and
ALTO Server for network map and cost map frequently. cost map from ALTO Server2, then it does not need to query the ALTO
Server for network map and cost map frequently.
+-------------+ +-------------+ +-------------+ +-------------+
| ALTO Server1| | ALTO Server2| | ALTO Server1| | ALTO Server2|
+-------------+ +-------------+ +-------------+ +-------------+
^ | ^ | ^ | ^ |
3| 4| b| |c 3| 4| b| |c
| | | | | | | |
v /----------+-\ v v /----------+-\ v
+---+ ////// \\\\\ +-----------+ ////// \\\\\
| | ||| ||| | | ||| |||
| |<===>| | | ALTO |<===>| |
|DNS| 2 | Application Tracker | | Discovery | 2 | Application Tracker |
| | ||| ||| | Service | ||| |||
| | \\\\\\ ///// | | \\\\\\ /////
+---+ ^ | \------------/ | +-----------+ ^ | \------------/ |
| |5 ^ |d | |5 ^ |d
1| | a| | 1| | a| |
| v | v | v | v
+-+---------+ +---+--------+ +-+---------+ +---+--------+
|Application| |Application | |Application| |Application |
|client1 | |client2 | | Client1 | | Client2 |
+-----------+ +------------+ +-----------+ +------------+
Figure 3: Third Party ALTO Server Discovery (Example) Figure 3: Third Party ALTO Server Discovery (Example)
1.3. Pre-Conditions 1.3. Pre-Conditions
The whole document assumes certain pre-conditions, such as: The whole document assumes certain pre-conditions, such as:
o The ALTO server discovery procedure is executed on a per IP o The ALTO server discovery procedure is executed on a per IP
address base. Multiple IP addresses per interface or multiple IP address base. Multiple IP addresses per interface or multiple IP
addresses assigned to different IP interfaces require to repeat addresses assigned to different IP interfaces require to repeat
the procedure for every IP address. It may be fine to group IP the procedure for every IP address. It may be fine to group IP
addresses according their domain suffixes and to perfom the addresses according their domain suffixes and to perfom the
procedure for such a group. However, this is out of scope of this procedure for such a group. However, this is out of scope of this
document. document.[Editor's note: this may relate to the work of the MIF
WG]
o The ALTO server discovery procedure is executed on a per IP family o The ALTO server discovery procedure is executed on a per IP family
base, i.e., seperate for IPv4 and IPv6. It is up to the ALTO base, i.e., seperate for IPv4 and IPv6. It is up to the ALTO
client to decide which of the possible multiple results of client to decide which of the possible multiple results of
different IP address families to use. The choice of whether to different IP address families to use. The choice of whether to
use IPv4 or IPv6 is out of scope of this document. use IPv4 or IPv6 is out of scope of this document.
o A change of the IP address at an interface invalidates the result o A change of the IP address at an interface invalidates the result
of the ALTO server discovery procedure. For instance, if the IP of the ALTO server discovery procedure. For instance, if the IP
address assigned to a mobile host changes due to host mobility, it address assigned to a mobile host changes due to host mobility, it
skipping to change at page 8, line 14 skipping to change at page 8, line 14
2. Protocol Overview 2. Protocol Overview
We define multiple alternatives to discover the IP address of the We define multiple alternatives to discover the IP address of the
ALTO server, as there are a number of ways possible how such ALTO server, as there are a number of ways possible how such
information can be provided to the ALTO client. The choice of method information can be provided to the ALTO client. The choice of method
is up to the local network deployment. For instance, there can be is up to the local network deployment. For instance, there can be
deployments where the ALTO server in charge for ALTO client is deployments where the ALTO server in charge for ALTO client is
provisioned by the network operator and communicated to the ALTO provisioned by the network operator and communicated to the ALTO
client's host via a DHCP option, while in other deployments no such client's host via a DHCP option, while in other deployments no such
means may exist. means may exist. It should be noted that there is no silver bullet
solution to the ALTO server discovery, as there too many deployment
scenarios in the server discovery space.
The following figure illustrates the different protocols that are The following figure illustrates the different protocols that are
used to find the URI of a suitable ALTO server. used to find the URI of a suitable ALTO server.
Descending order of Preference Descending Order of Preference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
-------------- -------- --------------- -------------- -------- ---------------
| User Input | | DHCP | | Reverse DNS | | User Input | | DHCP | | Reverse DNS |
-------------- -------- --------------- -------------- -------- ---------------
| | | | | |
\ | / \ | /
Retrieving the DNS suffix Retrieving the DNS suffix
\ | / \ | /
--------+---------- --------+----------
| |
----------- -----------
| U-NAPTR | | U-NAPTR |
----------- -----------
| |
Retrieving ALTO Server URI Retrieving ALTO Server URI
| |
| |
Final DNS lookup Final DNS lookup
Figure 1: Protocol Overview Figure 4: Protocol Overview
The figure above illustrates the U-NAPTR based resolution process to Figure 4 illustrates the U-NAPTR based resolution process to retrieve
retrieve the ALTO Server URL. As a precondition for resolution the the ALTO Server URL. As a precondition for resolution the U-NAPTR
U-NAPTR process needs the right domain name as input. This domain process needs the right domain name as input. This domain name is
name is determined by the IP address of the client and the DNS suffix determined by the IP address of the client and the DNS suffix of the
of the access network where the client is registered in. In order to access network where the client is registered in. In order to
retrieve the DNS suffix we specify three options: retrieve the DNS suffix we specify three options, as are listed in
descending order of preference:
User input: a user may manually specify the DNS suffix on its own, User input: a user may manually specify the DNS suffix on its own,
either to access a 3rd party ALTO service provider or as it does either to access a 3rd party ALTO service provider or as it does
know such information. know such information. This input may also origin from a web page
where the user downloads the configuration which is loaded as user
input.
DHCP: a network provider provides the DNS suffix through a DHCP DHCP: a network provider provides the DNS suffix through a DHCP
option. option.
Reverse DNS: the DNS system can be used to retrieve the DNS suffix Reverse DNS: the DNS system can be used to retrieve the DNS suffix
through reverse lookup of an FQDN associated with an IP address. through reverse lookup of an FQDN associated with an IP address.
This is the last resort if all other options failed. This is the last resort if all other options failed.
3. Retrieving the URI by U-NAPTR 3. Retrieving the URI by U-NAPTR
This section specifies the U-NAPTR based resolution process. To This section specifies the U-NAPTR based resolution process. To
start the U-NAPTR resolution process a domain name as input is start the U-NAPTR resolution process a domain name is required as
needed. Thus the section is devided into two parts: Section 3.1 input. Thus the section is devided into two parts: Section 3.1
describes the U-NAPTR resolution process itself. How the client describes the U-NAPTR resolution process itself. How the client
identifies this DNS suffix of the access network where the resource identifies this DNS suffix of the access network where the resource
consumer is registered in is described in Section 3.2. consumer is registered in is described in Section 3.2.
3.1. U-NAPTR Resolution 3.1. U-NAPTR Resolution
ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/ ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/
Dynamic Delegation Discovery Service) [RFC4848] application unique Dynamic Delegation Discovery Service) [RFC4848] application unique
strings, in the form of a DNS name. An example is strings, in the form of a DNS name. An example is
'altoserver.example.com'. 'altoserver.example.com'.
Clients need to use the U-NAPTR [RFC4848] specification described Clients need to use the U-NAPTR [RFC4848] specification described
below to obtain a URI (indicating host and protocol) for the below to obtain a URI (indicating host and protocol) for the
applicable ALTO service. In this document, only the HTTP and HTTPS applicable ALTO service. In this document, only the HTTP and HTTPS
URL schemes are defined. Note that the HTTP URL can be any valid URL schemes are defined, as the ALTO protocol specification defines
HTTP URL, including those containing path elements. the access over both protocols, but no other
[I-D.ietf-alto-protocol]. Note that the HTTP URL can be any valid
HTTP(s) URL, including those containing path elements.
The following two DNS entries show the U-NAPTR resolution for The following two DNS entries show the U-NAPTR resolution for
"example.com" to the HTTPS URL https://altoserver.example.com/secure "example.com" to the HTTPS URL https://altoserver.example.com/secure
or the HTTP URL http://altoserver.example.com, with the former being or the HTTP URL http://altoserver.example.com, with the former being
preferred. preferred.
example.com. example.com.
IN NAPTR 100 10 "u" "ALTO:https" IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://altoserver.example.com/secure!" "" "!.*!https://altoserver.example.com/secure!" ""
skipping to change at page 13, line 18 skipping to change at page 13, line 18
with respect to the resource consumer server discovery and the third with respect to the resource consumer server discovery and the third
party deployment scenarios. Each section discusses the proposed party deployment scenarios. Each section discusses the proposed
steps that are needed to determine the ALTO Server URI. steps that are needed to determine the ALTO Server URI.
4.1. Applicability for Resource Consumer Server Discovery 4.1. Applicability for Resource Consumer Server Discovery
In this scenario the ALTO server discovery procedure is performed by In this scenario the ALTO server discovery procedure is performed by
the resource consumer, for example a peer in a P2P system. After the 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 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 the ALTO server contact information with a third party, for example a
tracker, which then does the ALTO query on behalf of the peer. tracker, which then executes the ALTO query on behalf of the peer.
To complete the ALTO server discovery process the resource consumer To complete the ALTO server discovery process the resource consumer
first SHOULD check whether the user has provider the domain name first SHOULD check whether the user has provider the domain name
through manual configuration. If this is not the case the next step through manual configuration. If this is not the case the next step
SHOULD be to check for the access network domain name DHCP option SHOULD be to check for the access network domain name DHCP option
(Section 3.2.2). Finally the client SHOULD try to retrieve the (Section 3.2.2). Finally the client SHOULD try to retrieve the
domain name by the last option, the DNS reverse lookup on its IP domain name by the last option, the DNS reverse lookup on its IP
address as described in Section 3.2.3. address as described in Section 3.2.3.
A client can have several candidate IP addresses that it may use for
the discovery process. For example if it is located behind a NAT, a
private and a public IP address may be used for the discovery
process. It depends on the deployment scenario which of the IP
addresses is the correct one. Thus it is out-of-scope of this
document to specify how exactly the client finds the right IP
address. However in the following we list methods that may be used
in order to determine these candidate IP addresses. Generally in P2P
environments peers already have implemented mechanisms for NAT-
traversal. This includes proprietary solutions to determine a peer's
public IP address, for example by asking a neighbour peer about its
record of the own IP address. Non-proprietary solutions that are
favorable include the Session Traversal Utilities for NAT (STUN)
[RFC5986] protocol to determine the public address. If the client is
behind a residential gateway another option may be to use Universal
Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] or the NAT Port
Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp].
In case the ALTO discovery client has determined the domain name In case the ALTO discovery client has determined the domain name
through one of the described options it proceedes with the U-NAPTR through one of the described options it proceedes with the U-NAPTR
lookup as described in Section 3.1. lookup as described in Section 3.1.
4.2. Applicability for Third Party Server Discovery 4.2. Applicability for Third Party Server Discovery
In case of the third party server discovery deployment scenario the In case of the third party server discovery deployment scenario the
entity performing the ALTO server discovery process is different from entity performing the ALTO server discovery process is different from
the resource consumer. Typically the resource consumer is a peer the resource consumer. Typically the resource consumer is a peer
whereas the ALTO client is a resource directory which seeks for ALTO whereas the ALTO client is a resource directory which seeks for ALTO
skipping to change at page 15, line 8 skipping to change at page 15, line 8
address, for example one from a private network, we recommend that address, for example one from a private network, we recommend that
the resource consumer discovers the server itself and forwards the the resource consumer discovers the server itself and forwards the
ALTO server contact information directly to the third party entity, ALTO server contact information directly to the third party entity,
which in turn can then do the third party ALTO query. Again, which in turn can then do the third party ALTO query. Again,
forwarding the contact information from the resource consumer to the forwarding the contact information from the resource consumer to the
third party entity is out of scope of this document. third party entity is out of scope of this document.
5. Deployment Considerations 5. Deployment Considerations
The mechanism specified in this document needs some configuration The mechanism specified in this document needs some configuration
effort in order to work properly. Especially the domain name effort in order to work properly.
retrieved through the reverse DNS lookup (PTR records) and the
U-NAPTR entry need to be coordinated. In this section we discuss
this configuration for different scenarios.
5.1. Private customers or very small businesses 5.1. Reverse DNS Lookup
Especially the domain name retrieved through the reverse DNS lookup
(PTR records) and the U-NAPTR entry need to be coordinated. In this
section we discuss this configuration for different scenarios.
5.1.1. Private customers or very small businesses
For private customers and very small businesses that are DSL or cable For private customers and very small businesses that are DSL or cable
customers often a dynamically assigned IP address is provisioned. customers often a dynamically assigned IP address is provisioned.
Here, the reverse DNS lookup (PTR records) are controlled by the ISP Here, the reverse DNS lookup (PTR records) are controlled by the ISP
and they point to the ISP's domain, e.g.: and they point to the ISP's domain, e.g.:
p5B203EA1.dip.t-dialin.net. p5B203EA1.dip.t-dialin.net.
dslb-084-056-144-100.pools.arcor-ip.net. dslb-084-056-144-100.pools.arcor-ip.net.
skipping to change at page 15, line 44 skipping to change at page 15, line 47
dip.t-dialin.net. dip.t-dialin.net.
pools.arcor-ip.net. pools.arcor-ip.net.
bnut3700.dsl.brasiltelecom.net.br. bnut3700.dsl.brasiltelecom.net.br.
ispnetbilling.com. ispnetbilling.com.
pool.ukrtel.net. pool.ukrtel.net.
5.2. Medium-size customer networks 5.1.2. Medium-size customer networks
The second class of customers have their own DNS domain but only one The second class of customers have their own DNS domain but only one
single upstream ISP, e.g.: single upstream ISP, e.g.:
(1) ISP my-isp.net assigns an IP address a.b.c.d to its customer (1) ISP my-isp.net assigns an IP address a.b.c.d to its customer
(2) The customer decides that reverse mapping for a.b.c.d should be (2) The customer decides that reverse mapping for a.b.c.d should be
whatever.customerdomain.com whatever.customerdomain.com
(3) If the customer wants to support ALTO, he has to ask the ISP for (3) If the customer wants to support ALTO, he has to ask the ISP for
the URI of the ISP's ALTO server which can give guidance to the URI of the ISP's ALTO server which can give guidance to
a.b.c.d. Assume that ISP replies it is a.b.c.d. Assume that ISP replies it is
http://altoserver.my-isp.net http://altoserver.my-isp.net
(4) The customer establishes a U-NAPTR entry for his domain (4) The customer establishes a U-NAPTR entry for his domain
skipping to change at page 16, line 17 skipping to change at page 16, line 20
(3) If the customer wants to support ALTO, he has to ask the ISP for (3) If the customer wants to support ALTO, he has to ask the ISP for
the URI of the ISP's ALTO server which can give guidance to the URI of the ISP's ALTO server which can give guidance to
a.b.c.d. Assume that ISP replies it is a.b.c.d. Assume that ISP replies it is
http://altoserver.my-isp.net http://altoserver.my-isp.net
(4) The customer establishes a U-NAPTR entry for his domain (4) The customer establishes a U-NAPTR entry for his domain
customerdomain.com. IN NAPTR 200 10 "u" "ALTO:http" customerdomain.com. IN NAPTR 200 10 "u" "ALTO:http"
"!.*!http://altoserver.my-isp.net!" "" "!.*!http://altoserver.my-isp.net!" ""
5.3. Large Customers 5.1.3. Large Customers
For very large customers with multiple upstream connections we assume For very large customers with multiple upstream connections we assume
that they have their very own traffic optimization policies and thus that they have their very own traffic optimization policies and thus
run their own ALTO server anyway. In this case they need to manage run their own ALTO server anyway. In this case they need to manage
their DNS entries accordingly. their DNS entries accordingly.
5.2. DHCP option for DNS Suffix
Section 3.2.2 describes the usage of a DHCP option which allows the
network operator of the network where the ALTO client is attached to,
to provide a DNS suffix. However, this assumes that this particular
DHCP option is correctly passed from the DHCP server to the actual
host with the ALTO client, and that the particular host understands
this DHCP option. This memo assumes the client to be able to
understand the proposed DHCP option, otherwise there is no further
use of the DHCP option, but the client has to use the other proposed
mechanisms.
There are well-known issues with the handling of DHCP options in home
gateways. One issue is that unkown DHCP options are not passed
through some home gateways, effectively eliminating the DHCP option.
Another well-known issues is the usage of home gateway specific DNS
suffixes which "override" the DNS suffix provided by the network
operator. For instance, a host behind a home gateway may receive a
DNS suffix ".local" instead of "example.com". This suffix is not
usuable for the server discovery procedure.
[Editor's note: This section needs references about the well-known
issues with home gateways and it relates to the FUN activity on home
gateways which needs to be explored further.
6. IANA Considerations 6. IANA Considerations
This document registers the following U-NAPTR application service This document registers the following U-NAPTR application service
tag: tag:
Application Service Tag: ALTO Application Service Tag: ALTO
Defining Publication: The specification contained within this Defining Publication: The specification contained within this
document. document.
skipping to change at page 18, line 19 skipping to change at page 18, line 19
This is still to be done in later revision of this draft, as the This is still to be done in later revision of this draft, as the
draft evolves heavily right now. draft evolves heavily right now.
7.2. For U-NAPTR 7.2. For U-NAPTR
The address of an ALTO server is usually well-known within an access The address of an ALTO server is usually well-known within an access
network; therefore, interception of messages does not introduce any network; therefore, interception of messages does not introduce any
specific concerns. specific concerns.
The primary attack against the methods described in this document is The primary attack against the methods described in this document is
one that would lead to impersonation of a ALTO server since a device one that would lead to impersonation of an ALTO server since a device
does not necessarily have a prior relationship with a ALTO server. does not necessarily have a prior relationship with an ALTO server.
An attacker could attempt to compromise ALTO discovery at any of An attacker could attempt to compromise ALTO discovery at any of
three stages: three stages:
1. providing a falsified domain name to be used as input to U-NAPTR 1. providing a falsified domain name to be used as input to U-NAPTR
2. altering the DNS records used in U-NAPTR resolution 2. altering the DNS records used in U-NAPTR resolution
3. impersonation of the ALTO 3. impersonation of the ALTO server
This document focuses on the U-NAPTR resolution process and hence This document focuses on the U-NAPTR resolution process and hence
this section discusses the security considerations related to the DNS this section discusses the security considerations related to the DNS
handling. The security aspects of obtaining the domain name that is handling. The security aspects of obtaining the domain name that is
used for input to the U-NAPTR process is described in respective used for input to the U-NAPTR process is described in respective
documents, such as [I-D.ietf-geopriv-lis-discovery]. documents, such as [RFC5986].
The domain name that is used to authenticated the ALTO server is the The domain name that is used to authenticated the ALTO server is the
domain name in the URI that is the result of the U-NAPTR resolution. domain name in the URI that is the result of the U-NAPTR resolution.
Therefore, if an attacker were able to modify or spoof any of the DNS Therefore, if an attacker was able to modify or spoof any of the DNS
records used in the DDDS resolution, this URI could be replaced by an records used in the DDDS resolution, this URI could be replaced by an
invalid URI. The application of DNS security (DNSSEC) [RFC4033] invalid URI. The application of DNS security (DNSSEC) [RFC4033]
provides a means to limit attacks that rely on modification of the provides a means to limit attacks that rely on modification of the
DNS records used in U-NAPTR resolution. Security considerations DNS records used in U-NAPTR resolution. Security considerations
specific to U-NAPTR are described in more detail in [RFC4848]. specific to U-NAPTR are described in more detail in [RFC4848].
An "https:" URI is authenticated using the method described in An "https:" URI is authenticated using the method described in
Section 3.1 of [RFC2818]. The domain name used for this Section 3.1 of [RFC2818]. The domain name used for this
authentication is the domain name in the URI resulting from U-NAPTR authentication is the domain name in the URI resulting from U-NAPTR
resolution, not the input domain name as in [RFC3958]. Using the resolution, not the input domain name as in [RFC3958]. Using the
skipping to change at page 20, line 21 skipping to change at page 20, line 21
Missing reverse DNS entries for an IP address: There may be cases Missing reverse DNS entries for an IP address: There may be cases
where the reverse DNS lookup does not yield any result. However, where the reverse DNS lookup does not yield any result. However,
this will leave the ALTO client with no choice, other than giving this will leave the ALTO client with no choice, other than giving
up. This needs better documentation. up. This needs better documentation.
How to handled multiple results: For instance, a host behind a NAT How to handled multiple results: For instance, a host behind a NAT
that yields an ALTO server in the private IP address domain and that yields an ALTO server in the private IP address domain and
one in the public IP address domain. Whom to ask? one in the public IP address domain. Whom to ask?
Suffix Issues Document issues with suffix information provided by Normative Language The current version of this memo lacks the proper
DHCP or by other means. For instance, a host behind a NAT may normative language in many places.
have a configured DNS suffix ".local". This suffix is not usuable
for the server discovery procedure.
9. Contributors
Hannes Tschofenig provided the initial input to the U-NAPTR solution
part. Hannes and Martin Thomson provided excellent feedback and
input to the server discovery.
The authors would also like to thank the following persons for their
contribution to this document or predecessors:
Roni Even
Gustavo Garcia
Yu-Shun Wang
Victor Pascual
Richard Alimi
Yunfei Zhang
Y. Richard Yang
Xingfeng Jiang
Jay Gu
Ning Zong
David Bryan
Enrico Marocco
10. Conclusion 9. Conclusion
This document describes a general ALTO server discovery process and This document describes a general ALTO server discovery process and
discusses how the process can be applied in different deployment discusses how the process can be applied in different deployment
scenarios, including the resouce consumer discovery as well as the scenarios, including the resouce consumer discovery as well as the
third party discovery. third party discovery.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
11.2. Informative References 10.2. Informative References
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.ietf-alto-deployments]
Stiemerling, M. and S. Kiesel, "ALTO Deployment
Considerations", draft-ietf-alto-deployments-01 (work in
progress), March 2011.
[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-04 (work in progress), May 2010. draft-ietf-alto-protocol-04 (work in progress), May 2010.
[I-D.ietf-alto-reqs] [I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO) Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-08 (work in progress), Requirements", draft-ietf-alto-reqs-08 (work in progress),
March 2011. March 2011.
[I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-15 (work in progress),
March 2010.
[I-D.song-alto-server-discovery]
Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V.
Avila, "ALTO Service Discovery",
draft-song-alto-server-discovery-03 (work in progress),
July 2010.
[I-D.stiemerling-alto-deployments]
Stiemerling, M. and S. Kiesel, "ALTO Deployment
Considerations", draft-stiemerling-alto-deployments-03
(work in progress), June 2010.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472, Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006. April 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, April 2007.
[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.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, Location Information Server (LIS)", RFC 5986,
September 2010. September 2010.
[UPnP-IGD-WANIPConnection1]
UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0: WANIPConnection:1 Service
Template Version 1.01 For UPnP Version 1.0", DCP 05-001,
November 2001.
[bep24] Harrison, D., "Tracker Returns External IP", [bep24] Harrison, D., "Tracker Returns External IP",
BEP http://bittorrent.org/beps/bep_0024.html. BEP http://bittorrent.org/beps/bep_0024.html.
Appendix A. Acknowledgments Appendix A. Contributors List and Acknowledgments
The authors would like to thank Haibin Song, Richard Alimi, and Roni The initial version of this document was co-authored by Marco Tomsu
Even for fruitful discussions during the 75th IETF meeting. <marco.tomsu@alcatel-lucent.com>.
Hannes Tschofenig provided the initial input to the U-NAPTR solution Hannes Tschofenig provided the initial input to the U-NAPTR solution
part. Hannes and Martin Thomson provided excellent feedback and part. Hannes and Martin Thomson provided excellent feedback and
input to the server discovery. input to the server discovery.
The authors would also like to thank the following persons for their
contribution to this document or its predecessors: Richard Alimi,
David Bryan, Roni Even, Gustavo Garcia, Jay Gu, Xingfeng Jiang,
Enrico Marocco, Victor Pascual, Y. Richard Yang, Yu-Shun Wang, Yunfei
Zhang, Ning Zong.
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
skipping to change at page 27, line 4 skipping to change at page 25, line 43
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
Marco Tomsu
Alcatel-Lucent
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: marco.tomsu@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs
Haibin Song Haibin Song
Huawei Huawei
Email: melodysong@huawei.com Email: melodysong@huawei.com
 End of changes. 58 change blocks. 
168 lines changed or deleted 191 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/