draft-ietf-alto-path-vector-00.txt   draft-ietf-alto-path-vector-01.txt 
ALTO WG G. Bernstein ALTO WG G. Bernstein
Internet-Draft Grotto Networking Internet-Draft Grotto Networking
Intended status: Standards Track S. Chen Intended status: Standards Track S. Chen
Expires: November 4, 2017 Tongji University Expires: January 4, 2018 Tongji University
K. Gao K. Gao
Tsinghua University Tsinghua University
Y. Lee Y. Lee
Huawei Huawei
W. Roome W. Roome
M. Scharf M. Scharf
Nokia Nokia
Y. Yang Y. Yang
Yale University Yale University
J. Zhang J. Zhang
Tongji University Tongji University
May 3, 2017 July 3, 2017
ALTO Extension: Path Vector Cost Mode ALTO Extension: Path Vector Cost Mode
draft-ietf-alto-path-vector-00.txt draft-ietf-alto-path-vector-01.txt
Abstract Abstract
The Application-Layer Traffic Optimization (ALTO) Service has defined The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]
network and cost maps to provide basic network information, where the has defined several resources and services to provide clients with
cost maps allow only scalar (numerical or ordinal) cost mode values. basic network information. However, the base ALTO protocol and
This document introduces a new cost mode called path-vector to allow latest extensions only provide end-to-end metrics, which are
ALTO clients to support use cases such as capacity regions for insufficient to satisfy the demands of solving more complex network
applications. This document starts with a non-normative example optimization problems. This document introduces an extension to the
called multi-flow scheduling (or capacity region) to illustrate that base ALTO protocol, namely the path-vector extension, which allows
ALTO cost maps without path vectors cannot provide sufficient ALTO clients to query information such as capacity regions for a
information. This document then defines path-vector as a new cost given set of flows. A non-normative example called multi-flow
mode. scheduling is presented to illustrate the limitations of existing
ALTO (endpoint) cost maps. After that, details of the extension are
defined.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 12 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Case: Capacity Region for Multi-Flow Scheduling . . . . . 5 3. Use Case: Capacity Region for Multi-Flow Scheduling . . . . . 5
4. Overview of Approach . . . . . . . . . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Path Vector Data Format . . . . . . . . . . . . . . . . . 7 4.1. Path Vector . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Network Element Property Map . . . . . . . . . . . . . . 8 4.2. Cost Type Extension . . . . . . . . . . . . . . . . . . . 8
4.3. Flow Query Format . . . . . . . . . . . . . . . . . . . . 8 4.3. Abstract Network Element Property Map . . . . . . . . . . 8
4.4. Query Specific . . . . . . . . . . . . . . . . . . . . . 8 4.4. New Media Type: multipart/related . . . . . . . . . . . . 8
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 5. Path-Vector Extension: Basic Data Types . . . . . . . . . . . 9
5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Cost Metric . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Cost Metric . . . . . . . . . . . . . . . . . . . . . 9
5.1.2. Cost Mode: Path Vector . . . . . . . . . . . . . . . 9 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Network Element Name . . . . . . . . . . . . . . . . . . 10 5.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10
5.4. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10
5.4.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10 5.3. Abstract Network Element Name . . . . . . . . . . . . . . 11
5.4.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 5.4. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. Filtered Network Element Property Map . . . . . . . . . . 10 6. Path-Vector Extension: Services . . . . . . . . . . . . . . . 11
5.5.1. Accept Input Parameters . . . . . . . . . . . . . . . 10 6.1. IRD Extensions . . . . . . . . . . . . . . . . . . . . . 11
5.5.2. Capabilities . . . . . . . . . . . . . . . . . . . . 11 6.2. Cost Map Extensions . . . . . . . . . . . . . . . . . . . 12
5.5.3. Response . . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 12
6.2.2. Capabilities . . . . . . . . . . . . . . . . . . . . 12
5.6. IRD Extensions . . . . . . . . . . . . . . . . . . . . . 11 6.2.3. Property-map . . . . . . . . . . . . . . . . . . . . 12
5.7. Cost Map Extensions . . . . . . . . . . . . . . . . . . . 12 6.2.4. Response . . . . . . . . . . . . . . . . . . . . . . 13
5.7.1. Propertymap . . . . . . . . . . . . . . . . . . . . . 12 6.3. Filtered Cost Map Extensions . . . . . . . . . . . . . . 13
5.7.2. Response . . . . . . . . . . . . . . . . . . . . . . 12 6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13
5.8. Filtered Cost Map Extensions . . . . . . . . . . . . . . 12 6.3.2. Capabilities . . . . . . . . . . . . . . . . . . . . 13
5.8.1. Capabilities . . . . . . . . . . . . . . . . . . . . 12 6.3.3. Property-map . . . . . . . . . . . . . . . . . . . . 14
5.8.2. Accept Input Parameters . . . . . . . . . . . . . . . 13 6.3.4. Accept Input Parameters . . . . . . . . . . . . . . . 14
5.8.3. Propertymap . . . . . . . . . . . . . . . . . . . . . 14 6.3.5. Response . . . . . . . . . . . . . . . . . . . . . . 14
5.8.4. Response . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Endpoint Cost Service Extensions . . . . . . . . . . . . 14
5.9. Endpoint Cost Service Extensions . . . . . . . . . . . . 14 6.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . 15
5.9.1. Capabilities . . . . . . . . . . . . . . . . . . . . 15 6.4.2. Capabilities . . . . . . . . . . . . . . . . . . . . 15
5.9.2. Accept Input Parameters . . . . . . . . . . . . . . . 15 6.4.3. Property-map . . . . . . . . . . . . . . . . . . . . 15
5.9.3. Propertymap . . . . . . . . . . . . . . . . . . . . . 16 6.4.4. Accept Input Parameters . . . . . . . . . . . . . . . 15
5.9.4. Response . . . . . . . . . . . . . . . . . . . . . . 16 6.4.5. Response . . . . . . . . . . . . . . . . . . . . . . 15
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Information Resource Directory Example . . . . . . . . . 17 7.2. Information Resource Directory Example . . . . . . . . . 17
6.3. Cost Map Example . . . . . . . . . . . . . . . . . . . . 19 7.3. Single Query Example # 1 . . . . . . . . . . . . . . . . 18
6.4. Multi-Cost Filtered Cost Map Example . . . . . . . . . . 20 7.4. Single Query Example # 2 . . . . . . . . . . . . . . . . 20
6.5. Endpoint Cost Service Example . . . . . . . . . . . . . . 22 7.5. Multiple Queries Example . . . . . . . . . . . . . . . . 21
6.6. Network Element Property Map Example # 1 . . . . . . . . 23 7.5.1. Endpoint Cost Service Example . . . . . . . . . . . . 21
6.7. Network Element Property Map Example # 2 . . . . . . . . 24 7.5.2. Abstract Network Element Property Map Example . . . . 23
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 25 8.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 23
7.2. Compatibility with Multi-Cost Extensions . . . . . . . . 25 8.2. Compatibility with Multi-Cost Extensions . . . . . . . . 23
7.3. Compatibility with Incremental Update . . . . . . . . . . 26 8.3. Compatibility with Incremental Update . . . . . . . . . . 24
8. Time to live . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Design Decisions and Discussions . . . . . . . . . . . . . . 24
9. Design Decisions and Discussions . . . . . . . . . . . . . . 26 9.1. Provide More General Calendar Extension . . . . . . . . . 24
9.1. Path Vector or Path Graph . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.2. Provide More General Calendar Extension . . . . . . . . . 27 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24
9.3. Snapshot and real-time update . . . . . . . . . . . . . . 27 10.2. Resource Consumption on ALTO Servers . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 25
11.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 28 11.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 25
11.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 28 11.3. ALTO Entity Domain Registry . . . . . . . . . . . . . . 26
11.3. ALTO Entity Domain Registry . . . . . . . . . . . . . . 28 11.4. ALTO Network Element Property Type Registry . . . . . . 26
11.4. ALTO Network Element Property Type Registry . . . . . . 29 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 13.1. Normative References . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . 29 13.2. Informative References . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The ALTO base protocol [RFC7285] is designed for exposing network The ALTO base protocol [RFC7285] is designed for exposing network
information through services such as the Network Map service and the information through services such as the Network Map service and the
Cost Map service. These services use the extreme "single-node" Cost Map service. These services use an extreme "single-node"
abstraction, which represents the whole network with a single node abstraction, which represents the whole network with a single node
and hosts are connected to the node's access ports. and hosts with "endpoint groups" directly connected to the node.
Although the "single-node" abstraction works well for many settings, Although the "single-node" abstraction works well in many settings,
new use cases, such as inter-datacenter data transfers and scientific it lacks the ability to support new emerging use cases, such as
high-performance computing data transfers, require additional network inter-datacenter flow scheduling and scientific high-performance
information beyond the single-node abstraction, to support computing data transfers. Specifically, the base ALTO protocol MUST
application capabilities, in particular, the ability of application provide the following two functionalities:
flow scheduling.
Specifically, providing network information to support application o Providing information on shared bottlenecks: In the aforementioned
flow scheduling introduces multiple complexities. First, the use cases, the volume of a single flow can reach 10s - 100s Gbps,
underlying assumption of existing ALTO services is single-commodity so that the network cannot treat the flows as independent like in
flows. Hence, given the flow from a source to a destination, ALTO the base ALTO protocol. In this case, ALTO servers MUST be able
computes the network metrics of the flow and returns them to the to provide information on shared bottlenecks to help applications
application. The metric values for different flows are independent. avoid congestion.
Application flow scheduling, however, requires network information to
compute application-desirable multi-commodity flows, where multiple
flows under the control of the same application may share common
network bottlenecks. This requirement is beyond the capability of
the single-node abstraction adopted by the base ALTO protocol.
Second, some flow scheduling problems may consider end-to-end metrics
at the same time and thus require multiple costs to be updated
simultaneously. Such a requirement, even though already addressed by
[I-D.ietf-alto-multi-cost], still needs to be handled very carefully.
To address these complexities in supporting the new flow scheduling o Encapsulating multiple cost values in a single session: Some flow
use case, this document specifies a path-vector extension to the base scheduling problems take multiple metrics into consideration.
ALTO protocol. This extension introduces a new cost type, which uses Making multiple queries introduces larger communication overhead,
"path-vector" as cost mode and "ane" (abstract network element) as and more importantly, out-of-sync data for different cost types.
cost metric. It extends "Filtered Property Map" defined in Encapsulating multiple cost values in a single query and response
[I-D.roome-alto-unified-props] to address the issue of scalability session reduces communication overhead and simplifies the
and consistency in providing path vectors with fine-grained synchronization in use cases involving multiple cost types.
information. This document also registers a new entity domain,
entity specification and properties in the ALTO Entity Domain This draft aims to extend the base ALTO protocol to support these new
Registry. Besides, (Filtered) Cost Map and Endpoint Cost Service are functionalities, with the path-vector extension. The path-vector
extended to support path-vector and flow query format. The concept extension specifies how to encode the shared bottlenecks in a network
of "query specific" is put forward to correlate the response for a given set of flows with many design details driven by
information of (Filtered) Cost Map/Endpoint Cost service and query of effectiveness, performance and backward compatibility considerations.
property map.
The second functionality for simple cost types, such as those
introduced in the base protocol, is already addressed in a recent
extension, e.g. [I-D.ietf-alto-multi-cost]. However, the path-
vector extension in this document has introduced a new cost type
which complicates the situation. Thus, the multiple cost
encapsulation must still be taken into consideration.
The document is organized as follows. Section 3 gives an example of The document is organized as follows. Section 3 gives an example of
flow scheduling to illustrate the need to introduce cost mode "path- flow scheduling and illustrates the limitations of the base ALTO
vector" and cost metric "ane". Section 4 gives an overview of the protocol in such a use case. Section 4 gives an overview of the
path-vector extension. Section 5 specifies the new cost mode and path-vector extension, before specifying the details of the extension
cost metric, new domain type, entity properties and protocol in Section 5 and Section 6. Section 7 presents several examples, and
extensions for (Filtered) Cost Maps and Endpoint Cost Services. Section 9 explains some design decisions. Section 8 discusses
Section 6 presents several examples. Section 7 discusses the compatibility issues with some other ALTO extensions. Section 10 and
compatibility issues with some other proposed ALTO extensions. Section 11 discusses about security and IANA considerations.
Section 8 discusses the time to live problem. Section 9 discusses
several design decisions. Section 10 and Section 11 discusses about
security and IANA Considerations.
2. Terminology 2. Terminology
This document uses the following terms: Network Element, Network This document uses the same terms as defined in [RFC7285],
Element Name, Network Element Property, Network Element Property Map [I-D.ietf-alto-multi-cost] and [I-D.roome-alto-unified-props] with
and Path Vector. the following additional terms: Abstract Network Element, Abstract
Network Element Name, Abstract Network Element Property, Abstract
Network Element Property Map and Path Vector.
o Network Element (NE): A Network Element is an abstract network o Abstract Network Element (ANE): An abstract network element is an
element, which can be a link, a network switching device, or a set abstraction of network components, it can be an aggregation of
of devices. links, middle boxes, Virtualized Network Function (VNF), or even a
sub-network. An abstract network element has two attributes:
abstract network element name and abstract network element
property, which are defined below.
o Network Element Name (NEN): The id of a NE. It can be referenced o Abstract Network Element Name (ANEN): An abstract network element
by Cost Map, Filtered Cost Map, Endpoint Cost Service and Property name is an identifier which uniquely identifies an abstract
Map. network element, as defined in Section 5.3.
o Network Element Property (NEP): The property of a NE. It can be o Abstract Network Element Property (ANEP): An abstract network
the available bandwidth of a link, the delay or other available element property is a specific metric associated with a given
abstract network element, as introduced in Section 4.3. An
abstract network element CAN have several network element
properties. properties.
o Network Element Property Map (NEP Map): It is a Filtered Property o Abstract Network Element Property Map (ANEP Map): An abstract
Map resource defined in [I-D.roome-alto-unified-props] and network element property map is a Filtered Property Map defined in
supports "ane" domain in its "domain-types" capability. [I-D.roome-alto-unified-props] which supports the "ane" domain in
its "domain-types" capability.
o Cost Map, Filtered Cost Map, Endpoint Cost Service: If not
explained explicitly, they are the same definition as of
[I-D.ietf-alto-multi-cost] by default.
o Path Vector (PV): An array of NENs. It can be used to convey the o Path Vector (PV): A path vector is an array of abstract network
routing information. elements, representing an abstract path between entities (PIDs or
endpoints).
3. Use Case: Capacity Region for Multi-Flow Scheduling 3. Use Case: Capacity Region for Multi-Flow Scheduling
Consider the case that routing is given. Then what application-layer Consider the case that routing is given. Then what application-layer
traffic optimization will focus on is traffic scheduling among traffic optimization will focus on is traffic scheduling among
application-layer paths. Specifically, assume that an application application-layer paths. Specifically, assume that an application
has control over a set of flows F = {f_1, f_2, ..., f_|F|}. If has control over a set of flows F = {f_1, f_2, ..., f_|F|}. If
routing is given, what the application can control is x_1, x_2, ..., routing is given, what the application can control is x_1, x_2, ...,
x_|F|, where x_i is the amount of traffic for flow i. Let x = [x_1, x_|F|, where x_i is the amount of traffic for flow i. Let x = [x_1,
..., x_|F|] be the vector of the flow traffic amounts. Due to shared ..., x_|F|] be the vector of the flow traffic amounts. Due to shared
links, feasible values of x where link capacities are not exceeded links, feasible values of x where link capacities are not exceeded
can be a complex polytype. can be a complex polytype.
Specifically, consider a network as shown in Figure 1. The network Specifically, consider a network as shown in Figure 1. The network
has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches
sw1/sw3 provide access on one side, sw2/sw4 provide access on the sw1/sw3 provide access on one side, sw2/sw4 provide access on the
other side, and sw5-sw7 form the backbone. End hosts eh1 to eh4 are other side, and sw5-sw7 form the backbone. End hosts eh1 to eh4 are
connected to access switches sw1 to sw4 respectively. Assume that connected to access switches sw1 to sw4 respectively. Assume that
the bandwidth of each link is 100 Mbps. the bandwidth of link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps,
and the bandwidth of the rest links are 100 Mbps.
+------+ +------+
| | | |
--+ sw6 +-- --+ sw6 +--
/ | | \ / | | \
PID1 +-----+ / +------+ \ +-----+ PID2 PID1 +-----+ / +------+ \ +-----+ PID2
eh1__| |_ / \ ____| |__eh2 eh1__| |_ / \ ____| |__eh2
| sw1 | \ +--|---+ +---|--+ / | sw2 | | sw1 | \ +--|---+ +---|--+ / | sw2 |
+-----+ \ | | | |/ +-----+ +-----+ \ | | | |/ +-----+
\_| sw5 +---------+ sw7 | \_| sw5 +---------+ sw7 |
skipping to change at page 6, line 44 skipping to change at page 6, line 48
{eh3} | | {eh4} {eh3} | | {eh4}
PID3 | | PID4 PID3 | | PID4
+------+ +------+ +------+ +------+
| | | |
+----------------------+ +----------------------+
Figure 2: Base Single-Node Topology Abstraction. Figure 2: Base Single-Node Topology Abstraction.
Consider an application overlay (e.g., a large data analysis system) Consider an application overlay (e.g., a large data analysis system)
which needs to schedule the traffic among a set of end host source- which needs to schedule the traffic among a set of end host source-
destination pairs, say eh1 -> eh2, and eh3 -> eh4. The application destination pairs, say eh1 -> eh2 and eh1 -> eh4. The application
can request a cost map providing end-to-end available bandwidth, can request a cost map providing end-to-end available bandwidth,
using 'availbw' as cost-metric and 'numerical' as cost-mode. using 'availbw' as cost-metric and 'numerical' as cost-mode.
Assume that the application receives from the ALTO server that the The application will receive from ALTO server that the bandwidth of
bandwidth of eh1 -> eh2 and eh3 ->eh4 are both 100 Mbps. It cannot eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information is
determine that if it schedules the two flows together, whether it not enough. Consider the following two cases:
will obtain a total of 100 Mbps or 200 Mbps. This depends on whether
the routing paths of the two flows share a bottleneck in the
underlying topology:
o Case 1: If eh1 -> eh2 and eh3 -> eh4 use different paths, for o Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 ->
example, when the first uses sw1 -> sw5 -> sw7 -> sw2, and the sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 ->
second uses sw3 -> sw5 -> sw6 -> sw7 -> sw4. Then the application sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps.
will obtain 200 Mbps.
o Case 2: If eh1 -> eh2 and eh3 -> eh4 share a bottleneck, for o Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 ->
example, when both use the direct link sw5 -> sw7, then the sw2 -> eh2 and eh1 -> eh4 uses the path eh1 -> sw1 -> sw5 -> sw7
application will obtain only 100 Mbps. -> sw4 -> eh4, then the application will obtain only 100 Mbps.
To allow applications to distinguish the two aforementioned cases, To allow applications to distinguish the two aforementioned cases,
the network needs to provide more details. In particular, it needs the network needs to provide more details. In particular, it needs
to provide the following new capabilities: to provide the following new capabilities:
o The network needs to expose more detailed routing information to o The network needs to expose more detailed routing information to
show the shared bottlenecks. show the shared bottlenecks.
o The network needs to provide the necessary abstraction to hide the o The network needs to provide the necessary abstraction to hide the
real topology information as possible. real topology information as possible.
The path-vector extension defined in this document will satisfy all The path-vector extension defined in this document will satisfy all
the requirements. the requirements.
See [I-D.bernstein-alto-topo] for a survey of use-cases where See [I-D.bernstein-alto-topo] for a survey of use-cases where
extended network topology information is needed. extended network topology information is needed.
4. Overview of Approach 4. Overview
This section presents a non-normative overview of the path-vector This section presents a non-normative overview of the path-vector
extension defined in this document. It assumes the readers are extension. It assumes the readers are familiar with (Filtered) Cost
familiar with (Filtered) Cost Map and Endpoint Cost Service defined Map and Endpoint Cost Service defined in [RFC7285], their extensions
in [RFC7285], their extensions defined in [I-D.ietf-alto-multi-cost] defined in [I-D.ietf-alto-multi-cost] and Filtered Property Map
and Filtered Property Map defined in [I-D.roome-alto-unified-props]. defined in [I-D.roome-alto-unified-props].
4.1. Path Vector Data Format
The path-vector extension defined in this document introduces "path- 4.1. Path Vector
vector" as a cost mode, where a path vector between two entities
(either PIDs or endpoints) is an array of abstract network elements.
Each abstract network element is represented by a name. An abstract
network element can be a link, a network switching device, or a set
of devices.
One issue of introducing path vectors is how to encode them. The A path vector is an array of abstract network elements, representing
cost entries contained in an ALTO (Filtered) Cost Map or Endpoint an abstract path between entities (PIDs or endpoints). Each abstract
Cost Service are formally defined in Section 11.2.3.6 of [RFC7285] to network element has two attributes: name and property. The abstract
be any type of JSON value. But the section also suggests that network element names are encoded in cost maps and the abstract
implementations may assume the cost values are numbers unless network element properties are encoded in abstract network element
specifically defined by an extension. This document extends the property maps.
definition of Cost Map and Endpoint Cost Map to allow the returned
cost to be a path vector, which is a JSONArray of Network Element
Names.
4.2. Network Element Property Map 4.2. Cost Type Extension
The response with only the names of network elements does not provide To provide abstract network element names of a path in cost maps,
enough information. To be useful to applications, the extension need each cost value is a list of abstract network element names.
to provide desired properties of the abstract network elements as However, as defined in Section 6.1.2 of [RFC7285], a cost mode is
well. This document registers a new entity domain "ane" and entity either "numerical" or "ordinal", none of which can be used to present
specifications. The Filtered Property Map defined in a list.
[I-D.roome-alto-unified-props] supporting "ane" domain (named Network
Element Property Map) is used for ALTO clients to retrieve the
properties of abstract network elements.
4.3. Flow Query Format This document specifies a new cost mode "array" and a new cost metric
"ane-path". The new cost mode "array" means each cost value in the
cost maps is a list. The new cost metric "ane-path" means each cost
value represents an abstract path consisting of abstract network
element names between two entities (PIDs or endpoints).
Current queries of the (Filtered) Cost Map/Endpoint Cost Service are The new cost type follows the convention of the cost types in the
of cross-product format. Such format fails to support lists of base protocol. For example:
single src to single dst costs. So the input scheme of the Filtered
Cost Map and Endpoint Cost Service is extended to support the above
flow query format.
4.4. Query Specific +------------+--------------+---------------------------------------+
| cost mode | cost metric | meaning |
+------------+--------------+---------------------------------------+
| numerical | routingcost | a number representing the routing |
| | | cost |
| ordinal | hopcount | a ranking representing the hop count |
| array | ane-path | a list representing the ane path |
+------------+--------------+---------------------------------------+
Path Vector extension has raised a new occasion that different Table 1: Cost Types and Their Meanings
resources can be associated with the same query. Here, the cost path
vector of the (Filtered) Cost Map/Endpoint Cost Service and the
properties of the abstract network elements of the Network Element
Property Map are generated at the same time and they are related.
So, a query-specific attribute "query-id" is introduced in the "vtag"
to express such information. Also, the input parameters of the
Network Element Property Map is extended to support the query-
specific queries.
5. Protocol Extensions 4.3. Abstract Network Element Property Map
This section formally specifies the path-vector extension which Given that Cost Map and Endpoint Cost service now provide the
includes the following components: a new cost type, a new entity abstract network element names along a flow path, ALTO clients can
domain, extensions of (Filtered) Cost Map and Endpoint Cost Map. learn that there exist bottlenecks between different flows. However,
Below we specify each component in details. only providing the abstract network element names without abstract
network element properties is not enough, because ALTO clients often
require the information on specific metric values like the link
capacity. This document adopts the property map defined in a recent
draft [I-D.roome-alto-unified-props] to encode the properties of
abstract network elements. A new domain "ane" is registered in the
property map. Each entity in the "ane" domain is an abstract network
element. The property map which supports "ane" domain is an Abstract
Network Element Property Map.
5.1. Cost Type 4.4. New Media Type: multipart/related
The path-vector extension defined in this document enriches the cost In the base ALTO protocol, ALTO servers use media types in the HTTP
types defined in Section 6.1 of [RFC7285]. header to indicate the type of the response. Typically one response
only contains a single media type, such as "application/alto-
costmap+json" or "application/alto-propmap+json". This has limited
the capability of ALTO servers to return multiple services in a
single response.
5.1.1. Cost Metric Thus, an ALTO client MUST make multiple queries to get the
information from services of different types. This has led to the
data synchronization problem between dependent ALTO services because
when making the second query, the result for the first query may have
already changed. The very same problem can happen to Network Map and
Cost Map resources. However, unlike Network Map and Cost Map which
are considered more stable, path vectors and the dependent abstract
network element property maps might change more frequently.
This document specifies a new cost metric: "ane". It is of type Instead of introducing a new media type to encapsulate multiple types
CostMetric as defined in Section 10.6 of [RFC7285]. The cost metric in a single response, this documents adopts the "multipart" media
"ane" MUST NOT be used when the cost mode is not "path-vector" unless type defined in [RFC2387]. Thus, a response can contain both the
it is explicitly specified in a future extension. Meanwhile, an ALTO path vector as a Cost Map (or Endpoint Cost Map) and the
server with path-vector extension MUST support the cost metric "ane". corresponding abstract network element property map as a Property
Map. The media types of the path vector and the abstract network
element property map can still be retrieved from the response,
achieving consistency with the base ALTO protocol.
Cost metric "ane": This cost metric MUST be encoded as the For backward compatibility, this extension also allows ALTO clients
JSONString "ane". When cost metric is "ane", Network Element to make multiple queries instead of encapsulating abstract network
Names contained in the path vectors MUST be query-specific. element property map along with the path vector. Thus, each Cost Map
or Endpoint Cost Service with this extension MUST include a "prop-
map" in their capabilities to indicate where to retrieve the network
element properties. An additional field "query-id" MUST also be
added to the "vtag" field to uniquely identify a path vector query
session.
5.1.2. Cost Mode: Path Vector 5. Path-Vector Extension: Basic Data Types
This document specifies a new cost mode: "path-vector". The path- This section formally specifies the path-vector extension of some
vector cost mode is of type CostMode as defined in Section 6.1.2 of basic data types.
[RFC7285] and is encoded as the JSONString "path-vector".
A (Filtered) Cost Map resource or Endpoint Cost Service, when queried 5.1. Cost Type
with this cost mode, MUST return a CostMapData or EndpointCostMapData
whose cost value is a JSONArray of type NetworkElementName as
specified in Section 5.3.
This cost mode MUST be used with the cost metric "ane" unless it is This document extends the cost types defined in Section 6.1 of
explicitly specified by a future extension. [RFC7285] by introducing a new cost mode "array" and a new cost
metric "ane-path".
5.2. Version Tag 5.1.1. Cost Metric
To support the concept of query specific, a new field named "query- This document specifies a new cost metric: "ane-path". It is of type
id" is introduced to correlate the query information between the CostMetric as defined in Section 10.6 of [RFC7285]. The cost metric
(Filtered) Cost Map/Endpoint Cost Service response and the "ane-path" MUST NOT be used when the cost mode is not "array" unless
corresponding property map query. The object VersionTag as defined it is explicitly specified by a future extension. Meanwhile, an ALTO
in Section 10.3 of [RFC7285] is extended as follows: server with path-vector extension MUST support the cost metric "ane-
path".
object { Cost metric "ane-path": This cost metric MUST be encoded as the
ResourceID resource-id; JSONString "ane-path".
JSONString tag;
[JSONString query-id;]
} VersionTag;
resource-id, tag: As defined in Section 10.3 of [RFC7285]. 5.1.2. Cost Mode
query-id: A string used to uniquely identify the abstract network This document extends the CostMode defined in Section 10.5 of
elements in the property map. [RFC7285] with a new cost mode: "array". The extended CostMode is
encoded as a string and MUST have a value of either "numerical",
"ordinal" or "array" unless it is explicitly specified by a future
extension. In particular, this extension has specified that when the
cost metric is "ane-path", the cost value MUST be interpreted as a
JSONArray of Abstract Network Element Names (defined in Section 5.3).
5.3. Network Element Name An ALTO cost service MUST return a JSONArray of JSONValue when the
cost mode is "array" unless the interpretation is explicitly
specified by an ALTO extension.
This document also extends [RFC7285] with a new basic data type: Cost mode "array": This cost mode MUST be encoded as the JSONString
NetworkElementName. A NetworkElementName is of type EntityAddr as "array".
defined in Section 2.3 of [I-D.roome-alto-unified-props] and is
encoded as a JSONString. A NetworkElementName MUST be an EntityAddr
of the ANE domain (Section 5.4).
5.4. ANE Domain 5.2. ANE Domain
This document specifies a new domain in addition to the ones in This document specifies a new domain in addition to the ones in [I-
[I-D.roome-alto-unified-props]. D.roome-alto-unified-props].
5.4.1. Domain Name 5.2.1. Domain Name
ane ane
5.4.2. Domain-Specific Entity Addresses 5.2.2. Domain-Specific Entity Addresses
The entity address of ane domain is encoded as a JSON string. The The entity address of ane domain is encoded as a JSON string. The
string MUST be no more than 64 characters, and it MUST NOT contain string MUST be no more than 64 characters, and it MUST NOT contain
characters other than US-ASCII alphanumeric characters characters other than US-ASCII alphanumeric characters
(U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
U+002D), the colon (':', U+003A), the at sign ('@', code point U+002D), the colon (':', U+003A), the at sign ('@', code point
U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). U+0040), the low line ('_', U+005F), or the '.' separator (U+002E).
The '.' separator is reserved for future use and MUST NOT be used The '.' separator is reserved for future use and MUST NOT be used
unless specifically indicated in this document, or an extension unless specifically indicated in this document, or an extension
document. document.
5.5. Filtered Network Element Property Map 5.3. Abstract Network Element Name
A Filtered Network Element Property Map MUST be a Filtered Property An Abstract Network Element Name MUST be encoded as an EntityAddr as
Map as defined in Section 5 of [I-D.roome-alto-unified-props]. defined in Section 5.2.2. It MUST belong to the "ane" domain.
5.5.1. Accept Input Parameters 5.4. Version Tag
This document extends ReqFilteredPropertyMap defined in Section 5.3 This document extends the VersionTag, previously defined in
of [I-D.roome-alto-unified-props] by introducing an optional field Section 10.3 of [RFC7285] with an optional field "query-id". If an
named "query-id". The ReqFilteredPropertyMap is extended as follows: ALTO cost service supports the path-vector extension, this field MUST
be included in the "vtag" field, and the "vtag" field MUST be
included in the "meta" field in the response in order to provide the
"query-id" information.
object { object {
EntityAddr entities<1..*> ResourceID resource-id;
PropertyName properties<1..*>; JSONString tag;
[JSONString query-id;] [JSONString query-id;]
} ReqFilteredPropertyMap; } VersionTag;
entities, properties: The same as defined in Section 5.3 of
[I-D.roome-alto-unified-props].
query-id: Like the "query-id" defined in Section 5.2, the "query-id"
here is also a string used to uniquely identify the abstract
network elements in the property map.
5.5.2. Capabilities resource-id, tag: As defined in Section 10.3 of [RFC7285].
A Network Element Property Map MUST have capabilities "domain-types" query-id: A string used to uniquely identify the abstract network
and "prop-types" as defined in Section 4.4 of element names in the response and correlate abstract network
[I-D.roome-alto-unified-props]. The "domain-types" capability MUST element names with abstract network element properties. A "query-
contain domain "ane". And the "prop-types" capability MUST be a id" MUST be encoded in the same format as defined in Section 10.1
subset of property types which are registered with the "ALTO Network of [RFC7285].
Element Property Type Registry" defined in Section 11.4 of this
document.
5.5.3. Response 6. Path-Vector Extension: Services
The response is the same as for the Property Map, as defined in This section extends IRDResourceEntry, Cost Map Service and Endpoint
Section 4.6 of [I-D.roome-alto-unified-props], except that only the Cost Service.
requested entities and properties are returned for Filtered Network
Element Map. Examples can be found in Section 6.6 and Section 6.7.
5.6. IRD Extensions 6.1. IRD Extensions
This document extends IRDResourceEntry defined in Section 9.2.2 of This document extends IRDResourceEntry defined in Section 9.2.2 of
[RFC7285] by introducing a new entry named "propertymap". The [RFC7285] by introducing a new entry named "property-map", which
IRDResourceEntry object is extended as follows: indicates where the specific properties of the abstract network
elements can be retrieved. The IRDResourceEntry object is extended
as follows:
object { object {
JSONString uri; JSONString uri;
JSONString media-type; JSONString media-type;
[JSONString accepts;] [JSONString accepts;]
[Capabilities capabilities;] [Capabilities capabilities;]
[ResourceID uses<0..*>;] [ResourceID uses<0..*>;]
[ResourceID propertymap<0..*>;] [ResourceID property-map;]
} IRDResourceEntry; } IRDResourceEntry;
uri, media-type, accepts, capabilities, uses: The same as defined in uri, media-type, accepts, capabilities, uses: The same as defined in
Section 9.2.2 of [RFC7285]. Section 9.2.2 of [RFC7285].
propertymap: A list of resource IDs, defined in the same IRD, that property-map: A resource ID defined in the same IRD pointing to an
indicates where the specific properties of the returned abstract abstract network element property map as defined in Section 2.
network elements can be retrieved.
5.7. Cost Map Extensions 6.2. Cost Map Extensions
This document extends Cost Map defined in Section 11.2.3 of [RFC7285] This document extends the Cost Map defined in Section 11.2.3 of
by returning JSONArray instead of JSONNumber as the cost value, [RFC7285].
including "vtag" in "meta" field in the response, and adding a new
field referencing to the Network Element Property Map.
The media type, HTTP method, capabilities, accept input parameter and The specifications for "HTTP method", "accept input parameters" and
uses specifications are unchanged. "uses" are the same as defined in Section 11.2.3 of [RFC7285].
5.7.1. Propertymap 6.2.1. Media Type
If the Cost Map supports the path-vector extension, the field The path vector extension now enables ALTO clients to receive
"propertymap" provides a list of resource ids of Network Element multiple services in a cost map response.
Property Map. Each network element property map resource provides
properties for the dynamically generated abstract network elements.
5.7.2. Response Specifically, if an ALTO client accepts "multipart/related",
"application/alto-costmap+json" and "application/alto-propmap+json"
at the same time, the ALTO server MUST use "multipart/related" as the
media type in the HTTP header.
The response is the same as defined in Section 11.2.3.6 of [RFC7285] 6.2.2. Capabilities
except the follows:
o If the cost mode is "path-vector", the cost is a JSONArray of If a service supports the path-vector extension, the "cost-type-
Network Element Names. names" field MUST include a single cost type with "ane-path" as cost
metric and "array" as cost mode.
6.2.3. Property-map
If a service supports the path-vector extension, the "property-map"
field MUST be specified. This field is a resource ID of an abstract
network element property map where the abstract network element
properties are provided.
6.2.4. Response
If an ALTO client accepts "multipart/related" as defined in
Section 6.3.1, HTTP body of the response MUST consists of two parts
with the media types "application/alto-costmap+json" and
"application/alto-propmap+json" accordingly. Specifically, the part
with media type "application/alto-costmap+json" MUST be the first
part.
The content of the "application/alto-costmap+json" part uses the
format in Section 11.2.3.6 of [RFC7285] with the following
constraints:
o The cost value for a path vector query, e.g. the cost mode is
"array" and the cost metric is "ane-path", MUST be encoded as a
JSONArray of AbstractNetworkElementName.
o If the query sent by the client includes cost type path vector, o If the query sent by the client includes cost type path vector,
the "vtag" filed defined in Section 5.2 has to be included in the the "vtag" field defined in Section 5.4 has to be included in the
response. And the "query-id" information in "vtag" MUST be response. And the "query-id" information in "vtag" MUST be
provided to clients. provided to ALTO clients.
5.8. Filtered Cost Map Extensions 6.3. Filtered Cost Map Extensions
This document extends the Filtered Cost Map defined in Section 4.1 of This document extends the Filtered Cost Map defined in Section 4.1 of
[I-D.ietf-alto-multi-cost] by specifying details on capabilities, [I-D.ietf-alto-multi-cost].
returning JSONArray instead of JSONNumber as the cost value,
including "vtag" in "meta" field in the response, and adding a new
field referencing to the Network Element Property Map.
The media type, HTTP method and uses specifications are unchanged.
5.8.1. Capabilities
The FilteredCostMapCapabilities object is the same as defined in The specifications for "HTTP method" and "uses" are the same as
Section 4.1.1 of [I-D.ietf-alto-multi-cost] expect the follow: defined in Section 4.1 of [I-D.ietf-alto-multi-cost].
testable-cost-type-names: Cost type "path-vector" MUST NOT appear in 6.3.1. Media Type
the "testable-cost-type-names" field.
5.8.2. Accept Input Parameters The same as Section 6.2.1.
The ReqFilteredCostMap defined in Section 4.1.2 of 6.3.2. Capabilities
[I-D.ietf-alto-multi-cost] is extended, the meanings and the
constraints of some fields are also extended.
object { The FilteredCostMapCapabilities object has the same format as defined
[CostType cost-type;] in Section 4.1.1 of [I-D.ietf-alto-multi-cost] with the following
[CostType multi-cost-types<1..*>;] constraint:
[CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;]
[JSONString or-constraints<1..*><1..*>;]
[PIDFilter pids;]
[PIDFlowFilter pid-flows<1..*>;]
} ReqFilteredCostMap;
object { testable-cost-type-names: The path vector cost type with "ane-path"
PIDName src; as the cost metric and "array" as the cost mode MUST NOT be
PIDName dst; included in "testable-cost-type-names".
} PIDFlowFilter;
cost-type: If the cost type is path-vector and neither the 6.3.3. Property-map
"testable-cost-type-names" field is provided by the server nor the
"testable-cost-types" field is provided by the client, the
"constraints" field and the "or-constraints" field SHOULD NOT
appear. If not, the ALTO server MUST return an error with error
code E_INVALID_FIELD_VALUE. The server MAY include an optional
field named "field" in the "meta" field of the response, the value
of "field" is "constraints" or "or-constraints". The server MAY
also include an optional field named "value" in the "meta" field,
the value of "value" is "path-vector". If the "value" field is
specified, the "field" field MUST be specified.
multi-cost-types: If "multi-cost-types" includes cost type path- The same as Section 6.2.3.
vector, meanwhile, neither the "testable-cost-type-names" field is
provided by the server nor the "testable-cost-types" field is
provided by the client, the cost type index of path-vector MUST
NOT appear in the "constraints" field or the "or-constraints"
field. If not, the ALTO server MUST return an error with error
code E_INVALID_FIELD_VALUE. The server MAY include an optional
field named "field" in the "meta" field of the response, the value
of "field" is "constraints" or "or-constraints". The server MAY
also include an optional field named "value" in the "meta" field,
the value of "value" is "path-vector". If the "value" field is
specified, the "field" field MUST be specified.
testable-cost-types: "testable-cost-types" SHOULD NOT include path- 6.3.4. Accept Input Parameters
vector cost type. If "testable-cost-types" contains path-vector
cost type, the ALTO server MUST return an error with error code
E_INVALID_FIELD_VALUE. The server MAY include an optional field
named "field" in the "meta" field of the response, the value of
"filed" is "testable-cost-types/cost-mode". The server MAY also
include an optional field named "value" in the "meta" field, the
value of "value" is "path-vector". If the "value" field is
specified, the "field" field MUST be specified.
pid-flows: A list of PID src to PID dst for which path costs are to The ReqFilteredCostMap uses the same format as defined in
be returned. Section 4.1.2 of [I-D.ietf-alto-multi-cost], with the following
constraints:
Additional requirement is that the Client MUST specify either "pids" constraints, or-constraints: If the path vector cost type is
or "pid-flows", but MUST NOT specify both. included in either "cost-type" or "multi-cost-types", ALTO clients
MUST NOT use it in "constraints" or "or-constraints". Otherwise,
the ALTO server MUST return an error with error code
"E_INVALID_FIELD_VALUE".
5.8.3. Propertymap testable-cost-types: The path vector cost type MUST NOT be included
in the "testable-cost-types" field. Otherwise, the ALTO server
MUST return an error with error code "E_INVALID_FIELD_VALUE".
If the Filtered Cost Map supports the path-vector extension, the 6.3.5. Response
field "propertymap" provides a list of resource ids of Network
Element Property Map. Each network element property map resource
provides properties for the dynamically generated abstract network
elements.
5.8.4. Response If an ALTO client accepts "multipart/related" as defined in
Section 6.3.1, HTTP body of the response MUST consist of two parts
with the media types "application/alto-costmap+json" and
"application/alto-propmap+json" accordingly. Specifically, the part
with media type "application/alto-costmap+json" MUST be the first
part.
The response is the same as defined in Section 4.1.3 of The content of the "application/alto-costmap+json" part has the same
[I-D.ietf-alto-multi-cost] except the follows: format as defined in Section 4.1.3 of [I-D.ietf-alto-multi-cost] with
the following constraints:
o Whether the "cost-type" field or the "multi-cost-types" field o When the path vector cost type is included in "cost type" or
includes cost type path-vector, the cost is a JSONArray of Network "multi-cost-type", the corresponding cost value MUST be encoded as
Element Names. a JSONArray of AbstractNetworkElementName.
o If the query sent by the client includes cost type path vector, o If the query sent by the client includes cost type path vector,
the "vtag" filed defined in Section 5.2 has to be included in the the "vtag" field defined in Section 5.4 has to be included in the
response. And the "query-id" information in "vtag" MUST be response. And the "query-id" information in "vtag" MUST be
provided to clients. provided to ALTO clients.
5.9. Endpoint Cost Service Extensions 6.4. Endpoint Cost Service Extensions
This document extends the Endpoint Cost Service defined in This document extends the Endpoint Cost Service defined in
Section 4.2 in [I-D.ietf-alto-multi-cost] by specifying details on Section 4.2 in [I-D.ietf-alto-multi-cost].
capabilities, returning JSONArray instead of JSONNumber as the cost
value, including "vtag" in "meta" field in the response, and adding a
new field referencing to the Network Element Property Map.
The media type, HTTP method and uses specifications are unchanged. The specifications for "HTTP method" and "uses" are the same as
defined in Section 4.2 in [I-D.ietf-alto-multi-cost].
5.9.1. Capabilities 6.4.1. Media Type
The same as defined in Section 5.8.1. The path vector extension now enables ALTO clients to receive
multiple objects from the endpoint cost service response.
5.9.2. Accept Input Parameters Specifically, if an ALTO client accepts "multipart/related",
"application/alto-endpointcost+json" and "application/alto-
propmap+json" at the same time, the ALTO server MUST use "multipart/
related" as the media type in the HTTP header.
The ReqFilteredCostMap defined in Section 4.1.2 of 6.4.2. Capabilities
[I-D.ietf-alto-multi-cost] is extended, the meanings and the
constraints of some fields are also extended.
``` object { [CostType cost-type;][CostType multi-cost-types<1..*>;] The same as defined in Section 6.3.2.
[CostType testable-cost-types<1..*>;][JSONString constraints<0..*>;]
[JSONString or-constraints<1.._><1.._>;][EndpointFilter endpoints;]
[EndpointFlowFilter endpoint-flows<1..*>;] } ReqEndpointCostMap;
object { TypedEndpointAddr src; TypedEndpointAddr dst; } 6.4.3. Property-map
EndpointFlowFilter; ```
cost-type: If the cost type is path-vector and neither the The same as Section 6.2.3.
"testable-cost-type-names" field is provided by the server nor the
"testable-cost-types" field is provided by the client, the
"constraints" field and the "or-constraints" field SHOULD NOT
appear. If not, the ALTO server MUST return an error with error
code E_INVALID_FIELD_VALUE. The server MAY include an optional
field named "field" in the "meta" field of the response, the value
of "field" is "constraints" or "or-constraints". The server MAY
also include an optional field named "value" in the "meta" field,
the value of "value" is "path-vector". If the "value" field is
specified, the "field" field MUST be specified.
multi-cost-types: If "multi-cost-types" includes cost type path- 6.4.4. Accept Input Parameters
vector, meanwhile, neither the "testable-cost-type-names" field is
provided by the server nor the "testable-cost-types" field is
provided by the client, the cost type index of path-vector MUST
NOT appear in the "constraints" field or the "or-constraints"
field. If not, the ALTO server MUST return an error with error
code E_INVALID_FIELD_VALUE. The server MAY include an optional
field named "field" in the "meta" field of the response, the value
of "field" is "constraints" or "or-constraints". The server MAY
also include an optional field named "value" in the "meta" field,
the value of "value" is "path-vector". If the "value" field is
specified, the "field" field MUST be specified.
testable-cost-types: "testable-cost-types" SHOULD NOT include path- The ReqEndpointCostMap uses the same format as defined in
vector cost type. If "testable-cost-types" contains path-vector Section 4.2.2 of [I-D.ietf-alto-multi-cost], with the following
cost type, the ALTO server MUST return an error with error code constraints:
E_INVALID_FIELD_VALUE. The server MAY include an optional field
named "field" in the "meta" field of the response, the value of
"filed" is "testable-cost-types/cost-mode". The server MAY also
include an optional field named "value" in the "meta" field, the
value of "value" is "path-vector". If the "value" field is
specified, the "field" field MUST be specified.
endpoint-flows: A list of endpoint src to endpoint dst for which cost-type, multi-cost-types: ALTO clients MUST include the path
path costs are to be returned. vector cost type, e.g. the one with "ane-path" as cost metric and
"array" as cost mode, in either "cost-type" or "multi-cost-types"
to activate the path vector extension.
Additional requirement is that the Client MUST specify either constraints, or-constraints: If the path vector cost type is
"endpoints" or "endpoint-flows", but MUST NOT specify both. included in either "cost-type" or "multi-cost-types", ALTO clients
MUST NOT use it in "constraints" or "or-constraints". Otherwise,
the ALTO server MUST return an error with error code
"E_INVALID_FIELD_VALUE".
5.9.3. Propertymap testable-cost-types: The path vector cost type MUST NOT be included
in the "testable-cost-types" field. Otherwise, the ALTO server
MUST return an error with error code "E_INVALID_FIELD_VALUE".
If the Endpoint Cost Service supports the path-vector extension, the 6.4.5. Response
field "propertymap" provides a list of resource ids of Network
Element Property Map. Each network element property map resource
provides properties for the dynamically generated abstract network
elements.
5.9.4. Response If an ALTO client accepts "multipart/related" as defined in
Section 6.4.1, HTTP body of the response MUST consist of two parts
with the media types "application/alto-endpointcost+json" and
"application/alto-propmap+json" accordingly. Specifically, the part
with media type "application/alto-endpointcost+json" MUST be the
first part.
The response is the same as defined in Section 4.2.3 of The content of the "application/alto-endpointcost+json" part has the
[I-D.ietf-alto-multi-cost] except the follows: same format as defined in Section 4.2.3 of [I-D.ietf-alto-multi-cost]
with the following constraints:
o Whether the "cost-type" field or the "multi-cost-types" field o When the path vector cost type is included in "cost type" or
includes cost type path-vector, the cost is a JSONArray of Network "multi-cost-type", the corresponding cost value MUST be encoded as
Element Names. a JSONArray of AbstractNetworkElementName.
o If the query sent by the client includes cost type path vector, o If the query sent by the client includes cost type path vector,
the "vtag" filed defined in Section 5.2 has to be included in the the "vtag" field defined in Section 5.4 has to be included in the
response. And the "query-id" information in "vtag" MUST be response. And the "query-id" information in "vtag" MUST be
provided to clients. provided to ALTO clients.
6. Examples
This section lists a series of examples to proceed the multi-flow 7. Examples
scheduling like the use case in Section 3.
The recommended workflow is like the following: This section lists a series of examples to proceed the flow
scheduling use case in Section 3.
6.1. Workflow 7.1. Workflow
o Send the GET request for the whole Information Resource Directory. This section gives a typical workflow of an ALTO client using the
path-vector extension.
o Look for the resource of the (Filtered) Cost Map/Endpoint Cost 1. Send a GET request for the whole Information Resource Directory.
Service which contains the path-vector cost type and get the
resource id of the property map.
o Look for the resource of the property map to check whether it 2. Look for the resource of the (Filtered) Cost Map/Endpoint Cost
supports the desired "prop-types". Service which contains the path vector cost type and get the
resource ID of the dependent abstract network element property
map.
o Send request to the (Filtered) Cost Map/Endpoint Cost Service and 3. Check whether the capabilities of the property map includes the
get the response with "query-id" information. Meanwhile, the desired "prop-types".
properties of the returned abstract network elements are generated
in the corresponding Network Element Property Map.
o Send request to the Network Element Property Map with the returned 4. Send a path-vector request which accepts "multipart/related"
"query-id" information and get the response. media type following Section 6.2.1, Section 6.3.1 or
Section 6.4.1.
6.2. Information Resource Directory Example Alternatively, one can replace step 4 with the following:
Here is an example of an ALTO server's Information Resource 1. Send a path-vector request which accepts "application/alto-
Directory. In this example, both "filtered-multi-cost-map" and costmap+json" or "application/alto-endpointcost+json".
"default-endpoint-cost-map" support the multi-cost extension and the
path-vector extension. Resource "ane-property-map-availbw" supports
property "availbw" and resource "ane-property-map-delay" supports
property "delay".
"meta": { 2. Find the "query-id" in "vtag" in the response.
"cost-types": {
"pv-ane": {
"cost-mode": "path-vector",
"cost-metric": "ane"
},
"num-hopcount": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
},
"num-routingcost": {
"cost-mode": "numerical",
"cost-metric": "routingcost"
},
}
},
"resources": {
... NetworkMap Resource ... 3. Query the dependent abstract network element property map with
the query ID and abstract network element names to retrieve the
associated properties.
"default-network-map": { 7.2. Information Resource Directory Example
"uri": "http://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json"
},
... Cost Map Resource ... Here is an example of an Information Resource Directory. In this
example, filtered cost map "cost-map-pv" doesn't support the multi-
cost extension but support the path-vector extension, "endpoint-
multicost-map" supports both multi-cost extension and path-vector
extension. Filtered Property Map "propmap-delay-availbw" supports
properties "availbw" and "delay", and "propmap-location" supports
property "location".
"pv-cost-map": { {
"uri": "http://alto.example.com/pv/ane", "meta": {
"media-type": "application/alto-costmap+json", "cost-types": {
"capabilities": { "pv": {
"cost-type-names": ["pv-ane"] "cost-mode": "array",
"cost-metric": "ane-path"
},
"num-routingcost": {
"cost-mode": "numerical",
"cost-metric": "routingcost"
},
"num-hopcount": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
}
}
},
"resources": {
"my-default-networkmap": {
"uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json"
}
"cost-map-pv" : {
"uri": "http://alto.example.com/costmap/pv",
"media-type": "application/alto-costmap+json",
"accepts": "application/alto-costmapfilter+json",
"capabilities": {
"cost-type-names": [ "pv", "num-hopcount" ]
},
"property-map": "propmap-delay",
"uses": [ "my-default-networkmap" ]
}, },
"uses": ["default-network-map"], "endpoint-multicost-map" : {
"propertymap": ["ane-property-map-delay", "uri": "http://alto.exmaple.com/endpointcostmap/multicost",
"ane-property-map-availbw"] "media-type": "application/alto-endpointcost+json",
} "accepts": "application/alto-endpointcostparams+json",
"capabilities": {
... Multi-Cost Filtered Map Resource ... "cost-constraints": true,
"cost-type-names": [ "pv", "num-routingcost" ],
"filtered-multi-cost-map": { "max-cost-types": 2
"uri": "http://alto.example.com/costmap/multi/filtered", },
"media-type": "application/alto-costmap+json", "property-map": "propmap-availbw"
"accepts": "application/alto-costmapfilter+json",
"uses": ["default-network-map"],
"capabilities": {
"max-cost-types": 3,
"cost-type-names": ["pv-ane",
"num-routingcost",
"num-hopcount"],
"cost-constraints": true
}, },
"propertymap": ["ane-property-map-delay", "propmap-availbw" : {
"ane-property-map-availbw"] "uri": "http://alto.exmaple.com/propmap/availbw",
}, "media-type": "application/alto-propmap+json",
"accepts": "application/alto-propmapparams+json",
... Endpoint Cost Service Resource ... "capabilities": {
"domain-types": [ "ane" ],
"default-endpoint-cost-map": { "prop-types": [ "delay", "availbw" ]
"uri": "http://alto.example.com/endpointcost/lookup", }
"media-type": "application/alto-endpointcostmap+json",
"accepts": "application/alto-endpointcostparams+json",
"capabilities": {
"max-cost-types": 3,
"cost-type-names": ["pv-ane",
"num-routingcost",
"num-hopcount"],
"testable-cost-types-names": ["num-hopcount",
"num-routingcost"],
}, },
"propertymap": ["ane-property-map-delay"] "propmap-delay" : {
} "uri": "http://alto.exmaple.com/propmap/delay",
"media-type": "application/alto-propmap+json",
... Network Element Property Map Resource ... "accepts": "application/alto-propmapparams+json",
"capabilities": {
"ane-property-map-delay": { "domain-types": [ "ane" ],
"uri": "http://alto.example.com/propmap/lookup/delay", "prop-types": [ "delay" ]
"media-type": "application/alto-propmap+json", }
"accepts": "application/alto-propmapparams+json",
"capabilities": {
"domain-types": ["ane"],
"prop-types": ["delay"]
}
}
"ane-property-map-availbw": {
"uri": "http://alto.example.com/propmap/lookup/availbw",
"media-type": "application/alto-propmap+json",
"accepts": "application/alto-propmapparams+json",
"capabilities": {
"domain-types": ["ane"],
"prop-types": ["availbw"]
} }
} }
} }
6.3. Cost Map Example 7.3. Single Query Example # 1
Here is an example of the Cost Map request for path-vector and the
corresponding response. In response, the extended "vtag" field is
included in "meta" to provide "query-id" information.
GET /costmap/pv/ane HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
HTTP/1.1 200 OK POST /costmap/pv HTTP/1.1
Content-Length: [TBD] Host: alto.example.com
Content-Type: application/alto-costmap+json Accept: multipart/related, application/alto-costmap+json,
application/alto-propmap+json, application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-costmapfilter+json
{ {
"meta" : { "cost-type": {
"dependent-vtags" : [ "cost-mode": "array",
{ "resource-id": "default-network-map", "cost-metric": "ane-path"
"tag": "5eb2cb7f8d63a9fab71d9b34cbf763436315542f" },
} "pids": {
], "srcs": [ "PID1" ],
"vtag": [ "dsts": [ "PID2", "PID3" ]
{ "resource-id": "pv-cost-map",
"tag": "aef527ca2eb7a7566db0597407893e3f8eb1d9dff",
"query-id": "query0"
}
],
"cost-type" : {"cost-mode" : "pv",
"cost-metric": "ane"
}
},
"cost-map" : {
"PID1": { "PID2": ["ane:L001", "ane:L003"],
"PID3": ["ane:L002", "ane:L004"] },
"PID2": { "PID1": ["ane:L003", "ane:L002"],
"PID3": ["ane:L003", "ane:L004"] },
"PID3": { "PID1": ["ane:L004", "ane:L002"],
"PID2": ["ane:L004", "ane:L003"] }
}
} }
6.4. Multi-Cost Filtered Cost Map Example }
The following example presents the request and response of "filtered- HTTP/1.1 200 OK
multi-cost-map". In this example, the client is interested in the Content-Length: [TBD]
path-vector and numerical routing cost information. The client uses Content-Type: multipart/related; boundary=42
"or-constraints" but all the results satisfy the conditions. In
resposne, the extended "vtag" field is included in "meta" to provide
"query-id" information.
POST /costmap/multi/filtered HTTP/1.1 --42
Host: alto.example.com Content-Type: application/alto-costmap+json
Accept: application/alto-costmap+json,application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-costmapfilter+json
{ {
"multi-cost-types": [ "meta": {
{ "dependent-vtags": [
"cost-mode": "path-vector",
"cost-metric": "ane"
},
{ {
"cost-mode": "numerical", "resource-id": "default-network-map",
"cost-metric": "routingcost" "tag": "75ed013b3cb58f896e839582504f622838ce670f"
} }
], ],
"testable-cost-types": [ "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" },
{ "cost-mode": "numerical", "cost-metric": "routingcost" },
{ "cost-mode": "numerical", "cost-metric": "hopcount" }
],
"or-constraints": [
["[0] ge 50", "[1] le 60"]
],
"pid-flows": [
{ "src": "PID1", "dst": "PID2" },
{ "src": "PID2", "dst": "PID3" }
]
}
HTTP/1.1 200 OK
Content-Length: [TBD]
Content-Type: application/alto-costmap+json
{ "vtag": {
"meta": { "resource-id": "cost-map-pv",
"dependent-vtags": [ "tag": "27612897acf278ffu3287c284dd28841da78213",
{ "query-id": "query1"
"resource-id": "default-network-map",
"tag": "75ed013b3cb58f896e839582504f622838ce670f"
}
],
"vtag": [
{
"resource-id": "filtered-multi-cost-map",
"tag": "27612897acf278ffu3287c284dd28841da78213",
"query-id": "query1"
}
]
} }
"cost-type": {}, },
"multi-cost-types": [
{ "cost-mode": "path-vector", "cost-metric": "ane" },
{ "cost-mode": "numerical", "cost-metric": "routingcost"}
],
"cost-map": { "cost-map": {
"PID1": { "PID1": {
"PID2": [ [ "ane:L001", "ane:L003" ], 55 ] "PID2": [ "ane:L001", "ane:L003" ],
}, "PID3": [ "ane:L001", "ane:L004" ]
"PID2": {
"PID3": [ [ "ane:L003", "ane:L004" ], 60 ]
}
} }
} }
}
6.5. Endpoint Cost Service Example --42
Content-Type: application/alto-propmap+json
If the ALTO client expects the routing state information between {
endpoints, it can also query the "default-endpoint-cost-map" resource "property-map": {
which supports path vector. In resposne, the extended "vtag" field "ane:L001": { "delay": 46},
is included in "meta" to provide "query-id" information. "ane:L003": { "delay": 50},
"ane:L004": { "delay": 70}
}
}
POST /endpointcost/lookup HTTP/1.1 --42--
Host: alto.example.com
Accept: application/alto-endpointcost+json,application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-endpointcostparams+json
{ 7.4. Single Query Example # 2
"multi-cost-types": [
{ "cost-mode": "path-vector", "cost-metric": "ane" },
{ "cost-mode": "numerical", "cost-metric": "hopcount" }
], POST /endpointcostmap/multicost HTTP/1.1
"endpoint-flows": [ Host: alto.example.com
{ "src": "ipv4:192.0.2.2", "dst": "ipv4:203.0.113.45" }, Accept: multipart/related, application/alto-costmap+json,
{ "src": "ipv4:192.0.2.89", "dst": "ipv4:198.51.100.34" }, application/alto-propmap+json, application/alto-error+json
{ "src": "ipv4:194.2.3.67", "dst": "ipv4:202.56.54.230" }, Content-Length: [TBD]
{ "src": "ipv4:203.32.56.102", "dst": "ipv4:202.76.89.103" } Content-Type: application/alto-costmapfilter+json
]
{
"multi-cost-types": [
{
"cost-mode": "array",
"cost-metric": "ane-path"
},
{
"cost-mode": "numerical",
"cost-metric": "routingcost"
}
],
"endpoints": {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [ "ipv4:192.0.2.89",
"ipv4:203.0.113.45",
"ipv6:2001:db8::10" ]
} }
}
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: [TBD] Content-Length: [TBD]
Content-Type: application/alto-endpointcost+json Content-Type: multipart/related; boundary=example-2
{ --example-2
"meta": { Content-Type: application/alto-endpointcost+json
"vtag": [
{ {
"resource-id": "default-endpoint-cost-map", "meta": {
"tag": "73182ffa829dc28c218a1823bb1293dea232885", "multi-cost-types": [
"query-id": "query2" {"cost-mode": "array", "cost-metric": "ane-path"},
} {"cost-mode": "numerical", "cost-metric": "routingcost"}
], ]
"cost-type": {}, "vtag": {
"multi-cost-types": [ "resource-id": "endpoint-multicost-map",
{ "cost-mode": "path-vector", "cost-metric": "ane" }, "tag": "47612897acf278ffa3287cb84dd28841da78213",
{ "cost-mode": "numerical", "cost-metric": "hopcount" } "query-id": "query2"
] }
}, },
"endpoint-cost-map": { "endpoint-cost-map": {
"ipv4:192.0.2.2": { "ipv4:192.0.2.2": {
"ipv4:203.0.113.45": [ [ "ane:L10", "ane:L11", "ipv4:192.0.2.89": [[ "ane:L001", "ane:L003", "ane:L004" ], 77],
"ane:L15", "ane:L16", "ipv4:203.0.113.45": [[ "ane:L001", "ane:L004", "ane:L005" ], 68],
"ane:L17", "ane:L13" ], 100] "ipv6:2001:db8::10": [[ "ane:L001", "ane:L005", "ane:L007" ], 98]
},
"ipv4:192.0.2.89": {
"ipv4:198.51.100.34": [ [ "ane:L14", "ane:L11",
"ane:L12", "ane:L18",
"ane:L19" ], 124]
},
"ipv4:194.2.3.67": {
"ipv4:202.56.54.230": [ [ "ane:L21", "ane:L15",
"ane:L16", "ane:L17",
"ane:L18", "ane:L20"], 78]
},
"ipv4:203.32.56.102": {
"ipv4:202.76.89.103": [ [ "ane:L22", "ane:L16",
"ane:L23"], 168]
}
} }
} }
}
6.6. Network Element Property Map Example # 1 --example-2
Content-Type: application/alto-propmap+json
After the client send the query to the Multi-Cost Filtered Cost Map {
"filtered-multi-cost-map" and get the response with query-id "query1" "property-map": {
(See Section 6.4). The client send request to the "ane-property-map- "ane:L001": { "availbw": 50 },
availbw" with query-id "query1" and get the response. "ane:L003": { "availbw": 48 },
"ane:L004": { "availbw": 55 },
"ane:L005": { "availbw": 60 },
"ane:L007": { "availbw": 35 }
}
}
POST /propmap/lookup/availbw HTTP/1.1 --example-2--
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-propmapparams+json
{ 7.5. Multiple Queries Example
"query-id": "query1",
"entities" : [ "ane:L001",
"ane:L003",
"ane:L004" ],
"properties" : [ "availbw" ]
}
HTTP/1.1 200 OK 7.5.1. Endpoint Cost Service Example
Content-Length: [TBD] POST /endpointcostmap/multicost HTTP/1.1
Content-Type: application/alto-propmap+json Host: alto.example.com
Accept: application/alto-costmap+json, application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-costmapfilter+json
{ {
"property-map": { "multi-cost-types": [
"ane:L001": { "availbw": "50" }, {
"ane:L003": { "availbw": "70" }, "cost-mode": "array",
"ane:L004": { "availbw": "80" } "cost-metric": "ane-path"
},
{
"cost-mode": "numerical",
"cost-metric": "routingcost"
} }
],
"endpoints": {
"srcs": [ "ipv6:2001:db8::10" ],
"dsts": [ "ipv4:192.0.2.3",
"ipv4:203.0.113.56" ]
} }
}
6.7. Network Element Property Map Example # 2 HTTP/1.1 200 OK
Content-Length: [TBD]
Content-Type: application/alto-endpointcost+json
After the client send the query to the Endpoint Cost Service {
"default-endpoint-cost-map" and get the response with query-id "meta": {
"query2" (See Section 6.5). The client send request to the "ane- "vtag": {
property-map-delay" with query-id "query2" and get the response. "resource-id": "endpoint-multicost-map",
"tag": "f7622897bcf278ffu3287c284dd23841da78213",
"query-id": "query3"
},
"multi-cost-types": [
{ "cost-mode": "array", "cost-metric": "ane-path" },
{ "cost-mode": "numerical", "cost-metric": "routingcost"}
]
},
"endpoint-cost-map": {
"ipv6:2001:db8::10": {
"ipv4:192.0.2.3": [ "ane:L001", "ane:L006" ],
"ipv4:203.0.113.56": [ "ane:L001", "ane:L007" ]
}
}
}
POST /propmap/lookup/delay HTTP/1.1 7.5.2. Abstract Network Element Property Map Example
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-propmapparams+json
{ POST /propmap/availbw HTTP/1.1
"query-id": "query2", Host: alto.example.com
"entities" : [ "ane:L11", Accept: application/alto-propmap+json,application/alto-error+json
"ane:L15", Content-Length: [TBD]
"ane:L16", Content-Type: application/alto-propmapparams+json
"ane:L18" ],
"properties" : [ "delay" ]
}
HTTP/1.1 200 OK {
Content-Length: [TBD] "query-id": "query3",
Content-Type: application/alto-propmap+json "entities" : [ "ane:L001",
"ane:L006" ],
"properties" : [ "availbw" ]
}
{ HTTP/1.1 200 OK
"property-map": { Content-Length: [TBD]
"ane:L11": { "delay": "25" }, Content-Type: application/alto-propmap+json
"ane:L15": { "delay": "40" },
"ane:L16": { "delay": "60" }, {
"ane:L18": { "delay": "10" } "property-map": {
} "ane:L001": { "availbw": 25 },
"ane:L006": { "availbw": 40 }
} }
}
7. Compatibility 8. Compatibility
7.1. Compatibility with Legacy ALTO Clients/Servers 8.1. Compatibility with Legacy ALTO Clients/Servers
Legacy ALTO clients SHOULD NOT send queries with path vector Legacy ALTO clients SHOULD NOT send queries with the path-vector
extension and ALTO servers with this extension SHOULD NOT have any extension and ALTO servers with this extension SHOULD NOT have any
compatibility issue. Legacy ALTO servers do not support cost types compatibility issue. Legacy ALTO servers do not support cost types
with the "path-vector" cost mode and MUST NOT announce the extended with cost mode being "array" and cost metric being "ane-path", so
cost types in IRD. Thus, ALTO clients MUST NOT send queries they MUST NOT announce the extended cost types in IRD. Thus, ALTO
specified in this extension to legacy ALTO servers according to clients MUST NOT send queries specified in this extension to legacy
Section 11.3.2.3 [RFC7285]. ALTO servers according to Section 11.3.2.3 [RFC7285].
7.2. Compatibility with Multi-Cost Extensions 8.2. Compatibility with Multi-Cost Extensions
Path Vector is not a testable cost type. So two conditions have to Path Vector is not a testable cost type. Any format of constraints
be satisfied when multi-cost supports path-vector extension. Any SHOULD NOT be applied to cost type path-vector in order for multi-
format of constraints SHOULD NOT be applied to cost type path-vector. cost to support the path-vector extension. Specifically,
o Cost type path-vector MUST NOT be included in "testable-cost- o Cost type path-vector MUST NOT be included in "testable-cost-
types-names" or "testable-cost-types". types-names" or "testable-cost-types".
o When "testable-cost-types-names" is omitted in the "capabilities" o When "testable-cost-types-names" is omitted in the "capabilities"
and "testable-cost-types" is omitted in the input parameters, and "testable-cost-types" is omitted in the input parameters,
"constraints" or "or-constraints" SHOULD NOT add any format of "constraints" or "or-constraints" SHOULD NOT add any format of
constraints on cost type path-vector. constraints on cost type path-vector.
7.3. Compatibility with Incremental Update 8.3. Compatibility with Incremental Update
There is no compatibility issue with incremental update extension.
8. Time to live
The Network Element Property Map is dynamically enriched when the Without considering the incremental update of multipart/related
(Filtered) Cost Map/Endpoint Cost Service is queried of the path- information, there is no compatibility issue with incremental update
vector information. The properties of the abstract network elements extension. Compatibility issue with the incremental update of
can consume a large amount of resources when cached. So, a time-to- multipart/related information will be discussed and addressed in the
live is needed to remove outdated entries in the Network Element next version.
Property Map.
9. Design Decisions and Discussions 9. Design Decisions and Discussions
9.1. Path Vector or Path Graph 9.1. Provide More General Calendar Extension
When we introduce the "path-vector" as a cost mode in the Cost Map,
an unavoidable problem is how to handle multipath. Because a PID is
a group of endpoints, it is common that there are multiple paths
between two PIDs. The valid routing state information is all of the
accessible paths. So in this scenario, the Cost Map Resource SHOULD
provide the cost values including of the multiple paths.
A natural solution is to provide an array of path vectors as the cost
value. Every path vector in this array means an accessible path
between the source PID and the destination PID. It is different from
the solution of the path vector extension which provides an array of
network elements. So it requires to introduce a different cost mode.
This document proposes this new cost mode named "path-graph".
However, the "path-graph" will increase the complexity of the Cost
Map Response. Since the applications select ALTO as the protocol to
get the network information rather than other topology-based solution
such as I2RS, the major reason should be the simplicity. If we
provide "path-graph" for each PID pairs, the ALTO client has to
handle the complex data structure.
What's more, the "path-vector" is powerful enough to express multiple
paths. The simple solution is to list the network elements of all
accessible paths in a single path vector. This solution will lose
the information about paths. Another solution is to define the path
as a new type of network elements. In this way, the path vector can
provide an array of paths. Each element of this array contains a
path vector of network elements in the Network Element Property Map.
So in this document, we just introduce "path-vector" as the only
required cost mode for routing state information.
9.2. Provide More General Calendar Extension
Cost Calendar is proposed as a useful ALTO extension to provide the Cost Calendar is proposed as a useful ALTO extension to provide the
historical cost values for Filtered Cost Map Service and Endpoint historical cost values for Filtered Cost Map Service and Endpoint
Cost Service. Since path vector is an extension to these services, Cost Service. Since path vector is an extension to these services,
it SHOULD be compatible with Cost Calendar extension. it SHOULD be compatible with Cost Calendar extension.
However, the calendar of a path-vector (Endpoint) Cost Map is However, the calendar of a path-vector (Endpoint) Cost Map is
insufficient for the application which requires the historical data insufficient for the application which requires the historical data
of routing state information. The (Endpoint) Cost Map can only of routing state information. The (Endpoint) Cost Map can only
provide the changes of the paths. But more useful information is the provide the changes of the paths. But more useful information is the
skipping to change at page 27, line 36 skipping to change at page 24, line 46
resources which require the calendar supported. Because other resources which require the calendar supported. Because other
resources don't have to be updated frequently. But Network Element resources don't have to be updated frequently. But Network Element
Property Map as a use case of Unified Property Map will collect the Property Map as a use case of Unified Property Map will collect the
real-time information of the network. It SHOULD be updated as soon real-time information of the network. It SHOULD be updated as soon
as possible once the metrics of network elements change. as possible once the metrics of network elements change.
So the requirement is to provide a general calendar extension which So the requirement is to provide a general calendar extension which
not only meets the Filtered Cost Map and Endpoint Cost Service but not only meets the Filtered Cost Map and Endpoint Cost Service but
also applies to the Property Map Service. also applies to the Property Map Service.
9.3. Snapshot and real-time update
As the suggested workflow mentioned in Section 6.1, the properties of
the abstract network elements are computed ahead of the query of
these properties. So the properties of abstract network elements are
likely to be snapshot rather than realt-time value when queried.
10. Security Considerations 10. Security Considerations
10.1. Privacy Concerns
We can identify multiple potential security issues. A main security We can identify multiple potential security issues. A main security
issue is network privacy, as the path-vector information may reveal issue is network privacy, as the path-vector information may reveal
more network internal structures than the more abstract single-node more network internal structures than the more abstract single-node
abstraction. The network should consider protection mechanisms to abstraction. The network should consider protection mechanisms to
reduce information exposure, in particular, in settings where the reduce information exposure, in particular, in settings where the
network and the application do not belong to the same trust domain. network and the application do not belong to the same trust domain.
On the other hand, in a setting of the same trust domain, a key On the other hand, in a setting of the same trust domain, a key
benefit of the path-vector abstraction is reduced information benefit of the path-vector abstraction is reduced information
transfer from the network to the application. transfer from the network to the application.
skipping to change at page 28, line 20 skipping to change at page 25, line 24
the potential replication sites are). The application should the potential replication sites are). The application should
evaluate the potential privacy concerns. evaluate the potential privacy concerns.
Beyond the privacy issues, the computation of the path-vector is Beyond the privacy issues, the computation of the path-vector is
unlikely to be cachable, in that the results will depend on the unlikely to be cachable, in that the results will depend on the
particular requests (e.g., where the flows are distributed). Hence, particular requests (e.g., where the flows are distributed). Hence,
this service may become an entry point for denial of service attacks this service may become an entry point for denial of service attacks
on the availability of an ALTO server. Hence, authenticity and on the availability of an ALTO server. Hence, authenticity and
authorization of this ALTO service may need to be better protected. authorization of this ALTO service may need to be better protected.
10.2. Resource Consumption on ALTO Servers
The Abstract Network Element Property Map is dynamically enriched
when the (Filtered) Cost Map/Endpoint Cost Service is queried of the
path-vector information. The properties of the abstract network
elements can consume a large amount of resources when cached. So, a
time-to-live is needed to remove outdated entries in the Network
Element Property Map.
11. IANA Considerations 11. IANA Considerations
11.1. ALTO Cost Mode Registry 11.1. ALTO Cost Mode Registry
This document specifies a new cost mode "path-vector". However, the This document specifies a new cost mode "array". However, the base
base ALTO protocol does not have a Cost Mode Registry where new cost ALTO protocol does not have a Cost Mode Registry where new cost mode
mode can be registered. This new cost mode will be registered once can be registered. This new cost mode will be registered once the
the registry is defined either in a revised version of [RFC7285] or registry is defined either in a revised version of [RFC7285] or in
in another future extension. another future extension.
11.2. ALTO Cost Metric Registry 11.2. ALTO Cost Metric Registry
A new cost metric needs to be registered in the "ALTO Cost Metric A new cost metric needs to be registered in the "ALTO Cost Metric
Registry", listed in Table 1. Registry", listed in Table 2.
+-------------+---------------------+ +-------------+---------------------+
| Identifier | Intended Semantics | | Identifier | Intended Semantics |
+-------------+---------------------+ +-------------+---------------------+
| ane | See Section 5.1.1 | | ane-path | See Section 5.1.1 |
+-------------+---------------------+ +-------------+---------------------+
Table 1: ALTO Cost Metrics Table 2: ALTO Cost Metrics
11.3. ALTO Entity Domain Registry 11.3. ALTO Entity Domain Registry
As proposed in Section 9.2 of [I-D.roome-alto-unified-props], "ALTO As proposed in Section 9.2 of [I-D.roome-alto-unified-props], "ALTO
Entity Domain Registry" is requested. Besides, a new domain is to be Entity Domain Registry" is requested. Besides, a new domain is to be
registered, listed in Table 2. registered, listed in Table 3.
+-------------+--------------------------+--------------------------+ +-------------+--------------------------+--------------------------+
| Identifier | Entity Address Encoding | Hierarchy & Inheritance | | Identifier | Entity Address Encoding | Hierarchy & Inheritance |
+-------------+--------------------------+--------------------------+ +-------------+--------------------------+--------------------------+
| ane | See Section 5.4.2 | None | | ane | See Section 5.2.2 | None |
+-------------+--------------------------+--------------------------+ +-------------+--------------------------+--------------------------+
Table 2: ALTO Entity Domain Table 3: ALTO Entity Domain
11.4. ALTO Network Element Property Type Registry 11.4. ALTO Network Element Property Type Registry
The "ALTO Network Element Property Type Registry" is required by the The "ALTO Abstract Network Element Property Type Registry" is
ALTO Entity Domain "ane", listed in Table 3. required by the ALTO Entity Domain "ane", listed in Table 4.
+-------------+--------------------------+ +-------------+--------------------------+
| Identifier | Intended Semantics | | Identifier | Intended Semantics |
+-------------+--------------------------+ +-------------+--------------------------+
| availbw | The available bandwidth | | availbw | The available bandwidth |
| delay | The transmission delay | | delay | The transmission delay |
+-------------+--------------------------+ +-------------+--------------------------+
Table 3: ALTO Network Element Property Types Table 4: ALTO Abstract Network Element Property Types
12. Acknowledgments 12. Acknowledgments
The authors would like to thank discussions with Andreas Voellmy, The authors would like to thank discussions with Andreas Voellmy,
Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan
Liu, Xiao Shi, Xin Wang, and Yan Luo. Liu, Xiao Shi, Xin Wang, and Yan Luo.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
13.2. Informative References 13.2. Informative References
[I-D.amante-i2rs-topology-use-cases] [I-D.amante-i2rs-topology-use-cases]
skipping to change at page 30, line 43 skipping to change at page 28, line 17
Extensions to Support Application and Network Resource Extensions to Support Application and Network Resource
Information Exchange for High Bandwidth Applications", Information Exchange for High Bandwidth Applications",
draft-lee-alto-app-net-info-exchange-02 (work in draft-lee-alto-app-net-info-exchange-02 (work in
progress), July 2013. progress), July 2013.
[I-D.roome-alto-unified-props] [I-D.roome-alto-unified-props]
Roome, W., "Extensible Property Maps for the ALTO Roome, W., "Extensible Property Maps for the ALTO
Protocol", draft-roome-alto-unified-props-01 (work in Protocol", draft-roome-alto-unified-props-01 (work in
progress), July 2016. progress), July 2016.
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, DOI 10.17487/RFC2387, August 1998,
<http://www.rfc-editor.org/info/rfc2387>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<http://www.rfc-editor.org/info/rfc7285>. <http://www.rfc-editor.org/info/rfc7285>.
Authors' Addresses Authors' Addresses
Greg Bernstein Greg Bernstein
Grotto Networking Grotto Networking
 End of changes. 200 change blocks. 
862 lines changed or deleted 734 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/