One document matched: draft-wu-alto-te-metrics-01.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-01" 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></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>
</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>In this document, we define eleven Cost Metrics, extending the base
ALTO protocol [ALTO], which has defined only a single Cost Metric, i.e.,
the generic "routingcost" metric (Sec. 14.2 of ALTO base specification
[ALTO]).</t>
<t>The Cost Metrics that we define in this document focus on traffic
engineering. Additional metrics may be defined in other documents. In
particular, the Cost Metrics that we define in this document can be
gathered from routing systems; [RFC3630], [RFC3784], [OSPF-TE],
[ISIS-TE], [BGP-LS] and [BGP-PM] define mechanisms that allow an ALTO
Server to retrieve and derive the necessary information to provide the
metrics that we define in this document.</t>
<t>Note that the metrics 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>
<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>The definitions of a set of Cost Metrics can allow us to extend the
base protocol (e.g., allowing output and constraints use different Cost
Metrics), but such extensions are not in the scope of this document.</t>
</section>
<section title="Conventions used in this document">
<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 <xref
target="RFC2119">RFC2119</xref>.</t>
<t>Syntax specifications shown here use the augmented Backus-Naur Form
(ABNF) as described in [RFC5234], and are specified as in the base JSON
specification [RFC4627].</t>
</section>
<section title="Metric: Delay">
<t><list style="hanging">
<t hangText="Cost 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. 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. The delay is the time that the packet spends to travel from
source to destination. <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>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The delay
metric is part of ALTO information provided by ALTO server. ALTO
server may collect delay metric from routing protocol or deploy data
source to collect data to compute the delay metrics
[ALTO-DEPLOYMENT]. The data source can be either log server or OAM
system or P2P client,etc. <vspace blankLines="1" />When the delay
metric is collected from routing protocol, it is measured over a
measurement interval preconfigured by routing protocol. As described
in Section 5 of [ISIS-TE],the default measurement interval is set to
30 seconds. <vspace blankLines="1" />ALTO server may also have
additional data processing such as aggregating the results across
multiple systems, remove outliers, create additional statistics.
<vspace blankLines="1" />When the data is collected from data source
or collected from routing protocol, Either scheduling can be used so
that the past and present results for the delay metrics over a
period of time are recorded, e.g., measured every hours and
aggregated, or only the latest update is recorded. <vspace
blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute value.It 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="Metric: Delayjitter">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace
blankLines="1" />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 endhost
to endhost); 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>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
delayjitter metric is part of ALTO information provided by ALTO
server. ALTO server may collect delayjitter metric from routing
protocol or deploy data source to collect data to compute the delay
metrics [ALTO-DEPLOYMENT]. The data source can be either log server
or OAM system or P2P client, etc. <vspace blankLines="1" />When the
delayjitter metric is collected from routing protocol, it is
measured over a measurement interval preconfigured by routing
protocol. As described in Section 5 of [ISIS-TE], the default
measurement interval is set to 30 seconds. <vspace
blankLines="1" />ALTO server may also have additional data
processing such as aggregating the results across multiple systems,
remove outliers, create additional statistics. <vspace
blankLines="1" />When the data is collected from data source or
collected from routing protocol, either scheduling can be used so
that the past and present results for the delayjitter metrics over a
period of time can be recorded, e.g., measured every hours,or only
measure the latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute value.It 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 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: Pktloss">
<t><list style="hanging">
<t hangText="Cost Metric name:"><vspace
blankLines="1" />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 endhost to
endhost); 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>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
pktloss metric is part of ALTO information provided by ALTO server.
ALTO server may collect pktloss metric from routing protocol or
deploy data source to collect data to compute the delay metrics
[ALTO-DEPLOYMENT]. The data source can be either log server or OAM
system or P2P client,etc. <vspace blankLines="1" />When the pktloss
metric is collected from routing protocol, it is measured over a
measurement interval preconfigured by routing protocol. As described
in Section 5 of [ISIS-TE], the default measurement interval is set
to 30 seconds. <vspace blankLines="1" />ALTO server may also have
additional data processing such as aggregating the results across
multiple systems, remove outliers, create additional statistics.
<vspace blankLines="1" />When the data is collected from data source
or collected from routing protocol, either scheduling can be used so
that the past and present results for this metric over a period of
time can be recorded, e.g.,measured every hours,or only measure the
latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute value. It 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 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: Hopcount">
<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" />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>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute value. It 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>
</section>
<section title="Metric: Bandwidth">
<t><list style="hanging">
<t hangText="Cost 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" /></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 that may be
prefixed with an optional minus sign, which may be followed by a
fraction part and/or an exponent part. <vspace blankLines="1" /></t>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><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" />This is intended to be a constraint
attribute value It could be used as a cost metric constraint
attribute used 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>
</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="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:"><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 that may be
followed by an exponent part. <vspace blankLines="1" /></t>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
Maximum Bandwidth metric is gathered using [RFC3630], [RFC3784] or
[BGP-LS]. It is extended from Bandwidth cost metric and is part of
ALTO information provided by ALTO server. ALTO server may collect
Maximum Bandwidth metric from routing protocol or deploy data source
to collect data to compute the delay metrics [ALTO-DEPLOYMENT]. The
data source can be either log server or OAM system or P2P
client,etc. <vspace blankLines="1" />When the Maximum Bandwidth
metric is collected from routing protocol, it is measured over a
measurement interval preconfigured by routing protocol. As described
in Section 5 of [ISIS-TE], the default measurement interval is set
to 30 seconds. <vspace blankLines="1" />ALTO server may also have
additional data processing such as aggregating the results across
multiple systems, remove outliers, create additional statistics.
<vspace blankLines="1" />When the data is collected from data source
or collected from routing protocol, either scheduling can be used so
that the past and present results for this metric over a period of
time can be recorded, e.g.,measured every hours,or only measure the
latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute value. It 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 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="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 endhost to
endhost); 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 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 that may be
followed by an exponent part. <vspace blankLines="1" /></t>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
Maximum Reserved Bandwdith is gathered using [RFC3630], [RFC3784] or
[BGP-LS]. It is extended from Bandwidth Cost metric defined as part
of ALTO information provided by ALTO server. ALTO server may collect
Maximum Reserved Bandwdith metric from routing protocol or deploy
data source to collect data to compute the delay metrics
[ALTO-DEPLOYMENT]. The data source can be either log server or OAM
system or P2P client,etc. <vspace blankLines="1" />When the Maximum
Reserved Bandwdith metric is collected from routing protocol, it is
measured over a measurement interval preconfigured by routing
protocol. As described in Section 5 of [ISIS-TE], the default
measurement interval is set to 30 seconds. <vspace
blankLines="1" />ALTO server may also have additional data
processing such as aggregating the results across multiple systems,
remove outliers, create additional statistics. <vspace
blankLines="1" />When the data is collected from data source or
collected from routing protocol, either scheduling can be used so
that the past and present results for this metric over a period of
time can be recorded, e.g.,measured every hours,or only measure the
latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute value. It 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 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="Metric Description:"><vspace blankLines="1" />To
specify spatial and temporal unavailable reserved 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" /></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
'JSONArray' type with each value containing an integer component
that may be followed by an exponent part. <vspace
blankLines="1" /></t>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
Unavailable Reserved Bandwidth metric is gathered using [RFC3630],
[RFC3784] or [BGP-LS]. It is extended from Bandwidth Cost metric and
defined as part of ALTO information provided by ALTO server. ALTO
server may collect Unavailable Reserved Bandwidth metric from
routing protocol or deploy data source to collect data to compute
the delay metrics [ALTO-DEPLOYMENT]. The data source can be either
log server or OAM system or P2P client,etc. <vspace
blankLines="1" />When the Unavailable Reserved Bandwidth metric is
collected from routing protocol, it is measured over a measurement
interval preconfigured by routing protocol. As described in Section
5 of [ISIS-TE],the default measurement interval is set to 30
seconds. <vspace blankLines="1" />ALTO server may also have
additional data processing such as aggregating the results across
multiple systems, remove outliers, create additional statistics.
<vspace blankLines="1" />When the data is collected from data source
or collected from routing protocol, either scheduling can be used so
that the past and present results for this metric over a period of
time can be recorded, e.g.,measured every hours,or only measure the
latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute values. The values correspond
to the bandwidth that can be reserved with a setup priority of 0
through 7. It 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 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="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 endhost to endhost); 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 units are
bytes per second.<vspace blankLines="1" /></t>
<t hangText="Metric Value Type:"><vspace blankLines="1" />A single
'JSONArray' type with each value containing an integer component
that may be followed by an exponent part. <vspace
blankLines="1" /></t>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
Residue Bandwidth metric is gathered using [OSPF-TE], [ISIS-TE] or
[BGP-PM]. It is extended from Bandwidth Cost metric and is part of
ALTO information provided by ALTO server. ALTO server may collect
Residue Bandwidth metric from routing protocol or deploy data source
to collect data to compute the delay metrics [ALTO-DEPLOYMENT]. The
data source can be either log server or OAM system or P2P
client,etc. <vspace blankLines="1" />When the Residue Bandwidth
metric is collected from routing protocol, it is measured over a
measurement interval preconfigured by routing protocol. As described
in Section 5 of [ISIS-TE],the default measurement interval is set to
30 seconds. <vspace blankLines="1" />ALTO server may also have
additional data processing such as aggregating the results across
multiple systems, remove outliers, create additional statistics.
<vspace blankLines="1" />When the data is collected from data source
or collected from routing protocol, either scheduling can be used so
that the past and present results for this metric over a period of
time can be recorded, e.g.,measured every hours,or only measure the
latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute values. The values correspond
to the bandwidth that can be reserved with a setup priority of 0
through 7. It 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 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="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 endhost to endhost); 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 units are
bytes per second.<vspace blankLines="1" /></t>
<t hangText="Metric Value Type:"><vspace blankLines="1" />A single
'JSONArray' type with each value containing an integer component
that may be followed by an exponent part. <vspace
blankLines="1" /></t>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
Available Bandwidth metric is gathered using [OSPF-TE], [ISIS-TE] or
[BGP- PM]. It is extended from Bandwidth Cost metric and is part of
ALTO information provided by ALTO server. ALTO server may collect
Available Bandwidth metric from routing protocol or deploy data
source to collect data to compute the delay metrics
[ALTO-DEPLOYMENT]. The data source can be either log server or OAM
system or P2P client,etc. <vspace blankLines="1" />When the
Available Bandwidth metric is collected from routing protocol, it is
measured over a measurement interval preconfigured by routing
protocol. As described in Section 5 of [ISIS-TE],the default
measurement interval is set to 30 seconds. <vspace
blankLines="1" />ALTO server may also have additional data
processing such as aggregating the results across multiple systems,
remove outliers, create additional statistics. <vspace
blankLines="1" />When the data is collected from data source or
collected from routing protocol, either scheduling can be used so
that the past and present results for this metric over a period of
time can be recorded, e.g.,measured every hours,or only measure the
latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute values. The values correspond
to the bandwidth that can be reserved with a setup priority of 0
through 7. It 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 8: 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": "numerical",
"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": "numerical",
"cost-metric": "availbw"
}
},
"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: Utilized Bandwidth">
<t><list style="hanging">
<t hangText="Cost 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 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="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
'JSONArray' type with each value containing an integer component
that may be followed by an exponent part. <vspace
blankLines="1" /></t>
<t hangText="Cost Mode:"><vspace blankLines="1" />A Cost Mode is
encoded as a US-ASCII string. The string MUST either have the value
'numerical' or 'ordinal'. <vspace blankLines="1" /></t>
<t hangText="Collection Method:"><vspace blankLines="1" />The
Utilized Bandwidth metric is gathered using [OSPF-TE], [ISIS-TE] or
[BGP-PM]. It is extended from bandwidth cost metric and is part of
ALTO information provided by ALTO server. ALTO server may collect
Utilized Bandwidth metric from routing protocol or deploy data
source to collect data to compute the delay metrics
[ALTO-DEPLOYMENT]. The data source can be either log server or OAM
system or P2P client,etc. <vspace blankLines="1" />When The Utilized
Bandwidth metric is collected from routing protocol, it is measured
over a measurement interval preconfigured by routing protocol. As
described in Section 5 of [ISIS-TE],the default measurement interval
is set to 30 seconds. <vspace blankLines="1" />ALTO server may also
have additional data processing such as aggregating the results
across multiple systems, remove outliers, create additional
statistics. <vspace blankLines="1" />When the data is collected from
data source or collected from routing protocol, either scheduling
can be used so that the past and present results for this metric
over a period of time can be recorded, e.g.,measured every hours,or
only measure the latest update. <vspace blankLines="1" /></t>
<t hangText="ALTO Sample interval:"><vspace blankLines="1" />The
ALTO Server may collect values from the sources measurements done
e.g. every second over a period of 30 seconds. The ALTO Server may
then aggregate these values over ALTO Sample intevals of at least 30
seconds and provide updates every hour. <vspace
blankLines="1" /></t>
<t hangText="Use and Applications:"><vspace blankLines="1" />This is
intended to be a constraint attribute values. The values correspond
to the bandwidth that can be reserved with a setup priority of 0
through 7. It 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 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></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></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></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></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></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></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></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></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></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></organization>
</author>
<author fullname="S. Kiesel" initials="S." surname="Kiesel">
<organization></organization>
</author>
<author fullname="S. Previdi" initials="S." surname="Previdi">
<organization></organization>
</author>
<author fullname="M. Scharf" initials="M." surname="Scharf">
<organization></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:23:51 |