Internet DRAFT - draft-wydrych-alto-paths

draft-wydrych-alto-paths







Network Working Group                                         P. Wydrych
Internet-Draft                                            AGH University
Intended status: Standards Track                                   Q. Fu
Expires: January 7, 2016                                    China Mobile
                                                            July 6, 2015


                 Paths Extension for the ALTO Protocol
                      draft-wydrych-alto-paths-00

Abstract

   The Application-Layer Traffic Optimization (ALTO) protocol has been
   standardized in RFC7285 to ease better-than-random overlay connection
   management.  However, through the base protocol it is not possible to
   differenciate paths from a given source to a given destination and
   provide an ALTO client with a detailed information of sending traffic
   through these paths.

   This document describes an extension to the ALTO protocol allowing
   for representation of paths in the network maps, cost maps, and
   endpoint cost calculation.  Morever, this document defines a new path
   computation service.

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



Wydrych & Fu             Expires January 7, 2016                [Page 1]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   (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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Use-cases . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  MPLS and RSVP-TE  . . . . . . . . . . . . . . . . . .   4
       1.1.2.  Locator/ID Separation . . . . . . . . . . . . . . . .   4
       1.1.3.  Content Delivery Networks . . . . . . . . . . . . . .   5
       1.1.4.  Service Function Chaining . . . . . . . . . . . . . .   5
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   6
   2.  Extension Specification . . . . . . . . . . . . . . . . . . .   6
     2.1.  Information Resource Directory  . . . . . . . . . . . . .   6
       2.1.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Provider-Defined Path Identifier (PPID) . . . . . . . . .   9
       2.2.1.  PPID Nesting  . . . . . . . . . . . . . . . . . . . .   9
     2.3.  Map Service: Network Map  . . . . . . . . . . . . . . . .   9
       2.3.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   9
     2.4.  Map Service: Cost Map . . . . . . . . . . . . . . . . . .  10
       2.4.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  11
     2.5.  Map-Filtering Service: Filtered Network Map . . . . . . .  12
       2.5.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  12
     2.6.  Map-Filtering Service: Filtered Cost Map  . . . . . . . .  13
       2.6.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  14
     2.7.  Enpoint Cost Service  . . . . . . . . . . . . . . . . . .  14
       2.7.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  15
     2.8.  Path Computation Service  . . . . . . . . . . . . . . . .  16
       2.8.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  17
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   5.  Compatibility Considerations  . . . . . . . . . . . . . . . .  18
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   As stated in [RFC5693], information on network topologies and routing
   policies in today Internet are not generally available to the
   application layer.  At the same time, a lot of new overlay



Wydrych & Fu             Expires January 7, 2016                [Page 2]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   applications creating their own topologies on top of the physical one
   emerge.  As both network operators and users of the overlay
   applications may benefit from better-than-random overlay connection
   management, the ALTO protocol has been standardized in [RFC7285].

   In the current networks, a number of unique paths from a given source
   to a given destination often exist.  Even for the same pair of source
   and destination, the routing cost may be significantly different for
   each of the paths.  Especially in case of transit traffic, cost may
   depend on ingress and egress link policies.  Other factors that may
   influence the routing cost are, e.g., load of the links traversed
   throughout the network or capabilities of used routers.

   Moreover, a number of tunneling techniques are used currently to
   handle parts of the traffic separately.  To ensure that services of
   high quality are provided to customers, Internet Service Providers
   (ISPs) set up tunnels using specified paths.  Then, network devices
   are configured to take into account the tunnel parameters and, e.g.,
   prioritize traffic sent through a tunnel by using separate queues on
   routers.

                                 +------+
                                 |      |
                              ,--+ PID3 +--.
                             /   |      |   \
   +------+       +------+  /    +------+    \  +------+       +------+
   |      +-------+      +-'    /        \    `-+      +-------+      |
   | PIDA |       | PID1 |     /          \     | PID6 |       | PIDY |
   |      +.     ,+      +---./            \,---+      +.     ,+      |
   +------+ \   / +------+   /\  +------+  /\   +------+ \   / +------+
             \ /          \ /  `-+      +-'  \ /          \ /
              X            X     | PID4 |     X            X
             / \          / \  ,-+      +-.  / \          / \
   +------+ /   \ +------+   \/  +------+  \/   +------+ /   \ +------+
   |      +'     `+      +---'\            /`---+      +'     `+      |
   | PIDB |       | PID2 |     \          /     | PID7 |       | PIDZ |
   |      +-------+      +-.    \        /    ,-+      +-------+      |
   +------+       +------+  \    +------+    /  +------+       +------+
                             \   |      |   /
                              `--+ PID5 +--'
                                 |      |
                                 +------+

                  Figure 1: A redundant network topology.

   In Figure 1, a redundant network topology has been presented.  Due to
   the abovementioned observations, the cost of sending data from PIDA
   via PID1, PID4, and PID7 to PIDZ (using a known path) does not have



Wydrych & Fu             Expires January 7, 2016                [Page 3]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   to be equal to the sum of costs of sending independent flows from
   PIDA to PID1, from PID1 to PID4, from PID4 to PID7, and from PID7 to
   PIDZ in a best-effort way.

   Therefore, information on the cost of data transfer from a source to
   a destination provided by the network and cost maps using a base ALTO
   Protocol may be not accurate.

1.1.  Use-cases

   There are a number of situations in which would be optimal if a
   network device selected a path to a destination based not only on the
   information from the routing information databases.  In this
   document, the following are shortly described:

   o  establishments tunnels in MPLS networks,

   o  providing optimal EID-to-RLOC mapping in LISP sites,

   o  storing content replicas in CDNs,

   o  forwarding data between virtualized network functions.

1.1.1.  MPLS and RSVP-TE

   Currently, a lot of core networks use Multi-Protocol Label Switching
   (MPLS) [RFC3031] to forward IP packets and Resource Reservation
   Protocol (RSVP) to establish tunnels [RFC3209] between ingress and
   egress MPLS nodes.  Due to the link redundancy, there may be a number
   of paths that packet may flow through for each ingress/egress nodes
   pair.  The ALTO Protocol may be used during the optimal path
   establishment process, taking into account various factors like link
   policies or device and link load.

   For instance, PIDA and PIDB (in Figure 1) may aggregate the traffic
   sources, while PIDY and PIDZ - the traffic destinations.  If a MPLS
   network is established between nodes in PID1 to PID9, PID1 and PID2
   are ingress MPLS nodes, and PID6 and PID7 are the egress MPLS nodes,
   the ALTO Protocol with a paths extension may be used by the control
   plane to assist tunnel establishment from the ingress to the egress
   nodes.  Then, ISP may take into account source and destination of the
   packets to direct the traffic into a specific tunnel.

1.1.2.  Locator/ID Separation

   The recently standardized Locator/ID Separation Protocol (LISP)
   [RFC6830] separates the IP addresses into two numbering spaces:
   Endpoint Identifiers (EIDs) and Routing Locators (RLOCs).  Due to the



Wydrych & Fu             Expires January 7, 2016                [Page 4]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   multihoming, one EID may be possible to be mapped to more than one
   RLOC.  The ALTO Protocol may be used by the mapping service and/or by
   the ingress nodes select the optimal EID-to-RLOC mapping and, thus,
   the path used by the encapsulated packets.

   For instance, PIDA and PIDB (in Figure 1) may aggregate the traffic
   sources, while PIDY and PIDZ - the traffic destinations.  If a LISP
   network is established between nodes in PID1 to PID9, PID1 and PID2
   are Ingress Tunnel Routers, and PID6 and PID7 are the Egress Tunnel
   Routers, the ALTO Protocol with a paths extension may be used by the
   EID-to-RLOC mapping service to assist LISP tunnel establishment from
   the ingress to the egress nodes.

1.1.3.  Content Delivery Networks

   The content-delivery networks (CDNs) use replica servers to take
   benefit of caching in providing high quality service to the end-users
   [CDNs].  One of the crucial parts of each CDN is the algorithm
   deciding which data should be cached on which replica server and for
   how long.  Especially, when an end-user requests for a relatively new
   content that is available only at the origin servers, it may be
   cached on the replica servers while it is being delivered to the end-
   user.

   For instance, PIDA and PIDB (in Figure 1) may aggregate the origin
   servers, i.e., the authoritative content sources, while PIDY and PIDZ
   - the end-users' devices.  If a CDN network design is tiered, PID1
   and PID2 may aggregate data centers (DCs) with global replica
   servers, PID3 to PID5 - country-wide caches, and PID6 and PID7 -
   regional ones.  The ALTO protocol with a paths extension may assist
   the CDN controller in selecting through which DCs traffic from the
   content source to the end-users should be forwarded to both provide
   high-quality service and store content replicas in correct caches at
   the same time.

1.1.4.  Service Function Chaining

   As described in [I-D.fu-alto-nfv-usecase], the ALTO protocol can be
   used in the service function chaining (SFC) scenario, in which the
   SFC control plane may act as an ALTO client and ask ALTO server to
   provide a cost of a service function path (SFP).  SFP is a sequence
   of network functions which the traffic flow should travel through.
   Utilizing the ALTO protocol, the SFC control plane can get the cost
   of each different paths and make the decision of which path to
   choose.  In such a scenario, an extension of path is needed to define
   the SFP.





Wydrych & Fu             Expires January 7, 2016                [Page 5]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   For instance, PIDA and PIDB (in Figure 1) may aggregate the service
   consumers, while PIDY and PIDZ are the service providers.  If there
   is a requirement that the traffic from the service comsumer has to be
   processed by a sequence of service functions, e.g., a firewall (PID1
   or PID2), a deep packet inspector (PID3, PID4, or PID5), and a load-
   balancer (PID6 or PID7) in the correct order before reaching a
   service provider, the ALTO protocol with a paths extension may be
   used to optimize forwarding of the data between the service
   functions.

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

2.  Extension Specification

   This document specifies an extension to the ALTO Protocol, as defined
   in RFC 7285, by adding ability to provide path-specific information
   through map and endpoint cost services.  Moreover, this extension
   defines a new service called "path computation service".

   An ALTO server that is compliant with the paths extension MUST
   implement at least one of the services:

   o  paths-enhanced map service (both path-enabled network map and
      path-enabled cost map MUST be provided),

   o  paths-enhanced endpoint cost service,

   o  path computation service.

2.1.  Information Resource Directory

   This extension defines a new Boolean ALTO server capability: "paths".
   The default value of the "paths" capability is false.  Each resource
   that provides information using syntax defined in this document MUST
   be assigned "paths": true capability.  For clarity, an ALTO server
   implementing this extension MAY explicitly assign "path": false
   capability to the resources that are not providing any path
   information and are not using the syntax defined in this document.

2.1.1.  Example

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



Wydrych & Fu             Expires January 7, 2016                [Page 6]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   HTTP/1.1 200 OK
   Content-Length: 2477
   Content-Type: application/alto-directory+json

   {
     "meta": {
       "cost-types": {
         "num-routing": {
           "cost-mode": "numerical",
           "cost-metric": "routingcost"
         },
         "ord-routing": {
           "cost-mode": "ordinal",
           "cost-metric": "routingcost"
         }
       },
       "default-alto-network-map": "network-map"
     },
     "resources": {
       "my-default-network-map": {
         "uri": "http://alto.example.com/networkmap",
         "media-type": "application/alto-networkmap+json"
       },
       "my-default-paths-network-map": {
         "uri": "http://alto.example.com/paths/networkmap",
         "media-type": "application/alto-networkmap+json",
         "capabilities": {
           "paths": true
         }
       },
       "numerical-routing-cost-map": {
         "uri": "http://alto.example.com/costmap/num/routingcost",
         "media-type": "application/alto-costmap+json",
         "capabilities": {
           "cost-type-names": [
             "num-routing"
           ]
         },
         "uses": [
           "my-default-network-map"
         ]
       },
       "paths-numerical-routing-cost-map": {
         "uri": "http://alto.example.com/paths/costmap/num/routingcost",
         "media-type": "application/alto-costmap+json",
         "capabilities": {
           "paths": true,
           "cost-type-names": [



Wydrych & Fu             Expires January 7, 2016                [Page 7]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


             "num-routing"
           ]
         },
         "uses": [
           "my-default-network-map"
         ]
       },
       "endpoint-cost": {
         "uri": "http://alto.example.com/endpointcost/lookup",
         "media-type": "application/alto-endpointcost+json",
         "accepts": "application/alto-endpointcostparams+json",
         "capabilities": {
           "cost-constraints": true,
           "cost-type-names": [
             "num-routing",
             "ord-routing"
           ]
         }
       },
       "paths-endpoint-cost": {
         "uri": "http://alto.example.com/paths/endpointcost/lookup",
         "media-type": "application/alto-endpointcost+json",
         "accepts": "application/alto-endpointcostparams+json",
         "capabilities": {
           "paths": true,
           "cost-constraints": true,
           "cost-type-names": [
             "num-routing",
             "ord-routing"
           ]
         }
       },
       "path-computation": {
         "uri": "http://alto.example.com/paths/compute",
         "media-type": "application/alto-pathcompute+json",
         "accepts": "application/alto-pathcomputeparams+json",
         "capabilities": {
           "paths": true,
           "cost-constraints": true,
           "cost-type-names": [
             "num-routing",
             "ord-routing"
           ]
         }
       }
     }
   }




Wydrych & Fu             Expires January 7, 2016                [Page 8]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


2.2.  Provider-Defined Path Identifier (PPID)

   This extension introduces Provider-defined Path Identifiers (PPIDs)
   to provide a way to specify a sequence of endpoints traversed by the
   traffic.  A PPID is a string of type PPIDName and its associated list
   of PIDs.  The list of PIDs associated to a PPID MUST NOT be empty.
   The list of PIDs MUST NOT contain an undefined PID.

   A PPID Name MUST conform to all PID Name requirements specified by
   Section 10.1 of RFC 7285.  A PPID Name MUST begin with 'path.', i.e.,
   the word 'path' encoded in lower-case US-ASCII followed by the dot
   separator ('.', U+002E).  A PPID Name MUST contain at least one
   character after the dot separator.

   The type PPIDName is used in this document to indicate a string of
   this format.

2.2.1.  PPID Nesting

   The Provider-defined Path Identifiers may be nested in case one path
   contains another.  For instance, in case PIDs "PID1", "PID3", and
   "PID6" are defined, and a PPID "path.1-3" is defined as ["PID1",
   "PID3"], a PPID "path.1-3-6" consisting of "PID1", "PID3", and "PID6"
   may be defined both as ["PID1", "PID3", "PID6"] or ["path.1-3",
   "PID6"].

   Nested PPIDs MUST NOT create circular dependencies.  I.e., "path.A"
   MUST NOT contain "path.B" if "path.B" contains (directly or
   indirectly) "path.A".

2.3.  Map Service: Network Map

   Through this extension, a set of PPIDs is added to the network map.
   A network map MUST define all PIDs that PPIDs being defined comprise
   of.  A network map SHOULD define all needed PIDs before defining a
   PPID.  A network map SHOULD define a nested path before defining an
   outer one.

2.3.1.  Example












Wydrych & Fu             Expires January 7, 2016                [Page 9]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   GET /paths/networkmap HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-networkmap+json,application/alto-error+json

   HTTP/1.1 200 OK
   Content-Length: 988
   Content-Type: application/alto-networkmap+json

   {
     "meta": {
       "vtag": {
         "resource-id": "paths-network-map",
         "tag": "e65e696925e7cc350b562b6a7d5f2540"
       }
     },
     "network-map": {
       "PIDA": { "ipv4": [ "192.0.2.0/25" ] },
       "PIDB": { "ipv4": [ "192.0.2.128/25" ] },
       "PID1": { "ipv4": [ "198.51.100.1/32" ] },
       "PID2": { "ipv4": [ "198.51.100.2/32" ] },
       "PID3": { "ipv4": [ "198.51.100.3/32" ] },
       "PID4": { "ipv4": [ "198.51.100.4/32" ] },
       "PID5": { "ipv4": [ "198.51.100.5/32" ] },
       "PID6": { "ipv4": [ "198.51.100.6/32" ] },
       "PID7": { "ipv4": [ "198.51.100.7/32" ] },
       "PIDY": { "ipv4": [ "203.0.113.0/25" ] },
       "PIDZ": { "ipv4": [ "203.0.113.128/25" ] },
       "path.1-3-6": [ "PID1", "PID3", "PID6" ],
       "path.1-4-7": [ "PID1", "PID4", "PID7" ],
       "path.2-5-7": [ "PID2", "PID5", "PID6" ],
       "path.1-3-6-Y": [ "path.1-3-6", "PIDY" ],
       "path.1-3-6-Z": [ "path.1-3-6", "PIDZ" ],
       "path.1-4-7-Z": [ "path.1-4-7", "PIDZ" ],
       "path.2-5-7-Z": [ "path.2-5-7", "PIDZ" ]
     }
   }


2.4.  Map Service: Cost Map

   Through a cost map, an ALTO server implementing this extension lists
   the path costs from sources to destinations via paths defined in the
   network map.

   For each source/destination pair defined by a cost map, where a
   destination is a PPID, the cost value corresponds to the traffic
   originated in the source, traversing all-but-last PIDs of the path,
   and directed to the endpoint belonging to the last PID in the path.



Wydrych & Fu             Expires January 7, 2016               [Page 10]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   A cost map MUST NOT define costs source/destination pair where source
   is a PPID.  In other words, a PPIDName MUST NOT be a key of a
   CostMapData dictionary map object.

2.4.1.  Example

   GET /paths/costmap/num/routingcost HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-costmap+json,application/alto-error+json

   HTTP/1.1 200 OK
   Content-Length: 572
   Content-Type: application/alto-costmap+json

   {
     "meta": {
       "dependent-vtags": [
         {
           "resource-id": "paths-network-map",
           "tag": "e65e696925e7cc350b562b6a7d5f2540"
         }
       ],
       "cost-type": {
         "cost-mode": "numerical",
         "cost-metric": "routingcost"
       }
     },
     "cost-map": {
       "PIDA": { "PIDY": 50, "PIDZ": 100,
                 "path.1-3-6-Y": 10, "path.1-3-6-Z": 15,
                 "path.1-4-7-Z": 10, "path.2-5-7-Z": 20 },
       "PIDB": { "PIDY": 75, "PIDZ": 125,
                 "path.1-3-6-Y": 20, "path.1-3-6-Z": 30,
                 "path.1-4-7-Z": 25, "path.2-5-7-Z": 20 }
     }
   }


   In the above example, the routing cost of sending data from
   192.0.2.0/25 to 203.0.113.128/25 using a best-effort service is 125,
   while the routing cost of sending data from 192.0.2.0/25 via
   198.51.100.1, 198.51.100.4, and 198.51.100.7 to 203.0.113.128/25
   using a dedicated path (e.g., a tunnel) is 25.








Wydrych & Fu             Expires January 7, 2016               [Page 11]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


2.5.  Map-Filtering Service: Filtered Network Map

   An ALTO client requesting for network map filtering may specify both
   PIDs and PPIDs in the "pids" field of the request.  Through this
   extension, PIDs and PPIDs may be requested implicitly.  The behavior
   is different for PIDs and PPIDs requested.

   If a PID name was specified, an ALTO server MUST return the requested
   PID as well as:

   o  all PPIDs that have the specified PID at the last entry (i.e.,
      PPIDs for all paths ending in the specified PID);

   o  all nested PPID, recursively;

   o  all PIDs that are needed to define implicitly requested paths.

   If a PPID name was specified, an ALTO server MUST return the
   requested PPID as well as:

   o  all nested PPID, recursively;

   o  all PIDs that are needed to define explicitly and implicitly
      requested paths.

   If the list of PIDs is empty, the ALTO server MUST interpret the list
   as if it contained a list of all currently defined PIDs and PPIDs.

2.5.1.  Example






















Wydrych & Fu             Expires January 7, 2016               [Page 12]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   POST /paths/networkmap/filtered HTTP/1.1
   Host: alto.example.com
   Content-Length: 33
   Content-Type: application/alto-networkmapfilter+json
   Accept: application/alto-networkmap+json,application/alto-error+json

   {
     "pids": [ "PIDA", "PIDY" ]
   }

   HTTP/1.1 200 OK
   Content-Length: 477
   Content-Type: application/alto-networkmap+json

   {
     "meta": {
       "vtag": {
         "resource-id": "paths-network-map",
         "tag": "e65e696925e7cc350b562b6a7d5f2540"
       }
     },
     "network-map": {
       "PIDA": { "ipv4": [ "192.0.2.0/25" ] },
       "PID1": { "ipv4": [ "198.51.100.1/32" ] },
       "PID3": { "ipv4": [ "198.51.100.3/32" ] },
       "PID6": { "ipv4": [ "198.51.100.6/32" ] },
       "PIDY": { "ipv4": [ "203.0.113.0/25" ] },
       "path.1-3-6": [ "PID1", "PID3", "PID6" ],
       "path.1-3-6-Y": [ "path.1-3-6", "PIDY" ],
     }
   }


2.6.  Map-Filtering Service: Filtered Cost Map

   An ALTO client requesting for cost map filtering may specify both
   PIDs and PPIDs in the "pids"."dsts" field of the request.  Through
   this extension, PPIDs may be requested implicitly.  If a PID name was
   specified as a destination, an ALTO server MUST return the cost map
   for all source/destination pairs in which the requested PID is a
   destination as well as all source/destination pairs in which a PPID
   that have the specified PID at the last entry is a destination.

   If the list of destination PIDs is empty, the ALTO server MUST
   interpret the list as if it contained a list of all currently defined
   PIDs and PPIDs.

   The source PID list MUST NOT contain any PPIDs.



Wydrych & Fu             Expires January 7, 2016               [Page 13]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


2.6.1.  Example

   POST /paths/costmap/filtered HTTP/1.1
   Host: alto.example.com
   Content-Type: application/alto-costmapfilter+json
   Content-Length: 145
   Accept: application/alto-costmap+json,application/alto-error+json

   {
     "cost-type": {
       "cost-mode": "numerical",
       "cost-metric": "routingcost"
     },
     "pids": {
       "srcs": [ ],
       "dsts": [ "PIDY" ]
     }
   }

   HTTP/1.1 200 OK
   Content-Length: 370
   Content-Type: application/alto-costmap+json

   {
     "meta": {
       "dependent-vtags": [
         {
           "resource-id": "paths-network-map",
           "tag": "e65e696925e7cc350b562b6a7d5f2540"
         }
       ],
       "cost-type": {
         "cost-mode": "numerical",
         "cost-metric": "routingcost"
       }
     },
     "cost-map": {
       "PIDA": { "PIDY": 50, "path.1-3-6-Y": 10 },
       "PIDB": { "PIDY": 75, "path.1-3-6-Y": 20 }
     }
   }


2.7.  Enpoint Cost Service

   An ALTO client requesting for cost map filtering may specify both
   desinations and paths in the "endpoints"."dsts" field of the request.




Wydrych & Fu             Expires January 7, 2016               [Page 14]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   A cost for a path is requsted by specifying an array of typed
   endpoint addresses as a destination entry.

   For each source endpoint, the "endpoint-cost-map" field of the
   response contains a tree denoting costs for requested paths.  The
   subsequent endpoints a path comprise of are represented as internal
   nodes of a cost tree.

2.7.1.  Example

  POST /paths/endpointcost/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: 468
  Content-Type: application/alto-endpointcostparams+json
  Accept: application/alto-endpointcost+json,application/alto-error+json

  {
    "cost-type": {
      "cost-mode": "ordinal",
      "cost-metric": "routingcost"
    },
    "endpoints": {
      "srcs": [ "ipv4:192.0.2.2" ],
      "dsts": [
        "ipv4:203.0.113.128.129",
        [
          "ipv4:198.51.100.1",
          "ipv4:198.51.100.3",
          "ipv4:198.51.100.6",
          "ipv4:203.0.113.128.129"
        ],
        [
          "ipv4:198.51.100.1",
          "ipv4:198.51.100.4",
          "ipv4:198.51.100.7",
          "ipv4:203.0.113.128.129"
        ]
      ]
    }
  }

  HTTP/1.1 200 OK
  Content-Length: 495
  Content-Type: application/alto-endpointcost+json

  {
    "meta": {
      "cost-type": {



Wydrych & Fu             Expires January 7, 2016               [Page 15]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


        "cost-mode": "ordinal",
        "cost-metric": "routingcost"
      }
    },
    "endpoint-cost-map": {
      "ipv4:192.0.2.2": {
        "ipv4:203.0.113.128.129": 3,
        "ipv4:198.51.100.1": {
          "ipv4:198.51.100.3": {
            "ipv4:198.51.100.6": {
              "ipv4:203.0.113.128.129": 1
            }
          },
          "ipv4:198.51.100.4": {
            "ipv4:198.51.100.7": {
              "ipv4:203.0.113.128.129": 2
            }
          }
        }
      }
    }
  }


2.8.  Path Computation Service

   This document defines a new service called path computation service.
   This service provides information on best paths composed of the
   endpoints specified by a client.

   The path computation resource is requested using the HTTP POST
   method.  The media type of the path computation resource is
   "application/alto-pathcompute+json".  An ALTO client supplies the
   path computation parameters through a media type "application/alto-
   pathcomputeparams+json", with an HTTP POST entity body of a JSON
   object with fields:

   cost-type:  The cost type (Section 10.7 of <RFC7285>) to use for
      returned costs.  The "cost-metric" and "cost-mode" fields MUST
      match one of the supported cost types indicated in this resource's
      "capabilities" fields.  The ALTO client SHOULD omit the
      "description" field, and if present, the ALTO server MUST ignore
      the "description" field.

   endpoints:  A list of lists of endpoints from which paths may be
      composed.  The ALTO server MUST compose a path taking exactly one
      element from each list, preserving the order.




Wydrych & Fu             Expires January 7, 2016               [Page 16]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   The response comprises a list of suggested paths.  Each path is an
   object containing a list of endpoints forming the path and the path's
   cost.  The server MAY return more than one path.  The server MAY
   return no paths if it cannot compute an optimal one.

2.8.1.  Example

   POST /paths/compute HTTP/1.1
   Host: alto.example.com
   Content-Length: 296
   Content-Type: application/alto-pathcomputeparams+json
   Accept: application/alto-pathcompute+json,application/alto-error+json

   {
     "cost-type": {
       "cost-mode": "ordinal",
       "cost-metric": "routingcost"
     },
     "endpoints": [
       [ "ipv4:192.0.2.2" ],
       [ "ipv4:198.51.100.1" ],
       [ "ipv4:198.51.100.3", "ipv4:198.51.100.4" ],
       [ "ipv4:198.51.100.6", "ipv4:198.51.100.7" ],
       [ "ipv4:203.0.113.128.129" ]
     ]
   }

   HTTP/1.1 200 OK
   Content-Length: 536
   Content-Type: application/alto-pathcompute+json

   {
     "meta": {
       "cost-type": {
         "cost-mode": "ordinal",
         "cost-metric": "routingcost"
       }
     },
     "computed-paths": [
       {
         "path": [
           "ipv4:192.0.2.2",
           "ipv4:198.51.100.1",
           "ipv4:198.51.100.3",
           "ipv4:198.51.100.6",
           "ipv4:203.0.113.128.129"
         ],
         "cost": 1



Wydrych & Fu             Expires January 7, 2016               [Page 17]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


       },
       {
         "path": [
           "ipv4:192.0.2.2",
           "ipv4:198.51.100.1",
           "ipv4:198.51.100.4",
           "ipv4:198.51.100.7",
           "ipv4:203.0.113.128.129"
         ],
         "cost": 2
       }
     ]
   }


3.  IANA Considerations

   This document registers two application/alto-* media types:
   application/alto-pathcomputeparams+json and application/alto-
   pathcompute+json.

4.  Security Considerations

   This document does not introduce any privacy or security issues not
   already present in the ALTO protocol.

5.  Compatibility Considerations

   The extension defined in this document is compatible with the multi-
   cost extension [I-D.ietf-alto-multi-cost].  Whenever a cost value is
   considered in the server response, an array of multiple costs may be
   used if a server implements both paths and multi-cost extensions.

   The extension defined in this document is compatible with the
   incremental updates using server-sent events
   [I-D.ietf-alto-incr-update-sse].

6.  References

6.1.  Normative References

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

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



Wydrych & Fu             Expires January 7, 2016               [Page 18]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


6.2.  Informative References

   [CDNs]     Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content
              Delivery Networks", 2007,
              <http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.

   [I-D.fu-alto-nfv-usecase]
              Fu, Q., Cao, Z., and H. Song, "What's the Impact of
              Virtualization on Application-Layer Traffic Optimization
              (ALTO)?", draft-fu-alto-nfv-usecase-05 (work in progress),
              June 2015.

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

   [I-D.ietf-alto-multi-cost]
              Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
              ALTO", draft-ietf-alto-multi-cost-00 (work in progress),
              May 2015.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

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

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, January
              2013.

Appendix A.  Acknowledgments

   P. Wydrych's work on this draft were performed under contract
   15.11.230.190.

Authors' Addresses








Wydrych & Fu             Expires January 7, 2016               [Page 19]

Internet-Draft    Paths Extension for the ALTO Protocol        July 2015


   Piotr Wydrych
   AGH University of Science and Technology
   Mickiewicza 30
   Krakow  30-059
   Poland

   Phone: +48 12 617 48 17
   Email: piotr.wydrych@agh.edu.pl
   URI:   http://wydrych.net/


   Fu Qiao
   China Mobile
   Xuanwumenxi Ave. No.32
   Beijing
   China

   Email: fuqiao1@outlook.com

































Wydrych & Fu             Expires January 7, 2016               [Page 20]