Browse Prior Art Database

Traffic Engineering (TE) Extensions to OSPF Version 2 (RFC3630) Disclosure Number: IPCOM000019815D
Original Publication Date: 2003-Sep-01
Included in the Prior Art Database: 2003-Sep-30
Document File: 15 page(s) / 28K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 13% of the total text.

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.


This document describes extensions to the OSPF protocol version 2 to

support intra-area Traffic Engineering (TE), using Opaque Link State


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...