Internet DRAFT - draft-gao-alto-info-extension

draft-gao-alto-info-extension







ALTO WG                                                           K. Gao
Internet-Draft                                       Tsinghua University
Expires: January 7, 2016                                         Y. Yang
                                                         Yale University
                                                            July 6, 2015


        ALTO Extensions for Multi-Source Information Collection
                    draft-gao-alto-info-extension-01

Abstract

   The Application-Layer Traffic Optimization (ALTO) protocol enables
   the distribution of certain network information to applications.
   Hence, a fundamental functionality of an ALTO server is to collect
   general network information, especially from multiple "information
   sources".  In this document, we propose a preliminary solution to
   standardize the process of information collection for ALTO servers by
   extending the ALTO protocol with some new services, which can also
   serve as a unified approach of network information distribution.

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 January 7, 2016.

Copyright Notice

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



Gao & Yang               Expires January 7, 2016                [Page 1]

Internet-Draft               ALTO Extensions                   July 2015


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology and Notation  . . . . . . . . . . . . . . . .   4
   2.  ALTO Servers and Information Sources  . . . . . . . . . . . .   4
     2.1.  Information Sources . . . . . . . . . . . . . . . . . . .   4
     2.2.  Relationship Analysis . . . . . . . . . . . . . . . . . .   5
   3.  Protocol Design . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Common ALTO Information Bases . . . . . . . . . . . . . .   7
     3.2.  Overview of Extended ALTO Services  . . . . . . . . . . .   8
     3.3.  Extended Network Map  . . . . . . . . . . . . . . . . . .   8
     3.4.  Information Map . . . . . . . . . . . . . . . . . . . . .  12
     3.5.  Endpoint Information Service  . . . . . . . . . . . . . .  16
   4.  Future Improvement  . . . . . . . . . . . . . . . . . . . . .  20
     4.1.  Deriving ALTO Services from the Extensions  . . . . . . .  20
     4.2.  Information Aggregation Services  . . . . . . . . . . . .  21
     4.3.  Scope for Extended ALTO Services  . . . . . . . . . . . .  22
     4.4.  The Regulation of Property Specifications . . . . . . . .  22
     4.5.  Fetching Filtered Topological Information . . . . . . . .  23
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     6.1.  Media Types . . . . . . . . . . . . . . . . . . . . . . .  23
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   The "Application-Layer Traffic Optimization" protocol proposed in
   [RFC7285] defines several "maps" to publish network information to
   applications so that both the network providers and the application
   users can make better decisions on traffic steering and eventually
   achieve better performance.  However by specifying the protocol
   between ALTO clients and servers, [RFC7285] only describes part of
   the service model.  In this document we focus on the service model of
   ALTO servers.

   A fundamental functionality of the ALTO server is to collect
   information from what we call "information sources".  It is not
   surprising that there are many different information sources and thus
   we can describe a more complete service model for the server's side



Gao & Yang               Expires January 7, 2016                [Page 2]

Internet-Draft               ALTO Extensions                   July 2015


   in Figure 1, where the arrows indicate the direction of information
   flow.

                              +--------+  Method #1 +---------------+
                     ALTO     |        | <----------+  Information  |
      +----------+  Protocol  |        |            |   Source #1   |
      |   ALTO   | <--------- |        |            +---------------+
      |  Client  |            |        |
      +----------+            |        |  Method #2 +---------------+
                              |        | <----------+  Information  |
          ...        ...      |  ALTO  |            |   Source #2   |
                              | Server |            +---------------+
      +----------+   ALTO     |        |
      |   ALTO   |  Protocol  |        |    ...           ...
      |  Client  | <--------- |        |
      +----------+            |        |  Method #N +---------------+
                              |        | <----------+  Information  |
                              |        |            |   Source #N   |
                              +--------+            +---------------+

                Figure 1: Service Model for an ALTO server

   Since the relationships between ALTO servers and information sources
   can be very complex, as discussed in Section 2.2, the communication
   between them can hardly be unified.  Nevertheless, it is still
   possible and beneficial to design a generic protocol to collect
   statistics for servers implemented with certain patterns of ALTO
   information bases.

   With a standard protocol, the implementation of ALTO servers can be
   decoupled from the implementations of information sources, making it
   much easier to support the feature of fetching information from
   multiple sources and to be compatible with new information sources.
   Section 3 introduces the proposed protocol format in details.
   Despite the initial motivation to help ALTO server implementations
   gather necessary information, the protocol can also be applied as a
   unified information distribution method.

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








Gao & Yang               Expires January 7, 2016                [Page 3]

Internet-Draft               ALTO Extensions                   July 2015


1.2.  Terminology and Notation

   This document uses the following terms: Application, ALTO Server,
   ALTO Client and ALTO Response defined in [RFC5693]; Endpoint, ALTO
   Information and ALTO Information Base defined in [RFC7285].

   This document uses the same notations of describing JSON objects in
   [RFC7285], which are specified in [RFC7159].

   This document uses the following additional terms: Information
   Source.

   o  Information Source

      An information source is an entity that provides basic information
      for ALTO servers, see more detailed description in Section 2.1.

2.  ALTO Servers and Information Sources

   This section introduces the concept of "information sources" and
   discusses the possible relationships between an ALTO server and an
   information source.

2.1.  Information Sources

   An "information source" can be roughly described as any entity that
   is capable of providing information on the network but the exact
   meaning depends on the server implementation.  For example, in
   Software Defined Networking (SDN), for an ALTO server calculating the
   hop counts by calling the corresponding northbound API of a SDN
   controller, the controller is an information source.  Meanwhile, for
   an ALTO server using round trip time (RTT) as the routing cost
   metric, P2P clients submitting the statistics of a connection are
   regarded as information sources.  In this document we identify four
   major kinds of information sources:

   o  Human Input

      It is possible that the administrators of an ALTO server want to
      modify the output to meet the need of certain demands such as
      policy changes, so they may compose some data accordingly and
      input them into the server.  Also in the early stages of ALTO
      server development, human interference is inevitable to detect
      abnormal behavior.

   o  Network Measurement Tools





Gao & Yang               Expires January 7, 2016                [Page 4]

Internet-Draft               ALTO Extensions                   July 2015


      Due to financial, technical and security reasons it has been hard
      to fetch the required data directly from ISPs, thus many efforts
      have been made to measure different metrics using endpoint-based
      tools.  Since most of these tools require little support from the
      network infrastructure, lots of them can still work even if the
      Internet architecture evolves.  These measurement techniques can
      be valuable sources to ALTO services as the measured results often
      reflect the actual performance of the network.

   o  Network Operating Systems

      With the progress in opening up the network in recent years,
      especially with the development of SDN, the networking system
      itself has become an important source of network information.
      Using "northbound" APIs provided by SDN controllers, one can get
      both the configurations and the accurate running states of a
      network.

   o  Information Aggregators

      While information sources discussed above are capable to provide
      the "raw" data, these data can be aggregated, by a third-party
      aggregator or by a higher-level network OS as in some hierarchical
      SDN controller designs.  It is notable that an ALTO server itself
      can also be regarded as a source of aggregated information.

2.2.  Relationship Analysis

   The complexity of the relationships between ALTO servers and
   information sources comes from the following aspects:

   o  How to identify the boundary;

   o  How ALTO servers and information sources are coupled;

   o  The capabilities of information sources.

2.2.1.  Identification of Boundaries

   When we discuss the relationship between an ALTO server and the
   information source, it is important to identify the boundary first.
   As it is shown in Figure 2, we can see with different boundaries,
   different pairs of ALTO servers and information sources can be
   identified and their relationships are not quite the same.







Gao & Yang               Expires January 7, 2016                [Page 5]

Internet-Draft               ALTO Extensions                   July 2015


   +------------------+-----------------------------------------------+
   |  ALTO Server #A  |          Information Source #A                |


                          +---------------------------------------+
       +--------+         |  +---------+                          |
       |        |         |  |         |       Information        |
       |  Host  +------------+  Agent  |        Source #0         |
       |        |         |  |         |                          |
       +--------+         |  +---------+                          |
                          +---------------------------------------+

   |           ALTO SERVER #B             |   Information Source #B   |
   +--------------------------------------+---------------------------+

             Figure 2: Different Ways to Identify the Boundary

2.2.2.  Types of Coupling

   We identify three types of coupling ALTO servers and information
   sources.

   o  The ALTO server is deeply embedded into the information source,
      which is either a network OS or an information aggregator.  For
      example, our group has participated in a project to provide ALTO
      services in [OpenDaylight], an industrial SDN controller.

   o  The ALTO server is loosely coupled with the information source.
      One example is the ALTO server #A in Figure 2 if the host and
      agents are still coupled by some private protocol.

   o  The ALTO server is decoupled from the information sources by a
      standard protocol.  For example, an ALTO server which calculates
      its own costs by merging the routing costs from some other ALTO
      servers is decoupled from the its information sources as long as
      they can provide standard ALTO cost map service with the
      corresponding cost type.

