Network Working Group Venkata Naidu Internet Draft Marconi Communications Expiration Date: File name: draft-venkata-ospf-te-only-option-00.txt OSPF TE Only Option Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Venkata Naidu [Page i] Internet Draft OSPF TE Only Option April 2002 Table Of Contents 1.0 Abstract ................................................. 1 2.0 Overview ................................................. 2 2.1 Motivation ........................................... 2 2.2 Proposed Solution .................................... 3 3.0 TE Implementation Details ................................ 3 3.1 The T-bit ............................................ 3 4.0 Security Considerations .................................. 3 5.0 Future Works ............................................. 4 6.0 References ............................................... 4 7.0 Authors' Addresses ....................................... 4 Appendix A: The Options Field ................................ 5 1.0 Abstract OSPF is a link state routing protocol used for IP-network topology discovery using different types of Link State Advertisements. The resulting Link State Database (LSDB) is used to compute IP address forwarding table based on shortest-path criteria. OSPF has been extended to support Traffic Engineering, QoS in packet and non-packet networks. These has been a serious concern regarding scalability and convergence of information in large networks. This memo documents an optional OSPF capability to support TE only functionality. This OSPF TE Only option is to support existing and future Traffic Engineering extensions for packet and/or non-packet networks with out exchanging any hop-by-hop routing information. This is accomplished by exchanging T-bit option in OSPF Hello packets. This gives flexibility of supporting larger TE areas, increased scalability and improved convergence. 2.0 Overview Over the last several years the OSPF routing protocol [OSPF] has been widely deployed throughout the Internet. As a result of this deployment and the evolution of networking technology, OSPF has been extended to support many options; this evolution will obviously continue. This is an effort to extend OSPF to support TE Only capability with out exchanging any hop-by-hop routing information (like Router LSAs, Network LSAs etc) in an OSPF area. OSPF-TE sets out to discover TE network topology and perform collection and dissemination of TE metrics within the TE network. This results in the generation of an independent TE-LSDB, that would permit computation of TE circuit paths. In other words, Venkata Naidu [Page 1] Internet Draft OSPF TE Only Option April 2002 TE link-state information is totally independent of hop-by-hop link state information and logic flow in IGPs (both OSPF and ISIS). TE LSAs have all the information about logical/physical Links/Nodes in the system. For example, in the same routing domain, one can use ISIS for IP hop-by-hop routing and OSPF-TE for exchanging just TE information and updating TE Topology DataBase. OSPF will not exchange any other information for hop-by-hop routing purpose. Effectively, if we are able to make any IGP for TE only purpose then that is nothing but a different protocol exclusively for exchanging TE information. Doing this way has some advantages in scalability and information convergence as outlined in section 2.0. 2.1 Motivation At present OSPF is extended to support Traffic Engineering [OSPF-TE] GMPLS [OSPF-GMPLS] and Differentiated services. There has been lot of discussion about the convergence and scalability of this information in large IGPs confined areas. Routing Information needs faster convergence when compared to TE information. Because, if LSDBs in all routers are not identical then, that may cause routing loops. But, if TE information is not propagated then that won't cause any routing loops, rather might cause (unwanted) MPLS LSPs being setup/rejected. As a general rule, a TE network is likely to generate significantly more control traffic than a native OSPF network. The excess traffic is almost directly proportional to the rate at which TE circuits are setup and torn down within an autonomous system. It is important to ensure that TE database synchronizations happen quickly when compared to the aggregate circuit setup an teardown rates. With this extension, the "TE information" exchange is out-of-band w.r.t regular hop-by-hop routing information exchange. Out-of-band flooding gives better performance improvement in convergence. So, disseminating hop-by-hop Routing link-state information and TE link-state information is mutually beneficial to hop-by-hop routing computations and TE-LSPs. With this extension, effectively we can have the "TE Area" boundary totally different from "Routing Area Boundary". For example, "OSPF-TE Only" can be configured on bigger range than ISIS Routing Area. Effectively, we will be doing CSPF on multi-area (at least w.r.t ISIS). So that, we can have different combinations Venkata Naidu [Page 2] Internet Draft OSPF TE Only Option April 2002 of OSPF and ISIS running in the same routing domain performing different set of things. If the logic flow of TE and Routing Info in IGPs are different, operators can have flexibility of choosing (based on their requirements and performance measurements) different combinations of IGPs performing different set of actions in the same routing domain. From software development perspective, OSPF-TE Only takes less lot of space when compared to classical OSPF. Much of complex code in OSPF can be made independent of TE. This leads to easy maintenance and room for future extensions. All this can be done with out changing current (deployed) OSPF extensions but with one option exchange in Hello packets. 2.2 Proposed Solution The proposed solution is to exchange a T-bit option in OSPF Hello packets. When the bit is set, Router is not willing to receive any LSAs except TE-LSAs and the Router itself is not going to generate any type of LSAs except TE-LSAs. 3.0 Implementation Details 3.1 The T-bit An opaque-capable TE Only router learns of its neighbor's opaque capability at the "Hello Protocol handshake process". A neighbor is TE Only capable if and only if it sets T-bit in the Hello packets options fields. Also note that, a router is TE Only capable if and only if it supports [OSPF-OPAQUE]. When used in Hello packets, the TE Only options field allows a router to reject a neighbor because of capability mismatch. There is no requirement that all routers in a router domain and/or in OSPF area must agree on this TE Only option. Routers, which support this capability and router which doesn't may co-exist in the same routing domain. 4.0 Security Considerations All the above extensions are part of normal OSPF procedure w.r.t exchanging/flooding TE LSAs and authentication procedures. This memo does not create any new security issues for the OSPF protocol. Security considerations for the base OSPF protocol are covered in [OSPF]. Venkata Naidu [Page 3] Internet Draft OSPF TE Only Option April 2002 5.0 Future Work 1. The performance analysis of above extension in order to improve convergence time and scalability are under study. 2. Extending the above work to multi-area extensions and route servers are under consideration. 3. Extensions to silent-mode TE listeners (which serve as Topology Data base servers in area borders) are under study. 4. ISIS routing protocol also can be extended in a similar fashion. 6.0 References [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications Corp., April 1998. [OPAQUE] Coltun, Rob, "The OSPF Opaque LSA Option", RFC 2370, FORE Systems, July 1998. [MPLS-TE] Awduche, D., et al, "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999. [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF", (work in progress). [ISIS-TE] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," work in progress. [OSPF-GMPLS] Kompella, K., Rekhter, Y., et al, "OSPF Extensions in Support of Generalized MPLS," work in progress. 7.0 Authors' Addresses Venkata Naidu Marconi Communications 1595 Spring Hill Rd, 5th Floor Vienna VA 22031 Phone: (703) 245-4562 EMail: Venkata.Naidu@Marconi.com Venkata Naidu [Page 4] Internet Draft OSPF TE Only Option April 2002 Appendix A: The Options Field The OSPF options field is present in OSPF Hello packets, Database Description packets and all link state advertisements. See [OSPF]Appendix A.2 and [OSPF-OPAQUE] Appendix A.1 for a description of the options field. Seven bits are assigned but only one (the T-bit) is described completely in this section. -------------------------------------- | T | O | DC | EA | N/P | MC | E | * | -------------------------------------- The Hello and Opaque LSA options field T-bit: The T-bit is used only in the Hello Packets and LSA header. When the bit is set, Router is not willing to receive any LSAs except TE-LSAs and the Router itself is not going to generate any type of LSAs except TE-LSAs.