Subject: I-D Action:draft-shalunov-alto-infoexport-00.txt

From: [email-masked]
Date: Mon, 27 Oct 2008 16:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : ALTO Information Export Service
	Author(s)       : S. Shalunov, et al.
	Filename        : draft-shalunov-alto-infoexport-00.txt
	Pages           : 15
	Date            : 2008-10-27

The ALTO Information Export Service is a simple way to convey ISP
routing policy preferences to applications.  Applications that could
use this service are those that have a choice in connection
endpoints.  Examples of such applications are peer-to-peer and
content delivery networks.

Applications already have access to great amount of underlying
topology information.  For example, views of the Internet routing
table are easily available at looking glass servers and entirely
practical to download to every client.  What is missing is the
routing policy information -- what does the local ISP actually
prefer?

This document describes a very simple mechanism that would allow to
export such information to applications.  While such service would
primarily be provided by the network, i.e., the local ISP, third
parties could also operate this service.1.  Requirements notation

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 [RFC2119].2.  Overview

Each network region can choose to support the ALTO service.  (A
network region in this context is an Autonomous System, an ISP, or
perhaps a smaller region -- the details depend on the mechanism of
discovery.)

The service works as follows:

1.  The ISP prepares the ALTO information.  This maps some IP

 prefixes or AS numbers into priority values.  Higher priority

 values indicate higher desirability of the prefix.  There is a

 default treatment for IP numbers that are in none of the prefixes

 or AS numbers.

2.  The ISP serializes the information into a sequence of octets

 (Section 4).

3.  The application, running on a given host, discovers the resource

 and fetches the serialized ALTO information (Section 3).

4.  The application makes use of the information by preferring IP

 numbers with higher priority (Section 5).

The part of the ISP MAY be implemented, to give a few examples that
do not preclude other implementation options,

by running a script connecting to existing equipment, fetching

routing information, and then generating and uploading the

requisite file;

by running a database-backed application that is obtains routing

information from existing equipment and generates the requisite

file dynamically;

by modifying the software or hardware of existing equipment to

support these functions; or

by using new equipment for the purpose of operating this network

service.3.  Discovery

Discovery per se is out of scope for this document and will be
handled separately.

The necessary property of discovery is that a client, starting from
nothing on today's Internet that does not yet universally support
global-scope multicast and may include NATs, can find a URL that
describes the location of the local ALTO service, as configured by
the ISP.

Subsequent sections assume that this URL is found.  So that maximum
number of clients can use the ALTO service, the URL schema SHOULD be
"http" or "https".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt