One document matched: draft-wu-alto-te-metrics-02.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-02" 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>sunseawq@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="2014"/>
<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 |
| | jitter | [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 defining 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. The Measurement Interval(s) of the data sources can be
different from the interval that this document defines the metric.
Hence, an ALTO server needs to resolve the mismatch, when it happens.
[TODO: Need more specification.] </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="Metric: Delay">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Delay<vspace
blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string '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="Metric Unit:"><vspace blankLines="1"/>The unit is
microsecond.<vspace blankLines="1"/></t>
<t hangText="Metric Value Type:"><vspace blankLines="1"/>A single
'JSONNumber' type value containing a non-negative integer component
that may be followed by an exponent part. <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="Metric: Delay jitter">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Delay
jitter<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/> US-ASCII
string ‘delayjitter’<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="Metric Unit:"><vspace blankLines="1"/>The unit is
microsecond.<vspace blankLines="1"/></t>
<t hangText="Metric Value Type:"><vspace blankLines="1"/>A single
'JSONumber' type value containing an integer component that may be
followed by exponent part. <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="Metric: Packet loss">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Packet
loss<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'pktloss'<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="Metric Unit:"><vspace blankLines="1"/>The unit is
percentile.<vspace blankLines="1"/></t>
<t hangText="Metric Value Type:"><vspace blankLines="1"/>A single
number value containing an integer component that may be followed by
a fraction part and/or an exponent part. <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="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="Cost Metric name:"><vspace blankLines="1"/>Hop
count<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'hopcount'<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="Metric Unit:"><vspace blankLines="1"/>The unit is
integer number.<vspace blankLines="1"/></t>
<t hangText="Metric Value Type:"><vspace blankLines="1"/>A single
'JSONNumber' type value containing an integer component. <vspace
blankLines="1"/></t>
</list></t>
<t>Example:</t>
<t>TBA</t>
</section>
<section title="Metric: Bandwidth">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace
blankLines="1"/>Bandwidth<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'bw'<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="Metric Unit:"><vspace blankLines="1"/>The units are
bytes per second.<vspace blankLines="1"/></t>
<t hangText="Metric Value Type:"><vspace blankLines="1"/>A single
'JSONNumber' type value containing an integer component , which may
be followed by a fraction part and/or an exponent part. <vspace
blankLines="1"/></t>
</list></t>
</section>
<section title="Metric: Maximum Bandwidth">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Maximum
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'maxbandwidth'<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 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 context
interval. <vspace blankLines="1"/></t>
<t hangText=" Metric Unit and Metric Value Type:"><vspace
blankLines="1"/>See definition for the Bandwidth Cost Metric.<vspace
blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 4: 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="Metric: Maximum Reserved Bandwdith">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Maximum
Reserved Bandwidth<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'maxrvbw'<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal maximum reserved bandwidth 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="Metric Unit and Value Type:"><vspace blankLines="1"/>
See definition of the Bandwidth Cost Metric. <vspace
blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 5: 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="Metric: Unavailable Reserved Bandwidth">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Unavailable
Reserved Bandwidth<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'unresbw'<vspace blankLines="1"/></t>
<t hangText="Metric Description:"><vspace blankLines="1"/>To specify
spatial and temporal unavailable reserved 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.
[yry: Give details] 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="Metric Unit and Value Type:"><vspace
blankLines="1"/>See definition for the bandwidth Cost Metric.<vspace
blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 6: 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="Metric: Residue Bandwidth">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Residue
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'residubw'<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 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="Metric Unit and Value Type:"><vspace blankLines="1"/>
See definition of the general Bandwidth.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 7: 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="Metric: Available Bandwidth">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Available
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'availbw'<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 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="Metric Unit and Value Type:"><vspace blankLines="1"/>
See definition of the general Bandwidth.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 8: availbw value on source-destination endpoint pairs
GET /directory HTTP/1.1
Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 2333
Content-Type: application/alto-directory+json
{
"meta" : {
"cost-types": {
"calendaring-bw": { [YRY: Not use calendaring??]
"cost-mode" : "calendaring",
"cost-metric": "Availbandwidth",
"description": {"interval":mm/hh,"duration":mm/hh/dd/mm,
"start":mm/hh/dd/mm}
},
"resources" : {
"endpoint-cost" : {
"uri" : "http://alto.example.com/endpointcost/lookup",
"media-type" : "application/alto-endpointcost+json",
"accepts" : "application/alto-endpointcostparams+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "calendaring-bw"]
}
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": "calendaring",
"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": "calendaring",
"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="Metric: Utilized Bandwidth">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace blankLines="1"/>Utilized
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Cost Metric string:"><vspace blankLines="1"/>US-ASCII
string 'utilbw'<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 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="Metric Unit and Value Type:"><vspace blankLines="1"/>
See definition of the general Bandwidth.<vspace blankLines="1"/></t>
</list></t>
<figure>
<artwork>
Example 9: 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 |
| | jitter | [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>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D.Crocker" initials="D." surname="Crocker">
<organization/>
</author>
<date month="January" year="2008"/>
</front>
<seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor="RFC4627">
<front>
<title>The application/json Media Type for JavaScript Object
Notation (JSON)</title>
<author fullname="D. Crockford" initials="D." surname="Crockford">
<organization/>
</author>
<date month="July" year="2006"/>
</front>
<seriesInfo name="RFC" value="4627"/>
</reference>
<reference anchor="ALTO">
<front>
<title>ALTO Protocol</title>
<author fullname="R. Alimi" initials="R." surname="Alimi">
<organization/>
</author>
<date month="May" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-ietf-alto-protocol-16"/>
</reference>
<reference anchor="OSPF-TE">
<front>
<title>OSPF Traffic Engineering (TE) Metric Extensions</title>
<author fullname="S. Giacalone" initials="S." surname="Giacalone">
<organization/>
</author>
<date month="June" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-ietf-ospf-te-metric-extensions-04"/>
</reference>
<reference anchor="ISIS-TE">
<front>
<title>ISIS Traffic Engineering (TE) Metric Extensions</title>
<author fullname="S. Giacalone" initials="S." surname="Giacalone">
<organization/>
</author>
<date month="October" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-ietf-isis-te-metric-extensions-01"/>
</reference>
<reference anchor="BGP-LS">
<front>
<title>North-Bound Distribution of Link-State and TE Information
using BGP</title>
<author fullname="H.Gredler" initials="H." surname="Gredler">
<organization/>
</author>
<date month="May" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-ietf-idr-ls-distribution-03"/>
</reference>
<reference anchor="BGP-PM">
<front>
<title>BGP attribute for North-Bound Distribution of Traffic
Engineering (TE) performance Metrics</title>
<author fullname="Q.Wu" initials="Q." surname="Wu">
<organization/>
</author>
<date month="October" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-wu-idr-te-pm-bgp-02"/>
</reference>
</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>
<reference anchor="ALTO-DEPLOYMENT">
<front>
<title>ALTO Deployment Considerations</title>
<author fullname="M.Stiemerling" initials="M." surname="Stiemerling">
<organization/>
</author>
<author fullname="S. Kiesel" initials="S." surname="Kiesel">
<organization/>
</author>
<author fullname="S. Previdi" initials="S." surname="Previdi">
<organization/>
</author>
<author fullname="M. Scharf" initials="M." surname="Scharf">
<organization/>
</author>
<date month="October" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-ietf-alto-deployments-08"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:25:34 |