One document matched: draft-wu-alto-te-metrics-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-alto-te-metrics-08" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="ALTO Performance Cost Metrics">ALTO Performance Cost
Metrics</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Y. Richard Yang" initials="Y." surname="Yang">
<organization>Yale University</organization>
<address>
<postal>
<street>51 Prospect St</street>
<city>New Haven</city>
<region>CT</region>
<code>06520</code>
<country>USA</country>
</postal>
<email>yry@cs.yale.edu</email>
</address>
</author>
<author fullname="Young Lee" initials="Y." surname="Lee">
<organization>Huawei</organization>
<address>
<postal>
<street>1700 Alma Drive, Suite 500</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<email>leeyoung@huawei.com</email>
</address>
</author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy">
<organization>Nokia Bell Labs </organization>
<address>
<postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<region/>
<code>91460</code>
<country>FRANCE</country>
</postal>
<email>sabine.randriamasy@nokia-bell-labs.com</email>
</address>
</author>
<date year="2016"/>
<area>TSV Area</area>
<workgroup>ALTO Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>JavaScript Object Notation, Application-Layer Traffic
Optimization</keyword>
<abstract>
<t>Cost Metric is a basic concept in Application-Layer Traffic
Optimization (ALTO). It is used in both the Cost Map Service and the
Endpoint Cost Service. Future extensions to ALTO may also use Cost
Metric.</t>
<t>Different applications may benefit from different Cost Metrics. For
example, a Resource Consumer may prefer Resource Providers that have low
delay to the Resource Consumer. However the base ALTO protocol [ALTO]
has defined only a single cost metric, i.e., the generic "routingcost"
metric (Sec. 14.2 of ALTO base specification [ALTO]).</t>
<t>In this document, we proposes a set of Cost Metrics, derived and
aggregated from routing protocols with different granularity and scope,
such as BGP-LS,OSPF-TE and ISIS-TE, or from end to end traffic
management tool. We currently define 11 new Performance Metric to
measure network delay, jitter, packet loss, hop count, and bandwidth.
The metrics defined in this document provide a relatively comprehensive
set of Cost Metrics for ALTO and allow applications to determine "where"
to connect based on end to end network performance criteria. Additional
Cost Metrics such as financial cost metrics may be defined in other
documents.</t>
<t>Requirements Language The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Cost Metric is a basic concept in Application-Layer Traffic
Optimization (ALTO). It is used in both the Cost Map Service and the
Endpoint Cost Service. In particular, applications may benefit from
knowing network performance measured on several Cost Metrics. For
example, a more delay sensitive application may focus on latency, and a
more bandwidth-sensitive application may focus on available
bandwidth.</t>
<t>The objective of this document is to introduce 11 new performance
cost metrics, listed in Table 1, to support the aforementioned
applications and allow applications to determine "where" to connect
based on end to end network performance criteria. Hence, this document
extends the base ALTO protocol [ALTO], which defines only a single cost
metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base
specification [ALTO]).</t>
<figure>
<artwork>
+-----------+--------------+------------------------+
| Namespace | Property | Reference |
+-----------+--------------+------------------------+
| | delay | [RFCxxxx], Section 3 |
| | delayjitter | [RFCxxxx], Section 4 |
| | pktloss | [RFCxxxx], Section 5 |
| | hopcount | [RFCxxxx], Section 6 |
| | bandwidth | [RFCxxxx], Section 7 |
| | maxbw | [RFCxxxx], Section 8 |
| | maxresbw | [RFCxxxx], Section 9 |
| | unresdbw | [RFCxxxx], Section 10 |
| | residbw | [RFCxxxx], Section 11 |
| | availbw | [RFCxxxx], Section 12 |
| | utilbw | [RFCxxxx], Section 13 |
+-----------+--------------+------------------------+
Table 1.</artwork>
</figure>
<t>An ALTO server may provide a subset of the cost metrics defined in
this document. These cost metrics can be retreived and aggregated from
routing protocol or other traffic measurement management tool (See
Figure 1).<figure>
<artwork>
+--------+ +--------+ +--------+
| Client | | Client | | Client |
+----^---+ +---^----+ +---^----+
| | |
+-----------|-----------+
NBI |ALTO protocol
|
|
+--+-----+ retrieve +---------+
| ALTO |<----------------| Routing |
| Server | and aggregation| |
| |<-------------+ | Protocol|
+--------+ | +---------+
|
| +---------+
| |Management
---| |
| Tool |
+---------+
Figure 1.End to End Path Cost Metrics Exposing</artwork>
</figure></t>
<t>When an ALTO server supports a cost metric defined in this document,
the server SHOULD announce the metric in its IRD.</t>
<t>The definitions of a set of cost metrics can allow us to extend the
ALTO base protocol (e.g., allowing output and constraints use different
cost metrics), but such extensions are not in the scope of this
document.</t>
<t>One challenge in describing the metrics is that performance metrics
often depend on configuration parameters. For example, the value of
packet loss rate depends on the measurement interval and varies over
time. To handle this issue, ALTO server may collect data on time periods
covering the past, present or only collect data on present time. The
ALTO may further aggregate these data to provide an abstract and unified
view that can be more useful to applications. To make the ALTO client
understand whether the performance data is past data or present data,
the ALTO server needs to expose to the client the validity period of
each performance metric.</t>
<t>Following the ALTO base protocol, this document uses JSON to specify
the value type of each defined metric. See [RFC4627] for JSON data type
specification.</t>
</section>
<section title="Data sources, computation of defined cost metrics">
<t>The cost metrics described in this document are similar, in that they
may use similar data sources and have similar issues in their
calculation. Hence, instead of specifying such issues for each metric
individually, we specify the common issue in this section.</t>
<section title="Data sources">
<t>An ALTO server needs data sources to compute the cost metrics
described in this document. This document does not define the exact
data sources. For example, the ALTO server may use log servers or the
OAM system as its data source [ALTO-DEPLOYMENT]. In particular, the
cost metrics defined in this document can be computed using routing
systems as the data sources. Mechanisms defined in [RFC3630],
[RFC3784], [OSPF-TE], [ISIS-TE], [BGP-LS] and [BGP-PM] that allow an
ALTO Server to retrieve and derive the necessary information to
compute the metrics that we described in this document.</t>
</section>
<section title="Computation of metrics">
<t>An ALTO server processes measurements from data sources to compute
exposed metrics. It may need performance data processing tasks such as
aggregating the results across multiple systems, removing outliers,
and creating additional statistics.</t>
<t>One specific challenge in deriving the metrics in this document is
that these performance metrics depend on some configuration
parameters. For example, the value of packet loss rate depends on the
measurement interval and varies over time. If the ALTO server uses
aforementioned routing protocol based mechanisms as data sources, then
the measurement interval may be preconfigured by the routing protocol.
For example, Section 5 of [ISIS-TE] defines a default measurement
interval of 30 seconds. This document uses the term Measurement
Interval to refer to the measurement interval used by the data
sources. In the [ISIS-TE] case, it is a measurement interval set by
routing protocol. The Measurement Interval(s) of the data sources can
be different from the interval that this document derives the metric,
e.g., the interval used by this document is multiple of measurement
interval of the data sources. Hence, an ALTO server needs to resolve
the mismatch, when it happens.</t>
<t>Another issue of converting from data source measurements to ALTO
exposed metric values is that the measurement results that the ALTO
Server retrieves may be defined for only links, and hence, the server
will need to compose the link metrics to obtain path metrics used in
services such as the Cost Map Service. In this definition, we define
the metrics to be independent of link or path, considering that future
ALTO extensions may define link-based services, and hence the defined
metrics should still be usable.</t>
</section>
</section>
<section title="Cost Metric: Delay">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Delay<vspace
blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/> To
specify spatial and temporal aggregated delay between the specified
source and destination or the time that the packet spends to travel
from source to destination. The spatial aggregation unit is
specified in the query context (e.g., PID to PID, or endpoint to
endpoint); and the temporal unit is specified as the measurement
interval in the query context. <vspace blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/>The unit
is microsecond.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>This is
intended to be a constraint attribute value. A Cost Mode is encoded
as a US-ASCII string. The Metric value Type is a single 'JSONNumber'
type value containing a non-negative integer component that may be
followed by an exponent part.<vspace blankLines="1"/>This metric
could be used as a cost metric constraint attribute used either
together with cost metric attribute 'routingcost' or on its own or
as a returned cost metric in the response.<vspace
blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 1: Delay value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "delay"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta" :{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "delay"
}
},
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 10,
"ipv4:198.51.100.34" : 20,
"ipv6:2000::1:2345:6789:abcd" : 30,
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Delay Jitter">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Delay
jitter<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal aggregated jitter (latency variation) over the
specified source and destination. The spatial aggregation unit is
specified in the query context (e.g., PID to PID, or endpoint to
endpoint); and the temporal unit is specified as the measurement
interval in the query context. <vspace blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/>The unit
is microsecond.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/> See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:Use and Applications:"><vspace
blankLines="1"/>See section 3 for use and application.<vspace
blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 2: Delayjitter value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "delayjitter"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"delayjitter"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 0
"ipv4:198.51.100.34" : 1
"ipv6:2000::1:2345:6789:abcd" : 5
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Packet Loss">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Packet
loss<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal aggregated packet loss over the specified
source and destination. The spatial aggregation unit is specified in
the query context (e.g., PID to PID, or endpoint to endpoint); and
the temporal unit is specified as the measurement interval in the
query context. <vspace blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/>The unit
is percentile.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 3: pktloss value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "pktloss"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"pktloss"}
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 0,
"ipv4:198.51.100.34": 1,
"ipv6:2000::1:2345:6789:abcd" : 2,
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Hop Count">
<t>The metric hopcount is mentioned in [ALTO] as an example. This
section further clarifies its properties.</t>
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Hop count<vspace
blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/> To
specify the number of hops in the path between the source endpoint
and the destination endpoint. The hop count is a basic measurement
of distance in a network and can be exposed as Router Hops, IP hops
or other hops in direct relation to the routing prtocols originating
this information. it might also result from the aggregation of such
information.</t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/>The unit
is integer number.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 4: hopcount value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "hopcount"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric":"hopcount"}
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 5,
"ipv4:198.51.100.34": 3,
"ipv6:2000::1:2345:6789:abcd" : 2,
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Bandwidth">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Bandwidth<vspace
blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal aggregated bandwidth over the specified source
and destination. The spatial aggregation unit is specified in the
query context (e.g., PID to PID, or endhost to endhost); and the
temporal unit is specified as the measurement interval in the query
context. <vspace blankLines="1"/>This is just a definition of a
class of cost metric 'bandwidth'. The use of this cost metric is
always in conjunction with what it represents, which could be Max
Bandwidth (maxbw), Residual Bandwidth (residuebw) etc. <vspace
blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/>The
units are bytes per second.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Cost Metric: Maximum Bandwidth">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Maximum
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal maximum bandwidth over the specified source and
destination. The values correspond to the maximum bandwidth that can
be used (motivated from RFC 3630 Sec. 2.5.6.). The spatial
aggregation unit is specified in the query context (e.g., PID to
PID, or endhost to endhost); and the temporal unit is specified as
the measurement interval in the query context. <vspace
blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/>See
definition for the Bandwidth Cost Metric.<vspace
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 5: maxbw value on source-destination endpoint pairs
POST/ endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": { "cost-mode": "numerical",
"cost-metric": "maxbw"},
"endpoints": {
"srcs": [ "ipv4 : 192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "maxbw"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"ipv4:198.51.100.34" : 2000,
"ipv6:2000::1:2345:6789:abcd": 5000,
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Maximum Reservable Bandwidth">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Maximum
Reservable Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal maximum reservable bandwidth over the specified
source and destination. The value is corresponding to the maximum
bandwidth that can be reserved (motivated from RFC 3630 Sec.
2.5.7.). The spatial aggregation unit is specified in the query
context (e.g., PID to PID, or endpoint to endpoint); and the
temporal unit is specified as the measurement interval in the query
context. <vspace blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/> See
definition of the Bandwidth Cost Metric. <vspace
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 6: maxresbw value on source-destination endpoint pairs
POST/ endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type" { "cost-mode": "numerical",
"cost-metric": "maxresbw"},
"endpoints": {
"srcs": [ "ipv4 : 192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "maxresbw"
}
},
" endpoint-cost-map": {
"ipv4:192.0.2.2" {
"ipv4:192.0.2.89" : 0,
"ipv4:198.51.100.34": 2000,
"ipv6:2000::1:2345:6789:abcd": 5000,
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Unreserved Bandwidth">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Unreserved
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal unreserved bandwidth over the specified source
and destination. The values correspond to the bandwidth that can be
reserved with a setup priority of 0 through 7. Therefore this metric
is endcoded as an array of 8 values. The spatial aggregation unit is
specified in the query context (e.g., PID to PID, or endpoint to
endpoint); and the temporal unit is specified as the measurement
interval in the query context. <vspace blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/>See
definition for the bandwidth Cost Metric.<vspace
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 7: unresbw value on source-destination endpoint pairs
In this example, the Collection method specifies that the
'unresbw' values are defined as the 'unavailable bandwidth' specified
in section 2.5.8 of RFC3630: 8 unavailable bandwidth value are
reported in the same OSPF message using the same TLV. Each value
is corresponding to the bandwidth that can be reserved with a setup
priority of 0 through 7.
POST/ endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type" { "cost-mode": "numerical",
"cost-metric": "unresbw[1,8]" },
"endpoints": {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "unresbw[1,8]"
}
},
"endpoint-cost-map" {
"ipv4:192.0.2.2" {
"ipv4:192.0.2.89" : [0,0,0,0,0,0,0,0],
"ipv4:198.51.100.34": [0,0,0,0,0,0,0,2000],
"ipv6:2000::1:2345:6789:abcd": [0,0,0,0,0,0,0,5000],
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Residue Bandwidth">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Residue
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal residual bandwidth over the specified source
and destination. The value is calculated by subtracting tunnel
reservations from Maximum Bandwidth (motivated from [I-D.
ietf-isis-te-metric-extensions], Sec.4.5.). The spatial aggregation
unit is specified in the query context (e.g., PID to PID, or
endpoint to endpoint); and the temporal unit is specified as the
measurement interval in the query context. <vspace
blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/> See
definition of the general Bandwidth.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 8: residuebw value on source-destination endpoint pairs
POST/ endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": { "cost-mode": "numerical",
"cost-metric": "residubw"},
"endpoints": {
"srcs": [ "ipv4 : 192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type" {
"cost-mode": "numerical",
"cost-metric": "residubw"
}
},
"endpoint-cost-map" {
"ipv4:192.0.2.2" {
"ipv4:192.0.2.89" : 0,
"ipv4:198.51.100.34": 2000,
"ipv6:2000::1:2345:6789:abcd": 5000,
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Available Bandwidth">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Available
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal availaible bandwidth over the specified source
and destination. The value is calculated by subtracting the measured
bandwidth used for the actual forwarding of best effort traffic from
Residue Bandwidth (motivated from [I-D.
ietf-isis-te-metric-extensions], Sec.4.6.). The spatial aggregation
unit is specified in the query context (e.g., PID to PID, or
endpoint to endpoint); and the temporal unit is specified as the
measurement interval in the query context. <vspace
blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/> See
definition of the general Bandwidth.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 9: availbw value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": { "cost-mode": "numeric",
"cost-metric": "availbw"},
"endpoints": {
"srcs": [ "ipv4 : 192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numeric",
"cost-metric": "availbw"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2" {
"ipv4:192.0.2.89" : [6,5,7,8,4,10,7,6],
"ipv4:198.51.100.34" : [7,4,6,8,5,9,6,7],
"ipv6:2000::1:2345:6789:abcd" : [7,6,8,5,7,9,6,8],
}
}
}
</artwork>
</figure>
</section>
<section title="Cost Metric: Utilized Bandwidth">
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Utilized
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal utilized bandwidth over the specified source
and destination. The value is corresponding to the actual measured
bandwidth used for all traffic (motivated from [I-D.
ietf-isis-te-metric-extensions], Sec.4.7.). The spatial aggregation
unit is specified in the query context (e.g., PID to PID, or
endpoint to endpoint); and the temporal unit is specified as the
measurement interval in the query context. <vspace
blankLines="1"/></t>
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 2.2, Computation of metrics.<vspace
blankLines="1"/></t>
<t hangText="Units of Measurement:"><vspace blankLines="1"/> See
definition of the general Bandwidth.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
blankLines="1"/>See section 2.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 2.1, second paragraph for Measurement Timing.<vspace
blankLines="1"/></t>
<t hangText="Use and Applications:"><vspace blankLines="1"/>See
section 3 for use and application.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 10: utilbw value on source-destination endpoint pairs
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBA
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "utilbw"},
"endpoints": {
"srcs" : [ "ipv4 : 192.0.2.2" ],
"dsts" : [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv6:2000::1:2345:6789:abcd"
]
}
}
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost type": {
"cost-mode": "numerical",
"cost-metric": "utilbw"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2" {
"ipv4:192.0.2.89" : 0,
"ipv4:198.51.100.34" : 2000,
"ipv6:2000::1:2345:6789:abcd" : 5000,
}
}
}
</artwork>
</figure>
</section>
<section title="Security Considerations">
<t>The properties defined in this document present no security
considerations beyond those in Section 15 of the base ALTO specification
[ALTO].</t>
<t>However concerns addressed in Sections "15.1 Authenticity and
Integrity of ALTO Information", "15.2 Potential Undesirable Guidance
from Authenticated ALTO Information" and "15.3 Confidentiality of ALTO
Information" remain of utmost importance. Indeed, TE performance is a
highly sensitive ISP information and sharing TE metric values in
numerical mode requires full mutual confidence between the entities
managing the ALTO Server and Client. Numerical TE performance
information will most likely be distributed by ALTO Servers to Clients
under strict and formal mutual trust agreements. One the other hand,
ALTO Clients must be cognizant on the risks attached to such information
that they would have acquired outside formal conditions of mutual
trust.</t>
</section>
<section title="IANA Considerations">
<t>IANA has added the following entries to the ALTO cost map Properties
registry, defined in Section 3 of [RFCXXX].</t>
<figure>
<artwork>
+-----------+--------------+------------------------+
| Namespace | Property | Reference |
+-----------+--------------+------------------------+
| | delay | [RFCxxxx], Section 3 |
| | delayjitter | [RFCxxxx], Section 4 |
| | pktloss | [RFCxxxx], Section 5 |
| | hopcount | [RFCxxxx], Section 6 |
| | bandwidth | [RFCxxxx], Section 7 |
| | maxbw | [RFCxxxx], Section 8 |
| | maxresbw | [RFCxxxx] Section 9 |
| | unresdbw | [RFCxxxx], Section 10 |
| | residbw | [RFCxxxx], Section 11 |
| | availbw | [RFCxxxx], Section 12 |
| | utilbw | [RFCxxxx], Section 13 |
+-----------+--------------+------------------------+
</artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<?rfc include="reference.RFC.5234.xml"?>
<?rfc include="reference.RFC.4627.xml"?>
<?rfc include="reference.RFC.7285.xml"?>
<?rfc include="reference.RFC.7471.xml"?>
<?rfc include="reference.RFC.7752.xml"?>
<?rfc include="reference.I-D.ietf-isis-te-metric-extensions.xml"?>
<?rfc include="reference.I-D.ietf-idr-te-pm-bgp.xml"?>
</references>
<references title="Informative References">
<reference anchor="RFC6390">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization/>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization/>
</author>
<date month="July" year="2011"/>
</front>
<seriesInfo name="RFC" value="6390"/>
</reference>
<?rfc include="reference.I-D.ietf-alto-deployments.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:24:17 |