2.2.3.  Capabilities of Information Sources

   The capabilities of an information source, which declare the types of
   available information, are determined by the type of the information
   source and the limitation of the targeted network, both of which can
   vary significantly.  However, many capabilities are attached to a
   certain network element such as a router, a link, an attachment
   point, etc., which can significantly reduce the complexity.





Gao & Yang               Expires January 7, 2016                [Page 6]

Internet-Draft               ALTO Extensions                   July 2015


3.  Protocol Design

   As described above it is difficult to define a unified protocol to
   cover the need of ALL ALTO server implementations.  However, we can
   narrow down the demands by establishing clear boundaries and focus on
   the most general and most commonly used requirements.

   An observation is made that as mentioned in Section 2.1, the ALTO
   servers are actually one kind of information source and the ALTO
   protocol is designed to publish certain network information.  Hence,
   instead of designing a new protocol for data collection, which would
   result in functionality overlap with ALTO and introduce complexity
   from an implementation perspective, the solution proposed in this
   document is based on the ALTO protocol to avoid these drawbacks.  In
   this case, information sources can also take advantages of the ALTO
   framework such as the service discovery mechanism, and current ALTO
   implementations don't have to change anything if they want to serve
   as information sources too.

   To clarify the boundaries of the targeted information and to exploit
   the limitation of the current ALTO specification, especially for the
   network map service, two internal representations of an ALTO
   information service are introduced.  We derive our design based on
   these two representations and discuss how to extend the ALTO
   specification so that the extensions can fit in the framework.

3.1.  Common ALTO Information Bases

   Two typical internal representations of ALTO server implementations,
   as known as ALTO information bases, are identified for ALTO services
   as discussed below.  It can be seen that both structures are highly
   related to and can reflect the information sources they use.

   o  End-to-End

      In an end-to-end implementation, the network is represented as a
      full-mesh graph where the links are implicit and can be ignored.
      This can happen when the corresponding information source collects
      the information either by conducting end-to-end measurement
      methods or by making requests to other end-to-end information
      resources, whether as an intentional choice or being forced to do
      so because of the limitations of conditions or priorities to get
      topological information.

   o  Topological

      In this case the server is using a graph with explicit nodes and
      links to represent a network.  The graph is usually sparse and may



Gao & Yang               Expires January 7, 2016                [Page 7]

Internet-Draft               ALTO Extensions                   July 2015


      have internal nodes that are transparent to the ALTO clients.
      Such examples are servers retrieving topology information from a
      SDN controller, from a data aggregator such as CAIDA, or simply
      from a configuration parser.

3.2.  Overview of Extended ALTO Services

   It can be seen that the current ALTO specifications only publish end-
   to-end information to the clients.  That is probably good enough for
   end users to choose from different destinations, however, it cannot
   satisfy the needs of an implementation with a topological ALTO
   information base because the original ALTO protocol is not capable of
   publishing topological information.

   To support this feature, the following extensions are proposed for
   ALTO protocol:

   o  Section 3.3 introduces an extension of network maps which enables
      the distribution of topologies;

   o  Section 3.4 introduces the extension to publish information for
      all elements defined in the extended network map.

   o  Section 3.5 introduces the extension to support querying
      information between two endpoints.

3.3.  Extended Network Map

   The extended network map can publish topological information such as
   links between different endpoints.  The data component in the
   response uses the classic vertex-edge representation to describe the
   topology.

   Just as with the network map, filtering is also possible for the
   extended network map but due to timing issues it is not discussed in
   this document.

3.3.1.  Media Type

   The media types for extended network map is defined in Section 6.1.

3.3.2.  HTTP Method

   The extended network map is requested using the HTTP GET method.







Gao & Yang               Expires January 7, 2016                [Page 8]

Internet-Draft               ALTO Extensions                   July 2015


3.3.3.  Accept Input Parameters

   None

3.3.4.  Capabilities

   The capabilities of an extended network map are described using a
   JSON object of type ExtNetworkMapCapabilities:

       object {
           JSONString type<1..1>;
       } ExtNetworkMapCapabilities;

   with fields:

   o  type: the type of information that is published.  Currently the
      only valid options are "end-to-end" and "topological".

3.3.5.  Uses

   None.

