draft-ietf-alto-xdom-disc-00.txt   draft-ietf-alto-xdom-disc-01.txt 
ALTO S. Kiesel ALTO S. Kiesel
Internet-Draft University of Stuttgart Internet-Draft University of Stuttgart
Intended status: Informational M. Stiemerling Intended status: Standards Track M. Stiemerling
Expires: October 1, 2017 H-DA Expires: January 4, 2018 H-DA
March 30, 2017 July 3, 2017
Application Layer Traffic Optimization (ALTO) Cross-Domain Server Application Layer Traffic Optimization (ALTO) Cross-Domain Server
Discovery Discovery
draft-ietf-alto-xdom-disc-00 draft-ietf-alto-xdom-disc-01
Abstract Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications 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 algorithm specified in this document takes one
IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO:
"ALTO:https") as parameters. It performs DNS lookups (for NAPTR http" or "ALTO:https") as parameters. It performs DNS lookups (for
resource records in the in-addr.arpa. or ip6.arpa. tree) and returns NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and
one or more URI(s) of information resources related to that IP returns one or more URI(s) of information resources related to that
address. 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].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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 October 1, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
1.1. Multiple Information Sources and Partitioned Knowledge . . 4 1.1. Multiple Information Sources and Partitioned Knowledge . . 4
1.2. The Need for Cross-Domain ALTO Server Discovery . . . . . 5 1.2. The Need for Cross-Domain ALTO Server Discovery . . . . . 5
1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 6 1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 6
1.4. ALTO Requirements . . . . . . . . . . . . . . . . . . . . 6 1.4. ALTO Requirements . . . . . . . . . . . . . . . . . . . . 6
1.5. Document History . . . . . . . . . . . . . . . . . . . . . 7 1.5. Document History . . . . . . . . . . . . . . . . . . . . . 7
1.6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. ALTO Cross-Domain Server Discovery Procedure Specification . . 8 2. ALTO Cross-Domain Server Discovery Procedure Specification . . 8
2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Basic Principle . . . . . . . . . . . . . . . . . . . . . 8 2.2. Basic Principle . . . . . . . . . . . . . . . . . . . . . 8
2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 8 2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 8
2.4. Step 2: Add Shortened Domain Names . . . . . . . . . . . . 9 2.4. Step 2: Add Shortened Domain Names . . . . . . . . . . . . 10
2.5. Step 3: DNS lookups . . . . . . . . . . . . . . . . . . . 10 2.5. Step 3: DNS lookups . . . . . . . . . . . . . . . . . . . 11
3. Using the ALTO Protocol with ALTO Cross-Domain Server 3. Using the ALTO Protocol with ALTO Cross-Domain Server
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Endpoint Property Service . . . . . . . . . . . . . . . . 11 3.1. Network and Cost Map Service . . . . . . . . . . . . . . . 12
3.2. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 11 3.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 13
3.3. Network and Cost Map Service . . . . . . . . . . . . . . . 13 3.3. Endpoint Property Service . . . . . . . . . . . . . . . . 13
3.4. Map-Filtering Service . . . . . . . . . . . . . . . . . . 13 3.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 14
4. Implementation, Deployment, and Operational Considerations . . 14 4. Implementation, Deployment, and Operational Considerations . . 16
4.1. Considerations for ALTO Clients . . . . . . . . . . . . . 14 4.1. Considerations for ALTO Clients . . . . . . . . . . . . . 16
4.2. Deployment Considerations for Network Operators . . . . . 15 4.2. Deployment Considerations for Network Operators . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 16 5.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 18
5.2. Availability of the ALTO Server Discovery Procedure . . . 17 5.2. Availability of the ALTO Server Discovery Procedure . . . 19
5.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 18 5.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 20
5.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 18 5.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Requirements for ALTO Cross-Domain Server Appendix A. Requirements for ALTO Cross-Domain Server
Discovery . . . . . . . . . . . . . . . . . . . . . . 22 Discovery . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Discovery Client Application Programming Interface . . . . 22 A.1. Discovery Client Application Programming Interface . . . . 24
A.2. Data Storage and Authority Requirements . . . . . . . . . 22 A.2. Data Storage and Authority Requirements . . . . . . . . . 24
A.3. Cross-Domain Operations Requirements . . . . . . . . . . . 22 A.3. Cross-Domain Operations Requirements . . . . . . . . . . . 24
A.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 23 A.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 25
A.5. Further Requirements . . . . . . . . . . . . . . . . . . . 23 A.5. Further Requirements . . . . . . . . . . . . . . . . . . . 25
Appendix B. ALTO and Tracker-based Peer-to-Peer Applications . . 24 Appendix B. ALTO and Tracker-based Peer-to-Peer Applications . . 26
Appendix C. Contributors List and Acknowledgments . . . . . . . . 29 Appendix C. Contributors List and Acknowledgments . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
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 deployment scenarios
[I-D.ietf-alto-deployments]. [RFC7971].
1.1. Multiple Information Sources and Partitioned Knowledge 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 a single ALTO server. It is implicitly
assumed that this server can answer any query, possibly with some assumed that this server can answer any query, possibly with some
kind of default value if no exact data is known. No special kind of default value if no exact data is known. No special
provisions were made for the case that the ALTO information provisions were made for the case that the ALTO information
originates from multiple sources, which are possibly under the originates from multiple sources, which are possibly under the
control of different administrative entities (e.g., different ISPs) control of different administrative entities (e.g., different ISPs)
skipping to change at page 8, line 9 skipping to change at page 8, line 9
1.6. Feedback 1.6. Feedback
Comments and discussions about this document should be directed to Comments and discussions about this document should be directed to
the ALTO working group: alto@ietf.org. the ALTO working group: alto@ietf.org.
2. ALTO Cross-Domain Server Discovery Procedure Specification 2. ALTO Cross-Domain Server Discovery Procedure Specification
2.1. Interface 2.1. Interface
The algorithm specified in this document takes one IP address "X" and The algorithm specified in this document takes one IP address or
a U-NAPTR [RFC4848] Service Parameter (i.e., "ALTO:http" or "ALTO: prefix "X" and a U-NAPTR [RFC4848] Service Parameter (i.e., "ALTO:
https") as parameters. It performs DNS lookups and returns one or http" or "ALTO:https") as parameters. It performs DNS lookups and
more URI(s) of information resources related to that IP address. 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: For the remainder of the document, we use the notation:
IRD_URIS_X := XDOMDISC(X,"ALTO:https") IRD_URIS_X := XDOMDISC(X,"ALTO:https")
2.2. Basic Principle 2.2. Basic Principle
This algorithm closely follows [RFC7216] and re-uses parts of This algorithm closely follows [RFC7216] and re-uses parts of
[RFC7286]. [RFC7286].
The algorithm sequentially tries two different lookup strategies. The algorithm 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. If this lookup does not yield corresponding to the given IP address or prefix. If this lookup does
a usable result, further lookups with truncated domain names may be not yield a usable result, further lookups with truncated domain
tried. The goal is to allow deployment scenarios that require fine- names may be tried. The goal is to allow deployment scenarios that
grained discovery on a per-IP basis, as well as large-scale scenarios require fine-grained discovery on a per-IP basis, as well as large-
where discovery is to be enabled for a large number of IP addresses scale scenarios where discovery is to be enabled for a large number
with a small number of additional DNS resource records. of IP addresses with a small number of additional DNS resource
records.
2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup 2.3. Step 1: Prepare Domain Name for Reverse DNS Lookup
This task takes the IP address parameter the procedure was called This task takes the IP address or prefix "X", with which the
with and constructs a domain name, which is used for DNS lookups in procedure was called, and constructs a domain name "R", which is used
subsequent tasks. for DNS lookups in subsequent steps. We need to distinguish four
cases.
If the IP address given as a parameter to the procedure is an IPv4 2.3.1. IPv4 address
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.". For IPv6 addresses, the construction rules
in Section 2.5 of [RFC3596] apply and the special domain "IP6.ARPA."
is used.
Example values for IPv4 and IPv6 addresses could be (Note: a line If the parameter "X" is a single IPv4 address, the domain name is
break was added in the IPv6 example): 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:
R:="3.100.51.198.in-addr.arpa." X = 198.51.100.3 yields R := "3.100.51.198.in-addr.arpa."
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. 2.3.2. IPv4 prefix
1.0.0.2.ip6.arpa."
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
shortened by 20 labels,
5. if the prefix length is 47 bits or less, the domain name is
shortened by 24 labels.
Examples are:
X = 2001:0DB8::/64 yields
R := "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."
X = 2001:0DB8::/48 yields
R := "0.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa."
2.4. Step 2: Add Shortened Domain Names 2.4. Step 2: Add Shortened Domain Names
This task creates a list of several additional domain names, based on This task creates a list of several additional domain names, based on
the domain name yielded in Step 1. the domain name yielded in Step 1.
o For IP version 4, the domain name from Step 1 SHOULD be shortened 1. For an IPv4 address, the domain name from Step 1 SHOULD be
successively by one and two labels (i.e., purge the first or shortened successively by one and two labels (i.e., purge the
second dot from the left and everything left of it, respectively), first or second dot from the left and everything left of it,
and the results being added to the list. This corresponds to a respectively), and the results being added to the list. This
search on a /24 or /16 network prefix. corresponds to a search on a /24 or /16 network prefix.
o For IP version 6, the domain name from Step 1 SHOULD be shortened 2. For an IPv4 prefix, if the domain name has already been shortened
successively by 16, 18, 20, and 24 labels, and the results being by one label as per section Section 2.3.2, it SHOULD be shortened
added to the list. This corresponds to a search on a /64, /56, by one more label and the result being added to the list. If the
/48, or /32 network prefix. 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
shortened successively by 16, 18, 20, and 24 labels, and the
results being added to the list. This corresponds to a search on
a /64, /56, /48, or /32 network prefix.
4. For an IPv6 prefix, the domain name from Step 1 SHOULD be
shortened successively by 16, 18, 20, and 24 labels, and the
results being added to the list. However, if the domain name has
already been shortened in Step 1, Step 2 should not add domain
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 This list is intended to provide network operators with a degree of
flexibility in where discovery-related resource records can be placed flexibility in where discovery-related resource records can be placed
without significantly increasing the number of DNS names that are without significantly increasing the number of DNS names that are
searched. This does not attach any other significance to these searched. This does not attach any other significance to these
specific zone cuts or create a classful addressing hierarchy based on specific zone cuts or create a classful addressing hierarchy based on
the reverse DNS tree. the reverse DNS tree.
For example, the IPv4 address "192.0.2.75" could result in a list of For example, the IPv4 address "192.0.2.75" could result in a list of
domain names (with the result from Step 1 put in the first position): domain names (with the result from Step 1 put in the first position):
skipping to change at page 10, line 6 skipping to change at page 11, line 39
o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 8.b.d.0.1.0.0.2.ip6.arpa. o 8.b.d.0.1.0.0.2.ip6.arpa.
The limited number of labels by which each name is shortened is The limited number of labels by which each name is shortened is
intended to limit the maximum number of DNS queries produced by a intended to limit the maximum number of DNS queries produced by a
single invocation of the cross-domain ALTO server discovery single invocation of the cross-domain ALTO server discovery
procedure. No more than five U-NAPTR resolutions are invoked for procedure. No more than five U-NAPTR resolutions are invoked for
each IP address. each IP address or prefix.
2.5. Step 3: DNS lookups 2.5. Step 3: DNS lookups
The list of domain names which was created in the previous step is The list of domain names which was created in the previous step is
sequentially (from longest to shortest name) processed, as described sequentially (from longest to shortest name) processed, as described
in Section 3.2 of RFC 7286 [RFC7286]. in Section 3.2 of RFC 7286 [RFC7286].
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
skipping to change at page 11, line 26 skipping to change at page 12, line 26
o Endpoint Property Service, see Section 11.4 of [RFC7285] o Endpoint Property Service, see Section 11.4 of [RFC7285]
o Endpoint Cost Service, see Section 11.5 of [RFC7285] o Endpoint Cost Service, see Section 11.5 of [RFC7285]
Extension documents may specify further information resources; Extension documents may specify further information resources;
however, these are out of scope of this document. The information however, these are out of scope of this document. The information
resources that are available at a specific ALTO server are listed in resources that are available at a specific ALTO server are listed in
its Information Resource Directory (IRD, see Section 9 of [RFC7285]). its Information Resource Directory (IRD, see Section 9 of [RFC7285]).
3.1. Endpoint Property Service The ALTO Cross-Domain Server Discovery Procedure is most useful in
conjunction with the Endpoint Property Service and the Endpoint Cost
Service. However, for the sake of completeness, possible interaction
with all four services is discussed below.
3.1. Network and Cost Map Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 2) for an IP address or prefix "X"
and get a list of one or more IRD URI(s):
IRD_URIS_X := XDOMDISC(X,"ALTO:https"). These IRD(s) will always
contain a network and a cost map, as these are mandatory information
ressources (see Section 11.2 of [RFC7285]). However, the cost matrix
may be very sparse. If, according to the network map, PID_X is the
PID that contains the IP address or prefix X, and PID_1, PID_2,
PID_3, ... are other PIDS, the cost map may look like this:
From \ To PID_1 PID_2 PID_X PID_3
------+-----------------------------------
PID_1 | 92
PID_2 | 6
PID_X | 46 3 1 19
PID_3 | 38
In this example, all cells outside column "X" and row "X" are
unspecified. A cost map with this structure contains the same
information as what could be retrieved using the ECS, cases 1 and 2
in the subsection below. Accessing cells outside column "X" and row
"X" may not yield useful results.
Trying to assemble a more densely populated cost map from several
cost maps with this very sparse structure may be a non-trivial task,
as different ALTO servers may use different PID definitions (i.e.,
network maps) and incompatible scales for the costs, in particular
for the "routingcost" metric.
3.2. Map-Filtering Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 2) for an IP address or prefix "X"
and get a list of one or more IRD URI(s): IRD_URIS_X :=
XDOMDISC(X,"ALTO:https"). These IRD(s) may provide the optional Map-
Filtering Service (see Section 11.3 of [RFC7285]). This service
returns a subset of the full map, as specified by the client. As
discussed in Section 3.1, a cost map may be very sparse in the
envisioned deployment scenario. Therefore, depending on the
filtering criteria provided by the client, this service may return
results similar to the Endpoint Cost Service, or it may not return
any useful result.
3.3. Endpoint Property Service
If an ALTO client wants to query an Endpoint Property Service (see If an ALTO client wants to query an Endpoint Property Service (see
Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address
"X", it has to perform the following steps: "X" or a group of endpoints within IP prefix "X", respectively, it
has to perform the following steps:
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as
specified in Section 2): IRD_URIS_X := XDOMDISC(X,"ALTO:https") specified in Section 2): IRD_URIS_X := XDOMDISC(X,"ALTO:https")
2. The result IRD_URIS_X is a list of one or more Information 2. The result IRD_URIS_X is a list of one or more Information
Resource Directories (IRD, see Section 9 of [RFC7285]). Check Resource Directories (IRD, see Section 9 of [RFC7285]). Check
each of these IRDs for a suitable Endpoint Property Service and each of these IRDs for a suitable Endpoint Property Service and
query it. query it.
If the ALTO client wants to do a similar Endpoint Property query for If the ALTO client wants to do a similar Endpoint Property query for
a different IP address "Y", the whole procedure has to be repeated, a different IP address or prefix "Y", the whole procedure has to be
as IRD_URIS_Y := XDOMDISC(Y,"ALTO:https") may yield a different list repeated, as IRD_URIS_Y := XDOMDISC(Y,"ALTO:https") may yield a
of IRDs. Of course, the results of individual DNS queries may be different list of IRDs. Of course, the results of individual DNS
cached as indicated by their respective time-to-live (TTL) values. queries may be cached as indicated by their respective time-to-live
(TTL) values.
3.2. Endpoint Cost Service 3.4. Endpoint Cost Service
The ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 7285 The ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 7285
[RFC7285]) provides information about costs between individual [RFC7285]) provides information about costs between individual
endpoints and it also supports ranking. The ECS allows that endpoints and it also supports ranking. The ECS allows that
endpoints may be denoted by IP prefixes or IP addresses (as special endpoints may be denoted by IP addresses or prefixes. The ECS is
case of a prefix); however, this document assumes that all endpoints called with a list of one or more source IP addresses or prefixes,
are single IP addresses. The ECS is called with a list of one or which we will call (S1, S2, S3, ...), and a list of one or more
more source IP addresses, which we will call (S1, S2, S3, ...), and a destination IP addresses or prefixes, which we will call (D1, D2, D3,
list of one or more destination IP addresses, which we will call (D1, ...).
D2, D3, ...).
This specification distinguishes several cases, regarding the number This specification distinguishes several cases, regarding the number
of elements in the list of source and destination addresses, of elements in the list of source and destination addresses,
respectively: respectively:
1. Exactly one source address S1 and more than one destination 1. Exactly one source address S1 and more than one destination
addresses D1, D2, D3, ... In this case, the ALTO client has to addresses D1, D2, D3, ... In this case, the ALTO client has to
perform the following steps: perform the following steps:
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as
skipping to change at page 12, line 49 skipping to change at page 15, line 7
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 could
also split the list of destination addresses, and perform also split the list of destination addresses, and perform
separately for each destination address the same steps as in separately for each destination address the same steps as in
case 2, as specified above. case 2, as specified above. However, comparing results between
these sub-queries may be difficult, in particular if the cost
3.3. Network and Cost Map Service metric is a relative preference without a well-defined base unit
(e.g., the "routingcost" metric).
An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 2) for an IP address "X" and get a
list of one or more IRD URI(s): IRD_URIS_X := XDOMDISC(X,"ALTO:
https"). These IRD(s) will always contain a network and a cost map,
as these are mandatory information ressources (see Section 11.2 of
[RFC7285]). However, the cost matrix may be very sparse. If,
according to the network map, PID_X is the PID that contains the IP
address X, and PID_1, PID_2, PID_3, ... are other PIDS, the cost map
may look like this:
From \ To PID_1 PID_2 PID_X PID_3
------+-----------------------------------
PID_1 | 92
PID_2 | 6
PID_X | 46 3 1 19
PID_3 | 38
In this example, all cells outside column "X" and row "X" are
unspecified. A cost map with this structure contains the same
information as what could be retrieved using the ECS, cases 1 and 2
in the previous subsection. Accessing cells outside column "X" and
row "X" may not yield useful results.
Trying to assemble a more densely populated cost map from several
cost maps with this very sparse structure may be a non-trivial task,
as different ALTO servers may use different PID definitions (i.e.,
network maps) and incompatible scales for the costs, in particular
for the "routingcost" metric.
3.4. Map-Filtering Service
This issue is left for further study in this version of the draft.
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 14, line 28 skipping to change at page 16, line 28
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 algortihm specified in this document can discover ALTO server
URIs for a given IP address. The intention is, that a third party URIs for a given IP address or prefix. The intention is, that a
(e.g., a resource directory) that receives query messages from a third party (e.g., a resource directory) that receives query messages
resource consumer can use the source address in these messages to from a resource consumer can use the source address in these messages
discover suitable ALTO servers for this specific resource consumer. to discover suitable ALTO servers for this specific resource
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
policies and path costs. In some deployment scenarios, it may even policies and path costs. In some deployment scenarios, it may even
be required to ask different sets of ALTO servers for guidance. be required to ask different sets of ALTO servers for guidance.
Furthermore, source addresses in IP packets may be modified en-route Furthermore, source addresses in IP packets may be modified en-route
by Network Address Translators (NAT). by Network Address Translators (NAT).
skipping to change at page 20, line 25 skipping to change at page 22, 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.ietf-alto-deployments]
Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "ALTO Deployment Considerations",
draft-ietf-alto-deployments-15 (work in progress),
May 2016.
[I-D.kiesel-alto-3pdisc] [I-D.kiesel-alto-3pdisc]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M.,
Tomsu, M., and H. Song, "ALTO Server Discovery Protocol", Tomsu, M., and H. Song, "ALTO Server Discovery Protocol",
draft-kiesel-alto-3pdisc-05 (work in progress), draft-kiesel-alto-3pdisc-05 (work in progress),
March 2011. 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.
skipping to change at page 21, line 13 skipping to change at page 23, line 6
(work in progress), January 2014. (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.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/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
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
October 2009. October 2009.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO) Y. Yang, "Application-Layer Traffic Optimization (ALTO)
skipping to change at page 22, line 5 skipping to change at page 23, line 36
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, Traffic Optimization (ALTO) Protocol", RFC 7285,
September 2014. September 2014.
[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
S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971, DOI 10.17487/
RFC7971, October 2016,
<http://www.rfc-editor.org/info/rfc7971>.
Appendix A. Requirements for ALTO Cross-Domain Server Discovery Appendix A. Requirements for ALTO Cross-Domain Server Discovery
A solution for the problem described in the previous section would be A solution for the problem described in the previous section would be
an ALTO Cross-Domain Server Discovery system. This section itemizes an ALTO Cross-Domain Server Discovery system. This section itemizes
requirements. requirements.
A.1. Discovery Client Application Programming Interface A.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
skipping to change at page 30, line 22 skipping to change at page 32, line 22
Email: ietf-alto@skiesel.de Email: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/ URI: http://www.rus.uni-stuttgart.de/nks/
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 7938 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. 29 change blocks. 
133 lines changed or deleted 236 lines changed or added

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