tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7285

Proposed STD
Pages: 91
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ALTO

Application-Layer Traffic Optimization (ALTO) Protocol

Part 1 of 4, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                     R. Alimi, Ed.
Request for Comments: 7285                                        Google
Category: Standards Track                                  R. Penno, Ed.
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                            Y. Yang, Ed.
                                                         Yale University
                                                               S. Kiesel
                                                 University of Stuttgart
                                                              S. Previdi
                                                     Cisco Systems, Inc.
                                                                W. Roome
                                                          Alcatel-Lucent
                                                             S. Shalunov
                                                             Open Garden
                                                               R. Woundy
                                                                 Comcast
                                                          September 2014


         Application-Layer Traffic Optimization (ALTO) Protocol

Abstract

   Applications using the Internet already have access to some topology
   information of Internet Service Provider (ISP) networks.  For
   example, views to Internet routing tables at Looking Glass servers
   are available and can be practically downloaded to many network
   application clients.  What is missing is knowledge of the underlying
   network topologies from the point of view of ISPs.  In other words,
   what an ISP prefers in terms of traffic optimization -- and a way to
   distribute it.

   The Application-Layer Traffic Optimization (ALTO) services defined in
   this document provide network information (e.g., basic network
   location structure and preferences of network paths) with the goal of
   modifying network resource consumption patterns while maintaining or
   improving application performance.  The basic information of ALTO is
   based on abstract maps of a network.  These maps provide a simplified
   view, yet enough information about a network for applications to
   effectively utilize them.  Additional services are built on top of
   the maps.

   This document describes a protocol implementing the ALTO services.
   Although the ALTO services would primarily be provided by ISPs, other
   entities, such as content service providers, could also provide ALTO
   services.  Applications that could use the ALTO services are those
   that have a choice to which end points to connect.  Examples of such
   applications are peer-to-peer (P2P) and content delivery networks.

Page 2 
Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7285.

Copyright Notice

   Copyright (c) 2014 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.

Table of Contents

   1. Introduction ....................................................6
      1.1. Problem Statement ..........................................6
           1.1.1. Requirements Language ...............................7
      1.2. Design Overview ............................................7
   2. Terminology .....................................................7
      2.1. Endpoint ...................................................8
      2.2. Endpoint Address ...........................................8
      2.3. Network Location ...........................................8
      2.4. ALTO Information ...........................................8
      2.5. ALTO Information Base ......................................8
   3. Architecture ....................................................8
      3.1. ALTO Services and Protocol Scope ...........................9
      3.2. ALTO Information Reuse and Redistribution .................11
   4. ALTO Information Service Framework .............................11
      4.1. ALTO Information Services .................................12
           4.1.1. Map Service ........................................12
           4.1.2. Map-Filtering Service ..............................12

Top      ToC       Page 3 
           4.1.3. Endpoint Property Service ..........................12
           4.1.4. Endpoint Cost Service ..............................13
   5. Network Map ....................................................13
      5.1. Provider-Defined Identifier (PID) .........................13
      5.2. Endpoint Addresses ........................................14
      5.3. Example Network Map .......................................14
   6. Cost Map .......................................................15
      6.1. Cost Types ................................................16
           6.1.1. Cost Metric ........................................16
           6.1.2. Cost Mode ..........................................17
      6.2. Cost Map Structure ........................................18
      6.3. Network Map and Cost Map Dependency .......................18
      6.4. Cost Map Update ...........................................19
   7. Endpoint Properties ............................................19
      7.1. Endpoint Property Type ....................................19
           7.1.1. Endpoint Property Type: pid ........................19
   8. Protocol Specification: General Processing .....................19
      8.1. Overall Design ............................................19
      8.2. Notation ..................................................20
      8.3. Basic Operations ..........................................21
           8.3.1. Client Discovering Information Resources ...........21
           8.3.2. Client Requesting Information Resources ............22
           8.3.3. Server Responding to Information Resource Request ..22
           8.3.4. Client Handling Server Response ....................23
           8.3.5. Authentication and Encryption ......................23
           8.3.6. Information Refreshing .............................24
           8.3.7. Parsing of Unknown Fields ..........................24
      8.4. Server Response Encoding ..................................24
           8.4.1. Meta Information ...................................24
           8.4.2. Data Information ...................................25
      8.5. Protocol Errors ...........................................25
           8.5.1. Media Type .........................................25
           8.5.2. Response Format and Error Codes ....................25
           8.5.3. Overload Conditions and Server Unavailability ......28
   9. Protocol Specification: Information Resource Directory .........28
      9.1. Information Resource Attributes ...........................29
           9.1.1. Resource ID ........................................29
           9.1.2. Media Type .........................................29
           9.1.3. Capabilities .......................................29
           9.1.4. Accepts Input Parameters ...........................29
           9.1.5. Dependent Resources ................................30
      9.2. Information Resource Directory (IRD) ......................30
           9.2.1. Media Type .........................................30
           9.2.2. Encoding ...........................................30
           9.2.3. Example ............................................32
           9.2.4. Delegation Using IRD ...............................35
           9.2.5. Considerations of Using IRD ........................37
   10. Protocol Specification: Basic Data Types ......................38