3.3.6.  Response

   The "meta" field of the response is the same as of network map
   responses.

   The data component of an extended network map service is named
   "extended-network-map", which is a JSON object of type
   ExtNetworkMapData, where

       object {
           ExtNetworkMapData   extended-network-map;
       } InfoResourceExtNetworkMap : ResponseEntityBase;

       object {
           NodeData            nodes;
           [LinkData            links;]
       } ExtNetworkMapData;

       object-map {
           NodeName -> NodeDesc;
       } EndpointData;

       object {
           [JSONBool            internal;]
       } NodeDesc : EndpointAddrGroup;




Gao & Yang               Expires January 7, 2016                [Page 9]

Internet-Draft               ALTO Extensions                   July 2015


       object-map {
           LinkName -> LinkDesc;
       } LinkData;

       object {
           JSONString          pid<2..2>;
           JSONString          direction;
       } LinkDesc;

   If the "type" field in the capabilities is "end-to-end", there MUST
   be no "links" field in the data component and no "internal" field in
   any node description.  At the same time, ALTO clients MUST ignore
   these fields if they are mistakenly provided.

   If the "type" field in the capabilities is "topological", the "links"
   field and the "internal" field MUST be provided.

   The "direction" field indicates the allowed direction of traffic.
   The optional values are "both", "ltr" and "rtl".  If the value is not
   "both", the pid MUST be sorted to represent the correct direction
   where "ltr" indicates the direction of pid_0 --> pid_1 while "rtl"
   indicates pid_0 <-- pid_0.

3.3.7.  Example

   Figure 3 demonstrates a simple topology.

           +-----------+                          +-----------+
           |  Node #1  |----\                     |  Node #4  |
           +-----------+     |                    +-----------+
              |              |                     |
              |              |                    /
              \              |                   /
               \       +-----------+      +-----------+
                -------|  Node #3  |______|  node #6  |
                       +-----------+      +-----------+
                          |                      |
                         /                        \
                        /                          \
           +-----------+                           +-----------+
           |  Node #2  |                           |  Node #5  |
           +-----------+                           +-----------+

                        Figure 3: Example Topology

   The example request and the corresponding response for the extended
   network map based on this topology is given below.




Gao & Yang               Expires January 7, 2016               [Page 10]

Internet-Draft               ALTO Extensions                   July 2015


       GET /extnetworkmap HTTP/1.1
       Host: alto.example.org
       Accept: application/alto-extnetworkmap+json,
               application/alto-error+json

       HTTP/1.1 200 OK
       Content-Length: 1252
       Content-type: application/alto-extnetworkmap+json

       {
         "meta" : {
           "vtag": {
             "resource-id": "extended-network-map-example",
             "tag": "67e6183c00fe467a960f174b93f23cf7"
           }
         },
         "extended-network-map": {
           "nodes": {
             "node#1": {
               "internal": "false",
               "ipv4": [ "192.168.1.0/28" ]
             },
             "node#2": {
               "internal": "false",
               "ipv4": [ "192.168.1.128/28" ]
             },
             "node#3": {
               "internal": "true"
             },
             "node#4": {
               "internal": "false",
               "ipv4": [ "192.168.2.0/28" ]
             },
             "node#5": {
               "internal": "false",
               "ipv4": [ "192.168.2.128/28" ]
             },
             "node#6": {
               "internal": "true"
             }
           },
           "links": {
             "link#1": {
               "pid": ["node#1", "node#3"],
               "direction": "both"
             },
             "link#2": {
               "pid": ["node#1", "node#3"],



Gao & Yang               Expires January 7, 2016               [Page 11]

Internet-Draft               ALTO Extensions                   July 2015


               "direction": "both"
             },
             "link#3": {
               "pid": ["node#2", "node#3"],
               "direction": "both"
             },
             "link#4": {
               "pid": ["node#4", "node#6"],
               "direction": "both"
             },
             "link#5": {
               "pid": ["node#5", "node#6"],
               "direction": "both"
             },
             "link#6": {
               "pid": ["node#3", "node#6"],
               "direction": "both"
             }
           }
         }
       }

3.4.  Information Map

   The information map has many similarities with the cost map.  Instead
   of providing only the "cost" between endpoints, it is extended to
   publish generic network information for both endpoint/node pairs and
   links.  It is notable that there are no explicit distinctions between
   attributes and statistics, where the former represent the essence and
   configurations of the object that should seldom change while the
   latter represent the dynamic running state of a network.  However, an
   ALTO server can provide such indications in the corresponding
   specifications.

   Due to timing issues, the filtering on the information map is not
   described in this document but it is worthy pointing out that the
   filtered information map is quite essential to enhance the
   performance of fetching data for the interested nodes or links.

