Traffic Engineering (TE) Extensions to OSPF Version 2
RFC 3630
Document | Type |
RFC - Proposed Standard
(October 2003; No errata)
Updates RFC 2370
|
|
---|---|---|---|
Authors | Derek Yeung , Dave Katz , Kireeti Kompella | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3630 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Bill Fenner | ||
Send notices to | <rohit@utstar.com>, <john.moy@sycamorenet.com> |
Network Working Group D. Katz Request for Comments: 3630 K. Kompella Updates: 2370 Juniper Networks Category: Standards Track D. Yeung Procket Networks September 2003 Traffic Engineering (TE) Extensions to OSPF Version 2 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. 1. Introduction This document specifies a method of adding traffic engineering capabilities to OSPF Version 2 [1]. The architecture of traffic engineering is described in [5]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS [6]. It is expected that the traffic engineering extensions to OSPF will continue to mirror those in IS-IS. The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. Furthermore, no changes have been made to the operation of OSPFv2 flooding; in Katz, et al. Standards Track [Page 1] RFC 3630 TE Extensions to OSPF Version 2 September 2003 particular, if non-TE capable nodes exist in the topology, they MUST flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs (see [3]). 1.1. Applicability Many of the extensions specified in this document are in response to the requirements stated in [5], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as the proposal is to simply add more attributes to links in OSPF advertisements. The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include: o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering. For example, an OSPF-speaking device can participate in an OSPF area, build a traffic engineering database, and thereby report on the reservation state of links in that area. In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated, is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP-hard, or even unsolvable, depending on the nature of the attributes and constraints, and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here. Katz, et al. Standards Track [Page 2] RFC 3630 TE Extensions to OSPF Version 2 September 2003 Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and anShow full document text