One document matched: draft-song-alto-server-discovery-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3958 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml">
<!ENTITY RFC2915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2915.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC4848 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4848.xml">
<!ENTITY RFC2165 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2165.xml">
<!ENTITY RFC4795 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4795.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ietf-alto-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-problem-statement.xml">
<!ENTITY I-D.ietf-dhc-container-opt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-container-opt.xml">
<!ENTITY I-D.ietf-geopriv-lis-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lis-discovery.xml">
<!ENTITY I-D.wang-alto-p4p-specification SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wang-alto-p4p-specification.xml">
<!ENTITY I-D.cheshire-dnsext-multicastdns SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-multicastdns.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-song-alto-server-discovery-01"
ipr="trust200902" submissionType="IETF" xml:lang="">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="ALTO Server Discovery">ALTO Service Discovery</title>
<author fullname="Song Haibin" initials="H" role="editor" surname="Song">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<email>melodysong@huawei.com</email>
</address>
</author>
<author fullname="Marco Tomsu" initials="M" role="editor" surname="Tomsu">
<organization>Alcatel-lucent Bell Labs</organization>
<address>
<postal>
<street>Lorenzstrasse 10</street>
<city>70435 Stuttgart</city>
<country>Germany</country>
</postal>
<email>marco.tomsu@alcatel-lucent.com</email>
<uri>www.alcatel-lucent.com/bell-labs</uri>
</address>
</author>
<author fullname="Gustavo Garcia " initials="G" surname="Garcia">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Emilio Vargas</street>
<city>Madrid, Madrid</city>
<country>Spain</country>
</postal>
<phone>+34 913129826</phone>
<email>ggb@tid.es</email>
</address>
</author>
<author fullname="Yu-Shun Wang" initials="Y" surname="Wang">
<organization>Microsoft Corp.</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond, WA</city>
<code>98052</code>
<country>USA</country>
</postal>
<email>yu-shun.wang@microsoft.com</email>
</address>
</author>
<author fullname="Victor Pascual" initials="V" surname="Pascual">
<organization>Tekelec</organization>
<address>
<postal>
<street>Am Borsigturm 11</street>
<city>Berlin</city>
<code>D-13507</code>
<country>Germany</country>
</postal>
<phone>+49 30 32 51 32 12</phone>
<email>victor@iptel.org</email>
</address>
</author>
<date day="11" month="July" year="2009" />
<area>Applications Area</area>
<workgroup>ALTO</workgroup>
<keyword>ALTO</keyword>
<keyword>Server Discovery</keyword>
<abstract>
<t>Application-Layer Traffic Optimization (ALTO) service aims to provide
distributed applications with information to perform better-than-random
initial peer selection when multiple peers in the network are available
to provide a resource or service. In order to discover an
Application-Layer Traffic Optimization (ALTO) Server, a set of
mechanisms are required. These mechanisms enable applications to find an
information source which provides them with information regarding the
underlying network. This document discusses various scenarios of ALTO
discovery and specifies the use of several available options such as
DHCP or DNS.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="History">
<t>This document represents a merge of features from two previous
drafts:</t>
<t>(1). draft-wang-alto-discovery-00</t>
<t>(2). draft-song-alto-server-discovery-00</t>
<t>The ALTO service architecture and protocol are currently under
discussion and development within the IETF ALTO working group.</t>
<t>Although it is identified in the charter that a discovery mechanism
is needed, the preference is to adopt one or more existing mechanisms
for ALTO discovery rather than designing a new one. Note though
certain design decisions of the final ALTO framework will affect the
selection of discovery mechanisms. As a result, this document makes
minimum assumptions of the ALTO framework, and presents different
scenarios and available options based on prior and related discovery
mechanisms. This document will be updated to track the progress of the
ALTO requirements and solution.</t>
</section>
<section title="Overview">
<t>The ALTO problem statement draft <xref
target="I-D.ietf-alto-problem-statement"></xref> describes that in P2P
applications or client/server applications, resources or services are
often available through multiple replicas and each of those are
sometimes provided by different providers. ALTO service gives guidance
to a consumer or directory about which resource provider(s) to select,
in order to optimize the client's performance or quality of experience
while optimizing resource consumption in the underlying network
infrastructure.</t>
<t>In order to query the ALTO server, clients must first know one or
more ALTO servers that might provide useful information. The purpose
of the ALTO discovery mechanism is to find those servers in different
network and application scenarios.</t>
<t><xref target="sec_deployment"></xref> and <xref
target="sec_scenarios"></xref> discuss various scenarios of ALTO
service deployment and discovery. <xref
target="sec_mechanisms"></xref> provides a description of available
discovery mechanisms and its application to the ALTO service discovery
use case addressing potential issues and consideration for each.</t>
</section>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>The document uses terms defined in <xref
target="I-D.ietf-alto-problem-statement"></xref>.</t>
<t>In addition to the generic ALTO descriptions, the following terms are
used to describe the discovery mechanisms in this document:</t>
<t>o ALTO Discovery Client: The logical entity discovering the ALTO
Service. Depending on the scenario, this could be a Peer or a
Super-peer/Tracker.</t>
<t>o ALTO Discovery Server: The logical entity providing information to
locate the ALTO Service. Depending on the discovery mechanism, this
could be another Peer or a dedicated entity in the network.</t>
<t>o ALTO Discovery Domain: The scope of the network handled by a
particular ALTO Discovery Server.</t>
</section>
<section anchor="sec_deployment" title="ALTO Service Deployment">
<t>This section explores the various dimensions of the ALTO service
deployment and access scenarios, and briefly discusses their
implications to the discovery mechanisms. Figure 1 below shows a generic
ALTO framework diagram with discovery. .</t>
<figure>
<artwork>
+------+
+-----+ | Peers
+-----+ +------+ +=====| |--+-oo
| |......| |====+ oo+--*--+ o
+-----+ +------+ | o * ooooooo
Source of ALTO | o *
Topological Service | o +--*--+
information +===o=| | Tracker
o +-----+ /Super-peer
ALTO Discovery o o
Service o o
+------+ o o
| |oooooooooo
+------+
Legend:
=== ALTO query protocol
ooo ALTO service discovery protocol
*** Application protocol (out of scope)
... Provisioning or initialization (out of scope)
Figure 1 ALTO Discovery Diagram
</artwork>
</figure>
<section title="ISP-Centric vs. Application-Specific ALTO Service Deployments">
<t>An ALTO Server is the logical entity that provides query interfaces
for ALTO Clients. ALTO servers can be deployed in an ISP-centric
deployment or on the application level by application providers or
other trusted third parties:</t>
<t>1. A network operator which wants to optimize its traffic, e.g. to
reduce its transit traffic volume across the network boundaries; a
third party on behalf of one or even several ISPs.</t>
<figure>
<artwork>
+-----------+ +-----------+ +---------+
|ALTO Server| |ALTO Server| |ALTO |
| A | | B | |Service |
+-----------+ +-----------+ |Discovery|
^ ^ +---------+
+---+--+ +---+--+ o o
+|------|-------------------|------|-+ o o
|| | P2P Appication A | | |ooo o
++------+-------------------+------+-+ o
| | | | o
++------+-------------------+------+-+ o
|| | P2P Applcation B | | |oooooooo
++------+-------------------+------+-+
|ISP A | .............. | ISP B|
+------+ +------+
Figure 2: ISP-centric ALTO service deployment example
</artwork>
</figure>
<t>2. The application provider itself, a trusted third party or a user
community: acting on the application level and spanning different
networks. They run distributed algorithms to measure the overall
network through some mechanisms and provide an ALTO service to
numerous application clients. However in this case, the application
level service may not know the policy of network operators, so with
high probability it will also cause suboptimal result for the network
operator while benefitting the applications.</t>
<figure>
<artwork>
+---------+
+-----------+ |ALTO |
|ALTO Server| |Service |
+-----------+ |Discovery|
^ ^ +---------+
+------+ | | +------+ o o
+|------|--+---------|------|------|-+ o o
|| | P2P Appication A | | |ooo o
++------+------------+------+------+-+ o
| | | | | o
++------+------------|------+------+-+ o
|| | P2P Applcation B | | |oooooooo
++------+-------------------+------+-+
|ISP A | .............. | ISP B|
+------+ +------+
Figure 3: Application-centric ALTO service deployment example
</artwork>
</figure>
</section>
<section title="Cross-domain vs. Localized ALTO Server Discovery">
<t>For cross domain scenarios, the ALTO service includes the ALTO
servers provided by p2p application community as well as the ALTO
servers provided by a third party on behalf of multiple cooperating
network operators.</t>
<t>So there may be several ALTO servers distributed in different
operator's networks.</t>
<t>Each operator may provide the ALTO service using their own ALTO
servers. Each network operator may have its own traffic optimization
policy based on his network topology, however it may not know other
network operator's policies, nor be clear of other network operator's
topologies (e.g. topology hiding). Each of the ALTO servers may have a
FQDN.</t>
<t>The ALTO client (e.g. the Tracker) must be able to discover and
choose the ALTO server that has the information that is specific to
those clients located within that network.</t>
<t>In localized discovery deployments one or several ALTO servers
provide the service only to clients in their own network or autonomous
system.</t>
</section>
</section>
<section anchor="sec_scenarios" title="ALTO Service Discovery Scenarios">
<section title="Discovery Metrics">
<section title="Discovery Clients">
<t>The ALTO Client can be the Peer in the end-user host or an
external entity like a Super-peer or Resource Directory (aka
Tracker) on behalf of the Peer <xref
target="I-D.ietf-alto-problem-statement"></xref>. If a Super-Peer or
Tracker acts as an ALTO Client it needs to know and select the
suitable ALTO Service for the Peer being served.</t>
<t>In a hybrid model the location of the ALTO Server could be
communicated from the Peer to the Super-Peer using the application
protocol. It could also be discovered by the Super-Peer from other
Peer information received implicitly (like the Peer public IP
address) or received explicitly.</t>
<t>There could be scenarios where only the Peer (and not the
Super-Peer/Tracker) is able to access the ALTO Service, for example
if the ALTO Server is located in a private network.</t>
</section>
<section title="Service Location ">
<t>The ALTO service could be provided in a distributed and
cooperative fashion by the Peers in an overlay, or it can be
provided by a centralized entity (the ALTO Server) for a given
scope. In the former case, a DHT-style key-based routing algorithm
could be used to locate the peers with the target network
information in this type of distributed environment. For the latter
case, where a centralized ALTO Server is implicitly or explicitly
assigned to a specific network scope, an out-of-band discovery
mechanism is often required.</t>
<t>All current ALTO solution proposals, ([Infoexp], <xref
target="I-D.wang-alto-p4p-specification"></xref>), fall into the
second category.</t>
<t>The ALTO Server for a Peer could be in the same Local Area
Network (LAN), within the same ISP Network but not on the same LAN,
or in the Global Internet outside the ISP Network. Different network
scopes place different constraints on the discovery mechanisms.
Multicast discovery generally works within a single LAN only,
whereas DNS-based or DHCP-based discovery can span multiple subnets
within a single ISP or a single network administrative domain.
Internet scope discovery usually requires cross-domain indexing or
directory services. Note that peers participating in a single P2P
application may reside on the same or different ISP networks.
Scenarios like this may require hybrid discovery solutions that can
adapt to multiple network scopes at the same time. The discovery
mechanisms listed in this document should take into account possible
limitations of the ALTO service deployment in those network
scopes.</t>
</section>
<section title="Layering Perspective">
<t>The discovery process takes place before the first access to the
ALTO server. This discovery process could be done at host network
initialization time, at application initialization time or just
before the first ALTO query is sent.</t>
</section>
</section>
<section title="Discovery Scenarios">
<t>The ALTO service discovery scenarios are classified into two types:
one is the ALTO server providing service to the overall network, and
the other is where the ALTO server is providing service to the local
network.</t>
<section title="Local ALTO service discovery by end terminals">
<t>In p2p applications without a tracker like DHTs and other
conventional client/server applications, an end device needs to
discover the local ALTO server by itself.</t>
<t>After the discovery of an ALTO server, the p2p client can get
guidance from the ALTO server directly or through its application
tracker.</t>
<figure>
<artwork>
+---------------+
| ALTO Server |
+---------------+
^ ^ +-----------+
| | | ALTO |
| +---+---+ | Service |
| |tracker| | Discovery |
| +-------+ +---------+-+
| | o o
+------------+--+ | o o
|P2P Application|ooooo|oooooooooooo o
| Client A | | o
+---------------+ | o
| o
+--+-------------+ o
| P2P Application|oooooo
| Client B |
+----------------+
Figure 4: Local ALTO service discovery by end terminals (Example)
</artwork>
</figure>
</section>
<section title="Local ALTO service discovery by application trackers">
<t>Some p2p applications have trackers, and these applications don't
need to have their clients looking for the ALTO server guidance.
Trackers query the ALTO servers for guidance, and then return the
final ranked result to the application clients. However, application
clients are distributed among different network operators and
autonomous systems. Trackers must find different ALTO servers for
the clients located in different network operators or autonomous
systems.</t>
<t>Figure 5 shows an example for a tracker's ALTO server discovery.
For client 1, the tracker has not cached yet the mapping between
client 1's network operator and its ALTO server address, so it
queries the DNS server for the ALTO server address in that
operator's domain. And then the tracker interacts with the ALTO
server on behalf of client 1, finally, the ranked list is sent back
to client 1. For client 2, the tracker has cached the mapping
between client 2's network operator and its ALTO server address, so
it does not need to query the DNS for the address of ALTO server
2.</t>
<figure>
<artwork>
+-------------+ +-------------+
| ALTO Server1| | ALTO Server2|
+-------------+ +-------------+
^ | ^ |
3| 4| b| |c
| | | |
v /----------+-\ v
+---+ ////// \\\\\
| | ||| |||
| |<--->| |
|DNS| 2 | Application Tracker |
| | ||| |||
| | \\\\\\ /////
+---+ ^ | \------------/ |
| |5 ^ |d
1| | a| |
| v | v
+-+---------+ +---+--------+
|Application| |Application |
|client1 | |client2 |
+-----------+ +------------+
Figure 5: Local ALTO service discovery by application trackers (Example)
</artwork>
</figure>
</section>
</section>
</section>
<section anchor="sec_mechanisms" title="ALTO Service Discovery Mechanisms">
<t>One ALTO client should use one or several of the introduced discovery
mechanisms according to its application scenario until it finally finds
an appropriate ALTO server.</t>
<t>The following issues should be considered when designing the ALTO
service discovery mechanism.<list>
<t>Load Balance: When more than one ALTO server provide identical
service for the same area, we must find a mechanism to balance the
processing load between the ALTO servers;</t>
<t>Well known port: If ALTO server provides service through a well
known port, then the discovery mechanism only needs to discover the
IP address of an ALTO server that can provide service for a client,
otherwise, the discovery mechanism must discover both IP address and
port number through which the ALTO server provides the service.<list>
<t>Note:It will depend on the ALTO protocol whether a well know
port is used for the ALTO server. If there is no well known port
for the ALTO server, we need to discover the port information
with the discovery process.</t>
</list></t>
<t>IP address change: The IP address of the ALTO server may change
in some circumstances. The ALTO service discovery mechanism must be
well adaptable to this case when necessary.</t>
<t>Mobile Scenarios: When the end terminals are mobile equipments,
the data traffic may route via a roaming client's home agent's
router to the client, or route to the client directly. Which ALTO
server to choose should depend on the routing optimization mode
adopted for mobility. If the data traffic routes via the client's
home agent, it should choose the ALTO server that serves its home
area network, otherwise, it should choose the ALTO server that
serves its current network.</t>
</list></t>
<section anchor="dns-alto-disc"
title="ALTO service discovery using Domain Name System (DNS)"
toc="default">
<t>DNS is widely used on the Internet to discover the server address
for applications. ALTO service is a conventional client/server mode
service, which can use DNS lookup for its service discovery.</t>
<t>NAPTR <xref target="RFC2915"></xref> and SRV <xref
target="RFC2782"></xref> DNS resource records are appropriate to
provide service discovery mechanisms. The concrete application of
these resource records depends on the final ALTO requests/response
protocol. The use of NAPTR or SRV records is a trade-off between
flexibility and simplicity. S-NAPTR <xref target="RFC3958"></xref> and
U-NAPTR <xref target="RFC4848"></xref> mechanisms provide a Dynamic
Delegation Discovery System (DDDS) Application to map domain name,
service name and protocol name to a target host and port or to a
target URI. SRV records provide a mechanism to map domain name,
service name and transport protocol name to a target host and port.
The use of a NAPTR or SRV solution is open to discussion and depends
on the requirements of the ALTO protocol. Next section will asume the
use use of SRV records in the next sections are based on SRV.</t>
<section title="DNS-based ALTO discovery">
<t>Figure 6. shows a general DNS ALTO server discovery mechanism. A
server must register its SRV resource record with a well known
service name (e.g. _ALTO._TCP.example.com) in the DNS system. The
service name in this document refers to the name used for DNS SRV
query, which includes the service label, protocol name (TCP or UDP)
and domain name. Any ALTO client that wants to get the IP address
and port of the ALTO server sends a DNS SRV query to the DNS server
in that domain . <figure>
<artwork align="left"
name="Figure 6: DNS query for well known ALTO servers">
+-------------------------------------+
| DNS |
+-------------------------------------+
^ ^
| |
| |
|DNS configuration |DNS queries
|or dynamic update |and responses
| |
v v
+-------------+ +-------------+
| | | ALTO |
| ALTO Server | | Discovery |
| | | Client |
+-------------+ +-------------+
Figure 6: DNS query for well known ALTO servers
</artwork>
</figure></t>
</section>
<section title="Determine Service Name of Local ALTO servers">
<t>An ALTO discovery client must know its ALTO service name for it
before sending a query to the DNS system. Some ALTO servers may
provide service to the overall network, they may have well-known
service name. But in most cases, one ALTO server will only provide
service to its own local access network or autonomous system. There
will be multiple ALTO servers in the overall network. An ALTO
discovery client needs to find the service name of its local ALTO
server.</t>
<section anchor="DHCP_ACCESS_DOMAIN_NAME"
title="Using DHCP option for access domain name">
<t>There are DHCP options (OPTION_V4_ACCESS_DOMAIN and
OPTION_V6_ACCESS_DOMAIN) proposed in <xref
target="I-D.ietf-geopriv-lis-discovery"></xref> to discover the
local access domain names. The retrieved access domain name can be
used to form a SRV name by prefixing the ALTO service label to the
access domain name. If it failed with the SRV lookup with this
service name, then it will remove one tag from the left hand of
the access domain name and prefix the ALTO service label to form a
new SRV name. It will iterate the process until it succeeds in
getting an ATLO server information or failed.</t>
<t>It should be noticed that there are many residential gateways
(RG) which can act as DHCP servers themselves. RG becomes a
hindrance between the end terminals and the ALTO service
provider's DHCP server if we use DHCP. It should not depend on the
update of all these RGs to support this new DHCP Option for ALTO
server discovery. A <xref target="I-D.ietf-dhc-container-opt">DHCP
Container Option</xref> for server configuration should be used
here. With the Container Option, the DHCP server for the consumer
domain (e.g. RGs) can just pass the server configuration to the
end terminals without explicit knowledge of the DHCP options
contained in the Container. The DHCP Option for the access domain
name could be contained in the Container Option.</t>
</section>
<section title="Use IANA Database">
<t>The service name of a client's local ALTO server could be
formed by adding the service and protocol label before its domain
information. IANA and its subsidiary organizations (e.g. APNIC)
database can be used to lookup the physical domain of a client
through its public IP address, i.e. which network operator and/or
autonomous system the client belongs to. The <xref
target="WWW.WHOIS">WHOIS service</xref> on the Internet is also
available for this purpose. This mechanism requires ISPs assign
the domain names to their ALTO servers according to the AS and ISP
information (e.g. they have a rule to format the domain name,
AS.ISP.COM), then you can rebuid the domain name with the
information retrieved from WHOIS. Otherwise, you can't.</t>
<t>However, the mapping information may be changed due to the
business deals and network adjustment. For example, an ISP could
sell some part of its network (include all equipments, IP
addresses, AS number, and so on) to another ISP, and the ISP does
not have the responsibility to notify the IANA, and then the
information in the IANA database is wrong.</t>
</section>
<section title="Reverse DNS lookup">
<t>BEP 22 [BEP-22] framework uses reverse DNS lookup to determine
the domain name of a client through its public address. And then
use service label and the domain name to lookup the local server
in DNS. The following limitations should be considered when use
this mechanism.</t>
<t>(1) This method assumes that the access network provider also
provides the reverse DNS record and they control the domain that
is indicated in the "PTR" record. (In most cases it is true, but
not always)</t>
<t>(2) Furthermore, this method might not apply where a host is
given a domain name that is different from the domain name of the
access network.</t>
<t>(3) In case of NAT and a public ALTO server, it requires the
ALTO client to know its public IP address.</t>
<t>The advantage is that it doesn't require any
update/configuration/change in the DHCP servers of any residential
gateway.</t>
</section>
</section>
</section>
<section title="DHCP">
<t>There are other ways using DHCP to locate an ALTO server. One
suggestion is to use DHCP to obtain the ALTO server IP address and
port information directly. New DHCP options are needed for this
purpose. The residential gateways consideration for DHCP option must
be considered as described in <xref
target="DHCP_ACCESS_DOMAIN_NAME">.</xref></t>
<t>With this mechanism, the DHCP server needs to support load balance
if there are more than one ALTO servers for this access domain. The
maintenance is costly when the address of ALTO server changes.</t>
</section>
<section title="XRD">
<t>XRD is described in [XRD-1.0]. In order to begin the XRD discovery
you need the URL (or XRI) of the resource you want to discover
links/services related to. In other XRD use cases like OpenId or
OpenSocial, it is clear that you know that URL (the OpenId url of the
user, or the url of the OS container). But in case of ALTO Server
Discovery, the obtainment of this initial URL also needs to use some
discovery framework.</t>
</section>
<section title="Provisioning">
<t>A network operator can simply provide a configuration file that
contains the ALTO server address for its clients, provided that there
are only one or a few ALTO servers which provide identical service for
its network. An application can also provide such a configuration file
containing the ALTO server address if an existing ALTO server provides
identical service to the overall network.</t>
</section>
<section title="Manual Configuration">
<t>Manual configuration of the ALTO service location(s) could work in
a single ISP network scope, but is not scalable when multiple ISPs or
cross-domain ALTO services are required. P2P applications often
connect peers from ISPs that they may not have contacted before, and
manual configuration will not work without any prior knowledge of the
ALTO servers.</t>
</section>
<section title="Multicast and broadcast">
<t>Multicast or broadcast MAY be used in some scenarios for ALTO
discovery.</t>
<t>IP-multicast-based discovery generally works in two ways:</t>
<t>1. Clients send out multicast discovery requests and listen for
responses (usually unicast) from available servers or service
providers.</t>
<t>2. Servers or service providers send out multicast announcements
when they become available or periodically, and clients waits for the
next available multicast announcement to identify the servers or
service providers.</t>
<t>The on-demand requests and periodic announcements are not mutually
exclusive. An implementation can choose to utilize both
simultaneously. The configuration effort of multicast discovery is
fairly straightforward, only the multicast address and port are
needed. Service types and additional information are often encoded in
the requests or announcements messages, enabling the same multicast
channel to support discovery of different resources or services. There
are two main constraints of multicast-based discovery - scopes and
flooding messages. Routers disable multicast forwarding by default,
making it practically a single-subnet solution. Some forms of
discovery proxies are needed to extend the scope of multicast
discovery to multiple subnets. The second issue is the flooding of
multicast messages to all hosts on the same subnet. The total
bandwidth consumed by multicast depends on the arrival rate the client
application requests, and/or the frequency of the service
announcements. Older generations of 802.11-based wireless access
points often slow down the transmission of multicast messages or
generally have a higher packet loss rate for those, causing some
multicast discovery implementation to automatically re-send multicast
requests or announcements by default. This mitigation further
increases the amount of flooding messages on the LAN. Examples of
multicast-based discovery include [I-D.cheshire-dnsext-multicastdns],
[I-D.cai-ssdp-v1], [WSD], SLP [RFC2165], and LLMNR [RFC4795].</t>
</section>
<section title="Caching">
<t>Once a client has located an ALTO server for the first time, it can
cache it for use as future ALTO server. There are implications in case
of mobility of devices.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>As this document mainly proposes to use DNS and DHCP for ALTO service
discovery, it will depend on the DHCP security and DNS security for this
service discovery.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The service label for the ALTO service will depend on the final
protocol name for application-layer traffic optimization(TBD).</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to give special thanks to Roni Even for his
continuous contribution to this document.</t>
<t>We would also like to thank the following experts for their review
and valuable comments. <list>
<t>Y. Richard Yang</t>
<t>Xingfeng Jiang</t>
<t>Jay Gu</t>
<t>Ning Zong</t>
<t>(To be added)</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2782;
&RFC3958;
&RFC4848;
&RFC2915;
&I-D.ietf-alto-problem-statement;
&I-D.ietf-geopriv-lis-discovery;
&I-D.ietf-dhc-container-opt;
</references>
<references title="Informative References">
&RFC2629;
&RFC3552;
&RFC2165;
&RFC4795;
&I-D.cheshire-dnsext-multicastdns;
&I-D.wang-alto-p4p-specification;
&I-D.narten-iana-considerations-rfc2434bis;
<reference anchor="I-D.cai-ssdp-v1" target="draft-cai-ssdp-v1-03">
<front>
<title>Simple Service Discovery Protocol/1.0 Operating without an
Arbiter</title>
<author initials="Y" surname="Goland">
<organization></organization>
</author>
<author initials="T" surname="Cai">
<organization></organization>
</author>
<author initials="P" surname="Leach">
<organization></organization>
</author>
<author initials="Y" surname="Gu">
<organization></organization>
</author>
<author initials="S" surname="Albright">
<organization></organization>
</author>
<date month="October" year="1999" />
</front>
</reference>
<reference anchor="WWW.WHOIS">
<front>
<title>http://www.whois.net</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="BEP-22"
target="http://bittorrent.org/beps/bep_0022.html">
<front>
<title>BitTorrent Local Tracker Discovery Protocol</title>
<author initials="D" surname="Harrison">
<organization></organization>
</author>
<author initials="S" surname="Shalunov">
<organization></organization>
</author>
<author initials="G" surname="Hazel">
<organization></organization>
</author>
<date month="October" year="2008" />
</front>
</reference>
<reference anchor="XEP-1.0"
target="http://www.oasis-open.org/committees/download.php/32686/xrd-1.0-wd01.html">
<front>
<title>Extensible Resource Descriptor (XRD) Version 1.0</title>
<author initials="E" surname="Hammer-Lahav">
<organization></organization>
</author>
<date month="May" year="2009" />
</front>
</reference>
<reference anchor="WSD"
target="http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf">
<front>
<title>Web Services Dynamic Discovery (WS-Discovery)</title>
<author initials="J" surname="Beatty">
<organization></organization>
</author>
<date month="April" year="2005" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:30 |