3.4.1.  Media Type

   The media types for information map is defined in Section 6.1.

3.4.2.  HTTP Method

   The information map is requested using the HTTP GET method.





Gao & Yang               Expires January 7, 2016               [Page 12]

Internet-Draft               ALTO Extensions                   July 2015


3.4.3.  Accept Input Parameters

   None

3.4.4.  Capabilities

   The capabilities of an information map are described using a JSON
   object of type InfoMapCapabilities:

       object {
           JSONString    properties<0..*>;
       } InfoMapCapabilities;

   with fields:

   o  properties: the list containing the property names of paths and
      links.  The names SHOULD indicate the exact target using prefixes
      such as "path-" or "link-".  The properties here CAN contain both
      characteristic attributes and statistics for a given path/link.

3.4.5.  Uses

   The resource ID of the network map or the extended network map based
   on which the information map will be defined.

3.4.6.  Response

   The "meta" field of the response is described using the following
   JSON object:

       object {
           VersionTag    dependent-vtags<1..1>;
           VersionTag    vtag;
           [PropertyName -> PropertySpec;]
       } InfoMapMetaData;

       object {
           JSONString          type;
           [PropertyAttrName -> JSONValue;]
       } PropertySpec;

   with fields:

   o  vtag: the same as the "vtag" in the network map;

   o  dependent-vtags: the same as the "dependent-vtags" in the cost
      map, with the addition that resource ID can point to an extended
      network map;



Gao & Yang               Expires January 7, 2016               [Page 13]

Internet-Draft               ALTO Extensions                   July 2015


   o  PropertyName: the name listed in the capabilities.

   The "type" field in PropertySpec is either "path" or "link".

   The data component of an information map service is named
   "information-map", which is a JSON object of type InfoMapData, where:

       object {
           InfoMapData         information-map;
       } InfoResourceInfoMap : ResponseEntityBase;

       object-map {
           PropertyName -> PropertyMapData;
       } InfoMapData;

       object-map {
           NodeName -> { NodeName -> JSONValue };
       } PathPropertyData : PropertyMapData;

       object-map {
           LinkName -> JSONValue;
       } LinkPropertyData : PropertyMapData;

   If the "type" field in the corresponding PropertySpec is "path", the
   type of the PropertyMapData MUST be PathPropertyData and the same
   restriction rule applies to "link" and LinkPropertyData.

3.4.7.  Example

   The example of getting the hop counts between nodes, link cost and
   the link capacities is given below, using the topology in Figure 3.

       GET /example-infomap HTTP/1.1
       Host: alto.example.org
       Accept: application/alto-infomap+json,
               application/alto-error+json

       HTTP/1.1 200 OK
       Content-Length: 1434
       Content-type: application/alto-infomap+json

       {
         "meta": {
           "vtag": {
             "resource-id": "infomap-example",
             "tag": "e7822fdd03814561bdb955667ca06534"
           },
           "dependent-vtags": [



Gao & Yang               Expires January 7, 2016               [Page 14]

Internet-Draft               ALTO Extensions                   July 2015


             {
               "resource-id": "extended-network-map-example",
               "tag": "67e6183c00fe467a960f174b93f23cf7"
             }
           ],
           "path-hop-count-cost": {
             "type": "path",
             "mode": "numerical",
             "metric": "hopcount"
           },
           "link-cost": {
               "type": "link",
               "mode": "numerical",
               "metric": "routingcost"
           },
           "link-capacity": {
             "type": "link",
             "format": "text"
           }
         },
         "information-map": {
           "path-hop-count-cost": {
             "node#1": {
               "node#1": 0, "node#2": 2, "node#3": 1,
               "node#4": 3, "node#5": 3, "node#6": 2
             },
             "node#2": {
               "node#1": 2, "node#2": 0, "node#3": 1,
               "node#4": 3, "node#5": 3, "node#6": 2
             },
             "node#3": {
               "node#1": 1, "node#2": 1, "node#3": 0,
               "node#4": 2, "node#5": 2, "node#6": 1
             },
             "node#4": {
               "node#1": 3, "node#2": 3, "node#3": 2,
               "node#4": 0, "node#5": 2, "node#6": 1
             },
             "node#5": {
               "node#1": 3, "node#2": 3, "node#3": 2,
               "node#4": 2, "node#5": 0, "node#6": 1
             },
             "node#6": {
               "node#1": 2, "node#2": 2, "node#3": 1,
               "node#4": 1, "node#5": 1, "node#6": 0
             }
           },
           "link-cost": {



Gao & Yang               Expires January 7, 2016               [Page 15]

Internet-Draft               ALTO Extensions                   July 2015


               "link#1": 2,
               "link#2": 1,
               "link#3": 1,
               "link#4": 1,
               "link#5": 1,
               "link#6": 1
           },
           "link-capacity": {
             "link#1": "10Gbps",
             "link#2": "5Gbps",
             "link#3": "10Gbps",
             "link#4": "10Gbps",
             "link#5": "10Gbps",
             "link#6": "20Gbps"
           }
         }
       }