Top      ToC       Page 4 
      10.1. PID Name .................................................38
      10.2. Resource ID ..............................................38
      10.3. Version Tag ..............................................38
      10.4. Endpoints ................................................39
           10.4.1. Typed Endpoint Addresses ..........................39
           10.4.2. Address Type ......................................39
           10.4.3. Endpoint Address ..................................40
           10.4.4. Endpoint Prefixes .................................40
           10.4.5. Endpoint Address Group ............................41
      10.5. Cost Mode ................................................41
      10.6. Cost Metric ..............................................42
      10.7. Cost Type ................................................42
      10.8. Endpoint Property ........................................42
           10.8.1. Resource-Specific Endpoint Properties .............43
           10.8.2. Global Endpoint Properties ........................43
   11. Protocol Specification: Service Information Resources .........43
      11.1. Meta Information .........................................43
      11.2. Map Service ..............................................43
           11.2.1. Network Map .......................................44
           11.2.2. Mapping IP Addresses to PIDs for
                   'ipv4'/'ipv6' Network Maps ........................46
           11.2.3. Cost Map ..........................................47
      11.3. Map-Filtering Service ....................................50
           11.3.1. Filtered Network Map ..............................50
           11.3.2. Filtered Cost Map .................................53
      11.4. Endpoint Property Service ................................57
           11.4.1. Endpoint Property .................................58
      11.5. Endpoint Cost Service ....................................61
           11.5.1. Endpoint Cost .....................................61
   12. Use Cases .....................................................64
      12.1. ALTO Client Embedded in P2P Tracker ......................65
      12.2. ALTO Client Embedded in P2P Client: Numerical Costs ......66
      12.3. ALTO Client Embedded in P2P Client: Ranking ..............67
   13. Discussions ...................................................68
      13.1. Discovery ................................................68
      13.2. Hosts with Multiple Endpoint Addresses ...................68
      13.3. Network Address Translation Considerations ...............69
      13.4. Endpoint and Path Properties .............................69
   14. IANA Considerations ...........................................70
      14.1. application/alto-* Media Types ...........................70
      14.2. ALTO Cost Metric Registry ................................71
      14.3. ALTO Endpoint Property Type Registry .....................73
      14.4. ALTO Address Type Registry ...............................75
      14.5. ALTO Error Code Registry .................................76
   15. Security Considerations .......................................76
      15.1. Authenticity and Integrity of ALTO Information ...........77
           15.1.1. Risk Scenarios ....................................77
           15.1.2. Protection Strategies .............................77

