@techreport{shalunov-alto-infoexport-00,
    number =    {draft-shalunov-alto-infoexport-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-shalunov-alto-infoexport/00/},
    author =    {Stanislav Shalunov and Reinaldo Penno and Richard Woundy},
    title =     {{ALTO Information Export Service}},
    pagetotal = 15,
    year =      2008,
    month =     oct,
    day =       27,
    abstract =  {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".},
}