3.5.  Endpoint Information Service

   The endpoint information service to the information map is just as
   the endpoint cost service to the cost map.  It provides only the
   requested information for paths specified by given pairs of
   addresses.

3.5.1.  Media Type

   The media types for endpoint information service is defined in
   Section 6.1.

3.5.2.  HTTP Method

   The endpoint information service is requested using the HTTP POST
   method.

3.5.3.  Accept Input Parameters

   The input parameters for the endpoint information service is
   described using the following JSON object:

       object {
           EndpointFilter    endpoints;
           [PropertySpecName -> PropertySpec;]
           [JSONString       constraints<0..*>;]
       } EndpointInfoReq;






Gao & Yang               Expires January 7, 2016               [Page 16]

Internet-Draft               ALTO Extensions                   July 2015


   The EndpointFilter is the same as defined in [RFC7285].  The
   PropertySpec is the same as defined in Section 3.4.  The
   "constraints" have the following three components:

   o  A property name that indicates the property to filter.  The
      corresponding property MUST be declared in the capabilities
      otherwise it MUST be ignored.

   o  An operator as defined in [RFC7285]

   o  A constant or a symbolic property to be compared to.

3.5.4.  Capabilities

   The capabilities of the endpoint information service are described
   using a JSON object of type EndpointInfoCapabilities:

       object {
           JSONString    properties<0..*>;
       } EndpointInfoCapabilities;

   with fields:

   o  properties: the list containing the property names between
      endpoints.

3.5.5.  Uses

   The resource ID of the network map, information map or the extended
   network map based on which the endpoint information service will be
   defined.

3.5.6.  Response

   The "meta" field of the response is described using the following
   JSON object:

       object {
           VersionTag    dependent-vtags<1..1>;
           VersionTag    vtag;
           [PropertyName -> PropertySpec;]
       } EISMetaData;

       object {
           JSONString          type;
           [PropertyAttrName -> JSONValue;]
       } PropertySpec;




Gao & Yang               Expires January 7, 2016               [Page 17]

Internet-Draft               ALTO Extensions                   July 2015


   with fields:

   o  dependent-vtags: the same as the "dependent-vtags" in the cost
      map, with the addition that resource ID can point to an extended
      network map;

   o  vtag: the same as in the network map;

   o  PropertyName: the name listed in the request.

   The data component of an endpoint information service is named
   "endpoint-information", which is a JSON object of type EISData,
   where:

       object {
           EISData     endpoint-information;
       } InfoResourceEISData : ResponseEntityBase;

       object-map {
           PropertyName -> EISPropertyMapData;
       } EISData;

       object-map {
           TypedNodeAddr -> { TypedNodeAddr -> JSONValue };
       } EISPropertyMapData;

3.5.7.  Example

   The example of getting the routing cost is given below, using the
   same topology and routing cost information as in Section 3.4.7.





















Gao & Yang               Expires January 7, 2016               [Page 18]

Internet-Draft               ALTO Extensions                   July 2015


       POST /eis-example HTTP/1.1
       Host: alto.example.org
       Content-Length: 329
       Content-type: application/alto-endpointinfoparam+json
       Accept: application/alto-endpointinfo+json,
               application/alto-error+json


       {
         "endpoints": {
             "srcs": [ "ipv4:192.168.1.12", "node:node#1" ],
             "dsts": [
               "ipv4:192.168.1.13",
               "ipv4:192.168.2.34",
               "node:node#2"
             ]
         },
         "path-routingcost": {
           "type": "path",
           "mode": "numerical",
           "metric": "routingcost"
         },
         "constraints": ["link-capacity > 8Gbps"]
       }

       HTTP/1.1 200 OK
       Content-length: 601
       Content-type: application/alto-endpointinfo+json

       {
         "meta": {
           "vtag": {
             "resource-id": "eis-example",
             "tag": "5ffb08265da64136a13978055f3affb6"
           },
           "dependent-vtags": [
             {
               "resource-id": "extended-network-map-example",
               "tag": "67e6183c00fe467a960f174b93f23cf7"
             },
             {
               "resource-id": "infomap-example",
               "tag": "e7822fdd03814561bdb955667ca06534"
             }
           ]
         },





Gao & Yang               Expires January 7, 2016               [Page 19]

Internet-Draft               ALTO Extensions                   July 2015


         "endpoint-information": {
           "path-cost": {
             "ipv4:192.168.1.12": {
               "ipv4:192.168.1.13": 0,
               "ipv4:192.168.2.34": 4
             },
             "node:node#1": {
               "node:node#2": 3
             }
           }
         }
       }

   With the constraint of "link-capacity > 8Gbps" in the request, link#2
   should be filtered so the routing cost between node#1 and node#4 is 4
   instead of 3.

   It is notable that the endpoint information is only provided between
   endpoints with the same address type.