Top      ToC       Page 5 
           15.1.3. Limitations .......................................77
      15.2. Potential Undesirable Guidance from Authenticated ALTO
            Information ..............................................78
           15.2.1. Risk Scenarios ....................................78
           15.2.2. Protection Strategies .............................78
      15.3. Confidentiality of ALTO Information ......................79
           15.3.1. Risk Scenarios ....................................79
           15.3.2. Protection Strategies .............................79
           15.3.3. Limitations .......................................80
      15.4. Privacy for ALTO Users ...................................80
           15.4.1. Risk Scenarios ....................................80
           15.4.2. Protection Strategies .............................80
      15.5. Availability of ALTO Services ............................81
           15.5.1. Risk Scenarios ....................................81
           15.5.2. Protection Strategies .............................81
   16. Manageability Considerations ..................................81
      16.1. Operations ...............................................82
           16.1.1. Installation and Initial Setup ....................82
           16.1.2. Migration Path ....................................82
           16.1.3. Dependencies on Other Protocols and
                   Functional Components .............................83
           16.1.4. Impact and Observation on Network Operation .......83
      16.2. Management ...............................................84
           16.2.1. Management Interoperability .......................84
           16.2.2. Management Information ............................84
           16.2.3. Fault Management ..................................84
           16.2.4. Configuration Management ..........................84
           16.2.5. Performance Management ............................85
           16.2.6. Security Management ...............................85
   17. References ....................................................85
      17.1. Normative References .....................................85
      17.2. Informative References ...................................86
   Appendix A. Acknowledgments .......................................89
   Appendix B. Design History and Merged Proposals ...................90

Top      ToC       Page 6 
1.  Introduction

1.1.  Problem Statement

   This document defines the ALTO Protocol, which provides a solution
   for the problem stated in [RFC5693].  Specifically, in today's
   networks, network information such as network topologies, link
   availability, routing policies, and path costs are hidden from the
   application layer, and many applications benefited from such hiding
   of network complexity.  However, new applications, such as
   application-layer overlays, can benefit from information about the
   underlying network infrastructure.  In particular, these new network
   applications can be adaptive; hence, they can become more network
   efficient (e.g., reduce network resource consumption) and achieve
   better application performance (e.g., accelerated download rate), by
   leveraging network-provided information.

   At a high level, the ALTO Protocol specified in this document is an
   information-publishing interface that allows a network to publish its
   network information such as network locations, costs between them at
   configurable granularities, and endhost properties to network
   applications.  The information published by the ALTO Protocol should
   benefit both the network and the applications (i.e., the consumers of
   the information).  Either the operator of the network or a third
   party (e.g., an information aggregator) can retrieve or derive
   related information of the network and publish it using the ALTO
   Protocol.

   To allow better understanding of the goal of the ALTO Protocol, this
   document provides a short, non-normative overview of the benefits of
   ALTO to both networks and applications:

   o  A network that provides ALTO information can achieve better
      utilization of its networking infrastructure.  For example, by
      using ALTO as a tool to interact with applications, a network is
      able to provide network information to applications so that the
      applications can better manage traffic on more expensive or
      difficult-to-provision links such as long-distance, transit, or
      backup links.  During the interaction, the network can choose to
      protect its sensitive and confidential network state information,
      by abstracting real metric values into non-real numerical scores
      or ordinal ranking.

   o  An application that uses ALTO information can benefit from better
      knowledge of the network to avoid network bottlenecks.  For
      example, an overlay application can use information provided by
      the ALTO services to avoid selecting peers connected via high-
      delay links (e.g., some intercontinental links).  Using ALTO to

Top      ToC       Page 7 
      initialize each node with promising ("better-than-random") peers,
      an adaptive peer-to-peer overlay may achieve faster, better
      convergence.

1.1.1.  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].

1.2.  Design Overview

   The ALTO Protocol specified in this document meets the ALTO
   requirements specified in [RFC5693], and unifies multiple protocols
   previously designed with similar intentions.  See Appendix A for a
   list of people and Appendix B for a list of proposals that have made
   significant contributions to this effort.

   The ALTO Protocol uses a REST-ful (Representational State Transfer
   (REST)) design [Fielding-Thesis], and encodes its requests and
   responses using JSON [RFC7159].  These designs are chosen because of
   their flexibility and extensibility.  In addition, these designs make
   it possible for ALTO to be deployed at scale by leveraging existing
   HTTP [RFC7230] implementations, infrastructures and deployment
   experience.

   The ALTO Protocol uses a modular design by dividing ALTO information
   publication into multiple ALTO services (e.g., the Map service, the
   Map-Filtering Service, the Endpoint Property Service, and the
   Endpoint Cost Service).  Each ALTO service provides a given set of
   functionalities and is realized by a set of information resources,
   which are announced by information resource directories, to guide
   ALTO clients.

