One document matched: draft-wu-alto-te-metrics-07.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-07" 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 TE Metrics">ALTO Traffic Engineering 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>Alcatel-Lucent</organization>
<address>
<postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<region/>
<code>91460</code>
<country>FRANCE</country>
</postal>
<email>Sabine.Randriamasy@alcatel-lucent.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 define eleven Cost Metrics, derived from OSPF-TE
and ISIS-TE, 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 focusing on traffic
engineering (TE). 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 define eleven cost metrics,
listed in Table 1, to support the aforementioned applications. 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. 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 defining 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.</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 defined 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
defined 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 define in this document.</t>
</section>
<section title="Computation of metrics">
<t>An ALTO server process 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",
"ipv4:203.0.113.45"
]
}
}
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,
"ipv4:203.0.113.45" : 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",
"ipv4:203.0.113.45"
]
}
}
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
"ipv4:203.0.113.45" : 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",
"ipv4:203.0.113.45"
]
}
}
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,
"ipv4:203.0.113.45" : 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. <vspace blankLines="1"/> [Editor Note:
Need to specify which level (AS, IP perhaps), details TBD for
multiple-layer aspect.]</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",
"ipv4:203.0.113.45"
]
}
}
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,
"ipv4:203.0.113.45" : 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",
"ipv4:203.0.113.45"
]
}
}
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,
"ipv4:203.0.113.45": 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",
"ipv4:203.0.113.45"
]
}
}
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,
"ipv4:203.0.113.45": 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",
"ipv4:203.0.113.45"
]
}
}
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],
"ipv4:203.0.113.45": [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",
"ipv4:203.0.113.45"
]
}
}
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,
"ipv4:203.0.113.45": 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",
"ipv4:203.0.113.45"
]
}
}
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],
"ipv4:203.0.113.45" : [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",
"ipv4:203.0.113.45"
]
}
}
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,
"ipv4:203.0.113.45" : 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:20 |