draft-ietf-alto-performance-metrics-07.txt   draft-ietf-alto-performance-metrics-08.txt 
ALTO Working Group Q. Wu ALTO Working Group Q. Wu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track Y. Yang Intended status: Standards Track Y. Yang
Expires: January 9, 2020 Yale University Expires: May 7, 2020 Yale University
Y. Lee Y. Lee
D. Dhody D. Dhody
Huawei Huawei
S. Randriamasy S. Randriamasy
Nokia Bell Labs Nokia Bell Labs
July 08, 2019 November 04, 2019
ALTO Performance Cost Metrics ALTO Performance Cost Metrics
draft-ietf-alto-performance-metrics-07 draft-ietf-alto-performance-metrics-08
Abstract Abstract
Cost metric is a basic concept in Application-Layer Traffic Cost metric is a basic concept in Application-Layer Traffic
Optimization (ALTO), and is used in basic services including both the Optimization (ALTO), and is used in basic services including both the
cost map service and the endpoint cost service. cost map service and the endpoint cost service.
Different applications may use different cost metrics, but the ALTO Different applications may use different cost metrics, but the ALTO
base protocol documents only one single cost metric, i.e., the base protocol documents only one single cost metric, i.e., the
generic "routingcost" metric; see Sec. 14.2 of ALTO base generic "routingcost" metric; see Sec. 14.2 of ALTO base
specification [RFC7285]. Hence, if the resource consumer of an specification [RFC7285]. Hence, if the resource consumer of an
application prefers a resource provider that offers low-delay application prefers a resource provider that offers low-delay
delivery to the resource consumer, the base protocol does not define delivery to the resource consumer, the base protocol does not define
the cost metric to be used. the cost metric to be used.
ALTO cost metrics can be generic metrics and this document focuses on ALTO cost metrics can be generic metrics and this document focuses on
network performance metrics, including network delay, jitter, packet network performance metrics, including network delay, jitter, packet
loss, hop count, and bandwidth. These metrics can be derived and loss, hop count, and bandwidth. Additional cost metrics may be
aggregated from routing protocols with different granularity and documented in other documents.
When using an ALTO performance metric, applications need additional
information beyond the metric. In particular, its "cost-source",
such as it being an estimation or an SLA, is key to define the
meaning of a performance metric. Hence, each ALTO performance metric
should include the "cost-source" of the metric. To report an
estimated value of a performance metric, the ALTO server may derive
and aggregate from routing protocols with different granularity and
scope, such as BGP-LS, OSPF-TE and ISIS-TE, or from end-to-end scope, such as BGP-LS, OSPF-TE and ISIS-TE, or from end-to-end
traffic management tools. These metrics may then be exposed by an traffic management tools. These metrics may then be exposed by an
ALTO Server to allow applications to determine "where" to connect ALTO Server to allow applications to determine "where" to connect
based on network performance criteria. Additional cost metrics may based on network performance criteria.
be documented in other documents.
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", Requirements Language The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119]. 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.
skipping to change at page 2, line 20 skipping to change at page 2, line 22
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
(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. Network Performance Cost Metrics . . . . . . . . . . . . . . 5 2. Network Performance Cost Metrics . . . . . . . . . . . . . . 6
2.1. Cost Metric: One Way Delay (owdelay) . . . . . . . . . . 5 2.1. Cost Metric: One Way Delay (owdelay) . . . . . . . . . . 6
2.1.1. Intended Semantics . . . . . . . . . . . . . . . . . 6 2.1.1. Intended Semantics . . . . . . . . . . . . . . . . . 6
2.1.2. Use and Example . . . . . . . . . . . . . . . . . . . 6 2.1.2. Use and Example . . . . . . . . . . . . . . . . . . . 6
2.1.3. Measurement Considerations . . . . . . . . . . . . . 7 2.1.3. Measurement Considerations . . . . . . . . . . . . . 7
2.2. Cost Metric: RoundTrip Time (rtt) . . . . . . . . . . . . 7 2.2. Cost Metric: RoundTrip Time (rtt) . . . . . . . . . . . . 8
2.2.1. Intended Semantics . . . . . . . . . . . . . . . . . 8 2.2.1. Intended Semantics . . . . . . . . . . . . . . . . . 8
2.2.2. Use and Example . . . . . . . . . . . . . . . . . . . 8 2.2.2. Use and Example . . . . . . . . . . . . . . . . . . . 8
2.2.3. Measurement Considerations . . . . . . . . . . . . . 9 2.2.3. Measurement Considerations . . . . . . . . . . . . . 9
2.3. Cost Metric: Packet Delay Variation (pdv) . . . . . . . . 9 2.3. Cost Metric: Packet Delay Variation (pdv) . . . . . . . . 10
2.3.1. Intended Semantics . . . . . . . . . . . . . . . . . 10 2.3.1. Intended Semantics . . . . . . . . . . . . . . . . . 10
2.3.2. Use and Example . . . . . . . . . . . . . . . . . . . 10 2.3.2. Use and Example . . . . . . . . . . . . . . . . . . . 10
2.3.3. Measurement Considerations . . . . . . . . . . . . . 11 2.3.3. Measurement Considerations . . . . . . . . . . . . . 11
2.4. Cost Metric: Hop Count . . . . . . . . . . . . . . . . . 12 2.4. Cost Metric: Hop Count . . . . . . . . . . . . . . . . . 12
2.4.1. Intended Semantics . . . . . . . . . . . . . . . . . 12 2.4.1. Intended Semantics . . . . . . . . . . . . . . . . . 12
2.4.2. Use and Example . . . . . . . . . . . . . . . . . . . 13 2.4.2. Use and Example . . . . . . . . . . . . . . . . . . . 13
2.4.3. Measurement Considerations . . . . . . . . . . . . . 14 2.4.3. Measurement Considerations . . . . . . . . . . . . . 14
2.5. Cost Metric: Packet Loss . . . . . . . . . . . . . . . . 14 2.5. Cost Metric: Packet Loss . . . . . . . . . . . . . . . . 14
2.5.1. Intended Semantics . . . . . . . . . . . . . . . . . 14 2.5.1. Intended Semantics . . . . . . . . . . . . . . . . . 14
2.5.2. Use and Example . . . . . . . . . . . . . . . . . . . 15 2.5.2. Use and Example . . . . . . . . . . . . . . . . . . . 15
2.5.3. Measurement Considerations . . . . . . . . . . . . . 16 2.5.3. Measurement Considerations . . . . . . . . . . . . . 16
2.6. Cost Metric: Throughput . . . . . . . . . . . . . . . . . 16 2.6. Cost Metric: Throughput . . . . . . . . . . . . . . . . . 16
2.6.1. Intended Semantics . . . . . . . . . . . . . . . . . 17 2.6.1. Intended Semantics . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 27 skipping to change at page 3, line 29
3. Traffic Engineering Performance Cost Metrics . . . . . . . . 18 3. Traffic Engineering Performance Cost Metrics . . . . . . . . 18
3.1. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 19 3.1. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 19
3.1.1. Intended Semantics . . . . . . . . . . . . . . . . . 19 3.1.1. Intended Semantics . . . . . . . . . . . . . . . . . 19
3.1.2. Use and Example . . . . . . . . . . . . . . . . . . . 19 3.1.2. Use and Example . . . . . . . . . . . . . . . . . . . 19
3.1.3. Measurement Considerations . . . . . . . . . . . . . 20 3.1.3. Measurement Considerations . . . . . . . . . . . . . 20
3.2. Cost Metric: Link Residue Bandwidth . . . . . . . . . . . 21 3.2. Cost Metric: Link Residue Bandwidth . . . . . . . . . . . 21
3.2.1. Intended Semantics . . . . . . . . . . . . . . . . . 21 3.2.1. Intended Semantics . . . . . . . . . . . . . . . . . 21
3.2.2. Use and Example . . . . . . . . . . . . . . . . . . . 21 3.2.2. Use and Example . . . . . . . . . . . . . . . . . . . 21
3.2.3. Measurement Considerations . . . . . . . . . . . . . 22 3.2.3. Measurement Considerations . . . . . . . . . . . . . 22
4. Operational Considerations . . . . . . . . . . . . . . . . . 23 4. Operational Considerations . . . . . . . . . . . . . . . . . 23
4.1. Data Source Considerations . . . . . . . . . . . . . . . 23 4.1. Source Considerations . . . . . . . . . . . . . . . . . . 23
4.2. Computation Considerations . . . . . . . . . . . . . . . 24 4.2. Backward Compatibility Considerations . . . . . . . . . . 24
4.2.1. Configuration Parameters Considerations . . . . . . . 24 4.3. Computation Considerations . . . . . . . . . . . . . . . 24
4.2.2. Availability Considerations . . . . . . . . . . . . . 24 4.3.1. Configuration Parameters Considerations . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 4.3.2. Availability Considerations . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Cost Metric is a basic concept in Application-Layer Traffic Cost Metric is a basic concept in Application-Layer Traffic
Optimization (ALTO). It is used in both the ALTO cost map service Optimization (ALTO). It is used in both the ALTO cost map service
and the ALTO endpoint cost service, to allow applications to request and the ALTO endpoint cost service, to allow applications to request
network cost metrics. network cost metrics.
Different applications may use different cost metrics. Hence, the Different applications may use different cost metrics. Hence, the
ALTO base protocol [RFC7285] introduces an ALTO Cost Metric Registry ALTO base protocol [RFC7285] introduces an ALTO Cost Metric Registry
skipping to change at page 4, line 46 skipping to change at page 4, line 50
An ALTO server may provide only a subset of the cost metrics An ALTO server may provide only a subset of the cost metrics
described in this document. Hence, all cost metrics defined in this described in this document. Hence, all cost metrics defined in this
document are optional and not all them need to be exposed to document are optional and not all them need to be exposed to
applications. For example, those that are subject to privacy applications. For example, those that are subject to privacy
concerns should not be provided to unauthorized ALTO clients. concerns should not be provided to unauthorized ALTO clients.
When an ALTO server supports a cost metric defined in this document, When an ALTO server supports a cost metric defined in this document,
it MUST announce this metric in its information resource directory it MUST announce this metric in its information resource directory
(IRD). (IRD).
The cost metrics defined in this document can be retrieved and To make clear how the value of an ALTO performance metric is derived,
aggregated from routing protocols or other traffic measurement this document defines an optional field named "cost-source" to extend
management tools, with corresponding operational issues. A potential the ALTO "cost-type". The "cost-source" indicates how the metric is
architecture on computing these metrics is shown in Figure 1 below. derived, and currently it can be either "estimation" or "sla". If a
In Section 4, we discuss in more detail the operations issues and how "cost-type" does not include the optional "cost-source" field, the
to address them. application MUST assume that the value of "cost-source" is
"estimation".
An ALTO server may compute "estimation" values by retrieving and/or
aggregating information from routing protocols or other traffic
measurement management tools, with corresponding operational issues.
A potential architecture on estimating these metrics is shown in
Figure 1 below. In Section 4, we discuss in more detail the
operations issues and how to address them.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Client | | Client | | Client | | Client | | Client | | Client |
+----^---+ +---^----+ +---^----+ +----^---+ +---^----+ +---^----+
| | | | | |
+-----------|-----------+ +-----------|-----------+
NBI |ALTO protocol NBI |ALTO protocol
| |
| |
+--+-----+ retrieval +---------+ +--+-----+ retrieval +---------+
skipping to change at page 5, line 41 skipping to change at page 6, line 8
degrades it. We discuss security considerations in more details in degrades it. We discuss security considerations in more details in
Section 5. Section 5.
Following the ALTO base protocol, this document uses JSON to specify Following the ALTO base protocol, this document uses JSON to specify
the value type of each defined metric. See [RFC4627] for JSON data the value type of each defined metric. See [RFC4627] for JSON data
type specification. type specification.
2. Network Performance Cost Metrics 2. Network Performance Cost Metrics
This section introduces generic ALTO network performance metrics such This section introduces generic ALTO network performance metrics such
as one way delay,round trip delay,hop count,packet loss,throughput as one way delay, round trip delay, hop count, packet loss, and
derived and aggregated from routing protocols or from end to end throughput.
traffic management tools.
2.1. Cost Metric: One Way Delay (owdelay) 2.1. Cost Metric: One Way Delay (owdelay)
Metric name: Metric name:
One Way Delay One Way Delay
Metric Identifier: Metric Identifier:
owdelay owdelay
2.1.1. Intended Semantics 2.1.1. Intended Semantics
Metric Description: To specify spatial and temporal aggregated delay Metric Description: To specify spatial and temporal aggregated delay
of a stream of packets exchanged between the specified source and of a stream of packets exchanged between the specified source and
destination or the time that the packet spends to travel from source destination or the time that the packet spends to travel from source
to destination. The spatial aggregation level is specified in the to destination. The spatial aggregation level is specified in the
query context (e.g., PID to PID, or endpoint to endpoint). query context (e.g., PID to PID, or endpoint to endpoint).
Metric Representation: The metric value type is a single 'JSONNumber' Metric Representation: The metric value type is a single 'JSONNumber'
type value containing a non-negative integer component that may be type value conforming to the number specification of [RFC8259]
followed by an exponent part. See section 8.4.3 of [I-D.ietf-ippm- Section 6. The number MUST be non-negative. The unit is expressed
initial-registry] for metric unit. The unit is expressed in in milliseconds in this document.
milliseconds in this document.
2.1.2. Use and Example 2.1.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 1: Delay value on source-destination endpoint pairs Example 1: Delay value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
skipping to change at page 7, line 22 skipping to change at page 7, line 45
}, },
"endpoint-cost-map" : { "endpoint-cost-map" : {
"ipv4:192.0.2.2": { "ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 10, "ipv4:192.0.2.89" : 10,
"ipv4:198.51.100.34" : 20, "ipv4:198.51.100.34" : 20,
"ipv6:2000::1:2345:6789:abcd" : 30, "ipv6:2000::1:2345:6789:abcd" : 30,
} }
} }
} }
Comment: Since the "cost-type" does not include the "cost-source"
field, the values are based on "estimation".
2.1.3. Measurement Considerations 2.1.3. Measurement Considerations
Method of Measurement or Calculation: Method of Measurement or Calculation:
See section 8.3 of [I-D.ietf-ippm-initial-registry] for potential See section 8.3 of [I-D.ietf-ippm-initial-registry] for potential
measurement method. measurement method.
Measurement Point(s) with Potential Measurement Domain: Measurement Point(s) with Potential Measurement Domain:
See Section 4.1, Data sources for potential data sources. See Section 4.1, Data sources for potential data sources.
skipping to change at page 8, line 15 skipping to change at page 8, line 37
2.2.1. Intended Semantics 2.2.1. Intended Semantics
Metric Description: To specify spatial and temporal aggregated round Metric Description: To specify spatial and temporal aggregated round
trip delay between the specified source and destination or the time trip delay between the specified source and destination or the time
that the packet spends to travel from source to destination and then that the packet spends to travel from source to destination and then
from destination to source. The spatial aggregation level is from destination to source. The spatial aggregation level is
specified in the query context (e.g., PID to PID, or endpoint to specified in the query context (e.g., PID to PID, or endpoint to
endpoint). endpoint).
Metric Representation: The metric value type is a single 'JSONNumber' Metric Representation: The metric value type is a single 'JSONNumber'
type value containing a non-negative integer component that may be type value conforming to the number specification of [RFC8259]
followed by an exponent part. See section 4.4.3 of [I-D.ietf-ippm- Section 6. The number MUST be non-negative. The unit is expressed
initial-registry] for Measurement Unit. The unit is expressed in in milliseconds in this document.
milliseconds in this document.
2.2.2. Use and Example 2.2.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 2: Roundtrip Delay value on source-destination endpoint pairs Example 2: Roundtrip Delay value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
skipping to change at page 10, line 16 skipping to change at page 10, line 33
2.3.1. Intended Semantics 2.3.1. Intended Semantics
Metric Description: To specify spatial and temporal aggregated jitter Metric Description: To specify spatial and temporal aggregated jitter
(packet delay variation) with respect to the minimum delay observed (packet delay variation) with respect to the minimum delay observed
on the stream over the specified source and destination. The spatial on the stream over the specified source and destination. The spatial
aggregation level is specified in the query context (e.g., PID to aggregation level is specified in the query context (e.g., PID to
PID, or endpoint to endpoint). PID, or endpoint to endpoint).
Metric Representation: The metric value type is a single 'JSONNumber' Metric Representation: The metric value type is a single 'JSONNumber'
type value containing a non-negative integer component that may be type value conforming to the number specification of [RFC8259]
followed by an exponent part. See section 5.4.4 of [I-D.ietf-ippm- Section 6. The number MUST be non-negative. The unit is expressed
initial-registry] for Measurement Unit. The unit is expressed in in milliseconds in this document.
milliseconds in this document.
2.3.2. Use and Example 2.3.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 3: PDV value on source-destination endpoint pairs Example 3: PDV value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
skipping to change at page 12, line 40 skipping to change at page 12, line 40
To specify the number of hops in the path between the source To specify the number of hops in the path between the source
endpoint and the destination endpoint. The hop count is a basic endpoint and the destination endpoint. The hop count is a basic
measurement of distance in a network and can be exposed as Router measurement of distance in a network and can be exposed as Router
Hops, in direct relation to the routing protocols originating this Hops, in direct relation to the routing protocols originating this
information. information.
Metric Representation: Metric Representation:
The metric value type is a single 'JSONNumber' type value The metric value type is a single 'JSONNumber' type value
containing a non-negative integer component. The unit is integer conforming to the number specification [RFC8259], Section 6. The
number. number MUST be an integer and non-negative. The value represents
the number of hops.
2.4.2. Use and Example 2.4.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 4: hopcount value on source-destination endpoint pairs Example 4: hopcount value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
skipping to change at page 15, line 5 skipping to change at page 15, line 5
Metric Description: Metric Description:
To specify spatial and temporal aggregated packet loss over the To specify spatial and temporal aggregated packet loss over the
specified source and destination. The spatial aggregation level specified source and destination. The spatial aggregation level
is specified in the query context (e.g., PID to PID, or endpoint is specified in the query context (e.g., PID to PID, or endpoint
to endpoint). to endpoint).
Metric Representation: Metric Representation:
The metric value type is a single 'JSONNumber' type value which be The metric value type is a single 'JSONNumber' type value
be non-negative integer. The unit is percentile. conforming to the number specification of [RFC8259] Section 6.
The number MUST be non-negative. The value represents the
percentage of packet loss.
2.5.2. Use and Example 2.5.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 5: pktloss value on source-destination endpoint pairs Example 5: pktloss value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
skipping to change at page 17, line 16 skipping to change at page 17, line 16
Metric Description: Metric Description:
To specify spatial and temporal throughput over the specified To specify spatial and temporal throughput over the specified
source and destination. The spatial aggregation level is source and destination. The spatial aggregation level is
specified in the query context (e.g., PID to PID, or endpoint to specified in the query context (e.g., PID to PID, or endpoint to
endpoint). endpoint).
Metric Representation: Metric Representation:
The unit is Mbps. The metric value type is a single 'JSONNumber' type value
conforming to the number specification of [RFC8259] Section 6.
The number MUST be non-negative. The unit is Mbps.
2.6.2. Use and Example 2.6.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 5: throughtput value on source-destination endpoint pairs Example 5: throughtput value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
skipping to change at page 19, line 28 skipping to change at page 19, line 28
To specify spatial and temporal maximum reservable bandwidth over To specify spatial and temporal maximum reservable bandwidth over
the specified source and destination. The value is corresponding the specified source and destination. The value is corresponding
to the maximum bandwidth that can be reserved (motivated from RFC to the maximum bandwidth that can be reserved (motivated from RFC
3630 Sec. 2.5.7.). The spatial aggregation unit is specified in 3630 Sec. 2.5.7.). The spatial aggregation unit is specified in
the query context (e.g., PID to PID, or endpoint to endpoint). the query context (e.g., PID to PID, or endpoint to endpoint).
Metric Representation: Metric Representation:
The metric value type is a single 'JSONNumber' type value that is The metric value type is a single 'JSONNumber' type value that is
non-negative. The unit of measurement is mbps. non-negative. The unit of measurement is Mbps.
3.1.2. Use and Example 3.1.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 6: maxresbw value on source-destination endpoint pairs Example 6: maxresbw value on source-destination endpoint pairs
POST/ endpointcost/lookup HTTP/1.1 POST/ endpointcost/lookup HTTP/1.1
skipping to change at page 21, line 38 skipping to change at page 21, line 38
To specify spatial and temporal residual bandwidth over the To specify spatial and temporal residual bandwidth over the
specified source and destination. The value is calculated by specified source and destination. The value is calculated by
subtracting tunnel reservations from Maximum Bandwidth (motivated subtracting tunnel reservations from Maximum Bandwidth (motivated
from [RFC7810], Section 4.5.). The spatial aggregation unit is from [RFC7810], Section 4.5.). The spatial aggregation unit is
specified in the query context (e.g., PID to PID, or endpoint to specified in the query context (e.g., PID to PID, or endpoint to
endpoint). endpoint).
Metric Representation: Metric Representation:
The metric value type is a single 'JSONNumber' type value that is The metric value type is a single 'JSONNumber' type value that is
non-negative. The unit of measurement is mbps. non-negative. The unit of measurement is Mbps.
3.2.2. Use and Example 3.2.2. Use and Example
This metric could be used as a cost metric constraint attribute used This metric could be used as a cost metric constraint attribute used
either together with cost metric attribute 'routingcost' or on its either together with cost metric attribute 'routingcost' or on its
own or as a returned cost metric in the response. own or as a returned cost metric in the response.
Example 7: residuebw value on source-destination endpoint pairs Example 7: residuebw value on source-destination endpoint pairs
POST/ endpointcost/lookup HTTP/1.1 POST/ endpointcost/lookup HTTP/1.1
skipping to change at page 23, line 15 skipping to change at page 23, line 15
Measurement Point(s) with Potential Measurement Domain: Measurement Point(s) with Potential Measurement Domain:
See Section 4.1 of this document. See Section 4.1 of this document.
Measurement Timing: Measurement Timing:
See Section 5 of [RFC7810] for Measurement Timing. See Section 5 of [RFC7810] for Measurement Timing.
4. Operational Considerations 4. Operational Considerations
It can be non-trivial for an ALTO server to derive the metrics. The exact measurement infrastructure, measurement condition and
Also, the exact infrastructure and algorithms can vary from different computation algorithms can vary from different networks, and are
networks, and are outside the scope of this document. However, since outside the scope of this document. Both the ALTO server and the
they present challenges, we discuss these common challenges. ALTO clients, however, need to be cognizant of the operational issues
discussed below.
Also, the performance metrics specified in this document are similar, Also, the performance metrics specified in this document are similar,
in that they may use similar data sources and have similar issues in in that they may use similar data sources and have similar issues in
their calculation. Hence, we specify common issues unless one metric their calculation. Hence, we specify common issues unless one metric
has its unique challenges. has its unique challenges.
4.1. Data Source Considerations 4.1. Source Considerations
An ALTO server needs data sources to compute the cost metrics The additiona of the "cost-source" field is to solve a key issue: An
described in this document. This document does not define the exact ALTO server needs data sources to compute the cost metrics described
data sources. For example, the ALTO server may use log servers or in this document and an ALTO client needs to know the data sources to
better interpret the values.
To avoid too fine-grained information, this document introduces
"cost-source" to indicate only the high-level type of data sources:
"estimation" or "sla", where "estimation" is a type of measurement
data source and "sla" is a type that is more based on policy.
For estimation, for example, the ALTO server may use log servers or
the OAM system as its data source [RFC7971]. In particular, the cost the OAM system as its data source [RFC7971]. In particular, the cost
metrics defined in this document can be computed using routing metrics defined in this document can be computed using routing
systems as the data sources. Mechanisms defined in [RFC2681], systems as the data sources. Mechanisms defined in [RFC2681],
[RFC3393], [RFC7679], [RFC7680], [RFC3630], [RFC3784], [RFC7471], [RFC3393], [RFC7679], [RFC7680], [RFC3630], [RFC3784], [RFC7471],
[RFC7810], [RFC7752] and [I-D.ietf-idr-te-pm-bgp] that allow an ALTO [RFC7810], [RFC7752] and [I-D.ietf-idr-te-pm-bgp] that allow an ALTO
Server to retrieve and derive the necessary information to compute Server to retrieve and derive the necessary information to compute
the metrics that we describe in this document. the metrics that we describe in this document.
One challenge lies in the data sources originating the ALTO metric 4.2. Backward Compatibility Considerations
values. The very important purpose of ALTO is to guide application
traffic with provider network centric information that may be exposed
to ALTO Clients in the form of network performance metric values.
Not all of these metrics have values produced by standardized
measurement methods or routing protocols. Some of them involve
provider-centric policy considerations. Some of them may describe
wireless or cellular networks. To reliably guide users and
applications while preserving provider privacy, ALTO performance
metric values may also add abstraction to measurements or provide
unitless performance scores.
4.2. Computation Considerations One potential issue introduced by the optional "cost-source" field is
backward compatibility. Consider that an IRD which defines two cost-
types with the same "cost-mode" and "cost-metric", but one with
"cost-source" being "estimation" and the other being "sla". Then an
ALTO client that is not aware of the extension will not be able to
distinguish between these two types. A similar issue can arise even
with a single cost-type which has "cost-source" being "sla", but the
backward client will ignore this field and consider the metric
estimation. [RFC7285]
To address this issue, the only defined "routingcost" metric can be
ONLY "estimation".
4.3. Computation Considerations
The metric values exposed by an ALTO server may result from The metric values exposed by an ALTO server may result from
additional processing on measurements from data sources to compute additional processing on measurements from data sources to compute
exposed metrics. This may involve data processing tasks such as exposed metrics. This may involve data processing tasks such as
aggregating the results across multiple systems, removing outliers, aggregating the results across multiple systems, removing outliers,
and creating additional statistics. There are two challenges on the and creating additional statistics. There are two challenges on the
computation of ALTO performance metrics. computation of ALTO performance metrics.
4.2.1. Configuration Parameters Considerations 4.3.1. Configuration Parameters Considerations
Performance metrics often depend on configuration parameters. For Performance metrics often depend on configuration parameters. For
example, the value of packet loss rate depends on the measurement example, the value of packet loss rate depends on the measurement
interval and varies over time. To handle this issue, an ALTO server interval and varies over time. To handle this issue, an ALTO server
may collect data on time periods covering the previous and current may collect data on time periods covering the previous and current
time or only collect data on present time. The ALTO server may time or only collect data on present time. The ALTO server may
further aggregate these data to provide an abstract and unified view further aggregate these data to provide an abstract and unified view
that can be more useful to applications. To make the ALTO client that can be more useful to applications. To make the ALTO client
better understand how to use these performance data, the ALTO server better understand how to use these performance data, the ALTO server
may provide the client with the validity period of the exposed metric may provide the client with the validity period of the exposed metric
values. values.
4.2.2. Availability Considerations 4.3.2. Availability Considerations
Applications value information relating to bandwidth availability Applications value information relating to bandwidth availability
whereas bandwidth related metrics can often be only measured at the whereas bandwidth related metrics can often be only measured at the
link level. This document specifies a set of link-level bandwidth link level. This document specifies a set of link-level bandwidth
related values that may be exposed as such by an ALTO server. The related values that may be exposed as such by an ALTO server. The
server may also expose other metrics derived from their aggregation server may also expose other metrics derived from their aggregation
and having different levels of endpoint granularity, e.g., link and having different levels of endpoint granularity, e.g., link
endpoints or session endpoints. The metric specifications may also endpoints or session endpoints. The metric specifications may also
expose the utilized aggregation laws. expose the utilized aggregation laws.
skipping to change at page 25, line 30 skipping to change at page 25, line 45
| owdelay | See Section 2.1 | | owdelay | See Section 2.1 |
| rtt | See Section 2.2 | | rtt | See Section 2.2 |
| pdv | See Section 2.3 | | pdv | See Section 2.3 |
| hopcount | See Section 2.4 | | hopcount | See Section 2.4 |
| pktloss | See Section 2.5 | | pktloss | See Section 2.5 |
| throughput | See Section 2.6 | | throughput | See Section 2.6 |
| maxresbw | See Section 3.1 | | maxresbw | See Section 3.1 |
| residuebw | See Section 3.2 | | residuebw | See Section 3.2 |
+------------+--------------------+ +------------+--------------------+
This document requests the creation of the "ALTO Cost Source
Registry" with the following currently defined values:
+------------+------------------------+
| Identifier | Intended Semantics |
+------------+------------------------+
| estimation | Values by estimation |
| sla | Values reflect service |
| | level agreement |
+------------+------------------------+
7. Acknowledgments 7. Acknowledgments
The authors of this document would also like to thank Brian Trammell, The authors of this document would also like to thank Brian Trammell,
Haizhou Du, Kai Gao, Lili Liu, Li, Geng, Danny Alex Lachos Perez for Haizhou Du, Kai Gao, Lili Liu, Li, Geng, Danny Alex Lachos Perez for
the reviews and comments. the reviews and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-idr-te-pm-bgp] [I-D.ietf-idr-te-pm-bgp]
Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C.
Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering
Performance Metric Extensions", draft-ietf-idr-te-pm- Performance Metric Extensions", draft-ietf-idr-te-pm-
bgp-18 (work in progress), December 2018. bgp-18 (work in progress), December 2018.
[I-D.ietf-ippm-initial-registry] [I-D.ietf-ippm-initial-registry]
Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
"Initial Performance Metrics Registry Entries", draft- "Initial Performance Metrics Registry Entries", draft-
ietf-ippm-initial-registry-11 (work in progress), March ietf-ippm-initial-registry-12 (work in progress),
2019. September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679,
September 1999, <https://www.rfc-editor.org/info/rfc2679>. September 1999, <https://www.rfc-editor.org/info/rfc2679>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
 End of changes. 32 change blocks. 
75 lines changed or deleted 117 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/