2.  Terminology

   This document uses the following terms defined in [RFC5693]:
   Application, Overlay Network, Peer, Resource, Resource Identifier,
   Resource Provider, Resource Consumer, Resource Directory, Transport
   Address, ALTO Server, ALTO Client, ALTO Query, ALTO Response, ALTO
   Transaction, Local Traffic, Peering Traffic, and Transit Traffic.

   This document extends the term "ALTO Service" defined in [RFC5693].
   In particular, by adopting a modular design, this document allows the
   ALTO Protocol to provide multiple ALTO services.

Top      ToC       Page 8 
   This document also uses the following additional terms: Endpoint
   Address, Network Location, ALTO Information, and ALTO Information
   Base.

2.1.  Endpoint

   An endpoint is an application or host that is capable of
   communicating (sending and/or receiving messages) on a network.

   An endpoint is typically either a resource provider or a resource
   consumer.

2.2.  Endpoint Address

   An endpoint address represents the communication address of an
   endpoint.  Common forms of endpoint addresses include IP addresses,
   Media Access Control (MAC) addresses, and overlay IDs.  An endpoint
   address can be network-attachment based (e.g., IP address) or
   network-attachment agnostic (e.g., MAC address).

   Each endpoint address has an associated address type, which indicates
   both its syntax and semantics.

2.3.  Network Location

   This document uses network location as a generic term to denote a
   single endpoint or a group of endpoints.  For instance, it can be a
   single IPv4 or IPv6 address, an IPv4 or IPv6 prefix, or a set of
   prefixes.

2.4.  ALTO Information

   This document uses ALTO information as a generic term to refer to the
   network information provided by an ALTO server.

2.5.  ALTO Information Base

   This document uses the term ALTO information base to refer to the
   internal representation of ALTO information maintained by an ALTO
   server.  Note that the structure of this internal representation is
   not defined by this document.

3.  Architecture

   This section defines the ALTO architecture and the ALTO Protocol's
   place in the overall architecture.

Top      ToC       Page 9 
3.1.  ALTO Services and Protocol Scope

   Each network region in the global Internet can provide its ALTO
   services, which convey network information from the perspective of
   that network region.  A network region in this context can be an
   Autonomous System (AS), an ISP, a region smaller than an AS or ISP,
   or a set of ISPs.  The specific network region that an ALTO service
   represents will depend on the ALTO deployment scenario and ALTO
   service discovery mechanism.

   The ALTO services specified in this document define network endpoints
   (and aggregations thereof) and generic costs amongst them from the
   region's perspective.  The network endpoints may include all
   endpoints in the global Internet.  We say that the network
   information provided by the ALTO services of a network region
   represents the "my-Internet view" of the network region.

   The "my-Internet view" defined in this document does not specify the
   internal topology of a network, and hence, it is said to provide a
   "single-node" abstract topology.  Extensions to this document may
   provide topology details in "my-Internet view".

   Figure 1 provides an overall picture of ALTO's system architecture,
   so that one can better understand the ALTO services and the role of
   the ALTO Protocol.  In this architecture, an ALTO server prepares
   ALTO information, an ALTO client uses ALTO service discovery to
   identify an appropriate ALTO server, and the ALTO client requests
   available ALTO information from the ALTO server using the ALTO
   Protocol.

   The ALTO information provided by the ALTO server can be updated
   dynamically based on network conditions, or they can be seen as a
   policy that is updated on a longer time scale.

