< draft-ietf-isis-te-metric-extensions-02.txt   draft-ietf-isis-te-metric-extensions-03.txt >
Networking Working Group S. Previdi, Ed. Networking Working Group S. Previdi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Giacalone Intended status: Standards Track S. Giacalone
Expires: October 25, 2014 Thomson Reuters Expires: October 27, 2014 Thomson Reuters
D. Ward D. Ward
Cisco Systems, Inc. Cisco Systems, Inc.
J. Drake J. Drake
A. Atlas A. Atlas
Juniper Networks Juniper Networks
C. Filsfils C. Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Q. Wu Q. Wu
Huawei Huawei
April 23, 2014 April 25, 2014
IS-IS Traffic Engineering (TE) Metric Extensions IS-IS Traffic Engineering (TE) Metric Extensions
draft-ietf-isis-te-metric-extensions-02 draft-ietf-isis-te-metric-extensions-03
Abstract Abstract
In certain networks, such as, but not limited to, financial In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network information networks (e.g. stock market data providers), network
performance criteria (e.g. latency) are becoming as critical to data performance criteria (e.g. latency) are becoming as critical to data
path selection as other metrics. path selection as other metrics.
This document describes extensions to IS-IS TE (RFC5305) such that This document describes extensions to IS-IS Traffic Engineering
network performance information can be distributed and collected in a Extensions (RFC5305) such that network performance information can be
scalable fashion. The information distributed using ISIS TE Metric distributed and collected in a scalable fashion. The information
Extensions can then be used to make path selection decisions based on distributed using ISIS TE Metric Extensions can then be used to make
network performance. path selection decisions based on network performance.
Note that this document only covers the mechanisms with which network Note that this document only covers the mechanisms with which network
performance information is distributed. The mechanisms for measuring performance information is distributed. The mechanisms for measuring
network performance or acting on that information, once distributed, network performance or acting on that information, once distributed,
are outside the scope of this document. are outside the scope of this document.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2014. This Internet-Draft will expire on October 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . . 4 2. TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . . 4
3. Interface and Neighbor Addresses . . . . . . . . . . . . . . 5 3. Interface and Neighbor Addresses . . . . . . . . . . . . . . 5
4. Sub TLV Details . . . . . . . . . . . . . . . . . . . . . . . 6 4. Sub TLV Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Unidirectional Link Delay Sub-TLV . . . . . . . . . . . . 6 4.1. Unidirectional Link Delay Sub-TLV . . . . . . . . . . . . 6
4.2. Min/Max Unidirectional Link Delay Sub-TLV . . . . . . . . 7 4.2. Min/Max Unidirectional Link Delay Sub-TLV . . . . . . . . 7
4.3. Unidirectional Delay Variation Sub-TLV . . . . . . . . . 8 4.3. Unidirectional Delay Variation Sub-TLV . . . . . . . . . 8
4.4. Unidirectional Link Loss Sub-TLV . . . . . . . . . . . . 8 4.4. Unidirectional Link Loss Sub-TLV . . . . . . . . . . . . 9
4.5. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 9 4.5. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 10
4.6. Unidirectional Available Bandwidth Sub-TLV . . . . . . . 10 4.6. Unidirectional Available Bandwidth Sub-TLV . . . . . . . 11
4.7. Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . . 11 4.7. Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . . 12
5. Announcement Thresholds and Filters . . . . . . . . . . . . . 12 5. Announcement Thresholds and Filters . . . . . . . . . . . . . 13
6. Announcement Suppression . . . . . . . . . . . . . . . . . . 13 6. Announcement Suppression . . . . . . . . . . . . . . . . . . 14
7. Network Stability and Announcement Periodicity . . . . . . . 13 7. Network Stability and Announcement Periodicity . . . . . . . 14
8. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 13 8. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 14
9. Static Metric Override . . . . . . . . . . . . . . . . . . . 14 9. Static Metric Override . . . . . . . . . . . . . . . . . . . 14
10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In certain networks, such as, but not limited to, financial In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network information networks (e.g. stock market data providers), network
performance information (e.g. latency) is becoming as critical to performance information (e.g. latency) is becoming as critical to
data path selection as other metrics. data path selection as other metrics.
In these networks, extremely large amounts of money rest on the In these networks, extremely large amounts of money rest on the
ability to access market data in "real time" and to predictably make ability to access market data in "real time" and to predictably make
trades faster than the competition. Because of this, using metrics trades faster than the competition. Because of this, using metrics
such as hop count or cost as routing metrics is becoming only such as hop count or cost as routing metrics is becoming only
tangentially important. Rather, it would be beneficial to be able to tangentially important. Rather, it would be beneficial to be able to
make path selection decisions based on performance data (such as make path selection decisions based on performance data (such as
latency) in a cost-effective and scalable way. latency) in a cost-effective and scalable way.
This document describes extensions to IS-IS Extended Reachability TLV This document describes extensions to IS-IS Extended Reachability TLV
defined in [RFC5305] (hereafter called "IS-IS TE Metric Extensions"), defined in [RFC5305] (hereafter called "IS-IS TE Metric Extensions"),
that can be used to distribute network performance information (such that can be used to distribute network performance information (such
as link delay, delay variation, packet loss, residual bandwidth, as link delay, delay variation, packet loss, residual bandwidth, and
available bandwidth and utilized bandwidth). available bandwidth).
The data distributed by the TE Metric Extensions proposed in this The data distributed by the TE Metric Extensions proposed in this
document is meant to be used as part of the operation of the routing document is meant to be used as part of the operation of the routing
protocol (e.g. by replacing cost with latency or considering protocol (e.g. by replacing cost with latency or considering
bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or
for other uses such as supplementing the data used by an ALTO server for other uses such as supplementing the data used by an ALTO server
[I-D.ietf-alto-protocol]. With respect to CSPF, the data distributed [I-D.ietf-alto-protocol]. With respect to CSPF, the data distributed
by ISIS TE Metric Extensions can be used to setup, fail over, and by ISIS TE Metric Extensions can be used to setup, fail over, and
fail back data paths using protocols such as RSVP-TE [RFC3209]; fail back data paths using protocols such as RSVP-TE [RFC3209];
[I-D.atlas-mpls-te-express-path] describes some methods for using [I-D.atlas-mpls-te-express-path] describes some methods for using
skipping to change at page 4, line 8 skipping to change at page 4, line 8
ingress. ingress.
Note that the mechanisms described in this document only disseminate Note that the mechanisms described in this document only disseminate
performance information. The methods for initially gathering that performance information. The methods for initially gathering that
performance information, such as [RFC6375], or acting on it once it performance information, such as [RFC6375], or acting on it once it
is distributed are outside the scope of this document. Example is distributed are outside the scope of this document. Example
mechanisms to measure latency, delay variation, and loss in an MPLS mechanisms to measure latency, delay variation, and loss in an MPLS
network are given in [RFC6374]. While this document does not specify network are given in [RFC6374]. While this document does not specify
how the performance information should be obtained, the measurement how the performance information should be obtained, the measurement
of delay SHOULD NOT vary significantly based upon the offered traffic of delay SHOULD NOT vary significantly based upon the offered traffic
load. Thus, queuing delays and/or loss SHOULD NOT be included in any load. Thus, queuing delays SHOULD NOT be included in the delay
dynamic delay measurement. For links, such as Forwarding measurement. For links, such as Forwarding Adjacencies, care must be
Adjacencies, care must be taken that measurement of the associated taken that measurement of the associated delay avoids significant
delay avoids significant queuing delay; that could be accomplished in queuing delay; that could be accomplished in a variety of ways,
a variety of ways, including either by measuring with a traffic class including either by measuring with a traffic class that experiences
that experiences minimal queuing or by summing the measured link minimal queuing or by summing the measured link delays of the
delays of the components of the link's path. components of the link's path.
2. TE Metric Extensions to IS-IS 2. TE Metric Extensions to IS-IS
This document proposes new IS-IS TE sub-TLVs that can be announced in This document proposes new IS-IS TE sub-TLVs that can be announced in
ISIS Extended Reachability TLV (TLV-22) to distribute network ISIS Extended Reachability TLV (TLV-22) to distribute network
performance information. The extensions in this document build on performance information. The extensions in this document build on
the ones provided in IS-IS TE [RFC5305] and GMPLS [RFC4203]. the ones provided in IS-IS TE [RFC5305] and GMPLS [RFC4203].
IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS
reachability information TLV 141 (defined in [RFC5316]) and MT-IS TLV reachability information TLV 141 (defined in [RFC5316]) and MT-ISN
222 (defined in [RFC5120]) have nested sub-TLVs which permit the TLVs TLV 222 (defined in [RFC5120]) have nested sub-TLVs which permit the
to be readily extended. This document proposes several additional TLVs to be readily extended. This document proposes several
sub-TLVs: additional sub-TLVs:
Type Value Type Value
----------------------------------------------- -----------------------------------------------
TBA Unidirectional Link Delay TBA Unidirectional Link Delay
TBA Low/High Unidirectional Link Delay TBA Low/High Unidirectional Link Delay
TBA Unidirectional Delay Variation TBA Unidirectional Delay Variation
TBA Unidirectional Packet Loss TBA Unidirectional Packet Loss
TBA Unidirectional Residual Bandwidth TBA Unidirectional Residual Bandwidth
TBA Unidirectional Available Bandwidth TBA Unidirectional Available Bandwidth
TBA Unidirectional Utilized Bandwidth TBA Unidirectional Bandwidth Utilization
As can be seen in the list above, the sub-TLVs described in this As can be seen in the list above, the sub-TLVs described in this
document carry different types of network performance information. document carry different types of network performance information.
Many (but not all) of the sub-TLVs include a bit called the Anomalous The new sub-TLVs include a bit called the Anomalous (or "A") bit.
(or "A") bit. When the A bit is clear (or when the sub-TLV does not When the A bit is clear (or when the sub-TLV does not include an A
include an A bit), the sub-TLV describes steady state link bit), the sub-TLV describes steady state link performance. This
performance. This information could conceivably be used to construct information could conceivably be used to construct a steady state
a steady state performance topology for initial tunnel path performance topology for initial tunnel path computation, or to
computation, or to verify alternative failover paths. verify alternative failover paths.
When network performance violates configurable link-local thresholds When network performance violates configurable link-local thresholds
a sub-TLV with the A bit set is advertised. These sub-TLVs could be a sub-TLV with the A bit set is advertised. These sub-TLVs could be
used by the receiving node to determine whether to fail traffic to a used by the receiving node to determine whether to fail traffic to a
backup path, or whether to calculate an entirely new path. From an backup path, or whether to calculate an entirely new path. From an
MPLS perspective, the intent of the A bit is to permit LSP ingress MPLS perspective, the intent of the A bit is to permit LSP ingress
nodes to: nodes to:
A) Determine whether the link referenced in the sub-TLV affects any A) Determine whether the link referenced in the sub-TLV affects any
of the LSPs for which it is ingress. If there are, then: of the LSPs for which it is ingress. If there are, then:
skipping to change at page 5, line 33 skipping to change at page 5, line 33
If link performance then improves beyond a configurable minimum value If link performance then improves beyond a configurable minimum value
(reuse threshold), that sub-TLV can be re-advertised with the (reuse threshold), that sub-TLV can be re-advertised with the
Anomalous bit cleared. In this case, a receiving node can Anomalous bit cleared. In this case, a receiving node can
conceivably do whatever re-optimization (or failback) it wishes to do conceivably do whatever re-optimization (or failback) it wishes to do
(including nothing). (including nothing).
Note that when a sub-TLV does not include the A bit, that sub-TLV Note that when a sub-TLV does not include the A bit, that sub-TLV
cannot be used for failover purposes. The A bit was intentionally cannot be used for failover purposes. The A bit was intentionally
omitted from some sub-TLVs to help mitigate oscillations. See omitted from some sub-TLVs to help mitigate oscillations. See
Section 7 for more information. Section 5 for more information.
Consistent with existing IS-IS TE specifications [RFC5305], the Consistent with existing IS-IS TE specifications [RFC5305], the
bandwidth advertisements defined in this draft MUST be encoded as bandwidth advertisements defined in this draft MUST be encoded as
IEEE floating point values. The delay and delay variation IEEE floating point values. The delay and delay variation
advertisements defined in this draft MUST be encoded as integer advertisements defined in this draft MUST be encoded as integer
values. Delay values MUST be quantified in units of microseconds, values. Delay values MUST be quantified in units of microseconds,
packet loss MUST be quantified as a percentage of packets sent, and packet loss MUST be quantified as a percentage of packets sent, and
bandwidth MUST be sent as bytes per second. All values (except bandwidth MUST be sent as bytes per second. All values (except
residual bandwidth) MUST be calculated as rolling averages where the residual bandwidth) MUST be calculated as rolling averages where the
averaging period MUST be a configurable period of time. See averaging period MUST be a configurable period of time. See
Section 5 for more information. Section 5 for more information.
3. Interface and Neighbor Addresses 3. Interface and Neighbor Addresses
The use of TE Metric Extensions sub-TLVs is not confined to the TE The use of TE Metric Extensions SubTLVs is not confined to the TE
context. In other words, IS-IS TE Metric Extensions sub-TLVs defined context. In other words, IS-IS TE Metric Extensions SubTLVs defined
in this document can also be used for computing paths in the absence in this document can also be used for computing paths in the absence
of a TE subsystem. of a TE subsystem.
However, as for the TE case, Interface Address and Neighbor Address However, as for the TE case, Interface Address and Neighbor Address
sub-TLVs (IPv4 or IPv6) MUST be present. The encoding is defined in SubTLVs (IPv4 or IPv6) MUST be present. The encoding is defined in
[RFC5305] for IPv4 and in [RFC6119] for IPv6. [RFC5305] for IPv4 and in [RFC6119] for IPv6.
4. Sub TLV Details 4. Sub TLV Details
4.1. Unidirectional Link Delay Sub-TLV 4.1. Unidirectional Link Delay Sub-TLV
This sub-TLV advertises the average link delay between two directly This sub-TLV advertises the average link delay between two directly
connected IS-IS neighbors. The delay advertised by this sub-TLV MUST connected IS-IS neighbors. The delay advertised by this sub-TLV MUST
be the delay from the local neighbor to the remote one (i.e. the be the delay from the local neighbor to the remote one (i.e. the
forward path latency). The format of this sub-TLV is shown in the forward path latency). The format of this sub-TLV is shown in the
following diagram: following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Delay | |A| RESERVED | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 1
Type: TBA Type: TBA
Length: 4 Length: 4
A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when the measured value of this parameter exceeds its configured when the measured value of this parameter exceeds its configured
maximum threshold. The A bit is cleared when the measured value maximum threshold. The A bit is cleared when the measured value
falls below its configured reuse threshold. If the A-bit is clear, falls below its configured reuse threshold. If the A-bit is clear,
the sub-TLV represents steady state link performance. the sub-TLV represents steady state link performance.
skipping to change at page 7, line 25 skipping to change at page 7, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Low Delay | |A| RESERVED | Low Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | High Delay | | RESERVED | High Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 2
Type: TBA Type: TBA
Length: 8 Length: 8
A-bit. The A-bit represents the Anomalous (A) bit. The A bit is set A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when one or more measured values exceed a configured maximum when the measured value of this parameter exceeds its configured
threshold. The A bit is cleared when the measured value falls below maximum threshold. The A bit is cleared when the measured value
its configured reuse threshold. If the A bit is clear, the sub-TLV falls below its configured reuse threshold. If the A-bit is clear,
represents steady state link performance. the sub-TLV represents steady state link performance.
RESERVED. This field is reserved for future use. It MUST be set to RESERVED. This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Low Delay. This 24-bit field carries minimum measured link delay Low Delay. This 24-bit field carries minimum measured link delay
value (in microseconds) over a configurable interval, encoded as an value (in microseconds) over a configurable interval, encoded as an
integer value. integer value.
High Delay. This 24-bit field carries the maximum measured link High Delay. This 24-bit field carries the maximum measured link
delay value (in microseconds) over a configurable interval, encoded delay value (in microseconds) over a configurable interval, encoded
skipping to change at page 8, line 17 skipping to change at page 8, line 19
larger. larger.
4.3. Unidirectional Delay Variation Sub-TLV 4.3. Unidirectional Delay Variation Sub-TLV
This sub-TLV advertises the average link delay variation between two This sub-TLV advertises the average link delay variation between two
directly connected IS-IS neighbors. The delay variation advertised directly connected IS-IS neighbors. The delay variation advertised
by this sub-TLV MUST be the delay from the local neighbor to the by this sub-TLV MUST be the delay from the local neighbor to the
remote one (i.e. the forward path latency). The format of this sub- remote one (i.e. the forward path latency). The format of this sub-
TLV is shown in the following diagram: TLV is shown in the following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay Variation | |A| RESERVED | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 3
Type: TBA. Type: TBA.
Lenght: 4. Lenght: 4.
A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when the measured value of this parameter exceeds its configured
maximum threshold. The A bit is cleared when the measured value
falls below its configured reuse threshold. If the A-bit is clear,
the sub-TLV represents steady state link performance.
RESERVED. This field is reserved for future use. It MUST be set to RESERVED. This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Delay Variation. This 24-bit field carries the average link delay Delay Variation. This 24-bit field carries the average link delay
variation over a configurable interval in micro-seconds, encoded as variation over a configurable interval in micro-seconds, encoded as
an integer value. When set to 0, it has not been measured. When set an integer value. When set to 0, it has not been measured. When set
to the maximum value 16,777,215 (16.777215 sec), then the delay is at to the maximum value 16,777,215 (16.777215 sec), then the delay is at
least that value and may be larger. least that value and may be larger.
4.4. Unidirectional Link Loss Sub-TLV 4.4. Unidirectional Link Loss Sub-TLV
This sub-TLV advertises the loss (as a packet percentage) between two This sub-TLV advertises the loss (as a packet percentage) between two
directly connected IS-IS neighbors. The link loss advertised by this directly connected IS-IS neighbors. The link loss advertised by this
sub-TLV MUST be the packet loss from the local neighbor to the remote sub-TLV MUST be the packet loss from the local neighbor to the remote
one (i.e. the forward path loss). The format of this sub-TLV is one (i.e. the forward path loss). The format of this sub-TLV is
shown in the following diagram: shown in the following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Link Loss | |A| RESERVED | Link Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV has a type of TBD3.
The length is 4.
where: where:
Type: TBA. Type: TBA.
Length: 4. Length: 4.
A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when the measured value of this parameter exceeds its configured when the measured value of this parameter exceeds its configured
maximum threshold. The A bit is cleared when the measured value maximum threshold. The A bit is cleared when the measured value
falls below its configured reuse threshold. If the A-bit is clear, falls below its configured reuse threshold. If the A-bit is clear,
the sub-TLV represents steady state link performance. the sub-TLV represents steady state link performance.
A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when the measured value of this parameter exceeds its configured
maximum threshold. The A bit is cleared when the measured value
falls below its configured reuse threshold. If the A-bit is clear,
the sub-TLV represents steady state link performance.
RESERVED. This field is reserved for future use. It MUST be set to RESERVED. This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Link Loss. This 24-bit field carries link packet loss as a Link Loss. This 24-bit field carries link packet loss as a
percentage of the total traffic sent over a configurable interval. percentage of the total traffic sent over a configurable interval.
The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This
value is the highest packet loss percentage that can be expressed value is the highest packet loss percentage that can be expressed
(the assumption being that precision is more important on high speed (the assumption being that precision is more important on high speed
links than the ability to advertise loss rates greater than this, and links than the ability to advertise loss rates greater than this, and
that high speed links with over 50% loss are unusable). Therefore, that high speed links with over 50% loss are unusable). Therefore,
measured values that are larger than the field maximum SHOULD be measured values that are larger than the field maximum SHOULD be
encoded as the maximum value. When set to a value of all 1s (2^24 - encoded as the maximum value. When set to a value of all 1s (2^24 -
1), the link packet loss has not been measured. 1), the link packet loss has not been measured.
4.5. Unidirectional Residual Bandwidth Sub-TLV 4.5. Unidirectional Residual Bandwidth Sub-TLV
This sub-TLV advertises the residual bandwidth between two directly This TLV advertises the residual bandwidth between two directly
connected IS-IS neighbors. The residual bandwidth advertised by this connected IS-IS neighbors. The residual bandwidth advertised by this
sub-TLV MUST be the residual bandwidth from the system originating sub-TLV MUST be the residual bandwidth from the system originating
this sub-TLV to its neighbor. The format of this sub-TLV is shown in the LSA to its neighbor.
the following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Residual Bandwidth | | Residual Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: TBA. Type: TBA.
Length: 4. Length: 4.
A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when the measured value of this parameter exceeds its configured
maximum threshold. The A bit is cleared when the measured value
falls below its configured reuse threshold. If the A-bit is clear,
the sub-TLV represents steady state link performance.
RESERVED. This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received.
Residual Bandwidth. This field carries the residual bandwidth on a Residual Bandwidth. This field carries the residual bandwidth on a
link, forwarding adjacency [RFC4206], or bundled link in IEEE link, forwarding adjacency [RFC4206], or bundled link in IEEE
floating point format with units of bytes per second. For a link or floating point format with units of bytes per second. For a link or
forwarding adjacency, residual bandwidth is defined to be Maximum forwarding adjacency, residual bandwidth is defined to be Maximum
Bandwidth [RFC3630] minus the bandwidth currently allocated to RSVP- Bandwidth [RFC3630] minus the bandwidth currently allocated to RSVP-
TE LSPs. For a bundled link, residual bandwidth is defined to be the TE LSPs. For a bundled link, residual bandwidth is defined to be the
sum of the component link residual bandwidths. sum of the component link residual bandwidths.
The calculation of Residual Bandwidth is different than that of The calculation of Residual Bandwidth is different than that of
Unreserved Bandwidth [RFC3630]. Residual Bandwidth subtracts tunnel Unreserved Bandwidth [RFC3630]. Residual Bandwidth subtracts tunnel
skipping to change at page 10, line 41 skipping to change at page 11, line 11
Unreserved Bandwidth [RFC3630], on the other hand, is subtracted from Unreserved Bandwidth [RFC3630], on the other hand, is subtracted from
the Maximum Reservable Bandwidth (the bandwidth that can the Maximum Reservable Bandwidth (the bandwidth that can
theoretically be reserved) [RFC3630] and provides per-QoS-class theoretically be reserved) [RFC3630] and provides per-QoS-class
remainders. Residual Bandwidth and Unreserved Bandwidth [RFC3630] remainders. Residual Bandwidth and Unreserved Bandwidth [RFC3630]
can be used concurrently, and each has a separate use case (e.g. the can be used concurrently, and each has a separate use case (e.g. the
former can be used for applications like Weighted ECMP while the former can be used for applications like Weighted ECMP while the
latter can be used for call admission control). latter can be used for call admission control).
4.6. Unidirectional Available Bandwidth Sub-TLV 4.6. Unidirectional Available Bandwidth Sub-TLV
This sub-TLV advertises the available bandwidth between two directly This Sub-TLV advertises the available bandwidth between two directly
connected IS-IS neighbors. The available bandwidth advertised by connected IS-IS neighbors. The available bandwidth advertised by
this sub-TLV MUST be the available bandwidth from the system this sub-TLV MUST be the available bandwidth from the system
originating this sub-TLV. The format of this sub-TLV is shown in the originating this Sub-TLV. The format of this Sub-TLV is shown in the
following diagram: following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Available Bandwidth | | Available Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 4
Type: TBA. Type: TBA.
Length: 4. Length: 4.
A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
when the measured value of this parameter exceeds its configured
maximum threshold. The A bit is cleared when the measured value
falls below its configured reuse threshold. If the A-bit is clear,
the sub-TLV represents steady state link performance.
RESERVED. This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received.
Available Bandwidth. This field carries the available bandwidth on a Available Bandwidth. This field carries the available bandwidth on a
link, forwarding adjacency, or bundled link in IEEE floating point link, forwarding adjacency, or bundled link in IEEE floating point
format with units of bytes per second. For a link or forwarding format with units of bytes per second. For a link or forwarding
adjacency, available bandwidth is defined to be residual bandwidth adjacency, available bandwidth is defined to be residual bandwidth
(see Section 4.5) minus the measured bandwidth used for the actual minus the measured bandwidth used for the actual forwarding of non-
forwarding of non- RSVP-TE LSP packets. For a bundled link, RSVP-TE LSP packets. For a bundled link, available bandwidth is
available bandwidth is defined to be the sum of the component link defined to be the sum of the component link available bandwidths
available bandwidths. minus the measured bandwidth used for the actual forwarding of non-
RSVP-TE Label Switched Paths packets. For a bundled link, available
bandwidth is defined to be the sum of the component link available
bandwidths.
4.7. Unidirectional Utilized Bandwidth Sub-TLV 4.7. Unidirectional Utilized Bandwidth Sub-TLV
This sub-TLV advertises the bandwidth utilization between two This Sub-TLV advertises the bandwidth utilization between two
directly connected IS-IS neighbors. The bandwidth utilization directly connected IS-IS neighbors. The bandwidth utilization
advertised by this sub-TLV MUST be the bandwidth from the system advertised by this sub-TLV MUST be the bandwidth from the system
originating this sub-TLV. The format of this sub-TLV is shown in the originating this Sub-TLV. The format of this Sub-TLV is shown in the
following diagram: following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Utilized Bandwidth | | Bandwidth Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Utilized Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Figure 5 Figure 5
Type: TBA. Type: TBA.
Length: 4. Length: 4.
Utilized Bandwidth. This field carries the bandwidth utilization on A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set
a link, forwarding adjacency, or bundled link in IEEE floating point when the measured value of this parameter exceeds its configured
format with units of bytes per second. For a link or forwarding maximum threshold. The A bit is cleared when the measured value
adjacency, bandwidth utilization represent the actual utilization of falls below its configured reuse threshold. If the A-bit is clear,
the link (i.e.: as measured in the router). For a bundled link, the sub-TLV represents steady state link performance.
bandwidth utilization is defined to be the sum of the component link
bandwidth utilizations. RESERVED. This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received.
Bandwidth Utilization. This field carries the bandwidth utilization
on a link, forwarding adjacency, or bundled link in IEEE floating
point format with units of bytes per second. For a link or
forwarding adjacency, bandwidth utilization represent the actual
utilization of the link (i.e.: as measured in the router). For a
bundled link, bandwidth utilization is defined to be the sum of the
component link bandwidth utilization.
5. Announcement Thresholds and Filters 5. Announcement Thresholds and Filters
The values advertised in all sub-TLVs (except Low/High delay and The values advertised in all sub-TLVs (except Low/High delay and
residual bandwidth) MUST represent an average over a period or be residual bandwidth) MUST represent an average over a period or be
obtained by a filter that is reasonably representative of an average. obtained by a filter that is reasonably representative of an average.
For example, a rolling average is one such filter. For example, a rolling average is one such filter.
Low or High delay MAY be the lowest and/or highest measured value Low or High delay MAY be the lowest and/or highest measured value
over a measurement interval or MAY make use of a filter, or other over a measurement interval or MAY make use of a filter, or other
skipping to change at page 13, line 16 skipping to change at page 14, line 12
readvertisement of a measurement within the bounds would remain readvertisement of a measurement within the bounds would remain
governed solely by the measurement interval for that sub-TLV. governed solely by the measurement interval for that sub-TLV.
6. Announcement Suppression 6. Announcement Suppression
When link performance values change by small amounts that fall under When link performance values change by small amounts that fall under
thresholds that would cause the announcement of a sub-TLV, thresholds that would cause the announcement of a sub-TLV,
implementations SHOULD suppress sub-TLV readvertisement and/or implementations SHOULD suppress sub-TLV readvertisement and/or
lengthen the period within which they are refreshed. lengthen the period within which they are refreshed.
Only the accelerated advertisement threshold mechanism described in Only the accelerated advertisement threshold mechanism may shorten
Section 5 may shorten the re-advertisement interval. the re-advertisement interval. All suppression and re-advertisement
interval backoff timer features SHOULD be configurable.
All suppression and re-advertisement interval backoff timer features
SHOULD be configurable.
7. Network Stability and Announcement Periodicity 7. Network Stability and Announcement Periodicity
Section 5 and Section 6 provide configurable mechanisms to bound the Section 5 and Section 6 provide configurable mechanisms to bound the
number of re-advertisements. Instability might occur in very large number of re-advertisements. Instability might occur in very large
networks if measurement intervals are set low enough to overwhelm the networks if measurement intervals are set low enough to overwhelm the
processing of flooded information at some of the routers in the processing of flooded information at some of the routers in the
topology. Therefore care SHOULD be taken in setting these values. topology. Therefore care SHOULD be taken in setting these values.
Additionally, the default measurement interval for all sub-TLVs Additionally, the default measurement interval for all sub-TLVs
skipping to change at page 14, line 14 skipping to change at page 15, line 7
9. Static Metric Override 9. Static Metric Override
Implementations SHOULD permit the static configuration and/or manual Implementations SHOULD permit the static configuration and/or manual
override of dynamic measurements data on a per sub-TLV, per metric override of dynamic measurements data on a per sub-TLV, per metric
basis in order to simplify migrations and to mitigate scenarios where basis in order to simplify migrations and to mitigate scenarios where
measurements are not possible across an entire network. measurements are not possible across an entire network.
10. Compatibility 10. Compatibility
As per [RFC5305], unrecognized sub-TLVs should be silently ignored. As per [RFC5305], unrecognized Sub-TLVs should be silently ignored
11. Security Considerations 11. Security Considerations
This document does not introduce security issues beyond those This document does not introduce security issues beyond those
discussed in and [RFC5305]. discussed in [RFC3630] and [RFC5329].
12. IANA Considerations 12. IANA Considerations
IANA maintains the registry for the sub-TLVs. IS-IS TE Metric IANA maintains the registry for the sub-TLVs. IS-IS TE Metric
Extensions will require one new type code per sub-TLV defined in this Extensions will require one new type code per sub-TLV defined in this
document. document.
13. Acknowledgements 13. Acknowledgements
The authors would like to recognize Ayman Soliman, Nabil Bitar, David The authors would like to recognize Ayman Soliman, Nabil Bitar, David
skipping to change at page 15, line 24 skipping to change at page 16, line 16
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008. Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008. Traffic Engineering", RFC 5316, December 2008.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
"Traffic Engineering Extensions to OSPF Version 3", RFC
5329, September 2008.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, February 2011. Engineering in IS-IS", RFC 6119, February 2011.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
14.2. Informative References 14.2. Informative References
[I-D.atlas-mpls-te-express-path] [I-D.atlas-mpls-te-express-path]
Atlas, A., Drake, J., Giacalone, S., Ward, D., Previdi, Atlas, A., Drake, J., Giacalone, S., Ward, D., Previdi,
skipping to change at page 17, line 4 skipping to change at page 17, line 35
Email: jdrake@juniper.net Email: jdrake@juniper.net
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: bill.wu@huawei.com Email: sunseawq@huawei.com
 End of changes. 53 change blocks. 
98 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/