< draft-previdi-isis-te-metric-extensions-02.txt   draft-previdi-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: April 11, 2013 Thomson Reuters Expires: August 29, 2013 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.
October 08, 2012 February 25, 2013
IS-IS Traffic Engineering (TE) Metric Extensions IS-IS Traffic Engineering (TE) Metric Extensions
draft-previdi-isis-te-metric-extensions-02 draft-previdi-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 TE [RFC5305] such that
network performance information can be distributed and collected in a network performance information can be distributed and collected in a
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 April 11, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . . 4 2. TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . . 4
3. Interface and Neighbor Addresses . . . . . . . . . . . . . . . 6 3. Interface and Neighbor Addresses . . . . . . . . . . . . . . . 6
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. Unidirectional Delay Variation Sub-TLV . . . . . . . . . . 7 4.2. Unidirectional Delay Variation Sub-TLV . . . . . . . . . . 7
4.3. Unidirectional Link Loss Sub-TLV . . . . . . . . . . . . . 8 4.3. Unidirectional Link Loss Sub-TLV . . . . . . . . . . . . . 8
4.4. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 8 4.4. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 9
4.5. Unidirectional Available Bandwidth Sub-TLV . . . . . . . . 9 4.5. Unidirectional Available Bandwidth Sub-TLV . . . . . . . . 10
5. Announcement Thresholds and Filters . . . . . . . . . . . . . 10 5. Announcement Thresholds and Filters . . . . . . . . . . . . . 10
6. Announcement Suppression . . . . . . . . . . . . . . . . . . . 11 6. Announcement Suppression . . . . . . . . . . . . . . . . . . . 11
7. Network Stability and Announcement Periodicity . . . . . . . . 11 7. Network Stability and Announcement Periodicity . . . . . . . . 11
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network
performance information (e.g. latency) is becoming as critical to
data path selection as other metrics.
In these networks, extremely large amounts of money rest on the
ability to access market data in "real time" and to predictably make
trades faster than the competition. Because of this, using metrics
such as hop count or cost as routing metrics is becoming only
tangentially important. Rather, it would be beneficial to be able to
make path selection decisions based on performance data (such as
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, and as link delay, delay variation, packet loss, residual bandwidth, and
available bandwidth). available bandwidth).
The data distributed by IS-IS TE Metric Extensions is meant to be In certain networks, such as, but not limited to, financial
used as part of the operation of the routing protocol (e.g. by information networks (e.g. stock market data providers), network
replacing cost with latency or considering bandwidth as well as performance information (e.g. latency) is becoming as critical to
cost), by enhancing CSPF, or for other uses such as supplementing the data path selection as other metrics.
data used by an Alto server [I-D.ietf-alto-protocol]. With respect
to CSPF, the data distributed by IS-IS TE Metric Extensions can be The data distributed by the TE Metric Extensions proposed in this
used to setup, fail over, and fail back data paths using protocols document is meant to be used as part of the operation of the routing
such as RSVP-TE [RFC3209]. protocol (e.g. by replacing cost with latency or considering
bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or
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
by ISIS TE Metric Extensions can be used to setup, fail over, and
fail back data paths using protocols such as RSVP-TE [RFC3209];
[I-D.atlas-mpls-te-express-path] describes some methods for using
this information to compute Label Switched Paths (LSPs) at the LSP
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. is distributed are outside the scope of this document. Example
mechanisms to measure latency, delay variation, and loss in an MPLS
network are given in [RFC6374]. While this document does not specify
how the performance information should be obtained, the measurement
of delay SHOULD NOT vary significantly based upon the offered traffic
load. Thus, queuing delays SHOULD NOT be included in the delay
measurement. For links, such as Forwarding Adjacencies, care must be
taken that measurement of the associated delay avoids significant
queuing delay; that could be accomplished in a variety of ways,
including either by measuring with a traffic class that experiences
minimal queuing or by summing the measured link delays of the
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-ISN reachability information TLV 141 (defined in [RFC5316]) and MT-ISN
skipping to change at page 5, line 19 skipping to change at page 5, line 25
TBD2 Unidirectional Delay Variation TBD2 Unidirectional Delay Variation
TBD3 Unidirectional Packet Loss TBD3 Unidirectional Packet Loss
TBD4 Unidirectional Residual Bandwidth Sub TLV TBD4 Unidirectional Residual Bandwidth Sub TLV
TBD5 Unidirectional Available Bandwidth Sub TLV TBD5 Unidirectional Available Bandwidth Sub TLV
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 6, line 40 skipping to change at page 7, line 8
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 |A| RESERVED | Delay | | Type | Length |A| RESERVED | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay | | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV has a type of TBD1. This sub-TLV has a type of TBD1.
The length is 4. The length is 4.
Where: Where:
"A" represents the Anomalous (A) bit. The A bit is set when the "A" represents the Anomalous (A) bit. The A bit is set when the
skipping to change at page 11, line 20 skipping to change at page 11, line 34
When link performance average values change, but fall under the When link performance average values change, but fall under the
threshold that would cause the announcement of a sub-TLV with the A threshold that would cause the announcement of a sub-TLV with the A
bit set, implementations MAY suppress or throttle sub-TLV bit set, implementations MAY suppress or throttle sub-TLV
announcements. All suppression features and thresholds SHOULD be announcements. All suppression features and thresholds SHOULD be
configurable. configurable.
7. Network Stability and Announcement Periodicity 7. Network Stability and Announcement Periodicity
To mitigate concerns about stability, all values (except residual To mitigate concerns about stability, all values (except residual
bandwidth) MUST be calculated as rolling averages where the averaging bandwidth) MUST NOT be instantaneous measurements. The period to
period MUST be a configurable period of time, rather than compute statistics, whether rolling average, rolling 98th percentile,
instantaneous measurements. or network custom, MUST be a configurable period of time.
Announcements MUST also be able to be throttled using configurable Announcements MUST also be able to be throttled using configurable
inter-update throttle timers. The minimum announcement periodicity inter-update throttle timers. The minimum announcement periodicity
is 1 announcement per second. is 1 announcement per second.
8. Compatibility 8. Compatibility
As per [RFC5305], unrecognized Sub-TLVs should be silently ignored As per [RFC5305], unrecognized Sub-TLVs should be silently ignored
9. Security Considerations 9. Security Considerations
skipping to change at page 12, line 47 skipping to change at page 13, line 13
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, [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
"Traffic Engineering Extensions to OSPF Version 3", "Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, September 2008. 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
Measurement for MPLS Networks", RFC 6374, September 2011.
12.2. Informative References 12.2. Informative References
[I-D.atlas-mpls-te-express-path]
Atlas, A., Drake, J., Giacalone, S., Ward, D., Previdi,
S., and C. Filsfils, "Performance-based Path Selection for
Explicitly Routed LSPs",
draft-atlas-mpls-te-express-path-02 (work in progress),
February 2013.
[I-D.ietf-alto-protocol] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-13 (work in progress), draft-ietf-alto-protocol-13 (work in progress),
September 2012. September 2012.
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay
Measurement Profile for MPLS-Based Transport Networks", Measurement Profile for MPLS-Based Transport Networks",
RFC 6375, September 2011. RFC 6375, September 2011.
Authors' Addresses Authors' Addresses
 End of changes. 16 change blocks. 
43 lines changed or deleted 58 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/