Top      ToC       Page 10 
   +-------------------------------------------------------------------+
   |                         Network Region                            |
   |                                                                   |
   |                    +-----------+                                  |
   |                    | Routing   |                                  |
   |  +--------------+  | Protocols |                                  |
   |  | Provisioning |  +-----------+                                  |
   |  | Policy       |        |                                        |
   |  +--------------+\       |                                        |
   |                   \      |                                        |
   |                    \     |                                        |
   |  +-----------+      \+---------+                      +--------+  |
   |  |Dynamic    |       | ALTO    | ALTO Protocol        | ALTO   |  |
   |  |Network    |.......| Server  | ==================== | Client |  |
   |  |Information|       +---------+                      +--------+  |
   |  +-----------+      /                                /            |
   |                    /         ALTO SD Query/Response /             |
   |                   /                                /              |
   |          +----------+                  +----------------+         |
   |          | External |                  | ALTO Service   |         |
   |          | Interface|                  | Discovery (SD) |         |
   |          +----------+                  +----------------+         |
   |               |                                                   |
   +-------------------------------------------------------------------+
                   |
         +------------------+
         | Third Parties    |
         |                  |
         | Content Providers|
         +------------------+

                     Figure 1: Basic ALTO Architecture

   Figure 1 illustrates that the ALTO information provided by an ALTO
   server may be influenced (at the service provider's discretion) by
   other systems.  In particular, the ALTO server can aggregate
   information from multiple systems to provide an abstract and unified
   view that can be more useful to applications.  Examples of other
   systems include (but are not limited to) static network configuration
   databases, dynamic network information, routing protocols,
   provisioning policies, and interfaces to outside parties.  These
   components are shown in the figure for completeness but are outside
   the scope of this specification.  Recall that while the ALTO Protocol
   may convey dynamic network information, it is not intended to replace
   near-real-time congestion control protocols.

Top      ToC       Page 11 
   It may also be possible for an ALTO server to exchange network
   information with other ALTO servers (either within the same
   administrative domain or another administrative domain with the
   consent of both parties) in order to adjust exported ALTO
   information.  Such a protocol is also outside the scope of this
   specification.

3.2.  ALTO Information Reuse and Redistribution

   ALTO information may be useful to a large number of applications and
   users.  At the same time, distributing ALTO information must be
   efficient and not become a bottleneck.

   The design of the ALTO Protocol allows integration with the existing
   HTTP caching infrastructure to redistribute ALTO information.  If
   caching or redistribution is used, the response message to an ALTO
   client may be returned from a third party.

   Application-dependent mechanisms, such as P2P Distributed Hash Tables
   (DHTs) or P2P file sharing, may be used to cache and redistribute
   ALTO information.  This document does not define particular
   mechanisms for such redistribution.

   Additional protocol mechanisms (e.g., expiration times and digital
   signatures for returned ALTO information) are left for future
   investigation.

4.  ALTO Information Service Framework

   The ALTO Protocol conveys network information through ALTO
   information services (services for short), where each service defines
   a set of related functionalities.  An ALTO client can request each
   service individually.  All of the services defined in ALTO are said
   to form the ALTO service framework and are provided through a common
   transport protocol; messaging structure and encoding; and transaction
   model.  Functionalities offered in different services can overlap.

   The goals of the ALTO information services defined in this document
   are to convey (1) network locations, which denote the locations of
   endpoints at a network, (2) provider-defined costs for paths between
   pairs of network locations, and (3) network-related properties of
   endpoints.  The aforementioned goals are achieved by defining the Map
   Service, which provides the core ALTO information to clients, and
   three additional information services: the Map-Filtering Service, the
   Endpoint Property Service (EPS), and the Endpoint Cost Service (ECS).
   Additional information services can be defined in companion
   documents.  Figure 2 gives an overview of the information services.
   Details of the services are presented in subsequent sections.

Top      ToC       Page 12 
        .-----------------------------------------.
        | ALTO Information Services               |
        | .-----------. .----------. .----------. |
        | |    Map-   | | Endpoint | | Endpoint | |
        | | Filtering | | Property | |   Cost   | |
        | |  Service  | | Service  | | Service  | |
        | `-----------' `----------' `----------' |
        | .-------------------------------------. |
        | |  Map Service                        | |
        | |  .-------------.  .--------------.  | |
        | |  | Network Map |  |  Cost Map    |  | |
        | |  `-------------'  `--------------'  | |
        | `-------------------------------------' |
        `-----------------------------------------'

      Figure 2: ALTO Information Service Framework

4.1.  ALTO Information Services

4.1.1.  Map Service

   The Map Service provides batch information to ALTO clients in the
   forms of ALTO network maps (network maps for short) and ALTO cost
   maps (cost maps for short).  An ALTO network map (See Section 5)
   provides a full set of network location groupings defined by the ALTO
   server and the endpoints contained within each grouping.  An ALTO
   cost map (see Section 6) provides costs between defined groupings.

   These two maps can be thought of (and implemented) as simple files
   with appropriate encoding provided by the ALTO server.

4.1.2.  Map-Filtering Service

   Resource-constrained ALTO clients may benefit from the filtering of
   query results at the ALTO server.  This avoids the situation in which
   an ALTO client first spends network bandwidth and CPU cycles to
   collect results and then performs client-side filtering.  The Map-
   Filtering Service allows ALTO clients to query an ALTO server on ALTO
   network maps and/or cost maps based on additional parameters.

4.1.3.  Endpoint Property Service

   This service allows ALTO clients to look up properties for individual
   endpoints.  An example property of an endpoint is its network
   location (i.e., its grouping defined by the ALTO server).  Another
   example property is its connectivity type such as ADSL (Asymmetric
   Digital Subscriber Line), Cable, or FTTH (Fiber To The Home).

Top      ToC       Page 13 
4.1.4.  Endpoint Cost Service

   Some ALTO clients may also benefit from querying for costs and
   rankings based on endpoints.  The Endpoint Cost Service allows an
   ALTO server to return costs directly amongst endpoints.

5.  Network Map

   An ALTO network map defines a grouping of network endpoints.  This
   document uses ALTO network map to refer to the syntax and semantics
   of how an ALTO server defines the grouping.  This document does not
   discuss the internal representation of this data structure within an
   ALTO server.

   The definition of ALTO network maps is based on the observation that,
   in reality, many endpoints are near by to one another in terms of
   network connectivity.  By treating a group of nearby endpoints
   together as a single entity, an ALTO server indicates aggregation of
   these endpoints due to their proximity.  This aggregation can also
   lead to greater scalability without losing critical information when
   conveying other network information (e.g., when defining cost maps).

5.1.  Provider-Defined Identifier (PID)

   One issue is that proximity varies depending on the granularity of
   the ALTO information configured by the provider.  In one deployment,
   endpoints on the same subnet may be considered close; while in
   another deployment, endpoints connected to the same Point of Presence
   (POP) may be considered close.

   ALTO introduces provider-defined network location identifiers called
   Provider-defined Identifiers (PIDs) to provide an indirect and
   network-agnostic way to specify an aggregation of network endpoints
   that may be treated similarly, based on network topology, type, or
   other properties.  Specifically, a PID is a string of type PIDName
   (see Section 10.1) and its associated set of endpoint addresses.  As
   discussed above, there can be many different ways of grouping the
   endpoints and assigning PIDs.  For example, a PID may denote a
   subnet, a set of subnets, a metropolitan area, a POP, an autonomous
   system, or a set of autonomous systems.  Interpreting the PIDs
   defined in an ALTO network map using the "single-node" abstraction,
   one can consider that each PID represents an abstract port (POP) that
   connects a set of endpoints.

   A key use case of PIDs is to specify network preferences (costs)
   between PIDs instead of individual endpoints.  This allows cost
   information to be more compactly represented and updated at a faster
   time scale than the network aggregations themselves.  For example, an

Top      ToC       Page 14 
   ISP may prefer that endpoints associated with the same POP in a P2P
   application communicate locally instead of communicating with
   endpoints in other POPs.  The ISP may aggregate endpoints within a
   POP into a single PID in a network map.  The cost may be encoded to
   indicate that network locations within the same PID are preferred;
   for example, cost(PID_i, PID_i) == c and cost(PID_i, PID_j) > c for i
   != j.  Section 6 provides further details on using PIDs to represent
   costs in an ALTO cost map.

5.2.  Endpoint Addresses

   The endpoints aggregated into a PID are denoted by endpoint
   addresses.  There are many types of addresses, such as IP addresses,
   MAC addresses, or overlay IDs.  This document specifies (in
   Section 10.4) how to specify IPv4/IPv6 addresses or prefixes.
   Extension documents may define further address types; Section 14.4 of
   this document provides an IANA registry for endpoint address types.

5.3.  Example Network Map

   This document uses the ALTO network map shown in Figure 3 in most
   examples.

Top      ToC       Page 15 
       .------------------------------------------------------------.
       | An ALTO Network Map                                        |
       |                                                            |
       |  .-----------------------------------.  .----------------. |
       |  | NetLoc: PID-1                     |  | NetLoc: PID-3  | |
       |  |  .------------------------------. |  |                | |
       |  |  | 192.0.2.0/24                 | |  |  .-----------. | |
       |  |  | .--------------------------. | |  |  | 0.0.0.0/0 | | |
       |  |  | | Endpoint: 192.0.2.34     | | |  |  `-----------` | |
       |  |  | `--------------------------` | |  |                | |
       |  |  `------------------------------` |  |                | |
       |  |  .------------------------------. |  |                | |
       |  |  | 198.51.100.0/25              | |  |                | |
       |  |  | .--------------------------. | |  |                | |
       |  |  | | Endpoint: 198.51.100.100 | | |  |                | |
       |  |  | `--------------------------` | |  |                | |
       |  |  `------------------------------` |  |                | |
       |  `-----------------------------------`  |                | |
       |                                         |                | |
       |  .-----------------------------------.  |                | |
       |  | NetLoc: PID-2                     |  |                | |
       |  |  .------------------------------. |  |                | |
       |  |  | 198.51.100.128/25            | |  |                | |
       |  |  `------------------------------` |  |                | |
       |  `-----------------------------------`  `----------------` |
       `------------------------------------------------------------`

                       Figure 3: Example Network Map

6.  Cost Map

   An ALTO server indicates preferences amongst network locations in the
   form of path costs.  Path costs are generic costs and can be
   internally computed by a network provider according to its own
   policy.

   For a given ALTO network map, an ALTO cost map defines path costs
   pairwise amongst the set of source and destination network locations
   defined by the PIDs contained in the network map.  Each path cost is
   the end-to-end cost when a unit of traffic goes from the source to
   the destination.

   Since cost is directional from the source to the destination, an
   application, when using ALTO information, may independently determine
   how the resource consumer and resource provider are designated as the
   source or destination in an ALTO query and, hence, how to utilize the
   path cost provided by ALTO information.  For example, if the cost is

Top      ToC       Page 16 
   expected to be correlated with throughput, a typical application
   concerned with bulk data retrieval may use the resource provider as
   the source and the resource consumer as the destination.

   One advantage of separating ALTO information into network maps and
   cost maps is that the two types of maps can be updated at different
   time scales.  For example, network maps may be stable for a longer
   time while cost maps may be updated to reflect more dynamic network
   conditions.

   As used in this document, an ALTO cost map refers to the syntax and
   semantics of the information distributed by the ALTO server.  This
   document does not discuss the internal representation of this data
   structure within the ALTO server.

6.1.  Cost Types

   Path costs have attributes:

   o  Cost Metric: identifies what the costs represent;

   o  Cost Mode: identifies how the costs should be interpreted.

   The combination of a cost metric and a cost mode defines an ALTO cost
   type.  Certain queries for ALTO cost maps allow the ALTO client to
   indicate the desired cost type.  For a given ALTO server, the
   combination of cost type and network map defines a key.  In other
   words, an ALTO server MUST NOT define two ALTO cost maps with the
   same cost type \ network map pair.

6.1.1.  Cost Metric

   The cost metric attribute indicates what the cost represents.  For
   example, an ALTO server could define costs representing air miles,
   hop-counts, or generic routing costs.

   Cost metrics are indicated in protocol messages as strings.

6.1.1.1.  Cost Metric: routingcost

   An ALTO server MUST offer the "routingcost" cost metric.

   This cost metric conveys a generic measure for the cost of routing
   traffic from a source to a destination.  A lower value indicates a
   higher preference for traffic to be sent from a source to a
   destination.

Top      ToC       Page 17 
   Note that an ISP may internally compute routing cost using any method
   that it chooses (e.g., air miles or hop-count) as long as it conforms
   to the semantics.

6.1.2.  Cost Mode

   The cost mode attribute indicates how costs should be interpreted.
   Specifically, the cost mode attribute indicates whether returned
   costs should be interpreted as numerical values or ordinal rankings.

   It is important to communicate such information to ALTO clients, as
   certain operations may not be valid on certain costs returned by an
   ALTO server.  For example, it is possible for an ALTO server to
   return a set of IP addresses with costs indicating a ranking of the
   IP addresses.  Arithmetic operations that would make sense for
   numerical values, do not make sense for ordinal rankings.  ALTO
   clients may handle such costs differently.

   Cost modes are indicated in protocol messages as strings.

   An ALTO server MUST support at least one of the following modes:
   numerical and ordinal.  An ALTO client needs to be cognizant of
   operations when its desired cost mode is not supported.
   Specifically, an ALTO client desiring numerical costs MAY adjust its
   behaviors if only the ordinal cost mode is available.  Alternatively,
   an ALTO client desiring ordinal costs MAY construct ordinal costs
   from retrieved numerical values, if only the numerical cost mode is
   available.

6.1.2.1.  Cost Mode: numerical

   This cost mode is indicated by the string "numerical".  This mode
   indicates that it is safe to perform numerical operations (e.g.,
   normalization or computing ratios for weighted load-balancing) on the
   returned costs.  The values are floating-point numbers.

6.1.2.2.  Cost Mode: ordinal

   This cost mode is indicated by the string "ordinal".  This mode
   indicates that the cost values in a cost map represent ranking
   (relative to all other values in a cost map), not actual costs.  The
   values are non-negative integers, with a lower value indicating a
   higher preference.  Ordinal cost values in a cost map need not be
   unique or contiguous.  In particular, it is possible that two entries
   in a cost map have an identical rank (ordinal cost value).  This
   document does not specify any behavior by an ALTO client in this
   case; an ALTO client may decide to break ties by random selection,
   other application knowledge, or some other means.

Top      ToC       Page 18 
6.2.  Cost Map Structure

   A request for an ALTO cost map will either explicitly or implicitly
   include a list of source network locations and a list of destination
   network locations.  (Recall that a network location can be an
   endpoint address or a PID.)

   Specifically, assume that a request specifies a list of source
   network locations, say [Src_1, Src_2, ..., Src_m], and a list of
   destination network locations, say [Dst_1, Dst_2, ..., Dst_n].

   The ALTO server will return the path cost for each of the m*n
   communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ...,
   Src_m -> Dst_1, ..., Src_m -> Dst_n).  If the ALTO server does not
   define the path cost for a particular pair, that cost may be omitted.
   This document refers to this structure as a cost map.

   If the cost mode is ordinal, the path cost of each communicating pair
   is relative to the m*n entries.

