Third-Party ALTO Server Discovery (3pdisc)
draft-kist-alto-3pdisc-01
| The information below is for an old version of the document |
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2012-10-22
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
ALTO S. Kiesel
Internet-Draft University of Stuttgart
Intended status: Experimental M. Stiemerling
Expires: April 25, 2013 NEC Europe Ltd.
October 22, 2012
Third-Party ALTO Server Discovery (3pdisc)
draft-kist-alto-3pdisc-01
Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired
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 servers that can provide suitable guidance.
This document specifies a procedure for third-party ALTO server
discovery, which can be used if the ALTO client is not co-located
with the actual resource consumer, but instead embedded in a third
party such as a peer-to-peer tracker.
Kiesel & Stiemerling Expires April 25, 2013 [Page 1]
Internet-Draft Third-Party ALTO Server Discovery October 2012
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kiesel & Stiemerling Expires April 25, 2013 [Page 2]
Internet-Draft Third-Party ALTO Server Discovery October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Third-Party ALTO Server Discovery Procedure Overview . . . . . 5
3. Third-party ALTO Server Discovery Procedure Specification . . 6
3.1. Step 1: Retrieving the Domain Name . . . . . . . . . . . . 7
3.2. Step 2: U-NAPTR Resolution . . . . . . . . . . . . . . . . 7
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
4.1. IPv4 PTR lookup . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Private customers or very small businesses . . . . . . 8
4.1.2. Medium-size customer networks . . . . . . . . . . . . 8
4.1.3. Large Customers . . . . . . . . . . . . . . . . . . . 9
4.2. IPv6 PTR lookup . . . . . . . . . . . . . . . . . . . . . 9
5. Operational Considerations . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Contributors List and Acknowledgments . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Kiesel & Stiemerling Expires April 25, 2013 [Page 3]
Internet-Draft Third-Party ALTO Server Discovery October 2012
1. Introduction
The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired
resource [RFC5693]. ALTO is realized by a client-server protocol,
see requirement AR-1 in [RFC6708]. Before an ALTO client can ask for
guidance it needs to discover one or more ALTO servers that can
provide suitable guidance.
For applications that use a centralized resource directory, such as
tracker-based P2P applications, the efficiency of ALTO is
significantly improved if the ALTO client is embedded in said
resource directory instead of the resource consumer (see Section 4.1
of [I-D.ietf-alto-deployments]). The ALTO client embedded into the
resource directory asks for guidance on behalf of the resource
consumers. To that end, it needs to discover ALTO servers that can
give guidance suitable for these resource consumers, respectively.
This is called third-party party ALTO server discovery.
This document specifies a procedure for third-party ALTO server
discovery. In other words, this document tries to meet requirement
AR-33 in [RFC6708]. To some extent, AR-32, i.e., resource consumer
initiated ALTO server discovery, can be seen as a special case of
third-party ALTO server discovery. For that matter, an ALTO client
embedded in a ressouce consumer would have to figure out its own
"public" IP address (e.g., using STUN [RFC5389]), and then perform
the procedures described in this document. However, note that a less
flexible yet simpler approach for resource consumer initiated ALTO
server discovery is specified in [I-D.ietf-alto-server-discovery].
The ALTO protocol specification [I-D.ietf-alto-protocol] is based on
HTTP and expects the discovery procedure to yield an HTTP(S) URI.
Therefore, this procedure is based on U-NAPTR [RFC4848]. It tries to
directly find one or more ALTO server(s) that can give suitable
guidance to the ALTO client. Other schemes, such as discovering an
arbitrary ALTO server (which might not be able to give suitable
guidance to the client in question) and asking it to redirect the
client to a better server, are not considered in this document.
A more detailed discussion of various options where to place the
funcional entities comprising the overall ALTO architecture can be
found in [I-D.ietf-alto-deployments].
Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org.
Kiesel & Stiemerling Expires April 25, 2013 [Page 4]
Internet-Draft Third-Party ALTO Server Discovery October 2012
2. Third-Party ALTO Server Discovery Procedure Overview
The third-party ALTO server discovery procedure is performed in two
steps:
1. A DNS suffix is yieleded, by means of a DNS PTR lookup on the
resouce consumer's IP address (or the "public" IP address of the
outermost NAT in front of the resource consumer). This IP
address is the source address of application protocol messages
arriving at the resource directory.
2. This DNS suffix is used for an U-NAPTR lookup yielding the URI.
Further DNS lookups may be neccessary to determine the ALTO
server's IP address(es).
Typically, but not neccessarily, the DNS suffix is the domain name in
which the client is located, i.e., a PTR lookup on the client's IP
address would yield a similar name. However, due to the widespread
use of network address translation (NAT), trying to determine the DNS
suffix through a PTR lookup on the client's IP address is not
recommended.
Note: Step 1 could be merged with Step 1 of
[I-D.ietf-alto-server-discovery] in order to yield a combined draft.
Kiesel & Stiemerling Expires April 25, 2013 [Page 5]
Internet-Draft Third-Party ALTO Server Discovery October 2012
3. Third-party ALTO Server Discovery Procedure Specification
A already outlined in Section 2 the ALTO server discovery procedure
is performed in two steps, which will be specified in Section 3.1 and
Section 3.2, respectively. The following figure gives an overview:
IPv4 address IPv6 address
| |
v v
PTR lookup PTR lookup
| | | |
v v v v
no result result1 no result
| | |
v | V
FAIL | PTR lookup on (addr/64)
| | |
| v v
\ result1 no result
\ / |
\ / v
+ FAIL
|
v
NAPTR lookup on result1
| |
v v
result2 no result
\ |
\ v
\ shorten result1 by one component
\ from the left, including first dot
\ |
\ v
\ second NAPTR lookup on shortened name
\ | |
\ v v
\ result2 no result
\ / |
+ v
| FAIL
v
Third-party ALTO server discovery procedure's output is: result2
Kiesel & Stiemerling Expires April 25, 2013 [Page 6]
Internet-Draft Third-Party ALTO Server Discovery October 2012
3.1. Step 1: Retrieving the Domain Name
Textual specification TBD. See figure above.
Somewhere in the figure, we do a lookup on addr/64, which is the
"network part" of the IPv6 address computed as follows: addr/64 :=
addr & 0xFFFF:FFFF:FFFF:FFFF:0000:0000:0000:0000.
Note that the algorithm at some point tries to chop one component
from the DNS name, but there is no recursion, i.e., no DNS tree
walking.
3.2. Step 2: U-NAPTR Resolution
See Step 2 in [I-D.ietf-alto-server-discovery].
Kiesel & Stiemerling Expires April 25, 2013 [Page 7]
Internet-Draft Third-Party ALTO Server Discovery October 2012
4. Deployment Considerations
The mechanism specified in this document needs some configuration
effort in order to work properly.
4.1. IPv4 PTR lookup
Especially the domain name retrieved through the reverse DNS lookup
(PTR records) and the U-NAPTR entry need to be coordinated. In this
section we discuss this configuration for different scenarios.
4.1.1. Private customers or very small businesses
For private customers and very small businesses that are DSL or cable
customers often a dynamically assigned IP address is provisioned.
Here, the reverse DNS lookup (PTR records) are controlled by the ISP
and they point to the ISP's domain, e.g.:
d-c-b-a.dsl.westcoast.my-isp.net
In this case, it would be the responsibility of the respective ISP to
provide U-NAPTR entries for the DNS suffix without the endhost part,
e.g.:
westcoast.my-isp.net
4.1.2. Medium-size customer networks
The second class of customers have their own DNS domain but only one
single upstream ISP, e.g.:
(1) ISP my-isp.net assigns an IP address a.b.c.d to its customer
(2) The customer decides that reverse mapping for a.b.c.d should be
whatever.customerdomain.com
(3) If the customer wants to support ALTO, he has to ask the ISP for
the URI of the ISP's ALTO server which can give guidance to
a.b.c.d. Assume that ISP replies it is
http://altoserver.my-isp.net
(4) The customer establishes a U-NAPTR entry for his domain
customerdomain.com. IN NAPTR 200 10 "u" "ALTO:http"
"!.*!http://altoserver.my-isp.net!" ""
Kiesel & Stiemerling Expires April 25, 2013 [Page 8]
Internet-Draft Third-Party ALTO Server Discovery October 2012
4.1.3. Large Customers
For very large customers with multiple upstream connections we assume
that they have their very own traffic optimization policies and thus
run their own ALTO server anyway. In this case they need to manage
their DNS entries accordingly.
4.2. IPv6 PTR lookup
The IPv6 address space per subnet is much larger than with IPv4 and
mechanisms such as privacy extensions allow a host to randomly pick
an IP address. Establishing static PTR records for all IPv6
addresses in a /64 prefix is a cumbersome task and unlikely to
happen. One alternative is the use of dynamic DNS. Another option
is to do without PTR records for individual IP addresses and just
have a PTR record for the "network address". The algorithm presented
in the figure above can deal with that situation due to the second
PTR lookup on (addr/64) if the direct PTR lookup fails.
Kiesel & Stiemerling Expires April 25, 2013 [Page 9]
Internet-Draft Third-Party ALTO Server Discovery October 2012
5. Operational Considerations
TBD.
Kiesel & Stiemerling Expires April 25, 2013 [Page 10]
Internet-Draft Third-Party ALTO Server Discovery October 2012
6. Security Considerations
TBD. See also [I-D.ietf-alto-server-discovery].
Kiesel & Stiemerling Expires April 25, 2013 [Page 11]
Internet-Draft Third-Party ALTO Server Discovery October 2012
7. IANA Considerations
None.
Kiesel & Stiemerling Expires April 25, 2013 [Page 12]
Internet-Draft Third-Party ALTO Server Discovery October 2012
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-alto-deployments]
Stiemerling, M. and S. Kiesel, "ALTO Deployment
Considerations", draft-ietf-alto-deployments-03 (work in
progress), November 2011.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-13 (work in progress),
September 2012.
[I-D.ietf-alto-server-discovery]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
S. Yongchao, "ALTO Server Discovery",
draft-ietf-alto-server-discovery-04 (work in progress),
July 2012.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", RFC 6708, September 2012.
Kiesel & Stiemerling Expires April 25, 2013 [Page 13]
Internet-Draft Third-Party ALTO Server Discovery October 2012
Appendix A. Contributors List and Acknowledgments
The initial version of this document was co-authored by Marco Tomsu
<marco.tomsu@alcatel-lucent.com>.
Hannes Tschofenig provided the initial input to the U-NAPTR solution
part. Hannes and Martin Thomson provided excellent feedback and
input to the server discovery.
This memo borrows a lot of text from
[I-D.ietf-alto-server-discovery], as the 3pdisc was historically part
of this memo. Special thanks to Michael Scharf and Nico Schwan.
Martin Stiemerling is partially supported by the CHANGE project (
http://www.change-project.eu), a research project supported by the
European Commission under its 7th Framework Program (contract no.
257422). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the CHANGE project or the European Commission.
Kiesel & Stiemerling Expires April 25, 2013 [Page 14]
Internet-Draft Third-Party ALTO Server Discovery October 2012
Authors' Addresses
Sebastian Kiesel
University of Stuttgart Computing Center
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/
Martin Stiemerling
NEC Laboratories Europe
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 113
Email: martin.stiemerling@neclab.eu
URI: http://ietf.stiemerling.org
Kiesel & Stiemerling Expires April 25, 2013 [Page 15]