Internet Draft Internet Draft Bala Rajagopalan Expiration Date: August, 26, 1999 NEC USA IGP-Independent Routing Support for Traffic Engineering draft-rajagopalan-igpfree-te-00.txt 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. ABSTRACT This draft proposes that routing mechanisms in support of traffic engineering be developed independent of specific IGPs. A modular constraint-based routing overlay approach is suggested and its components are briefly described. 1. INTRODUCTION Constraint-based routing (of traffic trunks) has been identified as an important component of traffic engineering under MPLS [1]. Also, dynamic load distribution using optimized multipath routing has been proposed as a traffic engineering aid [7]. Other routing solutions in support of traffic engineering may evolve in the future. Routing mechanisms to support traffic engineering needs must therefore be flexible to accommodate possibly different routing solutions under a common framework. [Page 1] Internet Draft draft-rajagopalan-igpfree-te-00.txt Feb., 1999 This draft expands on the overlay model for constraint-based routing (CR) as presented in [2]. The essential theme proposed in this draft is the development of a modular intradomain routing overlay that aids in traffic engineering, as an alternative to extending each existing IGP separately to support traffic engineering or other QoS requirements [3-5]. In this regard, the present proposal differs from the general approach described in [5] which deals with extensibility of existing IGPs, specifically, link state protocols. The main advantage of the overlay approach is that it permits the development of routing mechanisms not constrained by any limitations of the underlying IGP. Examples of such constraints are: - the narrow range of metric values provided by IS-IS [6] - the overheads of flooding state information frequently (IS-IS and OSPF), - potential for incompatibility between any newly developed hierarchical network state representations with the existing representation and usage of aggregated routing information in link state protocols (ISIS and OSPF), and - the inability to utilize distance or path vector IGPs to disseminate constraint-based routing information. The overlay approach allows the development of a single standard set of routing mechanisms that can be used over many existing IGPs, including distance or path vector types [2]. Given that new mechanisms such as explicit route set-up and new algorithms for routing (e.g., OMP [7]) have to be deployed to support traffic engineering, it might be flexible to completely decouple existing IGPs from the new routing mechanisms. This draft recognizes the five components that need to be developed for constraint-based routing. These are: routing metrics definition, routing update propagation, network state representation, route computation and path establishment. Given the variety of solutions that may be developed to support traffic engineering and QoS support, it is proposed that the overall routing scheme be modular, with the ability to plug in different instances of some of the above components. For instance, it should be possible to employ different routing metrics and route computation algorithms as desired in an autonomous system, without requiring a new specification for each variant. [Page 2] Internet Draft draft-rajagopalan-igpfree-te-00.txt Feb., 1999 2. ROUTING METRICS It is proposed that individual ASs be given the ability to define and use routing metrics as per their needs. The reason for this is as follows. Many different routing strategies for traffic engineering and QoS support are possible and individual ASs must be able to deploy proprietary routing solutions internally, using any routing metric and route computation algorithm necessary [8]. In this regard, the CR overlay will only specify the format of the standard envelope for propagating any routing metric, and not necessarily the encoding and the semantics of all possible metrics. An example of such an envelope is the type-length-value (TLV) format. The specification of the encoding and the semantics of some metrics may be under user control. The encoding and the semantics of certain basic metrics such as bandwidth may be standardized, as proposed in [5]. 3. UPDATE PROPAGATION Under the modular approach proposed here, update propagation, routing information representation and explicit path establishment are perhaps the items that require complete specification. Under the overlay model, each router runs an overlay CR module that utilizes an underlying IGP to build a forwarding tree for propagating CR updates [2]. Update propagation must ensure consistent state information at every router. Details of one possible update propagation mechanism were described in [2]. The main reason for extending an existing IGP to support traffic engineering requirements is the ability to use the IGP's update propagation mechanism. This has the following disadvantages: - the IGP must necessarily be a link state scheme, since distance vector IGPs do not have any means to propagate link and nodal metrics required for constraint-based routing - the only choice available for propagating updates, even frequently changing state information, is flooding, and - the constraint-based routing updates must be handled like the basic topology updates, for instance, requiring aging, periodic refresh, etc., while the processing of state updates is simplified under the overlay model [2]. An overlay update propagation mechanism permits constraint- based routing implementation over both distance (or path) vector and link state IGPs. Furthermore, the operation can be made efficient. A drawback to implementing a separate update propagation scheme over a link state IGP, of course, is the duplication of some work. This is evident from the description in [2]. The advantages of the overlay method, in our opinion, outweighs the drawbacks. [Page 3] Internet Draft draft-rajagopalan-igpfree-te-00.txt Feb., 1999 4. NETWORK STATE REPRESENTATION The overlay approach permits an IGP-independent representation of network state information used by route computation algorithms. This has both advantages and disadvantages. The obvious dis- advantage is that each router must maintain separate representa- tions, one for the underlying IGP and one for constraint-based routing. The advantages, however, are as follows. First, a single representation may be developed for use over many IGPs. Second, the representation can be IGP-independent, thereby allowing new hierarchical encodings of aggregated state information which are different from those of the underlying IGPs. For example, an OSPF internal router presently maintains only reachability information about destinations in external areas and the path costs. It is conceivable that constraint- based routing representations of external areas may be more complex. It therefore seems best to decouple the two representations. Clearly, when the underlying IGP is not link state, a state representation for CR is anyway required. In this draft, we do not intend to describe a particular network state representation for the CR overlay. Certain basic features of such a representation, however, are to be noted: the network state representation must encode the network topology. In the case of hierarchical routing, a representation of the aggregated topology information may be required. For each router in the topology, a unique identifier (e.g., an IP address) would be required. The representation of point-to-point and broadcast links may be based on existing representations, such as in OSPF [2,9]. The specification of link metrics would require identification of links, via interface or subnet IP addresses. Nodal metrics in addition to link metrics would have to be represented. The network state representation used by the CR overlay is completely autonomous of the underlying IGP. The network state information can be incrementally built in a router through the receipt of CR update messages. In the case of a link state IGP, the CR module at a router utilizes the link state IGP topology representation only to identify the local forwarding tree branches, as described in [2]. 5. ROUTE COMPUTATION It must be recognized that a variety of schemes can be used to compute constraint-based routes. Indeed, entirely different routing paradigms may be used to support traffic engineering, from optimized multipath [7] to fine-grain flow-based routing. In this regard, our view is that the routing mechanisms developed for traffic engineering must provide broad support [Page 4] Internet Draft draft-rajagopalan-igpfree-te-00.txt Feb., 1999 for different routing schemes. This essentially implies that it must be possible for an individual AS to use possibly proprietary route computation and forwarding scheme within the general framework of a (standard) overlay CR scheme. Such an approach also suggests that it must be possible to realize any proprietary routing metric that is required for path computation. The implication of these requirements is that constraint-based routing must be modular, with certain modules being dynamically replaceable. The implementation aspects of this are beyond the scope of this draft. 6. PATH ESTABLISHMENT While path establishment for traffic engineering might rely on some explicit routing feature of protocols such as LDP or RSVP, additional mechanisms may be used for routing traffic. For instance, per packet forwarding decisions over multiple paths may be made, as in OMP [7]. In general, explicit routing is an important mechanism to realize constraint-based routing and it must be specified. Other forwarding mechanisms may be realized in conjunction with the associated path computation procedures. 7. SUMMARY AND CONCLUSIONS Constraint-based routing is composed of several components, as described in this draft. Whether implemented as an overlay or through the extension of link state IGPs all these components must be realized. The extension of existing IGPs is useful in realizing only one of these components, i.e., update propagation. Even the representation of network state information may not be possible via direct extension of an existing link state IGP. Other components such as route computation and path setup require new mechanisms to be developed. This draft proposed the development of constraint-based routing mechanisms independent of existing IGPs. This approach has some advantages, as described. The CR overlay may be considered a separate routing protocol, just as any extension of existing IGPs for CR results in a parallel routing protocol. However, as pointed out in [2], a CR overlay can utilize the underlying IGP to build and maintain the network topology view essential for forwarding CR updates efficiently. This draft also proposed that the CR overlay be modular, allowing new route computation procedures and metrics be implemented in a dynamic manner. The details of this may be depend on specific implementations and are outside the scope of this draft. [Page 5] Internet Draft draft-rajagopalan-igpfree-te-00.txt Feb., 1999 REFERENCES [1] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS", Internet Draft, draft-ietf-mpls-traffic-eng-00.txt, October 1998 [2] B. Rajagopalan and Q. Ma, "An Overlay Model for Constraint- Based Routing," Internet Draft, draft-rajagopalan-overlay-00.txt, January, 1999. [3] H. Smit and T. Li, "IS-IS Extensions for Traffic Engineering," Internet Draft, draft-ietf-isis-traffic-00.txt, February, 1999. [4] D. M. Yeung, "OSPF Extensions for Traffic Engineering," Internet Draft, draft-yeung-ospf-traffic-00.txt, February, 1999. [5] T. Li, G. Swallow and D. Awduche, "IGP Requirements for Traffic Engineering with MPLS", Internet Draft, draft-li-mpls-igp-te- 00.txt, February, 1999. [6] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments," RFC 1195, December, 1990. [7] C. Villamizar, "MPLS Optimized Multipath (MPLS-OMP)," Internet Draft, draft-villamizar-mpls-omp-01.txt, February, 1999. [8] E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A Framework for QoS-Based Routing," RFC 2386, August, 1998. [9] J. Moy, "OSPF Version 2", RFC 2328, April, 1998. Author's Address Bala Rajagopalan NEC C&C Research Labs 4 Independence Way Princeton, NJ 08540 U.S.A Ph: +1-609-951-2969 Email: braja@ccrl.nj.nec.com *** This draft expires on August, 26, 1999 *** [Page 6]