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]
