Traffic Engineering (TE) Extensions to OSPF Version 2
RFC 3630

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.