draft-ietf-ospf-te-metric-extensions-06.txt   draft-ietf-ospf-te-metric-extensions-07.txt 
Network Working Group S. Giacalone Network Working Group S. Giacalone
Internet Draft Unaffiliated Internet Draft Unaffiliated
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: March 2015 D. Ward Expires: May 2015 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
September 12, 2014 November 11, 2014
OSPF Traffic Engineering (TE) Metric Extensions OSPF Traffic Engineering (TE) Metric Extensions
draft-ietf-ospf-te-metric-extensions-06.txt draft-ietf-ospf-te-metric-extensions-07.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
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 March 12, 2015. This Internet-Draft will expire on May 11, 2015.
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 3, line 12 skipping to change at page 3, line 12
4.1.1. Type.................................................7 4.1.1. Type.................................................7
4.1.2. Length...............................................7 4.1.2. Length...............................................7
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..........................................8 4.1.5. Delay Value..........................................8
4.2. Min/Max Unidirectional Link Delay Sub-TLV.................8 4.2. Min/Max Unidirectional Link Delay Sub-TLV.................8
4.2.1. Type.................................................8 4.2.1. Type.................................................8
4.2.2. Length...............................................8 4.2.2. Length...............................................8
4.2.3. A bit................................................8 4.2.3. A bit................................................8
4.2.4. Reserved.............................................9 4.2.4. Reserved.............................................9
4.2.5. Low Delay............................................9 4.2.5. Min Delay............................................9
4.2.6. High Delay...........................................9 4.2.6. Max Delay............................................9
4.2.7. Reserved.............................................9 4.2.7. Reserved.............................................9
4.3. Unidirectional Delay Variation Sub-TLV...................10 4.3. Unidirectional Delay Variation Sub-TLV....................9
4.3.1. Type................................................10 4.3.1. Type................................................10
4.3.2. Length..............................................10 4.3.2. Length..............................................10
4.3.3. Reserved............................................10 4.3.3. Reserved............................................10
4.3.4. Delay Variation.....................................10 4.3.4. Delay Variation.....................................10
4.4. Unidirectional Link Loss Sub-TLV.........................10 4.4. Unidirectional Link Loss Sub-TLV.........................10
4.4.1. Type................................................11 4.4.1. Type................................................11
4.4.2. Length..............................................11 4.4.2. Length..............................................11
4.4.3. A bit...............................................11 4.4.3. A bit...............................................11
4.4.4. Reserved............................................11 4.4.4. Reserved............................................11
4.4.5. Link Loss...........................................11 4.4.5. Link Loss...........................................11
4.5. Unidirectional Residual Bandwidth Sub-TLV................12 4.5. Unidirectional Residual Bandwidth Sub-TLV................11
4.5.1. Type................................................12 4.5.1. Type................................................12
4.5.2. Length..............................................12 4.5.2. Length..............................................12
4.5.3. Residual Bandwidth..................................12 4.5.3. Residual Bandwidth..................................12
4.6. Unidirectional Available Bandwidth Sub-TLV...............13 4.6. Unidirectional Available Bandwidth Sub-TLV...............13
4.6.1. Type................................................13 4.6.1. Type................................................13
4.6.2. Length..............................................13 4.6.2. Length..............................................13
4.6.3. Available Bandwidth.................................13 4.6.3. Available Bandwidth.................................13
4.7. Unidirectional Utilized Bandwidth Sub-TLV................13 4.7. Unidirectional Utilized Bandwidth Sub-TLV................13
4.7.1. Type................................................14 4.7.1. Type................................................14
4.7.2. Length..............................................14 4.7.2. Length..............................................14
4.7.3. Utilized Bandwidth..................................14 4.7.3. Utilized Bandwidth..................................14
5. Announcement Thresholds and Filters...........................14 5. Announcement Thresholds and Filters...........................14
6. Announcement Suppression......................................15 6. Announcement Suppression......................................15
7. Network Stability and Announcement Periodicity................16 7. Network Stability and Announcement Periodicity................15
8. Enabling and Disabling Sub-TLVs...............................16 8. Enabling and Disabling Sub-TLVs...............................16
9. Static Metric Override........................................16 9. Static Metric Override........................................16
10. Compatibility................................................17 10. Compatibility................................................16
11. Security Considerations......................................17 11. Security Considerations......................................17
12. IANA Considerations..........................................17 12. IANA Considerations..........................................17
13. References...................................................17 13. References...................................................17
13.1. Normative References....................................17 13.1. Normative References....................................17
13.2. Informative References..................................17 13.2. Informative References..................................18
14. Acknowledgments..............................................18 14. Acknowledgments..............................................18
15. Author's Addresses...........................................18 15. Author's Addresses...........................................19
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 OSPF TE (hereafter called "OSPF This document describes extensions to OSPF TE (hereafter called "OSPF
TE Metric Extensions"), that can be used to distribute network TE Metric Extensions"), that can be used to distribute network
performance information (such as link delay, delay variation, packet performance information (viz link delay, delay variation, link loss,
loss, residual bandwidth, and available bandwidth). residual bandwidth, available bandwidth, and utilized bandwidth).
The data distributed by OSPF TE Metric Extensions is meant to be used The data distributed by OSPF TE Metric Extensions is meant to be used
as part of the operation of the routing protocol (e.g. by replacing as part of the operation of the routing protocol (e.g. by replacing
cost with latency or considering bandwidth as well as cost), by cost with latency or considering bandwidth as well as cost), by
enhancing CSPF, or for other uses such as supplementing the data used enhancing CSPF, or for use by a PCE [RFC4655] or an Alto server
by an Alto server [Alto]. With respect to CSPF, the data distributed [RFC7285]. With respect to CSPF, the data distributed by OSPF TE
by OSPF TE Metric Extensions can be used to setup, fail over, and Metric Extensions can be used to setup, fail over, and fail back data
fail back data paths using protocols such as RSVP-TE [RFC3209].[ paths using protocols such as RSVP-TE [RFC3209].
Draft-ietf-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 or acting on it once it is distributed are
is distributed are outside the scope of this document. Example outside the scope of this document. Example mechanisms to measure
mechanisms to measure latency, delay variation, and loss in an MPLS latency, delay variation, and loss in an MPLS network are given in
network are given in [RFC6374]. While this document does not [RFC6374]. While this document does not specify how the performance
specify how the performance information should be obtained, the information should be obtained, the measurement of delay SHOULD NOT
measurement of delay SHOULD NOT vary significantly based upon the vary significantly based upon the offered traffic load. Thus,
offered traffic load. Thus, queuing delays and/or loss SHOULD NOT queuing delays and/or loss SHOULD NOT be included in any dynamic
be included in any dynamic delay measurement. For links, such as delay measurement. For links, such as Forwarding Adjacencies, care
Forwarding Adjacencies, care must be taken that measurement of the must be taken that measurement of the associated delay avoids
associated delay avoids significant queuing delay; that could be significant queuing delay; that could be accomplished in a variety
accomplished in a variety of ways, including either by measuring of ways, including either by measuring with a traffic class that
with a traffic class that experiences minimal queuing or by summing experiences minimal queuing or by summing the measured link delays
the measured link delays of the components of the link's path. of the components of the link's path.
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.
skipping to change at page 5, line 37 skipping to change at page 5, line 35
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
(RFC4203), this document proposes several additional sub-TLVs for (RFC4203), this document proposes several additional sub-TLVs for
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 8 Low/High Unidirectional Link Delay TBD2 8 Min/Max Unidirectional Link Delay
TBD3 4 Unidirectional Delay Variation TBD3 4 Unidirectional Delay Variation
TBD4 4 Unidirectional Packet Loss TBD4 4 Unidirectional Link Loss
TBD5 4 Unidirectional Residual Bandwidth TBD5 4 Unidirectional Residual Bandwidth
TBD6 4 Unidirectional Available Bandwidth TBD6 4 Unidirectional Available Bandwidth
TBD7 4 Unidirectional Utilized Bandwidth
TBD7 4 Unidirectional Utilized 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
skipping to change at page 6, line 43 skipping to change at page 6, line 41
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).
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 section omitted from some sub-TLVs to help mitigate oscillations. See section
7. 1. for more information. 7. 1. for more information.
Consistent with existing OSPF TE specifications (RFC3630), the Link delay, delay variation, and link loss MUST be encoded as
bandwidth advertisements defined in this draft MUST be encoded as integers. Consistent with existing OSPF TE specifications [RFC3630],
IEEE floating point values. The delay and delay variation residual, available, and utilized bandwidth MUST be encoded in IEEE
advertisements defined in this draft MUST be encoded as integer floating point. Link delay and delay variation MUST be in units of
values. Delay values MUST be quantified in units of microseconds, microseconds, link loss MUST be a percentage, and bandwidth MUST be
packet loss MUST be quantified as a percentage of packets sent, and in units of bytes per second. All values (except residual bandwidth)
bandwidth MUST be sent as bytes per second. All values (except MUST be calculated as rolling averages where the averaging period
residual bandwidth) MUST be calculated as rolling averages where the MUST be a configurable period of time. See section 5. for more
averaging period MUST be a configurable period of time. See section 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 delay). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD1 | 4 | | TBD1 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Delay | |A| RESERVED | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 19 skipping to change at page 8, line 19
the maximum value 16,777,215 (16.777215 sec), then the delay is at the maximum value 16,777,215 (16.777215 sec), then the delay is at
least that value and may be larger. If there is no value to send least that value and may be larger. If there is no value to send
(unmeasured and not statically specified), then the sub-TLV should (unmeasured and not statically specified), then the sub-TLV should
not be sent or be withdrawn. not be sent or be withdrawn.
4.2. Min/Max Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link Delay Sub-TLV
This sub-TLV advertises the minimum and maximum delay values between This sub-TLV advertises the minimum and maximum delay values between
two directly connected OSPF neighbors. The delay advertised by this two directly connected OSPF neighbors. The delay advertised by this
sub-TLV MUST be the delay from the local neighbor to the remote one 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-TLV is shown (i.e. the forward path delay). The format of this sub-TLV is shown in
in the following diagram: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD2 | 8 | | TBD2 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| RESERVED | Min Delay | |A| RESERVED | Min Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Max Delay | | RESERVED | Max Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 10 skipping to change at page 9, line 10
one or more measured values exceed a configured maximum threshold. one or more measured values exceed a configured maximum threshold.
The A bit is cleared when the measured value falls below its The A bit is cleared when the measured value falls below its
configured reuse threshold. If the A bit is clear, the sub-TLV configured reuse threshold. If the A bit is clear, the sub-TLV
represents steady state link performance. represents steady state link performance.
4.2.4. Reserved 4.2.4. Reserved
This field is reserved for future use. It MUST be set to 0 when sent This field is reserved for future use. It MUST be set to 0 when sent
and MUST be ignored when received. and MUST be ignored when received.
4.2.5. Low Delay 4.2.5. Min Delay
This 24-bit field carries minimum measured link delay value (in This 24-bit field carries minimum measured link delay value (in
microseconds) over a configurable interval, encoded as an integer microseconds) over a configurable interval, encoded as an integer
value. value.
Implementations MAY also permit the configuration of a static (non Implementations MAY also permit the configuration of a static (non
dynamic) offset value (in microseconds) to be added to the measured dynamic) offset value (in microseconds) to be added to the measured
delay value, to facilitate the communication of operator specific delay value, to facilitate the communication of operator specific
delay constraints. delay constraints.
When set to the maximum value 16,777,215 (16.777215 sec), then the When set to the maximum value 16,777,215 (16.777215 sec), then the
delay is at least that value and may be larger. delay is at least that value and may be larger.
4.2.6. High Delay 4.2.6. Max Delay
This 24-bit field carries the maximum measured link delay value (in This 24-bit field carries the maximum measured link delay value (in
microseconds) over a configurable interval, encoded as an integer microseconds) over a configurable interval, encoded as an integer
value. value.
Implementations MAY also permit the configuration of a static (non Implementations MAY also permit the configuration of a static (non
dynamic) offset value (in microseconds) to be added to the measured dynamic) offset value (in microseconds) to be added to the measured
delay value, to facilitate the communication of operator specific delay value, to facilitate the communication of operator specific
delay constraints. delay constraints.
It is possible for the high delay and low delay to be the same value. It is possible for min delay and max delay to be the same value.
When the delay value is set to maximum value 16,777,215 (16.777215 When the delay value is set to maximum value 16,777,215 (16.777215
sec), then the delay is at least that value and may be larger. sec), then the delay is at least that value and may be larger.
4.2.7. Reserved 4.2.7. Reserved
This field is reserved for future use. It MUST be set to 0 when sent This field is reserved for future use. It MUST be set to 0 when sent
and MUST be ignored when received. and MUST be ignored when received.
When only an average delay value is sent, this field is not present
in the TLV.
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 OSPF neighbors. The delay variation advertised by directly connected OSPF neighbors. The delay variation advertised by
this sub-TLV MUST be the delay from the local neighbor to the remote 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-TLV is one (i.e. the forward path delay variation). The format of this sub-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD3 | 4 | | TBD3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Delay Variation | | RESERVED | Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.1. Type 4.3.1. Type
skipping to change at page 14, line 40 skipping to change at page 14, line 37
measured in the router). For a bundled link, bandwidth utilization is measured in the router). For a bundled link, bandwidth utilization is
defined to be the sum of the component link bandwidth utilizations. defined to be the sum of the component link bandwidth utilizations.
5. Announcement Thresholds and Filters 5. Announcement Thresholds and Filters
The values advertised in all sub-TLVs (except min/max delay and The values advertised in all sub-TLVs (except min/max 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 obtained by a filter that is reasonably representative of an
average. For example, a rolling average is one such filter. average. For example, a rolling average is one such filter.
Low or high delay MAY be the lowest and/or highest measured value Min and max 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
technique to obtain a reasonable representation of a low and high technique to obtain a reasonable representation of a min and max
value representative of the interval with compensation for outliers. value representative of the interval with compensation for outliers.
The measurement interval, any filter coefficients, and any The measurement interval, any filter coefficients, and any
advertisement intervals MUST be configurable per sub-TLV. advertisement intervals MUST be configurable per sub-TLV.
In addition to the measurement intervals governing re-advertisement, In addition to the measurement intervals governing re-advertisement,
implementations SHOULD provide per sub-TLV configurable accelerated implementations SHOULD provide per sub-TLV configurable accelerated
advertisement thresholds, such that: advertisement thresholds, such that:
1. If the measured parameter falls outside a configured upper bound 1. If the measured parameter falls outside a configured upper bound
for all but the min delay metric (or lower bound for min-delay for all but the min delay metric (or lower bound for min delay
metric only) and the advertised sub-TLV is not already outside metric only) and the advertised sub-TLV is not already outside
that bound or, that bound or,
2. If the difference between the last advertised value and current 2. If the difference between the last advertised value and current
measured value exceed a configured threshold then, measured value exceed a configured threshold then,
3. The advertisement is made immediately. 3. The advertisement is made immediately.
4. For sub-TLVs which include an A-bit (except low/high delay), an 4. For sub-TLVs which include an A-bit (except min/max delay), an
additional threshold SHOULD be included corresponding to the additional threshold SHOULD be included corresponding to the
threshold for which the performance is considered anomalous (and threshold for which the performance is considered anomalous (and
sub-TLVs with the A bit are sent). The A-bit is cleared when the sub-TLVs with the A bit are sent). The A-bit is cleared when the
sub-TLV's performance has been below (or re-crosses) this sub-TLV's performance has been below (or re-crosses) this
threshold for an advertisement interval(s) to permit fail back. threshold for an advertisement interval(s) to permit fail back.
To prevent oscillations, only the high threshold or the low threshold To prevent oscillations, only the high threshold or the low threshold
(but not both) may be used to trigger any given sub-TLV that supports (but not both) may be used to trigger any given sub-TLV that supports
both. both.
Additionally, once outside of the bounds of the threshold, any Additionally, once outside of the bounds of the threshold, any re-
readvertisement of a measurement within the bounds would remain advertisement 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 described in
section 6 may shorten the re-advertisement interval. section 6 may shorten the re-advertisement interval.
All suppression and re-advertisement interval backoff timer features All suppression and re-advertisement interval back-off timer features
SHOULD be configurable. SHOULD be configurable.
7. Network Stability and Announcement Periodicity 7. Network Stability and Announcement Periodicity
Sections 6 and 7 provide configurable mechanisms to bound the number Sections 6 and 7 provide configurable mechanisms to bound the number
of re-advertisements. Instability might occur in very large networks of re-advertisements. Instability might occur in very large networks
if measurement intervals are set low enough to overwhelm the 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.
skipping to change at page 17, line 18 skipping to change at page 17, line 14
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 [RFC3630] and [RFC5329]. discussed in [RFC3630] and [RFC5329].
12. IANA Considerations 12. IANA Considerations
IANA maintains the registry for the sub-TLVs. OSPF TE Metric IANA maintains the registry for the sub-TLVs. OSPF 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, as follows:
Type Description
TBD1 Unidirectional Link Delay
TBD2 Min/Max Unidirectional Link Delay
TBD3 Unidirectional Delay Variation
TBD4 Unidirectional Link Loss
TBD5 Unidirectional Residual Bandwidth
TBD6 Unidirectional Available Bandwidth
TBD7 Unidirectional Utilized Bandwidth
13. References 13. References
13.1. Normative References 13.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,
September 2003. September 2003.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
13.2. Informative References 13.2. Informative References
[RFC2328] Moy, J, "OSPF Version 2", RFC 2328, April 1998 [RFC2328] Moy, J, "OSPF Version 2", RFC 2328, April 1998
[RFC3031] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol
Label Switching Architecture", January 2001 Label Switching Architecture", January 2001
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC5250] Berger, L., Bryskin I., Zinin, A., Coltun, R., "The OSPF [RFC5250] Berger, L., Bryskin I., Zinin, A., Coltun, R., "The OSPF
Opaque LSA Option", RFC 5250, July 2008. Opaque LSA Option", RFC 5250, July 2008.
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Measurement Profile for MPLS-Based Transport Networks", Computation Element (PCE)-Based Architecture", RFC 4655,
RFC 6375, September 2011. August 2006.
[Alto] R. Alimi R. Penno Y. Yang, "ALTO Protocol" [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[Draft-ietf-mpls-te-express-path] Atlas, A., Drake, J., Giacalone, [RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
S., Ward, D., Previdi, S., and C. Filsfils, "Performance- Roome, W., Shalunov, S., and R. Woundy, "Application-
based Path Selection for Explicitly Routed LSPs using TE Layer Traffic Optimization (ALTO) Protocol", RFC 7285,
Metric Extensions", Draft-ietf-mpls-te-express-path (work September 2014.
in progress), October 2013
14. Acknowledgments 14. Acknowledgments
The authors would like to recognize Ayman Soliman, Nabil Bitar, David The authors would like to recognize Ayman Soliman, Nabil Bitar, David
McDysan, Edward Crabbe, and Don Fedyk for their contributions. McDysan, Edward Crabbe, and Don Fedyk for their contributions.
The authors also recognize Curtis Villamizar for significant comments The authors also recognize Curtis Villamizar for significant comments
and direct content collaboration. and direct content collaboration.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
 End of changes. 37 change blocks. 
78 lines changed or deleted 84 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/