One document matched: draft-giacalone-ospf-te-express-path-00.txt
Network Working Group S. Giacalone
Internet Draft Thomson Reuters
Intended status: Proposed Standard
Expires: September 2011 D. Ward
Juniper Networks
J. Drake
Juniper Networks
A. Atlas
Juniper Networks
March 4, 2011
OSPF Traffic Engineering (TE) Express Path
draft-giacalone-ospf-te-express-path-00.txt
Abstract
In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network
performance criteria (e.g. latency) have become (or are becoming) as
(or more) critical to data path selection than other metrics.
This document describes extensions to OSPF TE (RFC3630) such that
network performance information can be distributed and collected in a
scalable fashion. The information collected from OSPF TE Express Path
can then be used to make path selection decisions. Additionally, the
information passed in these extensions will permit granular network
performance monitoring.
Note that this document only covers the mechanisms with which network
performance information is distributed. The mechanisms for measuring
network performance or acting on that information, once distributed,
are outside the scope of this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Giacalone Expires September 4, 2011 [Page 1]
Internet-Draft OSPF TE Express Path March 2011
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 4, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. Express Path Extensions to OSPF TE.............................5
4. Sub TLV Details................................................6
4.1. Routine Unidirectional Link Delay Sub-TLV.................6
4.1.1. Type.................................................6
4.1.2. Length...............................................6
Giacalone, et al Expires September 4, 2011 [Page 2]
Internet-Draft OSPF TE Express Path March 2011
4.1.3. Delay Value..........................................6
4.2. Routine Unidirectional Delay Variation Sub-TLV............7
4.2.1. Type.................................................7
4.2.2. Length...............................................7
4.2.3. Delay Variation......................................7
4.3. Routine Unidirectional Link Loss Sub TLV..................7
4.3.1. Type.................................................8
4.3.2. Length...............................................8
4.3.3. Link Loss............................................8
4.4. Significant Unidirectional Link Delay Sub-TLV.............8
4.4.1. Type.................................................8
4.4.2. Length...............................................9
4.4.3. Delay Value..........................................9
4.5. Significant Unidirectional Link Loss Sub TLV..............9
4.5.1. Type.................................................9
4.5.2. Length...............................................9
4.5.3. Link Loss............................................9
5. Announcement Periodicity......................................10
6. Announcement Suppression......................................10
7. Compatibility.................................................10
8. Security Considerations.......................................10
9. IANA Considerations...........................................10
10. References...................................................11
10.1. Normative References....................................11
10.2. Informative References..................................11
11. Acknowledgments..............................................11
12. Author's Addresses...........................................12
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) have (or are becoming) as (or
more) critical to data path selection than other metrics. In many of
these networks, bandwidth is relatively rich and homogeneous (e.g. a
core network of all 10 or 20 Gigabit Ethernet links, or greater),
however path length (and therefore latency) can vary in between end-
points (e.g. PE nodes), and segment length or latency can change
based on the path protection scheme used. In these networks,
extremely large amounts of money rest on the ability to predictably
make trades faster than the competition and the ability to access
real time market data.
In certain financial services networks, hop count, cost, and
bandwidth are only tangentially important. Rather, it would be
Giacalone, et al Expires September 4, 2011 [Page 3]
Internet-Draft OSPF TE Express Path March 2011
beneficial to be able to granularly monitor network performance
and/or make path selection decisions based on performance data (such
as latency) in a cost-effective and scalable way. In addition, since
these networks may be built as overlays on top of multiple service
provider networks, strict link-by-link service level agreement
monitoring and enforcement mechanisms are needed.
This document describes extensions to OSPF TE (hereafter called "OSPF
TE Express Path"), that can be used to distribute various pieces of
network performance information (such as link latency). The
mechanisms described in this document only disseminate performance
information. The methods for initially gathering that performance
information, or acting on it once it is distributed are outside the
scope of this document. OSPF Express Path provides a number of
benefits:
The data distributed by OSPF TE Express Path can be used to make path
selection decisions. Using the link-by-link performance information
data distributed by OSPF TE Express Path, end-to-end path selection
can be performed based on performance metrics, as part of the normal
operation of various routing protocols (e.g. by replacing cost with
latency) or by using "second order" control plane protocols such as
CSPF, RSVP-TE [RFC3209], etc.
OSPF TE Express Path enables a scalable, open mechanism for link-by-
link SLA compliance monitoring, which is an important issue in large,
diverse networks that use transport services from various providers.
In networks like this, end-to-end latency is not always useful for
enforcement of "underlying" SLAs (since various links from different
providers may make up a path). This link-by-link performance
monitoring data could easily be gathered by looking at a routing
protocol's state database (on any router in an area, depending on
what is being monitoring and disseminated by the routing protocol),
using SNMP [RFC1441] on a per device basis, or in other ways.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
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
interpreted as carrying RFC-2119 significance.
Giacalone, et al Expires September 4, 2011 [Page 4]
Internet-Draft OSPF TE Express Path March 2011
3. Express Path Extensions to OSPF TE
The extensions in this document build on the ones provided in OSPF TE
(RFC3630) and GMPLS (RFC4203) to permit path selection and network
monitoring based on various network performance items. As such, this
document proposes new OSPF TE sub-TLVs that can be announced in OSPF
TE LSAs. 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 LSA to be readily extended. There are two main types
of OSPF TE LSA; the Router Address or Link TE LSA. Like the GMPLS
extensions (RFC4203), this document proposes additional sub-TLVs for
the Link TE LSA. As background, all OSPF TE TLVs and sub-TLVs use
the same general format (RFC3630):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As per (RFC3630) the Length field defines the length of the value
portion of the sub-TLV in octets (thus a TLV with no value portion
would have a length of zero). TLVs are padded to four-octet
alignment; padding is not included in the length field (so a three
octet value would have a length of three, but the total size of the
TLV would be eight octets). Unrecognized types are ignored.
OSPF TE Express Path defines several new sub-TLVs. These sub-TLVs
fall into 2 distinct categories; "Routine" or "Significant". Routine
and Significant sub-TLVs are intended to be used for different
purposes (i.e. monitoring or control plane manipulation,
respectively). The technical differences between Routine and
Significant sub-TLVs are related to the averaging periodicity and
announcement frequency of each category of sub-TLV. More information
on this subject can be found in section 5.
The following sub-TLVs are defined in OSPF TE Express Path:
Value Length Name
Giacalone, et al Expires September 4, 2011 [Page 5]
Internet-Draft OSPF TE Express Path March 2011
TBD1 4 Routine Unidirectional Link Delay
TBD2 4 Routine Unidirectional Delay Variation
TBD3 4 Routine Unidirectional Link Loss
TBD4 4 Significant Unidirectional Link Delay
TBD5 4 Significant Unidirectional Link Loss
4. Sub TLV Details
4.1. Routine Unidirectional Link Delay Sub-TLV
This TLV advertises the average link delay between two directly
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
forward path latency). The format of this sub-TLV is shown in the
following diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD1 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. Type
This sub-TLV has a type of TBD1
4.1.2. Length
The length is 4
4.1.3. Delay Value
This field carries the average link delay over a configurable
interval in micro-seconds, encoded as an IEEE floating point single
precision value.
Giacalone, et al Expires September 4, 2011 [Page 6]
Internet-Draft OSPF TE Express Path March 2011
4.2. Routine Unidirectional Delay Variation Sub-TLV
This TLV advertises the average link delay variation between two
directly connected OSPF neighbors. The delay variation advertised 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-TLV is
shown in the following diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD2 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Variation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.1. Type
This sub-TLV has a type of TBD2
4.2.2. Length
The length is 4
4.2.3. Delay Variation
This field carries the average link delay variation over a
configurable interval in micro-seconds, encoded as an IEEE floating
point single precision value.
4.3. Routine Unidirectional Link Loss Sub TLV
This TLV advertises the loss (as a packet percentage) between two
directly connected OSPF neighbors. The link loss advertised by this
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 shown
in the following diagram:
Giacalone, et al Expires September 4, 2011 [Page 7]
Internet-Draft OSPF TE Express Path March 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.1. Type
This sub-TLV has a type of TBD3
4.3.2. Length
The length is 4
4.3.3. Link Loss
This field carries the link packet loss as a percentage of the total
traffic sent over a configurable interval, encoded as an IEEE
floating point single precision value.
4.4. Significant Unidirectional Link Delay Sub-TLV
This TLV advertises the average link delay between two directly
connected OSPF neighbors. This TLV is announced when either a
configurable maximum average delay or a configurable reuse delay
threshold is passed. The delay advertised 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-TLV is shown in the following
diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD4 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.1. Type
This sub-TLV has a type of TBD4
Giacalone, et al Expires September 4, 2011 [Page 8]
Internet-Draft OSPF TE Express Path March 2011
4.4.2. Length
The length is 4
4.4.3. Delay Value
This field carries the average link delay over a configurable
interval in micro-seconds, encoded as an IEEE floating point single
precision value.
4.5. Significant Unidirectional Link Loss Sub TLV
This TLV advertises the loss (as a packet percentage) between two
directly connected OSPF neighbors. This TLV is announced when either
a configurable loss threshold or a configurable loss reuse threshold
is passed. The link loss advertised by this 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 shown in the
following diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5.1. Type
This sub-TLV has a type of TBD5
4.5.2. Length
The length is 4
4.5.3. Link Loss
This field carries the link packet loss as a percentage of the total
traffic sent over a configurable interval, encoded as an IEEE
floating point single precision value.
Giacalone, et al Expires September 4, 2011 [Page 9]
Internet-Draft OSPF TE Express Path March 2011
5. Announcement Periodicity
Routine announcements are intended to announce data for trending
applications (e.g. advertising small variations in performance
occurring over a longer period of time). Significant sub-TLVs are
intended to announce the occurrence of more dramatic events that
affect network performance (e.g. protection switching). A primary
function of Significant sub-TLVs are to manipulate the control plane.
Since Routine and Significant sub-TLVs have generally different
goals, implementations SHOULD permit them to be announced using
different thresholds and filtering (i.e. rolling average) parameters.
6. Announcement Suppression
Implementations MAY suppress Routine announcements when performance
metrics averages do not change by more than a certain amount. These
suppression thresholds SHOULD be configurable.
Significant announcements MUST only be sent when configurable
thresholds are surpassed.
7. Compatibility
As per (RFC3630), unrecognized TLVs should be silently ignored
8. Security Considerations
This document does not introduce security issues beyond those
discussed in [RFC3630] and [RFC5329].
9. IANA Considerations
IANA maintains the registry for the sub-TLVs. OSPF TE Express Path
will require one new type code per sub-TLV defined in this document.
Giacalone, et al Expires September 4, 2011 [Page 10]
Internet-Draft OSPF TE Express Path March 2011
10. References
10.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[RFC2328] Moy, J, "OSPF Version 2", RFC 2328, April 1998
[RFC3031] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol
Label Switching Architecture", January 2001
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC5250] Berger, L., Bryskin I., Zinin, A., Coltun, R., "The OSPF
Opaque LSA Option", RFC 5250, July 2008.
11. Acknowledgments
The authors would like to recognize Ayman Soliman for his
contributions.
This document was prepared using 2-Word-v2.0.template.dot.
Giacalone, et al Expires September 4, 2011 [Page 11]
Internet-Draft OSPF TE Express Path March 2011
12. Author's Addresses
Spencer Giacalone
Thomson Reuters
195 Broadway
New York NY 10007, USA
Email: Spencer.giacalone@thomsonreuters.com
Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
Email: dward@juniper.net
John Drake
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
Email: jdrake@juniper.net
Alia Atlas
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
Email: akatlas@juniper.net
Giacalone, et al Expires September 4, 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 22:04:52 |