RFC 3630 (rfc3630) - Page 2 of 14


Traffic Engineering (TE) Extensions to OSPF Version 2



Alternative Format: Original Text Document



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