Traffic Engineering (TE) Extensions to OSPF Version 2 (RFC3630)
Original Publication Date: 2003-Sep-01
Included in the Prior Art Database: 2003-Sep-30
Internet Society Requests For Comment (RFCs)
D. Katz: AUTHOR [+3]
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.
Network Working Group D. Katz
Request for Comments: 3630 K. Kompella
Updates: 2370 Juniper Networks
Category: Standards Track D. Yeung
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 (C) The Internet Society (2003). All Rights Reserved.
This document describes extensions to the OSPF protocol version 2 to
support intra-area Traffic Engineering (TE), using Opaque Link State
This document specifies a method of adding traffic engineering
capabilities to OSPF Version 2 . The architecture of traffic
engineering is described in . The semantic content of the
extensions is essentially identical to the corresponding extensions
to IS-IS . 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
Many of the extensions specified in this document are in response to
the requirements stated in , 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...