draft-ietf-alto-path-vector-02.txt   draft-ietf-alto-path-vector-03.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: June 21, 2018 Tongji University Expires: September 6, 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
December 18, 2017 March 5, 2018
ALTO Extension: Path Vector Cost Type ALTO Extension: Path Vector Cost Type
draft-ietf-alto-path-vector-02.txt draft-ietf-alto-path-vector-03.txt
Abstract Abstract
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]
has defined several resources and services to provide clients with has defined several resources and services to provide clients with
basic network information. However, the base ALTO protocol and basic network information. However, the base ALTO protocol and
latest extensions only provide end-to-end metrics, which are latest extensions only provide end-to-end metrics, which are
insufficient to satisfy the demands of solving more complex network insufficient to satisfy the demands of solving more complex network
optimization problems. This document introduces an extension to the optimization problems. This document introduces an extension to the
base ALTO protocol, namely the path-vector extension, which allows base ALTO protocol, namely the path-vector extension, which allows
skipping to change at page 2, line 15 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 June 21, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 Path Vector Extensions . . . . . . . . . . . . . 7 4. Overview of Path Vector Extensions . . . . . . . . . . . . . 7
4.1. Path Vector Cost Type Extensions . . . . . . . . . . . . 7 4.1. New Cost Type to Encode Path Vectors . . . . . . . . . . 7
4.1.1. New Cost Metric for Path Vector . . . . . . . . . . . 7 4.2. New Entity Domain to Provide ANE Properties . . . . . . . 8
4.1.2. New Cost Mode for Path Vector . . . . . . . . . . . . 8 4.3. New Service to Enable Multipart Resources . . . . . . . . 8
4.1.3. Path Vector Cost Type Semantics . . . . . . . . . . . 8 5. Path Vector Extension: Basic Data Types . . . . . . . . . . . 9
4.2. ANE Property Map . . . . . . . . . . . . . . . . . . . . 8 5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. media type for path vector: multipart/related . . . . . . 9 5.1.1. Cost Mode: array . . . . . . . . . . . . . . . . . . 9
4.4. Applicable ALTO services for Path Vector costs . . . . . 9 5.1.2. Cost Metric: ane-path . . . . . . . . . . . . . . . . 9
4.5. Impact of backwards compatibility on the PV design . . . 10 5.1.3. Path Vector Cost Type Semantics . . . . . . . . . . . 9
4.6. Requirements for PV on Clients and Servers . . . . . . . 10 5.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 10
5. Path-Vector Extension: Basic Data Types . . . . . . . . . . . 10 5.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10
5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10
5.1.1. Cost Mode: array . . . . . . . . . . . . . . . . . . 11 5.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 11
5.1.2. Cost Metric: ane-path . . . . . . . . . . . . . . . . 11
5.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Abstract Network Element Name . . . . . . . . . . . . . . 11 5.3. Abstract Network Element Name . . . . . . . . . . . . . . 11
6. Path Vector Extension: Services . . . . . . . . . . . . . . . 11
6. Path-Vector Extension: Services . . . . . . . . . . . . . . . 11
6.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 6.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11
6.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11
6.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 6.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12
6.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12 6.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 13 6.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 12
6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 12
6.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 13 6.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 12
6.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 13 6.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Multipart Cost Property Service . . . . . . . . . . . . . 13 6.3. Multipart Cost Property Service . . . . . . . . . . . . . 13
6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13
6.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 14 6.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13
6.3.3. Accept Input Parameters . . . . . . . . . . . . . . . 14 6.3.3. Accept Input Parameters . . . . . . . . . . . . . . . 13
6.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14 6.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14
6.3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3.6. Response . . . . . . . . . . . . . . . . . . . . . . 15 6.3.6. Response . . . . . . . . . . . . . . . . . . . . . . 14
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Information Resource Directory Example . . . . . . . . . 16 7.2. Information Resource Directory Example . . . . . . . . . 15
7.3. Example # 1 . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Example # 1 . . . . . . . . . . . . . . . . . . . . . . . 17
7.4. Example # 2 . . . . . . . . . . . . . . . . . . . . . . . 18 7.4. Example # 2 . . . . . . . . . . . . . . . . . . . . . . . 18
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 20 8.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 19
8.2. Compatibility with Multi-Cost Extensions . . . . . . . . 20 8.2. Compatibility with Multi-Cost Extensions . . . . . . . . 20
8.3. Compatibility with Incremental Update . . . . . . . . . . 20 8.3. Compatibility with Incremental Update . . . . . . . . . . 20
9. Design Decisions and Discussions . . . . . . . . . . . . . . 21 9. Design Decisions and Discussions . . . . . . . . . . . . . . 20
9.1. Provide More General Calendar Extension . . . . . . . . . 21 9.1. Provide More General Calendar Extension . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 21 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 21
10.2. Resource Consumption on ALTO Servers . . . . . . . . . . 22 10.2. Resource Consumption on ALTO Servers . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 22 11.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 21
11.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 22 11.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 22
11.3. ALTO Network Element Property Type Registry . . . . . . 22 11.3. ALTO Entity Domain Registry . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11.4. ALTO Network Element Property Type Registry . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The base ALTO protocol [RFC7285] is designed for exposing network The base ALTO protocol [RFC7285] is designed to expose network
information through services such as the Network Map service and the information through services such as Cost Map and Endpoint Cost
Cost Map service. These services use an extreme "single-node" service. These services use an extreme "single-node" network view
network view abstraction, which represents the whole network with a abstraction, which represents the whole network with a single node
single node and hosts with "endpoint groups" directly connected to and hosts with "endpoint groups" directly connected to the node.
the node.
Although the "single-node" network view abstraction works well in Although the "single-node" network view abstraction works well in
many settings, it lacks the ability to support new emerging use many settings, it lacks the ability to support emerging use cases,
cases, such as inter-datacenter flow scheduling, scientific high- such as inter-datacenter data transfers
performance computing data transfers and end-to-end paths crossing [I-D.lee-alto-app-net-info-exchange]. For these use cases,
heterogeneous technologies. For these use cases, more powerful applications require a more powerful network view abstraction beyond
network view abstraction is required. To provide a better network the "single-node" abstraction to support application capabilities, in
view abstraction, ALTO services need to support the following particular, the ability of multi-flow scheduling.
additional functionalities:
o Providing path vector rather than a simple path cost of endpoint To support capabilities like multi-flow scheduling,
to endpoint. The path vector exposes the network elements (e.g., [I-D.yang-alto-topology] provides many candidate network view
links, switches, middle boxes and their aggregations) that abstractions. This document uses one of those abstractions called
endpoint to endpoint traffic goes through. "path vector" abstraction. The path vector abstraction use path
vectors with abstract network elements to provide network graph view
for applications. Here, abstract network elements can be links,
switches, middleboxes and their aggregations. And a path vector
presents a sequence of abstract network elements that end-to-end
traffic goes through. Each abstract network element can own several
properties like "bandwidth" and "delay". These information may help
the application avoid network congestion, achieving better
application performance.
o Providing information of the network elements in the path vector. Providing path vector abstraction using ALTO introduces the following
The information can be "bandwidth" for links, "delay" between requirements:
neighboring switches and other properties of network elements.
These information may help the application avoid network
congestion, achieving better application performance.
To support these new functionalities, this document proposes the o Encoding path vectors rather than scalar cost values in cost maps:
path-vector extension, which introduces a qualitative cost type Cost maps allow only scalar (numerical or ordinal) cost values,
listing selected groups of one or more abstracted network elements in they cannot carry an array of abstract network elements as a cost.
an e2e path and optionally conveys some of their properties. A new cost type is required to encode path vectors as costs in
cost maps.
o Encoding the properties of abstract network elements: Unified
property map can provide properties of endpoints and pids, but it
cannot convey the properties of abstract network elements. A new
entity domain needs to be registered so that unified property map
can encode the properties of abstract network elements.
o Encapsulating multiple map messages in a single session: Making
multiple queries to get path vectors and the properties of
abstract network elements introduce additional communication
overhead. A mechanism to provide multiple map messages in a
single session is necessary.
This document proposes the path vector extension which satisfies
these additional requirements to the ALTO protocol. Specifically, it
encodes selected abstract network elements in an end-to-end path with
a new cost type called "path-vector", and conveys the properties of
abstract network elements using unified property map.
The rest of this document is organized as follows. Section 3 gives The rest of this document is organized as follows. Section 3 gives
an example of flow scheduling and illustrates the limitations of the an example of multi-flow scheduling and illustrates the limitations
base ALTO protocol in such a use case. Section 4 gives an overview of the base ALTO protocol in such a use case. Section 4 gives an
of the path-vector extension, before specifying the details of the overview of the path vector extension. Section 5 and Section 6
extension in Section 5 and Section 6. Section 7 presents several define the formal extension. Section 7 presents several examples.
examples, and Section 9 explains some design decisions. Section 8 Section 8 and Section 9 discusses compatibility issues with other
discusses compatibility issues with some other ALTO extensions. existing ALTO extensions and design decisions. Section 10 and
Section 10 and Section 11 discusses about security and IANA Section 11 review the security and IANA considerations.
considerations.
2. Terminology 2. Terminology
This document uses the same terms as defined in [RFC7285], [RFC8189] Besides the terms defined in [RFC7285], [RFC8189] and
and [I-D.ietf-alto-unified-props-new] with the following additional [I-D.ietf-alto-unified-props-new], this document also uses the
terms: Abstract Network Element, Abstract Network Element Name, following additional terms: Abstract Network Element, Abstract
Abstract Network Element Property, Abstract Network Element Property Network Element Name, Abstract Network Element Property, Abstract
Map and Path Vector. Network Element Property Map, Path Vector and Path-Vector.
o Abstract Network Element (ANE): An abstract network element is an o Abstract Network Element (ANE): An abstract network element is an
abstraction of network components, it can be an aggregation of abstraction of network components, it can be an aggregation of
links, middle boxes, Virtualized Network Function (VNF), or even a links, middle boxes, virtualized network function (VNF), or even a
sub-network. An abstract network element has two attributes: sub-network. An abstract network element has two attributes: a
name and a set of properties.
abstract network element name and abstract network element
property, which are defined below.
o Abstract Network Element Name (ANEN): An abstract network element o Abstract Network Element Name (ANE Name): An abstract network
name is an identifier which uniquely identifies an abstract element name is an identifier that uniquely identifies an abstract
network element, as defined in Section 5.3. network element, as defined in Section 5.3.
o Abstract Network Element Property (ANEP): An abstract network o Abstract Network Element Property (ANE Property): An abstract
element property is a specific metric associated with a given network element property is a network-related property of an
abstract network element, as introduced in Section 4.2. An abstract network element. It can be "bandwidth" for links and
abstract network element can have several network element "delay" between two switches.
properties.
o Abstract Network Element Property Map (ANE Property Map): An o Abstract Network Element Property Map (ANE Property Map): An
abstract network element property map is a Filtered Property Map abstract network element property map is a Filtered Property Map
defined in [I-D.ietf-alto-unified-props-new] which supports the defined in [I-D.ietf-alto-unified-props-new] which supports the
"ane" domain in its "domain-types" capability. "ane" domain in its "domain-types" capability.
o Path Vector (PV): A path vector is an array of ALTO Abstract o Path Vector: A path vector is an array of ALTO Abstract Network
Network Elements (ANEs), which presents an abstract network path Elements (ANEs). It presents an abstract network path between
between entities such as PIDs or endpoints. An ANE represents a entities such as PIDs or endpoints. An ANE represents a selected
selected part of an end-to-end path that the ALTO Server considers part of an end-to-end path that the ALTO Server considers worth
worth exposing. An ANE is a set of one or more network elements exposing.
such as links, switches, middle boxes and their aggregations, it
is expected to have properties that may influence the applications
e.g. when they select an endpoint or want to estimate their
performance.
3. Use Case: Capacity Region for Multi-Flow Scheduling 3. Use Case: Capacity Region for Multi-Flow Scheduling
Once routing has been configured in the network, application-layer Assume that an application has control over a set of flows, some
traffic optimization may want to schedule traffic among application- flows may go through shared links or switches and share a bottleneck.
layer paths. Specifically, assume that an application has control Existing cost maps can not reveal such information.
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, ..., 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 links,
feasible values of x where link capacities are not exceeded 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. Endhosts 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 link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps, the bandwidth of link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps,
and the bandwidth of the rest links are 100 Mbps. and the bandwidth of the rest links are 100 Mbps.
+------+ +------+
| | | |
--+ sw6 +-- --+ sw6 +--
/ | | \ / | | \
PID1 +-----+ / +------+ \ +-----+ PID2 PID1 +-----+ / +------+ \ +-----+ PID2
eh1__| |_ / \ ____| |__eh2 eh1__| |_ / \ ____| |__eh2
skipping to change at page 7, line 27 skipping to change at page 7, line 35
applications. applications.
The path-vector extension defined in this document meets all the The path-vector extension defined in this document meets all the
requirements. 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 Path Vector Extensions 4. Overview of Path Vector Extensions
This section presents the approaches taken to support the path-vector This section presents an overview of approaches adopted by the path
extension. It assumes the readers are familiar with (Filtered) Cost vector extension. It assumes the readers are familiar with
Map and Endpoint Cost Service defined in [RFC7285] and their (Filtered) Cost Map and Endpoint Cost Service defined in [RFC7285]
extensions defined in [RFC8189]. It also uses features such as and their extensions defined in [RFC8189]. The path vector extension
Filtered Property Map defined in [I-D.ietf-alto-unified-props-new]. also requires the support of Filtered Property Map defined in
[I-D.ietf-alto-unified-props-new].
4.1. Path Vector Cost Type Extensions
None of current cost types defined in [RFC7285] can be used to convey
path vector information. So, a new cost type with a new cost metric
"ane-path" and a new cost mode "array" is defined in this document.
Below are brief descriptions. Detailed information and
specifications are given in Section 5.1.1 and Section 5.1.2.
4.1.1. New Cost Metric for Path Vector
To represent an abstract network path, this document introduces a new
cost metric named "ane-path". A cost value in this metric is a list
containing the names of the ALTO ANEs that the ALTO Server has
specified as describing the network path elements. The ANE names
array is organized as a sequence beginning at the source of the path
and ending at its destination.
4.1.2. New Cost Mode for Path Vector
A cost mode as defined in Section 6.1.2 of [RFC7285], a cost mode is
either "numerical" or "ordinal" and none of these can be used to
present a list of ANE names. Therefore, this document specifies a
new cost mode named "array" for the cost metric "ane-path". The new
cost mode "array" means each cost value in the cost maps is a list.
4.1.3. Path Vector Cost Type Semantics
The new cost type follows the convention of the cost types in the The path vector extension is composed of three building blocks: (1) a
legacy ALTO protocol. Table 1 lists some of the current defined cost new cost type to encode path vectors; (2) a new entity domain for
types and their semantics. unified property extension [I-D.ietf-alto-unified-props-new] to
encode properties of abstract network elements; and (3) a new service
to provide path vector messages in a single session;
+------------+--------------+---------------------------------------+ 4.1. New Cost Type to Encode Path Vectors
| Cost Mode | Cost Metric | Semantics |
+------------+--------------+---------------------------------------+
| numerical | routingcost | a number representing the routing |
| | | cost |
| numerical | hopcount | a number representing the hop count |
| ordinal | routingcost | a ranking representing the routing |
| | | cost |
| ordinal | hopcount | a ranking representing the hop count |
| array | ane-path | a list representing the ane path |
+------------+--------------+---------------------------------------+
Table 1: Cost Types and Their Semantics Existing cost types defined in [RFC7285] only allow scalar cost
values, they cannot be used to convey vector format information.
This document defines a new cost mode to enable the cost value to
carry an array of elements, and a new cost metric to pass ANE names
as elements in the array. Detailed information and specifications
are given in Section 5.1.1 and Section 5.1.2.
The "routingcost" and "hopcount" can encoded in "numerical" or 4.2. New Entity Domain to Provide ANE Properties
"ordinal", however, the cost metric "ane-path" can only be applied to
the cost mode "array" defined in this document to convey path vector
information. The cost metric "ane-path" can not be used in
"numerical" or "ordinal" unless it is defined in future extensions.
If the ALTO server declares that it support cost type with cost
metric being "ane-path" and cost mode not being "array", the ALTO
client SHOULD ignore them.
4.2. ANE Property Map Given the new cost type introduced by Section 4.1, Cost Map and
Endpoint Cost Service can provide the ANE names along a flow path.
However, only providing the ANE names without properties is not
enough. To detect shared bottlenecks, ALTO clients may expect
information on specific ANE properties such as link capacity or
delay.
Given that Cost Map and Endpoint Cost service now provide the This document adopts the property map defined in
abstract network element names along a flow path, ALTO clients can [I-D.ietf-alto-unified-props-new] to encode the properties of
learn that there exist bottlenecks shared by different flows. abstract network elements. A new domain "ane" is registered in the
However, only providing the abstract network element names without property map. Each entity in the "ane" domain has an identifier of
abstract network element properties is not enough, some ALTO clients an ANE. An ANE identifier is the ANE name used in the values of the
may want to have information on specific ANE properties such as link "ane-path" metric defined in the present draft. ANE properties are
capacity or delay. This document adopts the property map resources provided in information resources called "Property Map Resource" and
defined in [I-D.ietf-alto-unified-props-new] to encode the properties "Filtered Property Map Resource". The "Filtered Property Map"
of ANEs. Draft [I-D.ietf-alto-unified-props-new] defines a new resource which supports the "ane" domain is used to encode the
entity domain called "ane" and each entity in the "ane" domain has an properties of ane entities, and it is called an ANE Property Map in
identifier of an ANE. An ANE identifier is the ANE name used in the this document.
values of the "ane-path" metric defined in the present draft. ANE
properties are provided in information resources called "Property Map
Resource" and "Filtered Property Map Resource". The "Filtered
Property Map" resource which support the "ane" domain is used to
encode the properties of ane entities, and it is called an ANE
Property Map in this document.
4.3. media type for path vector: multipart/related 4.3. New Service to Enable Multipart Resources
In the legacy ALTO protocol, ALTO servers use media types in the HTTP In the base ALTO protocol, ALTO servers use media types in the HTTP
header to indicate the type of the response. Typically one response header to indicate the type of the response. Typically one response
only contains a single media type, such as "application/alto- only contains a single media type, such as "application/alto-
costmap+json" or "application/alto-propmap+json". This has limited costmap+json" or "application/alto-propmap+json". This has limited
the capability of ALTO servers to return multiple services in a the capability of ALTO servers to return multiple map messages in a
single response. single response.
Thus, an ALTO client needs to make separate queries to get the Thus, an ALTO client needs to make separate queries to get the
information of related services. This may cause a data information of related services. This may cause a data
synchronization problem between dependent ALTO services because when synchronization problem between dependent ALTO services because when
making the second query, the result for the first query may have making the second query, the result for the first query may have
already changed. The very same problem can happen to Network Map and already changed. The same problem can happen to Network Map and Cost
Cost Map resources. However, unlike Network Map and Cost Map which Map resources. However, unlike Network Map and Cost Map which are
are considered more stable, Path Vectors and the dependent ANE considered more stable, Path Vectors and the dependent ANE Property
Property Maps might change more frequently. Maps might change more frequently.
Instead of introducing a new media type to encapsulate multiple types Instead of introducing a new media type to encapsulate multiple types
in a single response, this document adopts the "multipart/related" in a single response, this document adopts the "multipart/related"
media type defined in [RFC2387]. In this way, a response can contain media type defined in [RFC2387]. In this way, a response can contain
both the Path Vectors in a Filtered Cost Map (or Endpoint Cost Map) both the path vectors in a filtered cost map (or endpoint cost map)
and the associated ANE Property Map. The media types of the cost map and the associated ANE Property Map. The media types of the cost map
and the property map can still be retrieved from the response. The and the property map can still be retrieved from the response. The
interpretation of each media type in the "multipart/related" response interpretation of each media type in the "multipart/related" response
is consistent with the base ALTO protocol. is consistent with the base ALTO protocol.
4.4. Applicable ALTO services for Path Vector costs 5. Path Vector Extension: Basic Data Types
This document defines Filtered Cost Map and Endpoint Cost Map are
applicable for path vector costs. Although the new cost type for
path vector can also be used in the GET-mode Cost Map service from
[RFC7285], the behaviours of the ALTO server and client for such a
GET-mode service is not defined. So it is not recommended to apply
path vector costs to the GET-mode Cost Map service.
4.5. Impact of backwards compatibility on the PV design
The path vector extension on Filtered Cost Map and Endpoint Cost
Service is backward compatible with the base ALTO protocol. If the
ALTO server provides path vector extended Filtered Cost Map or
Endpoint Cost Service, but the client is a base ALTO client, then the
client will ignore the path vector cost type without conducting any
incompatibility. If the client sents a request with path vector cost
type, but the server is a base ALTO server, the server will return an
"E_INVALID_FIELD_VALUE" error.
4.6. Requirements for PV on Clients and Servers
A path vector extended ALTO server MUST implement the legacy ALTO
protocol specified in [RFC7285] with the following additional
requirements:
o If an ALTO server supports path vector extension, it MUST support
the Unified Property Map defined in
[I-D.ietf-alto-unified-props-new].
o If an ALTO server supports path vector extended Filtered Cost Map
or Endpoint Cost Service, the server MUST provide the associated
Property Map simultaneously.
o If an ALTO server provides "multipart/related" media type for path
vector, the server MUST provide the associated Filtered Cost Map
or Endpoint Cost Service and the Property Map simultaneously.
An ALTO client supported path vector extension MUST be able to
interpret Unified Property Map correctly. If the ALTO client wants
to interpret "multipart/related" path vector response, the client
MUST implement the path vector extension on Filtered Cost Map or
Endpoint Cost Service at first.
5. Path-Vector Extension: Basic Data Types
This section formally specifies a new cost type. This section formally specifies a new cost type and a new entity
domain.
5.1. Cost Type 5.1. Cost Type
This document extends the cost types defined in Section 6.1 of This document extends the cost types defined in Section 6.1 of
[RFC7285] by introducing a new cost mode "array" and a new cost [RFC7285] by introducing a new cost mode "array" and a new cost
metric "ane-path". metric "ane-path". In the rest content, this document use "path-
vector" to indicate the combination cost type of the cost mode
"array" and the cost metric "ane-path".
5.1.1. Cost Mode: array 5.1.1. Cost Mode: array
This document extends the CostMode defined in Section 10.5 of This document extends the CostMode defined in Section 10.5 of
[RFC7285] with a new cost mode: "array". This cost mode indicates [RFC7285] with a new cost mode: "array". This cost mode indicates
that every cost value in a cost map represents an array rather than a that every cost value in a cost map represents an array rather than a
simple value. The values are arrays of JSONValue. The specific type simple value. The values are arrays of JSONValue. The specific type
of each element in the array depends on the cost metric. of each element in the array depends on the cost metric.
5.1.2. Cost Metric: ane-path 5.1.2. Cost Metric: ane-path
This document specifies a new cost metric: "ane-path". This cost This document specifies a new cost metric: "ane-path". This cost
metric indicates that the cost value is a list of abstract network metric indicates that the cost value is a list of abstract network
elements which the path from a source to a destination goes across. elements which the path from a source to a destination goes across.
The values are arrays of ANE Names which are defined in Section 5.3. The values are arrays of ANE names which are defined in Section 5.3.
The cost metric "ane-path" SHOULD NOT be used when the cost mode is The cost metric "ane-path" SHOULD NOT be used when the cost mode is
not "array" unless it is explicitly specified by a future extension. not "array" unless it is explicitly specified by a future extension.
If an ALTO client send queries with the cost metric "ane-path" and a If an ALTO client send queries with the cost metric "ane-path" and a
non "array" cost mode, the ALTO server SHOULD return an error with non "array" cost mode, the ALTO server SHOULD return an error with
the error code "E_INVALID_FIELD_VALUE"; If an ALTO server declares the error code "E_INVALID_FIELD_VALUE"; If an ALTO server declares
the support of a cost type with the cost metric "ane-path" and a non the support of a cost type with the cost metric "ane-path" and a non
"array" cost mode, the ALTO client SHOULD assume such a cost type is "array" cost mode, the ALTO client SHOULD assume such a cost type is
invalid and ignore it. invalid and ignore it.
5.1.3. Path Vector Cost Type Semantics
The new cost type follows the convention of the cost types in the
base ALTO protocol. Table 1 lists some of the current defined cost
types and their semantics.
+------------+--------------+---------------------------------------+
| Cost Mode | Cost Metric | Semantics |
+------------+--------------+---------------------------------------+
| numerical | routingcost | a number representing the routing |
| | | cost |
| numerical | hopcount | a number representing the hop count |
| ordinal | routingcost | a ranking representing the routing |
| | | cost |
| ordinal | hopcount | a ranking representing the hop count |
| array | ane-path | a list representing the ane path |
+------------+--------------+---------------------------------------+
Table 1: Cost Types and Their Semantics
The "routingcost" and "hopcount" can encoded in "numerical" or
"ordinal", however, the cost metric "ane-path" can only be applied to
the cost mode "array" defined in this document to convey path vector
information. The cost metric "ane-path" can not be used in
"numerical" or "ordinal" unless it is defined in future extensions.
If the ALTO server declares that it support cost type with cost
metric being "ane-path" and cost mode not being "array", the ALTO
client SHOULD ignore them.
5.2. ANE Domain 5.2. ANE Domain
This document uses the same definition of entity domain name 'ane' as This document specifies a new entity domain in addition to the ones
defined in Section 3.4 of [I-D.ietf-alto-unified-props-new]. in [I-D.ietf-alto-unified-props-new].
5.2.1. Domain Name
ane
5.2.2. Domain-Specific Entity Addresses
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
characters other than US-ASCII alphanumeric characters
(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+0040), the low line ("_", U+005F), or the "." separator (U+002E).
The "." separator is reserved for future use and MUST NOT be used
unless specifically indicated in this document, or an extension
document.
5.2.3. Hierarchy and Inheritance
There is no hierarchy or inheritance for properties associated with
ANEs.
5.3. Abstract Network Element Name 5.3. Abstract Network Element Name
An Abstract Network Element Name is encoded as an EntityAddr of the An Abstract Network Element Name is encoded as an EntityAddr of the
"ane" domain as defined in Section 3.4.2 of "ane" domain as defined in Section 3.4.2 of
[I-D.ietf-alto-unified-props-new]. [I-D.ietf-alto-unified-props-new].
6. Path-Vector Extension: Services 6. Path Vector Extension: Services
This section extends Filtered Cost Map Service and Endpoint Cost This section extends Filtered Cost Map Service and Endpoint Cost
Service. Service. It also introduce a new service called "Multipart Cost
Property Service".
6.1. Filtered Cost Map Extensions 6.1. 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
[RFC8189]. [RFC8189].
The specifications for the "media type", "HTTP method" and "uses" are The specifications for the "media type", "HTTP method" and "uses" are
the same as defined in Section 4.1 of [RFC8189]. the same as defined in Section 4.1 of [RFC8189].
6.1.1. Capabilities 6.1.1. Capabilities
skipping to change at page 12, line 21 skipping to change at page 11, line 46
[ResourceID property-map;] [ResourceID property-map;]
} PathVectorFilteredCostMapCapabilities : FilteredCostMapCapabilities } PathVectorFilteredCostMapCapabilities : FilteredCostMapCapabilities
property-map: A resource ID defined in the same IRD pointing to an property-map: A resource ID defined in the same IRD pointing to an
ANE Property Map as defined in Section 2. This field MUST be ANE Property Map as defined in Section 2. This field MUST be
present if the path vector cost type is present in the "cost-type- present if the path vector cost type is present in the "cost-type-
names" field. names" field.
Other fields of the FilteredCostMapCapabilities object has the same Other fields of the FilteredCostMapCapabilities object has the same
format as defined in Section 4.1.1 of [RFC8189] with the following format as defined in Section 4.1.1 of [RFC8189] with the following
constraint: restriction:
testable-cost-type-names: The path vector cost type with "ane-path" testable-cost-type-names: The path vector cost type with "ane-path"
as the cost metric and "array" as the cost mode MUST NOT be as the cost metric and "array" as the cost mode MUST NOT be
included in "testable-cost-type-names". included in "testable-cost-type-names".
6.1.2. Accept Input Parameters 6.1.2. Accept Input Parameters
The ReqFilteredCostMap uses the same format as defined in The ReqFilteredCostMap uses the same format as defined in
Section 4.1.2 of [RFC8189], with the following constraints: Section 4.1.2 of [RFC8189], with the following restrictions:
constraints, or-constraints: If the path vector cost type is constraints, or-constraints: If the path vector cost type is
included in either "cost-type" or "multi-cost-types", ALTO clients included in either "cost-type" or "multi-cost-types", ALTO clients
MUST NOT use it in "constraints" or "or-constraints". Otherwise, MUST NOT use it in "constraints" or "or-constraints". Otherwise,
the ALTO server MUST return an error with error code the ALTO server MUST return an error with error code
"E_INVALID_FIELD_VALUE". "E_INVALID_FIELD_VALUE".
testable-cost-types: The path vector cost type MUST NOT be included testable-cost-types: The path vector cost type MUST NOT be included
in the "testable-cost-types" field. Otherwise, the ALTO server in the "testable-cost-types" field. Otherwise, the ALTO server
MUST return an error with error code "E_INVALID_FIELD_VALUE". MUST return an error with error code "E_INVALID_FIELD_VALUE".
6.1.3. Response 6.1.3. Response
If the ALTO client includes the path vector cost type in the "cost- If the ALTO client includes the cost type "path-vector" in the "cost-
type" or "multi-cost-types" field of the input parameter, the type" or "multi-cost-types" field of the input parameter, the
response use the same format as defined in Section 4.1.3 of response use the same format as defined in Section 4.1.3 of
[RFC8189], but the corresponding cost value MUST be encoded as a [RFC8189], but the corresponding cost value MUST be encoded as a
JSONArray of AbstractNetworkElementName. JSONArray of AbstractNetworkElementName.
6.2. Endpoint Cost Service Extensions 6.2. 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 [RFC8189]. Section 4.2 in [RFC8189].
The specifications for "HTTP method" and "uses" are the same as The specifications for "HTTP method", "media-type" and "uses" are the
defined in Section 4.2 in [RFC8189]. same as defined in Section 4.2 in [RFC8189].
6.2.1. Capabilities 6.2.1. Capabilities
The same as defined in Section 6.1.1. The same as defined in Section 6.1.1.
6.2.2. Accept Input Parameters 6.2.2. Accept Input Parameters
The ReqEndpointCostMap uses the same format as defined in The ReqEndpointCostMap uses the same format as defined in
Section 4.2.2 of [RFC8189], with the following constraints: Section 4.2.2 of [RFC8189], with the following restrictions:
cost-type, multi-cost-types: ALTO clients MUST include the path cost-type, multi-cost-types: ALTO clients MUST include the path
vector cost type, e.g. the one with "ane-path" as cost metric and 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" "array" as cost mode, in either "cost-type" or "multi-cost-types"
to activate the path vector extension. to activate the path vector extension.
constraints, or-constraints: If the path vector cost type is constraints, or-constraints: If the path vector cost type is
included in either "cost-type" or "multi-cost-types", ALTO clients included in either "cost-type" or "multi-cost-types", ALTO clients
MUST NOT use it in "constraints" or "or-constraints". Otherwise, MUST NOT use it in "constraints" or "or-constraints". Otherwise,
the ALTO server MUST return an error with error code the ALTO server MUST return an error with error code
skipping to change at page 20, line 18 skipping to change at page 19, line 40
"ane:L007": { "availbw": 35 } "ane:L007": { "availbw": 35 }
} }
} }
--example-2-- --example-2--
8. Compatibility 8. Compatibility
8.1. Compatibility with Legacy ALTO Clients/Servers 8.1. Compatibility with Legacy ALTO Clients/Servers
Legacy ALTO clients SHOULD NOT send queries with the path-vector The path vector extension on Filtered Cost Map and Endpoint Cost
extension and ALTO servers with this extension SHOULD NOT have any Service is backward compatible with the base ALTO protocol. If the
compatibility issue. Legacy ALTO servers do not support cost types ALTO server provides path vector extended Filtered Cost Map or
with cost mode being "array" and cost metric being "ane-path", so Endpoint Cost Service, but the client is a base ALTO client, then the
they MUST NOT announce the extended cost types in IRD. Thus, ALTO client will ignore the path vector cost type without conducting any
clients MUST NOT send queries specified in this extension to base incompatibility. If the client sents a request with path vector cost
ALTO servers according to Section 11.3.2.3 [RFC7285]. type, but the server is a base ALTO server, the server will return an
"E_INVALID_FIELD_VALUE" error.
8.2. Compatibility with Multi-Cost Extensions 8.2. Compatibility with Multi-Cost Extensions
Path Vector is not a testable cost type. Any format of constraints Cost type path-vector is not a testable cost type. Any format of
SHOULD NOT be applied to cost type path-vector in order for multi- constraints SHOULD NOT be applied to cost type path-vector in order
cost to support the path-vector extension. Specifically, for multi-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.
8.3. Compatibility with Incremental Update 8.3. Compatibility with Incremental Update
Without considering the incremental update of multipart/related [I-D.ietf-alto-incr-update-sse] defines incremental updates to ALTO
information, there is no compatibility issue with incremental update resources and hence it can be applied to the path-vector resource
extension. Compatibility issue with the incremental update of defined in this document.
multipart/related information will be discussed and addressed in the
next version.
9. Design Decisions and Discussions 9. Design Decisions and Discussions
9.1. Provide More General Calendar Extension 9.1. 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.
skipping to change at page 22, line 14 skipping to change at page 21, line 34
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 10.2. Resource Consumption on ALTO Servers
The Abstract Network Element Property Map is dynamically enriched TODO: The Abstract Network Element Property Map is dynamically
when the (Filtered) Cost Map/Endpoint Cost Service is queried of the enriched when the (Filtered) Cost Map/Endpoint Cost Service is
path-vector information. The properties of the abstract network queried of the path-vector information. The properties of the
elements can consume a large amount of resources when cached. So, a abstract network elements can consume a large amount of resources
time-to-live is needed to remove outdated entries in the Network when cached. So, a time-to-live is needed to remove outdated entries
Element Property Map. in the Abstract 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 "array". However, the base This document specifies a new cost mode "array". However, the base
ALTO protocol does not have a Cost Mode Registry where new cost mode ALTO protocol does not have a Cost Mode Registry where new cost mode
can be registered. This new cost mode will be registered once the can be registered. This new cost mode will be registered once the
registry is defined either in a revised version of [RFC7285] or in registry is defined either in a revised version of [RFC7285] or in
another future extension. another future extension.
skipping to change at page 22, line 44 skipping to change at page 22, line 18
Registry", listed in Table 2. Registry", listed in Table 2.
+-------------+---------------------+ +-------------+---------------------+
| Identifier | Intended Semantics | | Identifier | Intended Semantics |
+-------------+---------------------+ +-------------+---------------------+
| ane-path | See Section 5.1.2 | | ane-path | See Section 5.1.2 |
+-------------+---------------------+ +-------------+---------------------+
Table 2: ALTO Cost Metrics Table 2: ALTO Cost Metrics
11.3. ALTO Network Element Property Type Registry 11.3. ALTO Entity Domain Registry
As proposed in Section 9.2 of [I-D.ietf-alto-unified-props-new],
"ALTO Entity Domain Registry" is requested. Besides, a new domain is
to be registered, listed in Table 3.
+-------------+--------------------------+--------------------------+
| Identifier | Entity Address Encoding | Hierarchy & Inheritance |
+-------------+--------------------------+--------------------------+
| ane | See Section 5.2.2 | None |
+-------------+--------------------------+--------------------------+
Table 3: ALTO Entity Domain
11.4. ALTO Network Element Property Type Registry
The "ALTO Abstract Network Element Property Type Registry" is The "ALTO Abstract Network Element Property Type Registry" is
required by the 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 Abstract Network Element Property Types Table 4: ALTO Abstract Network Element Property Types
12. Acknowledgments 12. Acknowledgments
The authors would like to thank discussions with Randriamasy Sabine, The authors would like to thank discussions with Randriamasy Sabine,
Andreas Voellmy, Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Andreas Voellmy, Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao
Xiang, Tianyuan Liu, Xiao Shi, Xin Wang, and Yan Luo. Xiang, Tianyuan Liu, Xiao Shi, Xin Wang, and Yan Luo.
13. References 13. References
13.1. Normative References 13.1. Normative References
skipping to change at page 23, line 41 skipping to change at page 23, line 26
[I-D.amante-i2rs-topology-use-cases] [I-D.amante-i2rs-topology-use-cases]
Medved, J., Previdi, S., Lopez, V., and S. Amante, Medved, J., Previdi, S., Lopez, V., and S. Amante,
"Topology API Use Cases", draft-amante-i2rs-topology-use- "Topology API Use Cases", draft-amante-i2rs-topology-use-
cases-01 (work in progress), October 2013. cases-01 (work in progress), October 2013.
[I-D.bernstein-alto-topo] [I-D.bernstein-alto-topo]
Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology
Service: Uses Cases, Requirements, and Framework", draft- Service: Uses Cases, Requirements, and Framework", draft-
bernstein-alto-topo-00 (work in progress), October 2013. bernstein-alto-topo-00 (work in progress), October 2013.
[I-D.clemm-i2rs-yang-network-topo]
Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N.,
and H. Ananthakrishnan, "A YANG Data Model for Network
Topologies", draft-clemm-i2rs-yang-network-topo-01 (work
in progress), October 2014.
[I-D.ietf-alto-cost-calendar] [I-D.ietf-alto-cost-calendar]
Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N.
Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost-
calendar-01 (work in progress), February 2017. calendar-01 (work in progress), February 2017.
[I-D.ietf-alto-incr-update-sse]
Roome, W. and Y. Yang, "ALTO Incremental Updates Using
Server-Sent Events (SSE)", draft-ietf-alto-incr-update-
sse-08 (work in progress), January 2018.
[I-D.ietf-alto-unified-props-new] [I-D.ietf-alto-unified-props-new]
Roome, W. and Y. Yang, "Extensible Property Maps for the Roome, W., Chen, S., xinwang2014@hotmail.com, x., Yang,
ALTO Protocol", draft-ietf-alto-unified-props-new-00 (work Y., and J. Zhang, "Extensible Property Maps for the ALTO
in progress), July 2017. Protocol", draft-ietf-alto-unified-props-new-01 (work in
progress), December 2017.
[I-D.lee-alto-app-net-info-exchange] [I-D.lee-alto-app-net-info-exchange]
Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi,
Extensions to Support Application and Network Resource "ALTO Extensions to Support Application and Network
Information Exchange for High Bandwidth Applications", Resource Information Exchange for High Bandwidth
draft-lee-alto-app-net-info-exchange-02 (work in Applications in TE networks", draft-lee-alto-app-net-info-
progress), July 2013. exchange-04 (work in progress), October 2013.
[I-D.yang-alto-topology]
Bernstein, G., Lee, Y., Roome, W., Scharf, M., and Y.
Yang, "ALTO Topology Extensions: Node-Link Graphs", draft-
yang-alto-topology-06 (work in progress), March 2015.
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, DOI 10.17487/RFC2387, August 1998, RFC 2387, DOI 10.17487/RFC2387, August 1998,
<https://www.rfc-editor.org/info/rfc2387>. <https://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,
<https://www.rfc-editor.org/info/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
skipping to change at page 25, line 17 skipping to change at page 25, line 4
China China
Email: gaok12@mails.tsinghua.edu.cn Email: gaok12@mails.tsinghua.edu.cn
Young Lee Young Lee
Huawei Huawei
TX TX
USA USA
Email: leeyoung@huawei.com Email: leeyoung@huawei.com
Wendy Roome Wendy Roome
Nokia/Bell Labs Nokia/Bell Labs (Retired)
600 Mountain Ave, Rm 3B-324 124 Burlington Rd
Murray Hill, NJ 07974 Murray Hill, NJ 07974
USA USA
Phone: +1-908-582-7974 Phone: +1-908-464-6975
Email: wendy.roome@nokia.com Email: wendy@wdroome.com
Michael Scharf Michael Scharf
Nokia Nokia
Germany Germany
Email: michael.scharf@nokia.com Email: michael.scharf@nokia.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
51 Prospect St 51 Prospect St
 End of changes. 69 change blocks. 
293 lines changed or deleted 289 lines changed or added

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