draft-ietf-ospf-te-metric-extensions-01.txt   draft-ietf-ospf-te-metric-extensions-02.txt 
Network Working Group S. Giacalone Network Working Group S. Giacalone
Internet Draft Thomson Reuters Internet Draft Thomson Reuters
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: November 2012 D. Ward Expires: June 2013 D. Ward
Cisco Systems Cisco Systems
J. Drake J. Drake
Juniper Networks Juniper Networks
A. Atlas A. Atlas
Juniper Networks Juniper Networks
S. Previdi S. Previdi
Cisco Systems Cisco Systems
May 18, 2012 December 18, 2012
OSPF Traffic Engineering (TE) Metric Extensions OSPF Traffic Engineering (TE) Metric Extensions
draft-ietf-ospf-te-metric-extensions-01.txt draft-ietf-ospf-te-metric-extensions-02.txt
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 OSPF TE [RFC3630] such that This document describes extensions to OSPF TE [RFC3630] such that
network performance information can be distributed and collected in a network performance information can be distributed and collected in a
scalable fashion. The information distributed using OSPF TE Express scalable fashion. The information distributed using OSPF TE Metric
Path can then be used to make path selection decisions based on Extensions can then be used to make path selection decisions based on
network performance. 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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 18, 2012. This Internet-Draft will expire on June 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................4 2. Conventions used in this document..............................4
3. Express Path Extensions to OSPF TE.............................4 3. TE Metric Extensions to OSPF TE................................4
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.1.1. Type.................................................6 4.1.1. Type.................................................6
4.1.2. Length...............................................6 4.1.2. Length...............................................6
4.1.3. A bit................................................7 4.1.3. A bit................................................7
4.1.4. Reserved.............................................7 4.1.4. Reserved.............................................7
4.1.5. Delay Value..........................................7 4.1.5. Delay Value..........................................7
4.2. Unidirectional Delay Variation Sub-TLV....................7 4.2. Unidirectional Delay Variation Sub-TLV....................7
4.2.1. Type.................................................7 4.2.1. Type.................................................7
4.2.2. Length...............................................7 4.2.2. Length...............................................7
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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 OSPF TE (hereafter called "OSPF This document describes extensions to OSPF TE (hereafter called "OSPF
TE Express Path"), that can be used to distribute network performance TE Metric Extensions"), that can be used to distribute network
information (such as link delay, delay variation, packet loss, performance information (such as link delay, delay variation, packet
residual bandwidth, and available bandwidth). loss, residual bandwidth, and available bandwidth).
The data distributed by OSPF TE OSPF TE Express Path is meant to be The data distributed by OSPF TE Metric Extensions is meant to be used
used as part of the operation of the routing protocol (e.g. by as part of the operation of the routing protocol (e.g. by replacing
replacing cost with latency or considering bandwidth as well as cost with latency or considering bandwidth as well as cost), by
cost), by enhancing CSPF, or for other uses such as supplementing the enhancing CSPF, or for other uses such as supplementing the data used
data used by an Alto server [Alto]. With respect to CSPF, the data by an Alto server [Alto]. With respect to CSPF, the data distributed
distributed by OSPF TE Express Path can be used to setup, fail over, by OSPF TE Metric Extensions can be used to setup, fail over, and
and fail back data paths using protocols such as RSVP-TE [RFC3209]. fail back data paths using protocols such as RSVP-TE [RFC3209].
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 [Frost], or acting on it once it is performance information, such as [Frost], or acting on it once it is
distributed are outside the scope of this document. distributed are outside the scope of this document.
2. Conventions used in this document 2. Conventions used in this document
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
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance. interpreted as carrying RFC-2119 significance.
3. Express Path Extensions to OSPF TE 3. TE Metric Extensions to OSPF TE
This document proposes new OSPF TE sub-TLVs that can be announced in This document proposes new OSPF TE sub-TLVs that can be announced in
OSPF TE LSAs to distribute network performance information. The OSPF TE LSAs to distribute network performance information. The
extensions in this document build on the ones provided in OSPF TE extensions in this document build on the ones provided in OSPF TE
[RFC3630] and GMPLS [RFC4203]. [RFC3630] and GMPLS [RFC4203].
OSPF TE LSAs [RFC3630] are opaque LSAs [RFC5250] with area flooding OSPF TE LSAs [RFC3630] are opaque LSAs [RFC5250] with area flooding
scope. Each TLV has one or more nested sub-TLVs which permit the TE scope. Each TLV has one or more nested sub-TLVs which permit the TE
LSA to be readily extended. There are two main types of OSPF TE LSA; LSA to be readily extended. There are two main types of OSPF TE LSA;
the Router Address or Link TE LSA. Like the extensions in GMPLS the Router Address or Link TE LSA. Like the extensions in GMPLS
skipping to change at page 5, line 15 skipping to change at page 5, line 15
the Link TE LSA: the Link TE LSA:
Type Length Value Type Length Value
TBD1 4 Unidirectional Link Delay TBD1 4 Unidirectional Link Delay
TBD2 4 Unidirectional Delay Variation TBD2 4 Unidirectional Delay Variation
TBD3 4 Unidirectional Packet Loss TBD3 4 Unidirectional Packet Loss
TBD4 4 Unidirectional Residual Bandwidth Sub TLV TBD4 4 Unidirectional Residual Bandwidth
TBD5 4 Unidirectional Available Bandwidth Sub TLV TBD5 4 Unidirectional Available Bandwidth
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 Many (but not all) of the sub-TLVs include a bit called the Anomalous
(or "A") bit. When the A bit is clear (or when the sub-TLV does not (or "A") bit. When the A bit is clear (or when the sub-TLV does not
include an A bit), the sub-TLV describes steady state link include an A bit), the sub-TLV describes steady state link
performance. This information could conceivably be used to construct performance. This information could conceivably be used to construct
a steady state performance topology for initial tunnel path a steady state performance topology for initial tunnel path
computation, or to verify alternative failover paths. computation, or to 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:
B) Determine whether those LSPs still meet end-to-end performance B) The node determines whether those LSPs still meet end-to-end
objectives. If not, then: performance objectives. If not, then:
C) The node could then conceivably move affected traffic to a pre- C) The node could then conceivably move affected traffic to a pre-
established protection LSP or establish a new LSP and place the established protection LSP or establish a new LSP and place the
traffic in it. traffic in it.
If link performance then improves beyond a configurable minimum If link performance then improves beyond a configurable minimum
value (reuse threshold), that sub-TLV can be re-advertised with the value (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 conceivably do whatever re-optimization (or failback) it wishes to
do (including nothing). do (including nothing).
skipping to change at page 6, line 19 skipping to change at page 6, line 19
Consistent with existing OSPF TE specifications (RFC3630), the Consistent with existing OSPF TE specifications (RFC3630), 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 section averaging period MUST be a configurable period of time. See section
5. for more information. 5. for more information.
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 OSPF neighbors. The delay advertised by this sub-TLV MUST connected OSPF 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:
skipping to change at page 11, line 39 skipping to change at page 11, line 39
The announcement of all sub-TLVs that do not include the A bit SHOULD The announcement of all sub-TLVs that do not include the A bit SHOULD
be controlled by variation thresholds that govern when they are sent. be controlled by variation thresholds that govern when they are sent.
Sub-TLV that include the A bit are governed by several thresholds. Sub-TLV that include the A bit are governed by several thresholds.
Firstly, a threshold SHOULD be implemented to govern the announcement Firstly, a threshold SHOULD be implemented to govern the announcement
of sub-TLVs that advertise a change in performance, but not an SLA of sub-TLVs that advertise a change in performance, but not an SLA
violation (i.e. when the A bit is not set). Secondly, implementations violation (i.e. when the A bit is not set). Secondly, implementations
MUST provide configurable thresholds that govern the announcement of MUST provide configurable thresholds that govern the announcement of
sub-TLVs with the A bit set (for the indication of a performance sub-TLVs with the A bit set (for the indication of a performance
violation). Thirdly, implementations SHOULD provide reuse violation). Thirdly, implementations SHOULD provide reuse
thresholds. These thresholds govern sub-TLV re-announcement with the thresholds. This threshold governs sub-TLV re-announcement with the A
A bit cleared to permit fail back. bit cleared to permit fail back.
6. Announcement Suppression 6. Announcement Suppression
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
skipping to change at page 12, line 29 skipping to change at page 12, line 29
As per (RFC3630), unrecognized TLVs should be silently ignored As per (RFC3630), unrecognized TLVs should be silently ignored
9. Security Considerations 9. Security Considerations
This document does not introduce security issues beyond those This document does not introduce security issues beyond those
discussed in [RFC3630] and [RFC5329]. discussed in [RFC3630] and [RFC5329].
10. IANA Considerations 10. IANA Considerations
IANA maintains the registry for the sub-TLVs. OSPF TE Express Path IANA maintains the registry for the sub-TLVs. OSPF TE Metric
will require one new type code per sub-TLV defined in this document. Extensions will require one new type code per sub-TLV defined in this
document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630, Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
 End of changes. 15 change blocks. 
27 lines changed or deleted 28 lines changed or added

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