draft-ietf-alto-path-vector-04.txt   draft-ietf-alto-path-vector-05.txt 
ALTO WG G. Bernstein ALTO WG K. Gao
Internet-Draft Grotto Networking Internet-Draft Tsinghua University
Intended status: Standards Track S. Chen Intended status: Standards Track Y. Lee
Expires: January 3, 2019 Tongji University Expires: September 12, 2019 Huawei
K. Gao S. Randriamasy
Tsinghua University Nokia Bell Labs
Y. Lee
Huawei
W. Roome
M. Scharf
Nokia
Y. Yang Y. Yang
Yale University Yale University
J. Zhang J. Zhang
Tongji University Tongji University
July 2, 2018 March 11, 2019
ALTO Extension: Path Vector Cost Type ALTO Extension: Path Vector Cost Type
draft-ietf-alto-path-vector-04 draft-ietf-alto-path-vector-05
Abstract Abstract
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]
has defined cost maps and endpoint cost maps to provide basic network has defined cost maps and endpoint cost maps to provide basic network
information. However, they provide only scalar (numerical or information. However, they provide only scalar (numerical or
ordinal) cost mode values, which are insufficient to satisfy the ordinal) cost mode values, which are insufficient to satisfy the
demands of solving more complex network optimization problems. This demands of solving more complex network optimization problems. This
document introduces an extension to the base ALTO protocol, namely document introduces an extension to the base ALTO protocol, namely
the path-vector extension, which allows ALTO clients to query the path-vector extension, which allows ALTO clients to query
information such as capacity regions for a given set of flows. A information such as the capacity region for a given set of flows
non-normative example called multi-flow scheduling is presented to (called co-flows). A non-normative example called co-flow scheduling
illustrate the limitations of existing ALTO endpoint cost maps. is presented to illustrate the limitations of existing ALTO endpoint
After that, details of the extension are defined. 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 January 3, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Case: Capacity Region for Multi-Flow Scheduling . . . . . 5 3. Use Case: Capacity Region for Co-Flow Scheduling . . . . . . 5
4. Overview of Path Vector Extensions . . . . . . . . . . . . . 7 4. Overview of Path Vector Extensions . . . . . . . . . . . . . 7
4.1. New Cost Type to Encode Path Vectors . . . . . . . . . . 7 4.1. New Cost Type to Encode Path Vectors . . . . . . . . . . 7
4.2. New ALTO Entity Domain to Provide ANE Properties . . . . 8 4.2. New ALTO Entity Domain to Provide ANE Properties . . . . 8
4.3. Extended Cost Map/Endpoint Cost Service for Compound 4.3. Extended Cost Map/Endpoint Cost Service for Compound
Resources . . . . . . . . . . . . . . . . . . . . . . . . 8 Resources . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Cost Mode: array . . . . . . . . . . . . . . . . . . . . 9 5.1. Cost Mode: array . . . . . . . . . . . . . . . . . . . . 9
5.2. Cost Metric: ane-path . . . . . . . . . . . . . . . . . . 9 5.2. Cost Metric: ane-path . . . . . . . . . . . . . . . . . . 9
5.3. Path Vector Cost Type Semantics . . . . . . . . . . . . . 9 5.3. Path Vector Cost Type Semantics . . . . . . . . . . . . . 9
6. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Domain-Specific Entity Addresses . . . . . . . . . . . . 10 6.2. Domain-Specific Entity Addresses . . . . . . . . . . . . 10
6.3. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 10 6.3. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 10
7. Protocol Extensions for Path Vector Compound Query . . . . . 10 7. Protocol Extensions for Path Vector . . . . . . . . . . . . . 10
7.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 7.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11
7.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 7.1.1. Accept Input Parameters . . . . . . . . . . . . . . . 11
7.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 7.1.2. Capabilities . . . . . . . . . . . . . . . . . . . . 11
7.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12 7.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 12 7.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 12
7.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 13 7.2.1. Accept Input Parameters . . . . . . . . . . . . . . . 13
7.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 13 7.2.2. Capabilities . . . . . . . . . . . . . . . . . . . . 13
7.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 13 7.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 13
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Information Resource Directory Example . . . . . . . . . 14 8.2. Information Resource Directory Example . . . . . . . . . 14
8.3. Example # 1 . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. Example # 1 . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. Example # 2 . . . . . . . . . . . . . . . . . . . . . . . 18 8.4. Example # 2 . . . . . . . . . . . . . . . . . . . . . . . 18
8.5. Example #3 . . . . . . . . . . . . . . . . . . . . . . . 20 8.5. Example #3 . . . . . . . . . . . . . . . . . . . . . . . 20
9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 22 9.1. Compatibility with Base ALTO Clients/Servers . . . . . . 22
9.2. Compatibility with Multi-Cost Extension . . . . . . . . . 23 9.2. Compatibility with Multi-Cost Extension . . . . . . . . . 23
9.3. Compatibility with Incremental Update . . . . . . . . . . 23 9.3. Compatibility with Incremental Update . . . . . . . . . . 23
10. General Discussions . . . . . . . . . . . . . . . . . . . . . 23 10. General Discussions . . . . . . . . . . . . . . . . . . . . . 23
10.1. Provide Calendar for Property Map . . . . . . . . . . . 23 10.1. Provide Calendar for Property Map . . . . . . . . . . . 23
10.2. Constraint Tests for General Cost Types . . . . . . . . 24 10.2. Constraint Tests for General Cost Types . . . . . . . . 24
10.3. General Compound Resources Query . . . . . . . . . . . . 24 10.3. General Compound Resources Query . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24
11.2. Resource Consumption on ALTO Servers . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 25 12.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 25
12.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 25 12.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 26
12.3. ALTO Domain Registry . . . . . . . . . . . . . . . . . . 25 12.3. ALTO Entity Domain Registry . . . . . . . . . . . . . . 26
12.4. ALTO Network Element Property Type Registry . . . . . . 26 12.4. ALTO Network Element Property Type Registry . . . . . . 26
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The base ALTO protocol [RFC7285] is designed to expose network The base ALTO protocol [RFC7285] is designed to expose network
information through services such as cost map and endpoint cost information through services such as cost maps and endpoint cost
service. These services use an extreme "single-node" network view service. These services use an extreme "single-node" network
abstraction, which represents the whole network with a single node abstraction, which represents a whole network as a single node and
and hosts with "endpoint groups" directly connected to the node. hosts as "endpoint groups" directly connected to the node.
Although the "single-node" network view abstraction works well in Although the "single-node" abstraction works well in many settings,
many settings, it lacks the ability to support emerging use cases, it lacks the ability to support emerging use cases, such as co-flow
such as applications requiring large bandwidth or latency sensitivity scheduling for large-scale data analytics. For such a use case,
[I-D.bernstein-alto-topo], and inter-datacenter data transfers
[I-D.lee-alto-app-net-info-exchange]. For these use cases,
applications require a more powerful network view abstraction beyond applications require a more powerful network view abstraction beyond
the "single-node" abstraction to support application capabilities, in the "single-node" abstraction.
particular, the ability multi-flow scheduling.
To support capabilities like multi-flow scheduling, this document To support capabilities like co-flow scheduling, this document uses a
uses a "path vector" abstraction to represent more detailed network "path vector" abstraction to represent more detailed network graph
graph information like capacity regions. The path vector abstraction information like capacity regions. The path vector abstraction uses
uses path vectors with abstract network elements to provide network path vectors with abstract network elements to provide network graph
graph view for applications. A path vector consists of a sequence of view for applications. A path vector consists of a sequence of
Abstract Network Elements (ANEs) that end-to-end traffic goes abstract network elements (ANEs) that end-to-end traffic goes
through. ANEs can be links, switches, middleboxes, their through. Example ANEs include links, switches, middleboxes, and
aggregations, etc.; they have properties like "bandwidth", "delay", their aggregations. An ANE can have properties such as "bandwidth",
etc. These information may help the application avoid network "delay". Providing such information can help both applications to
congestion and achieve better application performance. achieve better application performance and networks to avoid network
congestion.
Providing path vector abstraction using ALTO introduces the following Providing path vector abstraction using ALTO introduces the following
additional requirements (ARs): additional requirements (ARs):
AR-1: The ALTO protocol SHOULD include the support for encoding AR-1: The path vector abstraction requires the encoding of array-
array-like cost values rather than scalar cost values in cost maps like cost values rather than scalar cost values in cost maps or
or endpoint cost maps. endpoint cost maps.
The ALTO server providing path vector abstraction SHOULD convey Specifically, the path vector abstraction requires the
sequences of ANEs between sources and destinations the ALTO client specification of the sequence of ANEs between sources and
requests. Theses information cannot be encoded by the scalar destinations. Such a sequence, however, cannot be encoded by the
types (numerical or ordinal) which the base ALTO protocol scalar types (numerical or ordinal) which the base ALTO protocol
supports. A new cost type is required to encode path vectors as supports.
costs.
AR-2: The ALTO protocol SHOULD include the support for encoding AR-2: The path vector abstraction requires the encoding of the
properties of ANEs. properties of aforementioned ANEs.
Only the sequences of ANEs are not enough for most use cases Specifically, only the sequences of ANEs are not enough for
mentioned previously. The properties of ANEs like "bandwidth" and existing use cases. Properties of ANEs such as "bandwidth" and
"delay" are required by applications to build the capacity region "delay" are needed by applications to properly construct capacity
or realize the latency sensitivity. regions.
AR-3: The ALTO server SHOULD allow the ALTO client to query path AR-3: The path vector abstraction requires consistent encoding of
vectors and the properties of abstract network elements path vectors (AR-1) and the properties of the elements in a path
consistently. vector (AR-2).
Path vectors and the properties of abstract network elements are Specifically, path vectors and the properties of abstract network
correlated information, but can be separated into different ALTO elements in the vectors are dependent. A mechanism to query both
information resources. A mechanism to query both of them of them consistently is necessary.
consistently is necessary.
This document proposes the path vector extension which satisfies This document proposes the path vector extension which satisfies
these additional requirements to the ALTO protocol. Specifically, these additional requirements to the ALTO protocol. Specifically,
the ALTO protocol encodes the array of ANEs over an end-to-end path the ALTO protocol encodes the array of ANEs over an end-to-end path
using a new cost type, and conveys the properties of ANEs using using a new cost type, and conveys the properties of ANEs using
unified property map [I-D.ietf-alto-unified-props-new]. We also unified property map [I-D.ietf-alto-unified-props-new]. We also
provide an optional solution to query separated path vectors and provide an optional solution to query separated path vectors and
properties of ANEs in a consistent way. But querying general properties of ANEs in a consistent way. But querying general
separated resources consistently is not the scope in this document. separated resources consistently is not the scope in this document.
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 multi-flow scheduling and illustrates the limitations an example of co-flow scheduling and illustrates the limitations of
of the base ALTO protocol in such a use case. Section 4 gives an the base ALTO protocol in such a use case. Section 4 gives an
overview of the path vector extension. Section 5 introduces a new overview of the path vector extension. Section 5 introduces a new
cost type. Section 6 registers a new domain in Domain Registry. cost type. Section 6 registers a new domain in Domain Registry.
Section 7 extends Filtered Cost Map and Endpoint Cost Service to Section 7 extends Filtered Cost Map and Endpoint Cost Service to
support the compound resource query. Section 8 presents several support the compound resource query. Section 8 presents several
examples. Section 9 and Section 10 discusses compatibility issues examples. Section 9 and Section 10 discusses compatibility issues
with other existing ALTO extensions and design decisions. Section 11 with other existing ALTO extensions and design decisions. Section 11
and Section 12 review the security and IANA considerations. and Section 12 review the security and IANA considerations.
2. Terminology 2. Terminology
skipping to change at page 5, line 34 skipping to change at page 5, line 24
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), etc. An links, middle boxes, virtualized network function (VNF), etc. An
abstract network element has two types of attributes: a name and a abstract network element has two types of attributes: a name and a
set of properties. set of properties.
o Path Vector: A path vector is an array of ANEs. It presents an o Path Vector: A path vector is an array of ANEs. It presents an
abstract network path between source/destination points such as abstract network path between source/destination points such as
PIDs or endpoints. PIDs or endpoints.
3. Use Case: Capacity Region for Multi-Flow Scheduling 3. Use Case: Capacity Region for Co-Flow Scheduling
Assume that an application has control over a set of flows, which may Assume that an application has control over a set of flows, which may
go through shared links or switches and share a bottleneck. The go through shared links or switches and share a bottleneck. The
application hopes to schedule the traffic among multiple flows to get application hopes to schedule the traffic among multiple flows to get
better performance. The capacity region information for those flows better performance. The capacity region information for those flows
will benefit the scheduling. However, existing cost maps can not will benefit the scheduling. However, existing cost maps can not
reveal such information. reveal such information.
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
skipping to change at page 6, line 42 skipping to change at page 6, line 42
+------+ +------+ +------+ +------+
| | | |
+----------------------+ +----------------------+
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 wants to schedule the traffic among a set of end host source- which wants to schedule the traffic among a set of end host source-
destination pairs, say eh1 -> eh2 and eh1 -> 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.
The application will receive from ALTO server that the bandwidth of The application will receive from ALTO server that the bandwidth of
eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information is eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information is
not enough. Consider the following two cases: not enough. Consider the following two cases:
o Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 -> o Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 ->
sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 -> sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 ->
sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps at sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps at
most. most.
skipping to change at page 10, line 47 skipping to change at page 10, line 47
The ANE name is usually unrelated to the physical device information. The ANE name is usually unrelated to the physical device information.
It is usually generated by the ALTO server on demand and used to It is usually generated by the ALTO server on demand and used to
distinguish from other ANEs in its dependent cost map or endpoint distinguish from other ANEs in its dependent cost map or endpoint
cost map. cost map.
6.3. Hierarchy and Inheritance 6.3. Hierarchy and Inheritance
There is no hierarchy or inheritance for properties associated with There is no hierarchy or inheritance for properties associated with
ANEs. ANEs.
7. Protocol Extensions for Path Vector Compound Query 7. Protocol Extensions for Path Vector
To make the ALTO client query the path vectors and properties of ANEs To make the ALTO client query the path vectors and properties of ANEs
efficiently and consistently, this document extends the Filtered Cost efficiently and consistently, this document extends the Filtered Cost
Map and Endpoint Cost Service. Map and Endpoint Cost Service.
7.1. Filtered Cost Map Extensions 7.1. Filtered Cost Map Extensions
This document extends Filtered Cost Map, as defined in Section 11.3.2 This document extends Filtered Cost Map, as defined in Section 11.3.2
of [RFC7285], by adding new input parameters and capabilities, and by of [RFC7285], by adding new input parameters and capabilities, and by
augmenting the property map into the data entry of the response. augmenting the property map into the data entry of the response.
The "media type", "HTTP method", and "uses" specifications (described The "media type", "HTTP method", and "uses" specifications (described
in Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], in Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285],
respectively) remain the same. respectively) remain the same.
7.1.1. Capabilities 7.1.1. Accept Input Parameters
The ReqFilteredCostMap object in Section 11.3.2.3 of [RFC7285] is
extended as follows:
object {
[PropertyName compound-properties<1..*>;]
} ReqPVFilteredCostMap : ReqFilteredCostMap;
compound-properties: If the capability "allow-compound-response" is
false, the ALTO client MUST NOT specify this field, and the ALTO
server MUST reject the request and return "E_INVALID_FILED_VALUE"
error when it receives a request including this field. If this
field is specified and accepted, the ALTO server MUST augment the
dependent property map with the properties in this field into the
response automatically.
7.1.2. Capabilities
The Filtered Cost Map capabilities are extended with two new members: The Filtered Cost Map capabilities are extended with two new members:
o dependent-property-map o dependent-property-map
o allow-compound-response o allow-compound-response
The capability "dependent-property-map" indicates which property map The capability "dependent-property-map" indicates which property map
this resource depends on, and the capability "allow-compound- this resource depends on, and the capability "allow-compound-
response" indicates whether the ALTO server supports the resource to response" indicates whether the ALTO server supports the resource to
skipping to change at page 12, line 5 skipping to change at page 12, line 23
map into the response automatically; the false value means the map into the response automatically; the false value means the
ALTO client cannot request the compound response. If omitted, the ALTO client cannot request the compound response. If omitted, the
default value is false; default value is false;
To be noticed that the capability "cost-constraints" is unexpected To be noticed that the capability "cost-constraints" is unexpected
for the "array" cost mode. The syntax and semantics of constraint for the "array" cost mode. The syntax and semantics of constraint
tests on the "array" cost mode depends on the implementation and can tests on the "array" cost mode depends on the implementation and can
be defined in the future documents. But it is not in the scope of be defined in the future documents. But it is not in the scope of
this document. this document.
7.1.2. Accept Input Parameters
The ReqFilteredCostMap object in Section 11.3.2.3 of [RFC7285] is
extended as follows:
object {
[PropertyName compound-properties<1..*>;]
} ReqPVFilteredCostMap : ReqFilteredCostMap;
compound-properties: If the capability "allow-compound-response" is
false, the ALTO client MUST NOT specify this field, and the ALTO
server MUST reject the request and return "E_INVALID_FILED_VALUE"
error when it receives a request including this field. If this
field is specified and accepted, the ALTO server MUST augment the
dependent property map with the properties in this field into the
response automatically.
7.1.3. Response 7.1.3. Response
If the ALTO client specifies the "cost-type" input parameter with If the ALTO client specifies the "cost-type" input parameter with
"ane-path" metric, the "dependent-vtags" field in the "meta" field of "ane-path" metric, the "dependent-vtags" field in the "meta" field of
the response MUST include the version tag of its dependent property the response MUST include the version tag of its dependent property
map following its dependent network map. map following its dependent network map.
If the ALTO client specifies the "compound-properties" input If the ALTO client specifies the "compound-properties" input
parameter which is accepted by the ALTO server, the response MUST parameter which is accepted by the ALTO server, the response MUST
include a "property-map" field following the "cost-map" field, and include a "property-map" field following the "cost-map" field, and
skipping to change at page 13, line 5 skipping to change at page 13, line 5
This document extends the Endpoint Cost Service, as defined in This document extends the Endpoint Cost Service, as defined in
Section 11.5.1 of [RFC7285], by adding new input parameters and Section 11.5.1 of [RFC7285], by adding new input parameters and
capabilities and by augmenting the property map into the data entry capabilities and by augmenting the property map into the data entry
of the response. of the response.
The media type, HTTP method, and "uses" specifications (described in The media type, HTTP method, and "uses" specifications (described in
Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively) Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively)
are unchanged. are unchanged.
7.2.1. Capabilities 7.2.1. Accept Input Parameters
The extensions to the Endpoint Cost Service capabilities are
identical to the extensions to the Filtered Cost Map (see
Section 7.1.1).
7.2.2. Accept Input Parameters
The ReqEndpointCostMap object in Section 11.5.1.3 of [RFC7285] is The ReqEndpointCostMap object in Section 11.5.1.3 of [RFC7285] is
extended as follows: extended as follows:
object { object {
[PropertyName compound-properties<1..*>;] [PropertyName compound-properties<1..*>;]
} ReqPVEndpointCostMap : ReqEndpointCostMap; } ReqPVEndpointCostMap : ReqEndpointCostMap;
The "compound-properties" has the same interpretation as defined in The "compound-properties" has the same interpretation as defined in
Section 7.1.2 Section 7.1.1.
7.2.2. Capabilities
The extensions to the Endpoint Cost Service capabilities are
identical to the extensions to the Filtered Cost Map (see
Section 7.1.2).
7.2.3. Response 7.2.3. Response
If the ALTO client specifies the "cost-type" input parameter with If the ALTO client specifies the "cost-type" input parameter with
"ane-path" metric, the response MUST include the "meta" field with "ane-path" metric, the response MUST include the "meta" field with
the "dependent-vtags" in it, and the "dependent-vtags" field MUST the "dependent-vtags" in it, and the "dependent-vtags" field MUST
include the version tag of its dependent property map. include the version tag of its dependent property map.
If the ALTO client specifies the "compound-properties" input If the ALTO client specifies the "compound-properties" input
parameter which is accepted by the ALTO server, the response MUST parameter which is accepted by the ALTO server, the response MUST
skipping to change at page 14, line 17 skipping to change at page 14, line 17
2. Look for the resource of the (Filtered) Cost Map/Endpoint Cost 2. Look for the resource of the (Filtered) Cost Map/Endpoint Cost
Service which supports the "ane-path" cost metric and get the Service which supports the "ane-path" cost metric and get the
resource ID of the dependent property map. resource ID of the dependent property map.
3. Check whether the capabilities of the property map includes the 3. Check whether the capabilities of the property map includes the
desired "prop-types". desired "prop-types".
4. Check whether the (Filtered) Cost Map/Endpoint Cost Service 4. Check whether the (Filtered) Cost Map/Endpoint Cost Service
allows the compound response. allows the compound response.
1. If allowed, the ALTO client can send a request including the 5. If allowed, the ALTO client can send a request including the
desired ANE properties to the ALTO server and receive a desired ANE properties to the ALTO server and receive a compound
compound response with the cost map/endpoint cost map and the response with the cost map/endpoint cost map and the property
property map. map.
2. If not allowed, the ALTO client sends a query for the cost 6. If not allowed, the ALTO client sends a query for the cost map/
map/endpoint cost map first. After receiving the response, endpoint cost map first. After receiving the response, the ALTO
the ALTO client interprets all the ANE names appearing in the client interprets all the ANE names appearing in the response and
response and sends another query for the property map on sends another query for the property map on those ANE names.
those ANE names.
8.2. Information Resource Directory Example 8.2. Information Resource Directory Example
Here is an example of an Information Resource Directory. In this Here is an example of an Information Resource Directory. In this
example, filtered cost map "cost-map-pv" doesn't support the multi- example, filtered cost map "cost-map-pv" doesn't support the multi-
cost extension but support the path-vector extension, "endpoint- cost extension but support the path-vector extension, "endpoint-
multicost-map" supports both multi-cost extension and path-vector multicost-map" supports both multi-cost extension and path-vector
extension. Filtered Property Map "propmap-availbw-delay" supports extension. Filtered Property Map "propmap-availbw-delay" supports
properties "availbw" and "delay". properties "availbw" and "delay".
skipping to change at page 22, line 41 skipping to change at page 22, line 41
"ane:L001": { "availbw": 50, "delay": 46 }, "ane:L001": { "availbw": 50, "delay": 46 },
"ane:L003": { "availbw": 48, "delay": 50 }, "ane:L003": { "availbw": 48, "delay": 50 },
"ane:L004": { "availbw": 55, "delay": 70 }, "ane:L004": { "availbw": 55, "delay": 70 },
"ane:L005": { "availbw": 60, "delay": 100 }, "ane:L005": { "availbw": 60, "delay": 100 },
"ane:L007": { "availbw": 35, "delay": 100 } "ane:L007": { "availbw": 35, "delay": 100 }
} }
} }
9. Compatibility 9. Compatibility
9.1. Compatibility with Legacy ALTO Clients/Servers 9.1. Compatibility with Base ALTO Clients/Servers
The path vector extension on Filtered Cost Map and Endpoint Cost The path vector extension on Filtered Cost Map and Endpoint Cost
Service is backward compatible with the base ALTO protocol: Service is backward compatible with the base ALTO protocol:
o If the ALTO server provides extended capabilities "dependent- o If the ALTO server provides extended capabilities "dependent-
property-map" and "allow-compound-response" for Filtered Cost Map property-map" and "allow-compound-response" for Filtered Cost Map
or Endpoint Cost Service, but the client only supports the base or Endpoint Cost Service, but the client only supports the base
ALTO protocol, then the client will ignore those capabilities ALTO protocol, then the client will ignore those capabilities
without conducting any incompatibility. without conducting any incompatibility.
skipping to change at page 23, line 17 skipping to change at page 23, line 17
the server will ignore this field. the server will ignore this field.
9.2. Compatibility with Multi-Cost Extension 9.2. Compatibility with Multi-Cost Extension
This document does not specify how to integrate the "array" cost mode This document does not specify how to integrate the "array" cost mode
and the "ane-path" cost metric with the multi-cost extension and the "ane-path" cost metric with the multi-cost extension
[RFC8189]. Although there is no reason why somebody has to compound [RFC8189]. Although there is no reason why somebody has to compound
the path vectors with other cost types in a single query, there is no the path vectors with other cost types in a single query, there is no
compatible issue doing it without constraint tests. compatible issue doing it without constraint tests.
As Section 7.1.1 mentions, the syntax and semantics of whether As Section 7.1.2 mentions, the syntax and semantics of whether
"constraints" or "or-constraints" field for the "array" cost mode is "constraints" or "or-constraints" field for the "array" cost mode is
not specified in this document. So if an ALTO server provides a not specified in this document. So if an ALTO server provides a
resource with the "array" cost mode and the capability "cost- resource with the "array" cost mode and the capability "cost-
constraints" or "testable-cost-types-names", the ALTO client MAY constraints" or "testable-cost-types-names", the ALTO client MAY
ignore the capability "cost-constraints" or "testable-cost-types- ignore the capability "cost-constraints" or "testable-cost-types-
names" unless the implementation or future docuements specify the names" unless the implementation or future documents specify the
behavior. behavior.
9.3. Compatibility with Incremental Update 9.3. Compatibility with Incremental Update
As this document still follows the basic request/response protocol As this document still follows the basic request/response protocol
with JSON encoding, it is surely compatible with the incremental with JSON encoding, it is surely compatible with the incremental
update service as defined by [I-D.ietf-alto-incr-update-sse]. But update service as defined by [I-D.ietf-alto-incr-update-sse]. But
the following details are to be noticed: the following details are to be noticed:
o When using the compound response, updates on both cost map and o When using the compound response, updates on both cost map and
skipping to change at page 24, line 43 skipping to change at page 24, line 43
As the last paragraph of Section 4.3 mentions, querying multiple ALTO As the last paragraph of Section 4.3 mentions, querying multiple ALTO
information resources continuously is a general requirement. And the information resources continuously is a general requirement. And the
coming issues like inefficiency and inconsistency are also general. coming issues like inefficiency and inconsistency are also general.
There is no standard solving these issues yet. So we need some There is no standard solving these issues yet. So we need some
approach to make the ALTO client request the compound ALTO approach to make the ALTO client request the compound ALTO
information resources in a single query. information resources in a single query.
11. Security Considerations 11. Security Considerations
11.1. Privacy Concerns This document is an extension of the base ALTO protocol, so the
Security Considerations of the base ALTO protocol fully apply when
this extension is provided by an ALTO server.
We can identify multiple potential security issues. A main security The path vector extension requires additional considerations on two
issue is network privacy, as the path vector information may reveal security considerations discussed in the base protocol:
more network internal structures than the more abstract single-node confidentiality of ALTO information (Section 15.3 of [RFC7285]) and
abstraction. The network should consider protection mechanisms to availability of ALTO service (Section 15.5 of [RFC7285]).
reduce information exposure, in particular, in settings where the
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
benefit of the path-vector abstraction is reduced information
transfer from the network to the application.
Beyond the privacy issues, the computation of the path vector is For confidentiality of ALTO information, a network operator should be
unlikely to be cacheable, in that the results will depend on the aware of that this extension may introduce a new risk: the path
particular requests (e.g., where the flows are distributed). Hence, vector information may make network attacks easier. For example, as
this service may become an entry point for denial of service attacks the path vector information may reveal more network internal
on the availability of an ALTO server. Hence, authenticity and structures than the more abstract single-node abstraction, an ALTO
authorization of this ALTO service may need to be better protected. client may detect the bottleneck link and start a distributed denial-
of-service (DDoS) attack involving minimal flows to conduct the in-
network congestion.
11.2. Resource Consumption on ALTO Servers To mitigate this risk, the ALTO server should consider protection
mechanisms to reduce information exposure or obfuscate the real
information, in particular, in settings where the network and the
application do not belong to the same trust domain. But the
implementation of path vector extension involving reduction or
obfuscation should guarantees the constraints on the requested
properties are still accurate.
The dependent Property Map of path vectors is dynamically enriched For availability of ALTO service, an ALTO server should be cognizant
when the (Filtered) Cost Map/Endpoint Cost Service is queried of the that using path vector extension might have a new risk: frequent
path-vector information. The properties of the abstract network requesting for path vectors might conduct intolerable increment of
elements can consume a large amount of resources when cached. So, a the server-side storage and break the ALTO server. It is known that
time-to-live is needed to remove outdated entries in the Abstract the computation of path vectors is unlikely to be cacheable, in that
Network Element Property Map. the results will depend on the particular requests (e.g., where the
flows are distributed). Hence, the service providing path vectors
may become an entry point for denial-of-service attacks on the
availability of an ALTO server. To avoid this risk, authenticity and
authorization of this ALTO service may need to be better protected.
Even if there is no intentional attack, the dependent property map of
path vector might be still dynamically enriched, in that every new
request for path vectors will make the ALTO server generate a new
property map. So the properties of the abstract network elements can
consume a large amount of resources when cached. To avoid this, the
ALTO server providing the path vector extension should support a
time-to-live configuration for the property map, so that the outdated
entries can be removed from the property map resource.
12. IANA Considerations 12. IANA Considerations
12.1. ALTO Cost Mode Registry 12.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 25, line 46 skipping to change at page 26, line 18
Registry", listed in Table 2. Registry", listed in Table 2.
+-------------+---------------------+ +-------------+---------------------+
| Identifier | Intended Semantics | | Identifier | Intended Semantics |
+-------------+---------------------+ +-------------+---------------------+
| ane-path | See Section 5.2 | | ane-path | See Section 5.2 |
+-------------+---------------------+ +-------------+---------------------+
Table 2: ALTO Cost Metrics Table 2: ALTO Cost Metrics
12.3. ALTO Domain Registry 12.3. ALTO Entity Domain Registry
As proposed in Section 9.2 of [I-D.ietf-alto-unified-props-new], As proposed in Section 9.2 of [I-D.ietf-alto-unified-props-new],
"ALTO Domain Registry" is requested. Besides, a new domain is to be "ALTO Domain Entity Registry" is requested. Besides, a new domain is
registered, listed in Table 3. to be registered, listed in Table 3.
+-------------+--------------------------+--------------------------+ +-------------+--------------------------+--------------------------+
| Identifier | Entity Address Encoding | Hierarchy & Inheritance | | Identifier | Entity Address Encoding | Hierarchy & Inheritance |
+-------------+--------------------------+--------------------------+ +-------------+--------------------------+--------------------------+
| ane | See Section 6.2 | None | | ane | See Section 6.2 | None |
+-------------+--------------------------+--------------------------+ +-------------+--------------------------+--------------------------+
Table 3: ALTO Domain Table 3: ALTO Entity Domain
12.4. ALTO Network Element Property Type Registry 12.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 Domain "ane", listed in Table 4. required by the ALTO 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 4: ALTO Abstract Network Element Property Types Table 4: ALTO Abstract Network Element Property Types
13. Acknowledgments 13. Acknowledgments
The authors would like to thank discussions with Randriamasy Sabine, The authors would like to thank discussions with Andreas Voellmy,
Andreas Voellmy, Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan
Xiang, Tianyuan Liu, Xiao Shi, Xin Wang, and Yan Luo. Liu, Xiao Shi, Xin Wang, and Yan Luo. The authors thank Greg
Bernstein (Grotto Networks), Dawn Chen (Tongji University), Wendy
Roome, and Michael Scharf for their contributions to earlier drafts.
14. References 14. References
14.1. Normative References 14.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/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997, <https://www.rfc-editor.org/info/
<https://www.rfc-editor.org/info/rfc2119>. rfc2119>.
14.2. Informative References 14.2. Informative References
[I-D.amante-i2rs-topology-use-cases]
Medved, J., Previdi, S., Lopez, V., and S. Amante,
"Topology API Use Cases", draft-amante-i2rs-topology-use-
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.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] [I-D.ietf-alto-incr-update-sse]
Roome, W. and Y. Yang, "ALTO Incremental Updates Using Roome, W., Yang, Y., and S. Chen, "ALTO Incremental
Server-Sent Events (SSE)", draft-ietf-alto-incr-update- Updates Using Server-Sent Events (SSE)", draft-ietf-alto-
sse-08 (work in progress), January 2018. incr-update-sse-15 (work in progress), December 2018.
[I-D.ietf-alto-unified-props-new] [I-D.ietf-alto-unified-props-new]
Roome, W., Chen, S., xinwang2014@hotmail.com, x., Yang, Roome, W., Chen, S., xinwang2014@hotmail.com, x., Yang,
Y., and J. Zhang, "Extensible Property Maps for the ALTO Y., and J. Zhang, "Extensible Property Maps for the ALTO
Protocol", draft-ietf-alto-unified-props-new-01 (work in Protocol", draft-ietf-alto-unified-props-new-01 (work in
progress), December 2017. progress), December 2017.
[I-D.lee-alto-app-net-info-exchange]
Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi,
"ALTO Extensions to Support Application and Network
Resource Information Exchange for High Bandwidth
Applications in TE networks", draft-lee-alto-app-net-info-
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.
[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>.
[RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
Application-Layer Traffic Optimization (ALTO)", RFC 8189, Application-Layer Traffic Optimization (ALTO)", RFC 8189,
DOI 10.17487/RFC8189, October 2017, DOI 10.17487/RFC8189, October 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8189>. editor.org/info/rfc8189>.
Authors' Addresses Authors' Addresses
Greg Bernstein
Grotto Networking
Fremont, CA
USA
Email: gregb@grotto-networking.com
Shiwei Dawn Chen
Tongji University
4800 Caoan Road
Shanghai 201804
China
Email: dawn_chen_f@hotmail.com
Kai Gao Kai Gao
Tsinghua University Tsinghua University
Beijing Beijing Beijing Beijing
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 Sabine Randriamasy
Nokia/Bell Labs (Retired) Nokia Bell Labs
124 Burlington Rd Route de Villejust
Murray Hill, NJ 07974 NOZAY 91460
USA FRANCE
Phone: +1-908-464-6975
Email: wendy@wdroome.com
Michael Scharf Email: Sabine.Randriamasy@nokia-bell-labs.com
Nokia
Germany
Email: michael.scharf@nokia.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
51 Prospect St 51 Prospect St
New Haven CT New Haven CT
USA USA
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Jingxuan Jensen Zhang Jingxuan Jensen Zhang
Tongji University Tongji University
 End of changes. 58 change blocks. 
204 lines changed or deleted 173 lines changed or added

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