4.  Future Improvement

   In the preceding sections three new ALTO services are introduced,
   however, they only provide basic functionalities to distribute
   general network information.  In this section we discuss some
   advanced topics about the extensions for enhancements in
   functionalities and performance.

4.1.  Deriving ALTO Services from the Extensions

   Even though the extended network map is capable to provide
   topological information, sometimes applications would still only
   request for end-to-end information.  Also, due to backward-
   compatibility considerations, a network map derived from the extended
   network map is desired.

   One simple implementation is to crop the "links" field from the data
   component in an extended network map response, ignore all internal
   nodes and rename the "nodes" field to "network-map".

   At the same time, new information maps and an endpoint information
   services can be derived from the corresponding ones for the base
   extended network map.  For example, consider the hop count as the
   targeted information, the hop counts between two endpoints can be
   derived by summing up the hop counts (which all have the value of 1)
   on all the links on the path.  That example also demonstrate how the
   cost map can be derived from certain information maps.




Gao & Yang               Expires January 7, 2016               [Page 20]

Internet-Draft               ALTO Extensions                   July 2015


4.2.  Information Aggregation Services

   With the extensions introduced in Section 3, an generic ALTO server
   implementation can collect information by querying other ALTO servers
   providing these information.  However, question still remains that
   how the original data can be collected.

   One possible way is to use customized ALTO servers, for example, one
   embedded into a SDN controller.

   Another approach is to enable passive data collection in an ALTO
   server where the ALTO server declares a new kind of ALTO
   "aggregation" service.  The aggregation service defines the format of
   information it can resolve so that information sources, whether they
   are ALTO servers, ALTO clients or third-party agents, can push the
   data to the server.

   The Internet Draft [I-D.ietf-alto-incr-update-sse], which uses
   Server-Sent Events (SSE) to push incremental updates to the ALTO
   clients, can also be used as a passive data collection method.  Both
   methods can transport partial data to the aggregator ALTO server,
   however, the information sources using the "aggregation" service
   don't have to launch an ALTO server instance, thus this approach
   allows more lightweight publishers and can apply in more general
   scenarios.

   A comparison between the methods mentioned above is listed in
   Table 1.  In "Ext-ALTO with SSE" and "Ext-ALTO", the aggregator ALTO
   server acts as a client to the publisher ALTO servers which provide
   the extended ALTO services introduced in this document with and
   without the SSE mechanism respectively.  In "ALTO Aggregation", the
   aggregator ALTO server is providing the "aggregation" service and
   there is no demand on the publisher other than following the
   protocol.

   +--------------------+--------------+--------------+---------------+
   | Description        | Aggregator   | Publisher    | Partial Data  |
   +--------------------+--------------+--------------+---------------+
   | Ext-ALTO           | ALTO Server  | ALTO Server  | No            |
   |                    | Active       | Passive      |               |
   | Ext-ALTO with SSE  | ALTO Server  | ALTO Server  | Yes           |
   |                    | Active       | Active       |               |
   | ALTO Aggregation   | ALTO Server  | Any          | Yes           |
   |                    | Passive      | Active       |               |
   +--------------------+--------------+--------------+---------------+

        Table 1: Comparison between Different Ways to Collect Data




Gao & Yang               Expires January 7, 2016               [Page 21]

Internet-Draft               ALTO Extensions                   July 2015


