draft-ietf-alto-xdom-disc-01.txt   draft-ietf-alto-xdom-disc-02.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: January 4, 2018 H-DA Expires: September 6, 2018 H-DA
July 3, 2017 March 5, 2018
Application Layer Traffic Optimization (ALTO) Cross-Domain Server Application Layer Traffic Optimization (ALTO) Cross-Domain Server
Discovery Discovery
draft-ietf-alto-xdom-disc-01 draft-ietf-alto-xdom-disc-02
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 that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource. ALTO is realized by a client-server protocol. Before an resource. ALTO is realized by a client-server protocol. Before an
ALTO client can ask for guidance it needs to discover one or more ALTO client can ask for guidance it needs to discover one or more
ALTO servers that can provide suitable guidance. ALTO servers that can provide suitable guidance.
In some deployment scenarios, in particular if the information about In some deployment scenarios, in particular if the information about
the network topology is partitioned and distributed over several ALTO the network topology is partitioned and distributed over several ALTO
servers, it may be needed to discover an ALTO server outside of the servers, it may be needed to discover an ALTO server outside of the
own network domain, in order to get appropriate guidance. This own network domain, in order to get appropriate guidance. This
document details applicable scenarios, itemizes requirements, and document details applicable scenarios, itemizes requirements, and
specifies a procedure for ALTO cross-domain server discovery. specifies a procedure for ALTO cross-domain server discovery.
Technically, the algorithm specified in this document takes one Technically, the procedure specified in this document takes one
IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO: IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO:
http" or "ALTO:https") as parameters. It performs DNS lookups (for http" or "ALTO:https") as parameters. It performs DNS lookups (for
NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and
returns one or more URI(s) of information resources related to that returns one or more URI(s) of information resources related to that
IP address or prefix. IP address or prefix.
Terminology and Requirements Language Terminology and Requirements Language
This document makes use of the ALTO terminology defined in RFC 5693 This document makes use of the ALTO terminology defined in RFC 5693
[RFC5693]. [RFC5693].
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Multiple Information Sources and Partitioned Knowledge . . 4 2. ALTO Cross-Domain Server Discovery Procedure Specification . . 5
1.2. The Need for Cross-Domain ALTO Server Discovery . . . . . 5 2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 6 2.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 6
1.4. ALTO Requirements . . . . . . . . . . . . . . . . . . . . 6 2.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 6
1.5. Document History . . . . . . . . . . . . . . . . . . . . . 7 2.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 7
1.6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Using the ALTO Protocol with ALTO Cross-Domain Server
2. ALTO Cross-Domain Server Discovery Procedure Specification . . 8 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Network and Cost Map Service . . . . . . . . . . . . . . . 8
2.2. Basic Principle . . . . . . . . . . . . . . . . . . . . . 8 3.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 9
2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 8 3.3. Endpoint Property Service . . . . . . . . . . . . . . . . 9
2.4. Step 2: Add Shortened Domain Names . . . . . . . . . . . . 10 3.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 10
2.5. Step 3: DNS lookups . . . . . . . . . . . . . . . . . . . 11 4. Implementation, Deployment, and Operational Considerations . . 12
3. Using the ALTO Protocol with ALTO Cross-Domain Server 4.1. Considerations for ALTO Clients . . . . . . . . . . . . . 12
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Deployment Considerations for Network Operators . . . . . 13
3.1. Network and Cost Map Service . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
3.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 13 5.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 14
3.3. Endpoint Property Service . . . . . . . . . . . . . . . . 13 5.2. Availability of the ALTO Server Discovery Procedure . . . 15
3.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 14 5.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 16
4. Implementation, Deployment, and Operational Considerations . . 16 5.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 16
4.1. Considerations for ALTO Clients . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4.2. Deployment Considerations for Network Operators . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
5.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
5.2. Availability of the ALTO Server Discovery Procedure . . . 19 Appendix A. Multiple Information Sources and Partitioned
5.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 20 Knowledge . . . . . . . . . . . . . . . . . . . . . . 20
5.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 20 A.1. Classification of Solution Approaches . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 A.2. Discussion of Solution Approaches . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . . 22 A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 22
Appendix A. Requirements for ALTO Cross-Domain Server Appendix B. Requirements for ALTO Cross-Domain Server
Discovery . . . . . . . . . . . . . . . . . . . . . . 24 Discovery . . . . . . . . . . . . . . . . . . . . . . 23
A.1. Discovery Client Application Programming Interface . . . . 24 B.1. Discovery Client Application Programming Interface . . . . 23
A.2. Data Storage and Authority Requirements . . . . . . . . . 24 B.2. Data Storage and Authority Requirements . . . . . . . . . 23
A.3. Cross-Domain Operations Requirements . . . . . . . . . . . 24 B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 23
A.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 25 B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 24
A.5. Further Requirements . . . . . . . . . . . . . . . . . . . 25 B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 24
Appendix B. ALTO and Tracker-based Peer-to-Peer Applications . . 26 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 25
Appendix C. Contributors List and Acknowledgments . . . . . . . . 31 Appendix D. Contributors List and Acknowledgments . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
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 that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource [RFC5693]. ALTO is realized by an HTTP-based client-server resource [RFC5693]. ALTO is realized by an HTTP-based client-server
protocol [RFC7285], which can be used in various deployment scenarios protocol [RFC7285], which can be used in various scenarios [RFC7971].
[RFC7971].
1.1. Multiple Information Sources and Partitioned Knowledge
The ALTO base protocol document [RFC7285] specifies the communication The ALTO base protocol document [RFC7285] specifies the communication
between an ALTO client and a single ALTO server. It is implicitly between an ALTO client and one ALTO server. In principle, the client
assumed that this server can answer any query, possibly with some may send any ALTO query. For example, it might ask for the routing
kind of default value if no exact data is known. No special cost between any two IP addresses, or it might request network and
provisions were made for the case that the ALTO information cost maps for the whole network, which might be the worldwide
originates from multiple sources, which are possibly under the Internet. It is assumed that the server can answer any query,
control of different administrative entities (e.g., different ISPs) possibly with some kind of default value if no exact data is known.
or that the overall ALTO information is partitioned and stored on
several ALTO servers.
1.1.1. Classification of Solution Approaches
Various protocol extensions and other solutions have been proposed to
deal with multiple information sources and partitioned knowledge.
They can be classified as follows:
1 Ensure that all ALTO servers have the same knowlegde
1.1 Ensure data replication and synchronization within the
provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]).
1.2 Use an Inter-ALTO-server data replication protocol. Possibly,
the ALTO protocol itself - maybe with some extensions - could be
used for that purpose; however, this has not been studied in
detail so far.
2 Accept that different ALTO servers (possibly operated by
different organizations, e.g., ISPs) do not have the same
knowledge
2.1 Allow ALTO clients to send arbitrary queries to any ALTO server
(e.g. the one discovered using [RFC7286]). If this server
cannot answer the query itself, it will fetch the data on behalf
of the client, using the ALTO protocol or a to-be-defined inter-
ALTO-server request forwarding protocol.
2.2 Allow ALTO clients to send arbitrary queries to any ALTO server
(e.g. the one discovered using [RFC7286]). If this server
cannot answer the query itself, it will redirect the client to
the "right" ALTO server that has the desired information, using
a small to-be-defined extension of the ALTO protocol.
2.3 ALTO clients need to use some kind of "search engine" that
indexes ALTO servers and redirects and/or gives cached results.
2.4 ALTO clients need to use a new discovery mechanism to discover
the ALTO server that has the desired information and contact it
directly.
1.1.2. Discussion of Solution Approaches
The provisioning or initialization protocol for ALTO servers (cf. RFC
5693, Fig 1 [RFC5693]) is currently not standardized. It was a
conscious decision not to include this in the scope of the IETF ALTO
working group. The reason is that there are many different kinds of
information sources. This implementation specific protocol will
adapt them to the ALTO server, which offers a standardized protocol
to the ALTO clients. However, adding the task of synchronization
between ALTO servers to this protocol (i.e., approach 1.1) would
overload this protocol with a second functionality that requires
standardization for seamless multi-domain operation.
For the 1.? solution approaches, in addition to general technical
feasibility and issues like overhead and caching efficiency, another
aspect to consider is legal liability. Operator "A" might prefer not
to publish information about nodes in or paths between the networks
of operators "B" and "C" through A's ALTO server, even if A knew that
information. This is not only a question of map size and processing
load on A's ALTO server. Operator A could also face legal liability
issues if that information had a bad impact on the traffic
engineering between B's and C's networks, or on their business
models.
No specific actions to build a "search engine" based solution
(approach 2.3) are currently known and it is unclear what could be
the incentives to operate such an engine. Therefore, this approach
is not considered in the remainder of this document.
1.2. The Need for Cross-Domain ALTO Server Discovery
Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the
specification of an ALTO protocol extension or a new protocol that
runs between ALTO servers. A large-scale, maybe Internet-wide,
multi-domain deployment would also need mechanisms by which an ALTO
server could discover other ALTO servers, learn which information is
available where, and ideally also who is authorized to publish
information related to a given part of the network. Approach 2.4
needs the same mechanisms, except that they are used on the client-
side instead of the server-side.
It is sometimes questioned whether there is a need for a solution
that allows clients to ask arbitrary queries, even if the ALTO
information is partitioned and stored on many ALTO servers. The main
argument is, that clients are supposed to optimize the traffic from
and to themselves, and that the information needed for that is most
likely stored on a "nearby" ALTO server, i.e., the one that can be
discovered using [RFC7286]. However, there are scenarios where the
ALTO client is not co-located with an endpoint of the to-be-optimized
data transmission. Instead, the ALTO client is located at a third
party, which takes part in the application signaling, e.g., a so-
called "tracker" in a peer-to-peer application. One such scenario,
where it is advantageous to place the ALTO client not at an endpoint
of the user data transmission, is analyzed in Appendix B.
1.3. Solution Approach
Several solution approaches for cross-domain ALTO server discovery
have been evaluated, using the criteria documented in Appendix A.
One of them was to use the ALTO protocol itself for the exchange of
information availability [I-D.kiesel-alto-alto4alto]. However, the
drawback of that approach is that a new registration administration
authority would have to be established.
This document specifies a DNS-based procedure for cross-domain ALTO
server discovery, which was inspired by "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The
primary goal is that this procedure can be used on the client-side
(i.e., approach 2.4), but together with new protocols or protocol
extensions it could also be used to implement the other solution
approaches itemized above.
1.4. ALTO Requirements
During the design phase of the overall ALTO solution, two different
server discovery scenarios have been identified and documented in the
ALTO requirements document [RFC6708]. The first scenario, documented
in Req. AR-32, can be supported using the discovery mechanisms
specified in [RFC7286]. An alternative approach, based on IP anycast
[I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This
document, in contrast, tries to address Req. AR-33.
1.5. Document History
This document is a direct successor of [I-D.kiesel-alto-3pdisc] and No special provisions were made for deployment scenarios with
[I-D.kist-alto-3pdisc]. The scenario and mechanisms described here multiple ALTO servers, with some servers having more accurate
and in these documents have been referred to as "third-party server information about some parts of the network topology while others
discovery" in the past. However, to avoid naming ambiguities with a having better information about other parts of the network
completely different scenario, it has been renamed to "ALTO Cross- ("partitioned knowledge"). Various ALTO use cases have been studied
Domain Server Discovery". in the context of such scenarios. In some cases, one cannot assume
that a topologically nearby ALTO server (e.g., a server discovered
with the procedure specified in [RFC7286]) will always provide useful
information to the client. One such scenario is detailed in
Appendix C. Several solution approaches, such as redirecting a
client to a server that has more accurate information or forwarding
the request to it on behalf of the client, have been proposed and
analyzed (see Appendix A), but none has been specified so far.
1.6. Feedback This document specifies an ALTO server discovery procedure that runs
on the client side. An ALTO client, which wants to send a query
related to a specific IP address or prefix X, may use the procedure
specified in Section 2 with X as a parameter, in order to perform DNS
lookups and find an ALTO server that can provide a competent answer.
The wording "related to" in the previous sentence is intentionally
kept somewhat vague, as the exact semantics depends on the ALTO
service to be used; see Section 3 for details.
Comments and discussions about this document should be directed to Those who are in control of the "reverse DNS" (i.e., the
the ALTO working group: alto@ietf.org. corresponding subdomain of in-addr.arpa. or ip6.arpa.) for a given IP
address or prefix - typically an Internet Service Provider (ISP), a
corporate IT department, or a university's computing center - may add
resource records to the DNS that point to a suitable ALTO server. In
many cases, it may be an ALTO server run by that ISP or IT
department, as they naturally have good insight into routing costs
from and to their networks. However, they may also refer to an ALTO
server run by a different organization, e.g., their upstream ISP.
2. ALTO Cross-Domain Server Discovery Procedure Specification 2. ALTO Cross-Domain Server Discovery Procedure Specification
2.1. Interface This procedure was inspired by [RFC7216] and re-uses parts of
The algorithm specified in this document takes one IP address or
prefix "X" and a U-NAPTR [RFC4848] Service Parameter (i.e., "ALTO:
http" or "ALTO:https") as parameters. It performs DNS lookups and
returns one or more URI(s) of information resources related to that
IP address or prefix, in particular the URI(s) of one or more
Information Resource Directory (IRD, see Section 9 of [RFC7285]).
For the remainder of the document, we use the notation:
IRD_URIS_X := XDOMDISC(X,"ALTO:https")
2.2. Basic Principle
This algorithm closely follows [RFC7216] and re-uses parts of
[RFC7286]. [RFC7286].
The algorithm sequentially tries two different lookup strategies. The procedure sequentially tries two different lookup strategies.
First, an ALTO-specific U-NAPTR record is searched in the "reverse First, an ALTO-specific U-NAPTR record is searched in the "reverse
tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
corresponding to the given IP address or prefix. If this lookup does corresponding to the given IP address or prefix. If this lookup does
not yield a usable result, further lookups with truncated domain not yield a usable result, further lookups with truncated domain
names may be tried. The goal is to allow deployment scenarios that names may be tried. The goal is to allow deployment scenarios that
require fine-grained discovery on a per-IP basis, as well as large- require fine-grained discovery on a per-IP basis, as well as large-
scale scenarios where discovery is to be enabled for a large number scale scenarios where discovery is to be enabled for a large number
of IP addresses with a small number of additional DNS resource of IP addresses with a small number of additional DNS resource
records. records.
2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup 2.1. Interface
This task takes the IP address or prefix "X", with which the
procedure was called, and constructs a domain name "R", which is used
for DNS lookups in subsequent steps. We need to distinguish four
cases.
2.3.1. IPv4 address
If the parameter "X" is a single IPv4 address, the domain name is
constructed according to the rules specified in Section 3.5 of
[RFC1035] and it is rooted in the special domain "IN-ADDR.ARPA.".
One example is:
X = 198.51.100.3 yields R := "3.100.51.198.in-addr.arpa."
2.3.2. IPv4 prefix
If the parameter "X" is an IPv4 prefix (i.e., an address block in
CIDR [RFC4632] notation), the domain name is at first constructed as
described in section Section 2.3.1. Then,
1. if the prefix length is 32 bits, no further steps are performed
(i.e., the action is equivalent to Section 2.3.1),
2. if the prefix length is 24 to 31 bits, the domain name is
shortened by one label (i.e., purge the first dot from the left
and everything left of it),
3. if the prefix length is 23 bits or less, the domain name is
shortened by two labels (i.e., purge the second dot from the left
and everything left of it).
Examples are:
X = 198.51.100.3/32 yields R := "3.100.51.198.in-addr.arpa."
X = 198.51.100.40/29 yields R := "100.51.198.in-addr.arpa."
X = 198.51.100.128/25 yields R := "100.51.198.in-addr.arpa."
X = 198.51.100.0/24 yields R := "100.51.198.in-addr.arpa."
X = 198.51.100.0/22 yields R := "51.198.in-addr.arpa."
2.3.3. IPv6 address
If the parameter "X" is a single IPv6 address, the domain name is
constructed according to the rules specified in Section 2.5 of
[RFC3596] and the special domain "IP6.ARPA." is used. One example is
(note: a line break was added):
X = 2001:0DB8::20 yields
R := "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.ip6.arpa."
2.3.4. IPv6 prefix
If the parameter "X" is an IPv6 prefix (i.e., an address block in
CIDR [RFC4632] notation), the domain name is at first constructed as
described in section Section 2.3.3. Then,
1. if the prefix length is 128 bits, no further steps are performed
(i.e., the action is equivalent to Section 2.3.3),
2. if the prefix length is 64 bits, the domain name is shortened by
16 labels (i.e., purge the 16th dot from the left and everything
left of it),
3. if the prefix length is 63 to 56 bits, the domain name is
shortened by 18 labels,
4. if the prefix length is 55 to 48 bits, the domain name is The procedure specified in this document takes one IP address or
shortened by 20 labels, prefix X and a U-NAPTR Service Parameter as parameters.
5. if the prefix length is 47 bits or less, the domain name is The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR
shortened by 24 labels. notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for
IPv6). In both cases, it consists of an IP address A and a prefix
length L. For IPv4, it holds: 0 <= L <= 32 and for IPv6, it holds: 0
<= L <= 128.
Examples are: For example, for X=198.51.100.0/24, we get A=198.51.100.0 and L=24.
Similarly, for X=2001:0DB8::20/128, we get A=2001:0DB8::20 and L=128.
X = 2001:0DB8::/64 yields The procedure SHOULD always be called with the U-NAPTR Service
R := "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa." Parameter [RFC4848] set to "ALTO:https". However, other parameter
values MAY be used in some scenarios, e.g., "ALTO:http" to request
unencrypted transmission for debugging purposes, or other application
protocol or service tags if applicable.
X = 2001:0DB8::/48 yields The procedure performs DNS lookups and returns one or more URI(s) of
R := "0.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa." information resources related to that IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD,
see Section 9 of [RFC7285]).
2.4. Step 2: Add Shortened Domain Names For the remainder of the document, we use the notation:
IRD_URIS_X := XDOMDISC(X,"ALTO:https")
This task creates a list of several additional domain names, based on 2.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
the domain name yielded in Step 1.
1. For an IPv4 address, the domain name from Step 1 SHOULD be If A is an IPv4 address, a domain name R32 is constructed according
shortened successively by one and two labels (i.e., purge the to the rules specified in Section 3.5 of [RFC1035] and it is rooted
first or second dot from the left and everything left of it, in the special domain "IN-ADDR.ARPA.".
respectively), and the results being added to the list. This
corresponds to a search on a /24 or /16 network prefix.
2. For an IPv4 prefix, if the domain name has already been shortened For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.".
by one label as per section Section 2.3.2, it SHOULD be shortened
by one more label and the result being added to the list. If the
domain name has already been shortened by two labels, no further
shortening should occur.
3. For an IPv6 address, the domain name from Step 1 SHOULD be If A is an IPv6 address, the domain name R128 is constructed
shortened successively by 16, 18, 20, and 24 labels, and the according to the rules specified in Section 2.5 of [RFC3596] and the
results being added to the list. This corresponds to a search on special domain "IP6.ARPA." is used.
a /64, /56, /48, or /32 network prefix.
4. For an IPv6 prefix, the domain name from Step 1 SHOULD be For example (note: a line break was added after the second line),
shortened successively by 16, 18, 20, and 24 labels, and the A = 2001:0DB8::20 yields
results being added to the list. However, if the domain name has R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
already been shortened in Step 1, Step 2 should not add domain 1.0.0.2.IP6.ARPA."
names to the list that are longer than the result of Step 1.
This list is intended to provide network operators with a degree of 2.3. Step 2: Prepare Shortened Domain Names
flexibility in where discovery-related resource records can be placed
without significantly increasing the number of DNS names that are
searched. This does not attach any other significance to these
specific zone cuts or create a classful addressing hierarchy based on
the reverse DNS tree.
For example, the IPv4 address "192.0.2.75" could result in a list of For this step, an auxiliary function "skip" is defined as follows:
domain names (with the result from Step 1 put in the first position): skip(str,n) will skip all characters in the string str, up to and
including the n-th dot, and return the remaining part of str. For
example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.".
o 75.2.0.192.in-addr.arpa. If A is an IPv4 address, the following additional domain names are
generated from the result of the previous step: R24=skip(R32,1),
R16=skip(R32,2), and R8=skip(R32,3). Removing one label from a
domain name (i.e., one number of the "dotted quad notation")
corresponds to shortening the prefix length by 8 bits.
o 2.0.192.in-addr.arpa. For example, R32="3.100.51.198.IN-ADDR.ARPA." yields
R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and
R8="198.IN-ADDR.ARPA.".
o 0.192.in-addr.arpa. If A is an IPv6 address, the following additional domain names are
generated from the result of the previous step: R64=skip(R128,16),
R56=skip(R128,18), R48=skip(R128,20), and R32=skip(R128,24).
Removing one label from a domain name (i.e., one hex digit)
corresponds to shortening the prefix length by 4 bits.
Similarly, the IPv6 address "2001:DB8::28e4:3a93:4429:dfb5" could For example (note: a line break was added after the first line),
result in a list: R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." yields
R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."
o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.0.0.8.b.d.0. 2.4. Step 3: Perform DNS U-NAPTR lookups
1.0.0.2.ip6.arpa.
o 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. The address type of A (i.e., IPv4 or IPv6) and the value of L are
matched against the first and the second column of the following
table, respectively:
o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. +-------------+-------------+-------------+-----------------------+
| 1: Addresss | 2: Prefix | 3: MUST | 4: SHOULD do further |
| Type of A | Length L | lookup first| lookups in that order |
+-------------+-------------+-------------+-----------------------+
| IPv4 | 32 | R32 | R24, R16, R8 |
| IPv4 | 24 .. 31 | R24 | R16, R8 |
| IPv4 | 16 .. 23 | R16 | R8 |
| IPv4 | 8 .. 15 | R8 | (none) |
| IPv4 | 0 .. 7 | (none, procedure fails w/o result) |
+-------------+-------------+-------------+-----------------------+
| IPv6 | 128 | R128 | R64, R56, R48, R32 |
| IPv6 | 64 (..127) | R64 | R56, R48, R32 |
| IPv6 | 56 .. 63 | R56 | R48, R32 |
| IPv6 | 48 .. 55 | R48 | R32 |
| IPv6 | 32 .. 47 | R32 | (none) |
| IPv6 | 0 .. 31 | (none, procedure fails w/o result) |
+-------------+-------------+-------------+-----------------------+
o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Then, the domain name given in column 3 and the U-NAPTR Service
Parameter the procedure was called with (usually "ALTO:https") MUST
be used for an U-NAPTR [RFC4848] lookup, in order to obtain one or
more URIs (indicating protocol, host, and possibly path elements) for
the ALTO server's Information Resource Directory (IRD). If such
URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure
returns that information to the caller and terminates successfully.
o 8.b.d.0.1.0.0.2.ip6.arpa. For example, the following two U-NAPTR resource records can be used
for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in
the previous step) to the HTTPS URIs "https://alto1.example.net/ird"
and "https://alto2.example.net/ird", with the former being preferred.
The limited number of labels by which each name is shortened is 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https"
intended to limit the maximum number of DNS queries produced by a "!.*!https://alto1.example.net/ird!" ""
single invocation of the cross-domain ALTO server discovery
procedure. No more than five U-NAPTR resolutions are invoked for
each IP address or prefix.
2.5. Step 3: DNS lookups 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" ""
The list of domain names which was created in the previous step is If no matching U-NAPTR records can be found, the procedure SHOULD try
sequentially (from longest to shortest name) processed, as described further lookups, using the domain names from column 4 in the
in Section 3.2 of RFC 7286 [RFC7286]. indicated order, until one lookup succeeds. If no IRD URI could be
found after looking up all domain names from column 3 and column 4,
the procedure terminates unsuccessfully, without producing a result.
3. Using the ALTO Protocol with ALTO Cross-Domain Server Discovery 3. Using the ALTO Protocol with ALTO Cross-Domain Server Discovery
Based on a modular design principle, ALTO provides several ALTO Based on a modular design principle, ALTO provides several ALTO
services, each consisting of a set of information resouces that can services, each consisting of a set of information resouces that can
be accessed using the ALTO protocol. The ALTO protocol specification be accessed using the ALTO protocol. The ALTO protocol specification
defines the following ALTO services and their corresponding defines the following ALTO services and their corresponding
information resouces: information resouces:
o Network and Cost Map Service, see Section 11.2 of [RFC7285] o Network and Cost Map Service, see Section 11.2 of [RFC7285]
o Map-Filtering Service, see Section 11.3 of [RFC7285] o Map-Filtering Service, see Section 11.3 of [RFC7285]
skipping to change at page 13, line 4 skipping to change at page 9, line 4
From \ To PID_1 PID_2 PID_X PID_3 From \ To PID_1 PID_2 PID_X PID_3
------+----------------------------------- ------+-----------------------------------
PID_1 | 92 PID_1 | 92
PID_2 | 6 PID_2 | 6
PID_X | 46 3 1 19 PID_X | 46 3 1 19
PID_3 | 38 PID_3 | 38
In this example, all cells outside column "X" and row "X" are In this example, all cells outside column "X" and row "X" are
unspecified. A cost map with this structure contains the same unspecified. A cost map with this structure contains the same
information as what could be retrieved using the ECS, cases 1 and 2 information as what could be retrieved using the ECS, cases 1 and 2
in the subsection below. Accessing cells outside column "X" and row in Section 3.4. Accessing cells outside column "X" and row "X" may
"X" may not yield useful results. not yield useful results.
Trying to assemble a more densely populated cost map from several Trying to assemble a more densely populated cost map from several
cost maps with this very sparse structure may be a non-trivial task, cost maps with this very sparse structure may be a non-trivial task,
as different ALTO servers may use different PID definitions (i.e., as different ALTO servers may use different PID definitions (i.e.,
network maps) and incompatible scales for the costs, in particular network maps) and incompatible scales for the costs, in particular
for the "routingcost" metric. for the "routingcost" metric.
3.2. Map-Filtering Service 3.2. Map-Filtering Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery An ALTO client may invoke the ALTO Cross-Domain Server Discovery
skipping to change at page 15, line 4 skipping to change at page 11, line 4
3. Exactly one source address S1 and exactly one destination address 3. Exactly one source address S1 and exactly one destination address
D1. The ALTO client may perform the same steps as in case 1, as D1. The ALTO client may perform the same steps as in case 1, as
specified above. As an alternative, it may also perform the same specified above. As an alternative, it may also perform the same
steps as in case 2, as specified above. steps as in case 2, as specified above.
4. More than one source addresses S1, S2, S3, ... and more than one 4. More than one source addresses S1, S2, S3, ... and more than one
destination addresses D1, D2, D3, ... In this case, the ALTO destination addresses D1, D2, D3, ... In this case, the ALTO
client should split the list of source addresses, and perform client should split the list of source addresses, and perform
separately for each source address the same steps as in case 1, separately for each source address the same steps as in case 1,
as specified above. As an alternative, the ALTO client could as specified above. As an alternative, the ALTO client may also
also split the list of destination addresses, and perform split the list of destination addresses, and perform separately
separately for each destination address the same steps as in for each destination address the same steps as in case 2, as
case 2, as specified above. However, comparing results between specified above. However, comparing results between these sub-
these sub-queries may be difficult, in particular if the cost queries may be difficult, in particular if the cost metric is a
metric is a relative preference without a well-defined base unit relative preference without a well-defined base unit (e.g., the
(e.g., the "routingcost" metric). "routingcost" metric).
4. Implementation, Deployment, and Operational Considerations 4. Implementation, Deployment, and Operational Considerations
4.1. Considerations for ALTO Clients 4.1. Considerations for ALTO Clients
4.1.1. Resource Consumer Initiated Discovery 4.1.1. Resource Consumer Initiated Discovery
To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource
consumer initiated ALTO server discovery, can be seen as a special consumer initiated ALTO server discovery, can be seen as a special
case of cross-domain ALTO server discovery. To that end, an ALTO case of cross-domain ALTO server discovery. To that end, an ALTO
skipping to change at page 16, line 27 skipping to change at page 12, line 27
of Network Address Translators (NAT), additional protocols and of Network Address Translators (NAT), additional protocols and
mechanisms such as STUN [RFC5389] would be needed and considerations mechanisms such as STUN [RFC5389] would be needed and considerations
for UNSAF [RFC3424] apply. Therefore, using the procedures specified for UNSAF [RFC3424] apply. Therefore, using the procedures specified
in this document for resource consumer based ALTO server discovery is in this document for resource consumer based ALTO server discovery is
generally NOT RECOMMENDED. Note that a less versatile yet simpler generally NOT RECOMMENDED. Note that a less versatile yet simpler
approach for resource consumer initiated ALTO server discovery is approach for resource consumer initiated ALTO server discovery is
specified in [RFC7286]. specified in [RFC7286].
4.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility 4.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility
The algortihm specified in this document can discover ALTO server The procedure specified in this document can discover ALTO server
URIs for a given IP address or prefix. The intention is, that a URIs for a given IP address or prefix. The intention is, that a
third party (e.g., a resource directory) that receives query messages third party (e.g., a resource directory) that receives query messages
from a resource consumer can use the source address in these messages from a resource consumer can use the source address in these messages
to discover suitable ALTO servers for this specific resource to discover suitable ALTO servers for this specific resource
consumer. consumer.
However, resource consumers (as defined in Section 2 of [RFC5693]) However, resource consumers (as defined in Section 2 of [RFC5693])
may reside on hosts with more than one IP address, e.g., due to may reside on hosts with more than one IP address, e.g., due to
IPv4/v6 dual stack operation and/or multihoming. IP packets sent IPv4/v6 dual stack operation and/or multihoming. IP packets sent
with different source addresses may be subject to different routing with different source addresses may be subject to different routing
skipping to change at page 22, line 25 skipping to change at page 18, line 25
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[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.
7.2. Informative References 7.2. Informative References
[I-D.kiesel-alto-3pdisc]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M.,
Tomsu, M., and H. Song, "ALTO Server Discovery Protocol",
draft-kiesel-alto-3pdisc-05 (work in progress),
March 2011.
[I-D.kiesel-alto-alto4alto] [I-D.kiesel-alto-alto4alto]
Kiesel, S., "Using ALTO for ALTO server selection", Kiesel, S., "Using ALTO for ALTO server selection",
draft-kiesel-alto-alto4alto-00 (work in progress), draft-kiesel-alto-alto4alto-00 (work in progress),
July 2010. July 2010.
[I-D.kiesel-alto-ip-based-srv-disc] [I-D.kiesel-alto-ip-based-srv-disc]
Kiesel, S. and R. Penno, "Application-Layer Traffic Kiesel, S. and R. Penno, "Application-Layer Traffic
Optimization (ALTO) Anycast Address", Optimization (ALTO) Anycast Address",
draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), draft-kiesel-alto-ip-based-srv-disc-03 (work in progress),
July 2014. July 2014.
[I-D.kist-alto-3pdisc]
Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
(work in progress), January 2014.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291,
February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632,
August 2006, <http://www.rfc-editor.org/info/rfc4632>. August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[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.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
skipping to change at page 24, line 5 skipping to change at page 20, line 5
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "Application-Layer Traffic Optimization (ALTO) H. Song, "Application-Layer Traffic Optimization (ALTO)
Server Discovery", RFC 7286, June 2014. Server Discovery", RFC 7286, June 2014.
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "Application-Layer Traffic Optimization (ALTO) S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971, DOI 10.17487/ Deployment Considerations", RFC 7971, DOI 10.17487/
RFC7971, October 2016, RFC7971, October 2016,
<http://www.rfc-editor.org/info/rfc7971>. <http://www.rfc-editor.org/info/rfc7971>.
Appendix A. Requirements for ALTO Cross-Domain Server Discovery Appendix A. Multiple Information Sources and Partitioned Knowledge
A solution for the problem described in the previous section would be The ALTO base protocol document [RFC7285] specifies the communication
an ALTO Cross-Domain Server Discovery system. This section itemizes between an ALTO client and a single ALTO server. It is implicitly
requirements. assumed that this server can answer any query, possibly with some
kind of default value if no exact data is known. No special
provisions were made for the case that the ALTO information
originates from multiple sources, which are possibly under the
control of different administrative entities (e.g., different ISPs)
or that the overall ALTO information is partitioned and stored on
several ALTO servers.
A.1. Discovery Client Application Programming Interface A.1. Classification of Solution Approaches
Various protocol extensions and other solutions have been proposed to
deal with multiple information sources and partitioned knowledge.
They can be classified as follows:
1 Ensure that all ALTO servers have the same knowlegde
1.1 Ensure data replication and synchronization within the
provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]).
1.2 Use an Inter-ALTO-server data replication protocol. Possibly,
the ALTO protocol itself - maybe with some extensions - could be
used for that purpose; however, this has not been studied in
detail so far.
2 Accept that different ALTO servers (possibly operated by
different organizations, e.g., ISPs) do not have the same
knowledge
2.1 Allow ALTO clients to send arbitrary queries to any ALTO server
(e.g. the one discovered using [RFC7286]). If this server
cannot answer the query itself, it will fetch the data on behalf
of the client, using the ALTO protocol or a to-be-defined inter-
ALTO-server request forwarding protocol.
2.2 Allow ALTO clients to send arbitrary queries to any ALTO server
(e.g. the one discovered using [RFC7286]). If this server
cannot answer the query itself, it will redirect the client to
the "right" ALTO server that has the desired information, using
a small to-be-defined extension of the ALTO protocol.
2.3 ALTO clients need to use some kind of "search engine" that
indexes ALTO servers and redirects and/or gives cached results.
2.4 ALTO clients need to use a new discovery mechanism to discover
the ALTO server that has the desired information and contact it
directly.
A.2. Discussion of Solution Approaches
The provisioning or initialization protocol for ALTO servers (cf. RFC
5693, Fig 1 [RFC5693]) is currently not standardized. It was a
conscious decision not to include this in the scope of the IETF ALTO
working group. The reason is that there are many different kinds of
information sources. This implementation specific protocol will
adapt them to the ALTO server, which offers a standardized protocol
to the ALTO clients. However, adding the task of synchronization
between ALTO servers to this protocol (i.e., approach 1.1) would
overload this protocol with a second functionality that requires
standardization for seamless multi-domain operation.
For the 1.? solution approaches, in addition to general technical
feasibility and issues like overhead and caching efficiency, another
aspect to consider is legal liability. Operator "A" might prefer not
to publish information about nodes in or paths between the networks
of operators "B" and "C" through A's ALTO server, even if A knew that
information. This is not only a question of map size and processing
load on A's ALTO server. Operator A could also face legal liability
issues if that information had a bad impact on the traffic
engineering between B's and C's networks, or on their business
models.
No specific actions to build a "search engine" based solution
(approach 2.3) are currently known and it is unclear what could be
the incentives to operate such an engine. Therefore, this approach
is not considered in the remainder of this document.
A.3. The Need for Cross-Domain ALTO Server Discovery
Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the
specification of an ALTO protocol extension or a new protocol that
runs between ALTO servers. A large-scale, maybe Internet-wide,
multi-domain deployment would also need mechanisms by which an ALTO
server could discover other ALTO servers, learn which information is
available where, and ideally also who is authorized to publish
information related to a given part of the network. Approach 2.4
needs the same mechanisms, except that they are used on the client-
side instead of the server-side.
It is sometimes questioned whether there is a need for a solution
that allows clients to ask arbitrary queries, even if the ALTO
information is partitioned and stored on many ALTO servers. The main
argument is, that clients are supposed to optimize the traffic from
and to themselves, and that the information needed for that is most
likely stored on a "nearby" ALTO server, i.e., the one that can be
discovered using [RFC7286]. However, there are scenarios where the
ALTO client is not co-located with an endpoint of the to-be-optimized
data transmission. Instead, the ALTO client is located at a third
party, which takes part in the application signaling, e.g., a so-
called "tracker" in a peer-to-peer application. One such scenario,
where it is advantageous to place the ALTO client not at an endpoint
of the user data transmission, is analyzed in Appendix C.
A.4. Our Solution Approach
Several solution approaches for cross-domain ALTO server discovery
have been evaluated, using the criteria documented in Appendix B.
One of them was to use the ALTO protocol itself for the exchange of
information availability [I-D.kiesel-alto-alto4alto]. However, the
drawback of that approach is that a new registration administration
authority would have to be established.
This document specifies a DNS-based procedure for cross-domain ALTO
server discovery, which was inspired by "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The
primary goal is that this procedure can be used on the client-side
(i.e., approach 2.4), but together with new protocols or protocol
extensions it could also be used to implement the other solution
approaches itemized above.
A.5. Relation to the ALTO Requirements
During the design phase of the overall ALTO solution, two different
server discovery scenarios have been identified and documented in the
ALTO requirements document [RFC6708]. The first scenario, documented
in Req. AR-32, can be supported using the discovery mechanisms
specified in [RFC7286]. An alternative approach, based on IP anycast
[I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This
document, in contrast, tries to address Req. AR-33.
Appendix B. Requirements for ALTO Cross-Domain Server Discovery
This appendix itemizes requirements that have been collected before
the design phase and that are reflected by the design of the ALTO
Cross-Domain Server Discovery Procedure.
B.1. Discovery Client Application Programming Interface
The discovery client will be called through some kind of application The discovery client will be called through some kind of application
programming interface (API) and the parameters will be an IP address programming interface (API) and the parameters will be an IP address
and, for purposes of extensibility, a service identifier such as and, for purposes of extensibility, a service identifier such as
"ALTO". It will return one or more URI(s) that offers the requested "ALTO". It will return one or more URI(s) that offers the requested
service ("ALTO") for the given IP address. service ("ALTO") for the given IP address.
In other words, the client would be used to retrieve a mapping: In other words, the client would be used to retrieve a mapping:
(IP address, "ALTO") -> IRD-URI(s) (IP address, "ALTO") -> IRD-URI(s)
where IRD-URI(s) is one or more URI(s) of Information Resource where IRD-URI(s) is one or more URI(s) of Information Resource
Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that
can give reasonable guidance to a resource consumer with the can give reasonable guidance to a resource consumer with the
indicated IP address. indicated IP address.
A.2. Data Storage and Authority Requirements B.2. Data Storage and Authority Requirements
The information for mapping IP addresses and service parameters to The information for mapping IP addresses and service parameters to
URIs should be stored in a - preferably distributed - database. It URIs should be stored in a - preferably distributed - database. It
must be possible to delegate administration of parts of this must be possible to delegate administration of parts of this
database. Usually, the mapping from a specific IP address to an URI database. Usually, the mapping from a specific IP address to an URI
is defined by the authority that has administrative control over this is defined by the authority that has administrative control over this
IP address, e.g., the ISP in residential access networks or the IT IP address, e.g., the ISP in residential access networks or the IT
department in enterprise, university, or similar networks. department in enterprise, university, or similar networks.
A.3. Cross-Domain Operations Requirements B.3. Cross-Domain Operations Requirements
The cross-domain server discovery mechanism should be designed in The cross-domain server discovery mechanism should be designed in
such a way that it works across the public Internet and also in other such a way that it works across the public Internet and also in other
IP-based networks. This in turn means that such mechanisms cannot IP-based networks. This in turn means that such mechanisms cannot
rely on protocols that are not widely deployed across the Internet or rely on protocols that are not widely deployed across the Internet or
protocols that require special handling within participating protocols that require special handling within participating
networks. An example is multicast, which is not generally available networks. An example is multicast, which is not generally available
across the Internet. across the Internet.
The ALTO Cross-Domain Server Discovery protocol must support gradual The ALTO Cross-Domain Server Discovery protocol must support gradual
deployment without a network-wide flag day. If the mechanism needs deployment without a network-wide flag day. If the mechanism needs
some kind of well-known "rendezvous point", re-using an existing some kind of well-known "rendezvous point", re-using an existing
infrastructure (such as the DNS root servers or the WHOIS database) infrastructure (such as the DNS root servers or the WHOIS database)
should be preferred over establishing a new one. should be preferred over establishing a new one.
A.4. Protocol Requirements B.4. Protocol Requirements
The protocol must be able to operate across middleboxes, especially The protocol must be able to operate across middleboxes, especially
across NATs and firewalls. across NATs and firewalls.
The protocol shall not require any pre-knowledge from the client The protocol shall not require any pre-knowledge from the client
other than any information that is known to a regular IP host on the other than any information that is known to a regular IP host on the
Internet. Internet.
A.5. Further Requirements B.5. Further Requirements
The ALTO cross domain server discovery cannot assume that the server The ALTO cross domain server discovery cannot assume that the server
discovery client and the server discovery responding entity are under discovery client and the server discovery responding entity are under
the same administrative control. the same administrative control.
Appendix B. ALTO and Tracker-based Peer-to-Peer Applications Appendix C. ALTO and Tracker-based Peer-to-Peer Applications
This appendix illustrates one ALTO use case and shows that ALTO
Cross-Domain Server Discovery is beneficial in that scenario.
The ALTO protocol specification [RFC7285] details how an ALTO client The ALTO protocol specification [RFC7285] details how an ALTO client
can query an ALTO server for guiding information and receive the can query an ALTO server for guiding information and receive the
corresponding replies. However, in the considered scenario of a corresponding replies. However, in the considered scenario of a
tracker-based P2P application, there are two fundamentally different tracker-based P2P application, there are two fundamentally different
possibilities where to place the ALTO client: possibilities where to place the ALTO client:
1. ALTO client in the resource consumer ("peer") 1. ALTO client in the resource consumer ("peer")
2. ALTO client in the resource directory ("tracker") 2. ALTO client in the resource directory ("tracker")
skipping to change at page 29, line 29 skipping to change at page 28, line 29
analysis. Assume that the swarm has a total number of N peers, out analysis. Assume that the swarm has a total number of N peers, out
of which are M "good" and N-M "bad" peers, which are all known to the of which are M "good" and N-M "bad" peers, which are all known to the
tracker. A new peer wants to join the swarm and therefore asks the tracker. A new peer wants to join the swarm and therefore asks the
tracker for a list of peers. tracker for a list of peers.
If, according to the first approach, the tracker randomly picks n If, according to the first approach, the tracker randomly picks n
peers from the N known peers, the result can be described with the peers from the N known peers, the result can be described with the
hypergeometric distribution. The probability that the tracker reply hypergeometric distribution. The probability that the tracker reply
contains exactly k "good" peers (and n-k "bad" peers) is: contains exactly k "good" peers (and n-k "bad" peers) is:
/ m \ / N - m \ / M \ / N - M \
\ k / \ n - k / \ k / \ n - k /
P(X=k) = --------------------- P(X=k) = ---------------------
/ N \ / N \
\ n / \ n /
/ n \ n! / n \ n!
with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1
k! (n-k)! k! (n-k)!
The probability that the reply contains at most k "good" peers is: The probability that the reply contains at most k "good" peers is:
skipping to change at page 31, line 5 skipping to change at page 30, line 5
scenario with the ALTO client embedded in the resource directory is scenario with the ALTO client embedded in the resource directory is
advantageous, because it is ensured that the addresses of the "best" advantageous, because it is ensured that the addresses of the "best"
resource providers are actually delivered to the resource consumer. resource providers are actually delivered to the resource consumer.
An architectural implication of this insight is that the ALTO server An architectural implication of this insight is that the ALTO server
discovery procedures must support ALTO queries on behalf of remote discovery procedures must support ALTO queries on behalf of remote
resource consumers. That is, as the tracker issues ALTO queries on resource consumers. That is, as the tracker issues ALTO queries on
behalf of the peer which contacted the tracker, the tracker must be behalf of the peer which contacted the tracker, the tracker must be
able to discover an ALTO server that can give guidance suitable for able to discover an ALTO server that can give guidance suitable for
that respective peer. that respective peer.
Appendix C. Contributors List and Acknowledgments Appendix D. Contributors List and Acknowledgments
The initial version of this document was co-authored by Marco Tomsu The initial version of this document was co-authored by Marco Tomsu
(Alcatel-Lucent). (Alcatel-Lucent).
This document borrows some text from [RFC7286], as it was This document borrows some text from [RFC7286], as historically, it
historically part of that memo. Special thanks to Michael Scharf and has been part of the draft that eventually became said RFC. Special
Nico Schwan. thanks to Michael Scharf and Nico Schwan.
Authors' Addresses Authors' Addresses
Sebastian Kiesel Sebastian Kiesel
University of Stuttgart Information Center University of Stuttgart Information 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.izus.uni-stuttgart.de
Martin Stiemerling Martin Stiemerling
University of Applied Sciences Darmstadt, Computer Science Dept. University of Applied Sciences Darmstadt, Computer Science Dept.
Haardtring 100 Haardtring 100
Darmstadt 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 16 37938 Phone: +49 6151 16 37938
Email: mls.ietf@gmail.com Email: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org URI: http://ietf.stiemerling.org
 End of changes. 58 change blocks. 
372 lines changed or deleted 351 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/