Previous

Content

Next 

Traffic Engineering (TE) Extensions to OSPFv2

  

RFC 3630:  Traffic Engineering (TE) Extensions to OSPFv2 was written by RD.Katz, K.Kompella and D.Young in September 2003. Here I'm trying to make a brief summary of this document.
This documenty specifies a method of adding traffic engineering capabililties to OSPFv2 as extensions, providing a way of describing bandwidth and administrative constraint and distributing the information within an OSPF area.
The information being distributed can be used to build an "extended" link state database (LS-database), just as router LSAs are used to build a "regular" LS-database. Nevertheless, the extended LS-database, referred here as the Traffic Engineering Database (TED) has additional attributes. TED is used to:
  1. Monitoring extended link attributes:
      An OSPF-speaking device can participate in an OSPF area, build a TED, and thereby report on the reservation state of links in that area.
         		  
  2. Defining local constraint-based source routing:
      A router R can compute a path from a source A to a destination node B (typically A is the router itself). B is specified by a "router address". This path may be subject to various constraint on the attributes of the links and nodes the path traverses. This path can 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 (it could be: "those packets whose IP destination is learned from B", and the path can be created using MPLS tunnels).
         		  
  3. Defining global traffic engineering:
      A device can build a TED, input a traffic matrix and an optimization function, crunch on the information, and compute optimal or near-optimal routing for the entire network (some example of this operation has been implemented by Q-OSPF, however, this implementation written in 1999, does not use the LS extensions proposed in this RFC, obviously. L.B.).  
Limitations
  • Extensions specify here are for intra-area distribution of TE information. Inter-area and inter-AS are beyond the scope of this document.
  • Extensions specify here capture reservation state of point-to-point links. Multi-access links may not be accurately reflected, except in the special case in which there are only two devices in the multi-access network.
  • Unnumbered links are not supported.