4.3.  Scope for Extended ALTO Services

   With the approaches in Section 3 and the ones discussed in sections
   above, we represent how ALTO protocol can be used to distribute
   network information to the applications in Figure 4 where the normal
   paths represent ALTO protocol and the starred path represents some
   private protocol.

           +---------------------+               +--------------------+
           |                     |       ********+                    |
           |                     |       *       | Private            |
           |                     v       v       | Information Source |
           |                  +--+-------+--+    |                    |
    +------+------+           |             |    +--------------------+
    |             +<----------+ Generic     |
    | ALTO Client |           | ALTO Server |           +-------------+
    |             |  +--------+             +<----------+             |
    +-------------+  |        +--+----------+           | Third-Party |
                     |           ^                      | Aggregator  |
                     v           |     +-------------+  |             |
           +---------+---+       +-----+             |  +-------------+
           |             |             | Customized  |
           | ALTO Client |             | ALTO Server |
           |             +<------------+             |
           +-------------+             +-------------+

                   Figure 4: AN ALTO Deployment Scenario

4.4.  The Regulation of Property Specifications

   In the specifications for the information map and endpoint
   information service, the information to be published is identified by
   so-called property specifications.  However, there are no standard
   providing the specifications of other properties at the moment.  Even
   though the specification for "cost-type" proposed in [RFC7285] can be
   seen as an example, it can still lead to confusions if two ALTO
   servers happen to use the same mode-metric combination but use
   different measure units.

   Just like the cost types in [RFC7285], a registry for the information
   specification used by the information map and the endpoint
   information service MUST be created and maintained by IANA in the
   future.  To get started, future proposals SHOULD designate some
   initial values by providing the specifications for some commonly used
   information, such as the link capacity, available bandwidth, etc.

   Another approach is to design a management system where new
   specifications can be validated and registered with an "exp:" prefix,



Gao & Yang               Expires January 7, 2016               [Page 22]

Internet-Draft               ALTO Extensions                   July 2015


   which indicates that they are experimental properties, before they
   are standardized.

4.5.  Fetching Filtered Topological Information

   One way to fetch filtered topological information, as the name
   suggests, is to use the filtered information map which returns only
   the requested data of the requested nodes/links.  The filtered
   information map has not been specified in this document yet but is
   planned to be included in future updates.

   Another approach can be achieved in the following way: First use a
   special type of TypedNodeAddr, the "NodeName", to identify the
   targeted nodes, and then implement an endpoint information service
   that returns the links between two requested nodes with all the
   requested data attached.  This particular service can be useful to
   merge the given sequence of links to a single "virtual" link, which
   may help reduce the size of network view and encapsulate details of
   the original topology.

5.  Security Considerations

   This document has not conducted its security analysis.

6.  IANA Considerations

   This document defines registries for application/alto-* media types.

6.1.  Media Types

   The media types for the three ALTO extensions are listed below:

     +--------------+------------------------------+----------------+
     | Type         | Subtype                      | Specification  |
     +--------------+------------------------------+----------------+
     | application  | alto-extnetworkmap+json      | Section 3.3.6  |
     | application  | alto-infomap+json            | Section 3.4.6  |
     | application  | alto-endpointinfo+json       | Section 3.5.6  |
     | application  | alto-endpointinfoparam+json  | Section 3.5.3  |
     +--------------+------------------------------+----------------+

                           Table 2: Media Types

   The media types defined in this document have the same constraints
   and properties as those defined in [RFC7285], except the authors'
   information.





Gao & Yang               Expires January 7, 2016               [Page 23]

Internet-Draft               ALTO Extensions                   July 2015


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [I-D.ietf-alto-incr-update-sse]
              Roome, W. and Y. Yang, "ALTO Incremental Updates Using
              Server-Sent Events (SSE)", draft-ietf-alto-incr-update-
              sse-00 (work in progress), May 2015.

   [OpenDaylight]
              Medved, J., Varga, R., Tkacik, A., and K. Gray,
              "Opendaylight: towards a model-driven sdn controller
              architecture", 2014.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693, October
              2009.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.

   [RFC7285]  Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
              Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
              Traffic Optimization (ALTO) Protocol", RFC 7285, September
              2014.

Authors' Addresses

   Kai Gao
   Tsinghua University
   30 Shuangqinglu Street, Haidian District
   Beijing  100084
   China

   Email: gaok12@mails.tsinghua.edu.cn











Gao & Yang               Expires January 7, 2016               [Page 24]

Internet-Draft               ALTO Extensions                   July 2015


   Y. Richard Yang
   Yale University
   51 Prospect St
   New Haven  CT
   USA

   Email: yry@cs.yale.edu












































Gao & Yang               Expires January 7, 2016               [Page 25]