6.3.  Network Map and Cost Map Dependency

   An ALTO cost map gives path costs between the PIDs defined in an ALTO
   network map.  An ALTO server may modify an ALTO network map at any
   time, say by adding or deleting PIDs, or even redefining them.
   Hence, to effectively use an instance of an ALTO cost map, an ALTO
   client must know which version of the network map defined the PIDs in
   that cost map.  Version tags allow an ALTO client to correlate cost
   map instances with the corresponding versions of the network maps.

   Specifically, a version tag is a tuple of (1) an ID for the resource
   (e.g., an ALTO network map) and (2) a tag (an opaque string)
   associated with the version of that resource.  An ALTO network map
   distributed by an ALTO server includes its version tag.  An ALTO cost
   map referring to PIDs also includes the version tag for the network
   map on which it is based.

   Two ALTO network maps are the same if they have the same version tag.
   Whenever the content of an ALTO network map maintained by an ALTO
   server changes, the tag MUST also be changed.  Possibilities of
   setting the tag component include the last-modified timestamp for the
   network map, or a hash of its contents, where the collision
   probability is considered zero in practical deployment scenarios.

Top      ToC       Page 19 
6.4.  Cost Map Update

   An ALTO server can update an ALTO cost map at any time.  Hence, the
   same cost map retrieved from the same ALTO server but from different
   requests can be inconsistent.

7.  Endpoint Properties

   An endpoint property defines a network-aware property of an endpoint.

7.1.  Endpoint Property Type

   For each endpoint and an endpoint property type, there can be a value
   for the property.  The type of an endpoint property is indicated in
   protocol messages as a string.  The value depends on the specific
   property.  For example, for a property such as whether an endpoint is
   metered, the value is a true or false value.  See Section 10.8 for
   more details on specifying endpoint properties.

7.1.1.  Endpoint Property Type: pid

   An ALTO server MUST define the "pid" endpoint property type for each
   ALTO network map that it provides.  Specifically, each ALTO network
   map defines multiple PIDs.  For an "ipv4"/"ipv6" network map, given
   an endpoint's IP address, the ALTO server uses the algorithm
   specified in Section 11.2.2 to look up the PID of the endpoint.  This
   PID is the "pid" property of the endpoint for the network map.  See
   Section 11.4.1.7 for an example.



(page 19 continued on part 2)

Next RFC Part