Open Shortest Path First traffic engineering extensions: Difference between revisions
imported>Caesar Schinas m (Robot: Changing template: TOC-right) |
imported>Howard C. Berkowitz No edit summary |
||
| Line 3: | Line 3: | ||
A series of extensions<ref name=RFC3630>{{citation | id = RFC3630| title = Traffic Engineering (TE) Extensions to OSPF Version 2 | A series of extensions<ref name=RFC3630>{{citation | id = RFC3630| title = Traffic Engineering (TE) Extensions to OSPF Version 2 | ||
| author = D. Katz, K. Kompella, D. Yeung | | author = D. Katz, K. Kompella, D. Yeung | ||
| date = September 2003 | url = http://www.ietf.org/rfc/rfc3630.txt}}</ref> to the '''Open Shortest Path First (OSPF)''' Version 2 (i.e., for [[Internet Protocol version 4]] have been defined to support routes that not only reflect the shortest, cheapest path between addreses, but to include the ''[[traffic engineering]]'' extensions used to support [[Multi- | | date = September 2003 | url = http://www.ietf.org/rfc/rfc3630.txt}}</ref> to the '''Open Shortest Path First (OSPF)''' Version 2 (i.e., for [[Internet Protocol version 4]] have been defined to support routes that not only reflect the shortest, cheapest path between addreses, but to include the ''[[traffic engineering]]'' extensions used to support [[Multi-Protocol Label Switching]] (MPLS) with bandwidth and administrative constraints.<ref name=RFC2702>{{citation | ||
| author = Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus | | author = Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus | ||
| title = Requirements for Traffic Engineering Over MPLS | | title = Requirements for Traffic Engineering Over MPLS | ||
Revision as of 17:23, 10 February 2011
A series of extensions[1] to the Open Shortest Path First (OSPF) Version 2 (i.e., for Internet Protocol version 4 have been defined to support routes that not only reflect the shortest, cheapest path between addreses, but to include the traffic engineering extensions used to support Multi-Protocol Label Switching (MPLS) with bandwidth and administrative constraints.[2]
Several technologies intertwine in this specification. MPLS paths are created over an IP topology, which is usually generated by an interior routing protocol, such as OSPF or Intermediate System-Intermediate System. To go beyond topology into bandwidth capacity specification and the application of administrative constraints (e.g., only a certain category of traffic may traverse a path), these routing protocols need to apply not just topology and link metrics, but also the additional MPLS information that is used to refine the routing table computation. The Internet Engineering Task Force (IETF) intends to keep the functionality, if not the syntax, of this additional information aligned between OSPF and ISIS.
MPLS itself is being extended to support Generalized MPLS, which supports not just packet-switching networks, but additional technologies, for which similar topology computation will work, such as optical wavelength and time division (e.g., SONET/SDH) networks. [3]. As with the original MPLS extensions to OSPF, there are also GMPLS extensions. [4]
References
- ↑ D. Katz, K. Kompella, D. Yeung (September 2003), Traffic Engineering (TE) Extensions to OSPF Version 2, RFC3630
- ↑ Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus (September 1999), Requirements for Traffic Engineering Over MPLS, RFC2702
- ↑ K. Kompella, Y. Rekhter, Ed., ed. (October 2005), Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
- ↑ K. Kompella, Y. Rekhter,, ed. (October 2005), OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC4203