Internet Draft Francois Le Faucheur Thomas D. Nadeau Cisco Systems, Inc. Angela Chiu AT&T William Townsend Tenor Networks Darek Skalecki Nortel Networks IETF Internet Draft Expires: January, 2001 Document: draft-lefaucheur-diff-te-reqts-00.txt July, 2000 Requirements for support of Diff-Serv-aware MPLS Traffic Engineering 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. Abstract This document defines the requirements for support of Diff-Serv- aware MPLS Traffic Engineering on a per-Class-Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. A companion document [DIFF-TE-EXT] proposes actual extensions to OSPF, ISIS, RSVP and CR-LDP in order to meet those requirements. Le Faucheur, et. al 1 Requirements for Diff-Serv Traffic Engineering July 2000 1. Introduction As Diff-Serv becomes prominent in providing scalable multi-class of services in IP networks, performing traffic engineering at a per- class level instead of an aggregated level is needed to further enhance networks in performance and efficiency. By mapping a traffic trunk in a given class on a separate LSP, it allows the traffic trunk to utilize resources available on both shortest path(s) and non-shortest paths and follow paths that meet constraints which are specific to the given class. It also allows each class to select the proper protection/restoration mechanism(s) that satisfy its survivability requirements in a cost effective manner. Besides the set of parameters defined for the general aggregate TE [TE-REQ], a new set of per-class parameters needs to be provided at each LSR interface and propagated via extensions to the IGP (ISIS/OSPF) [TEWG-FW]. Furthermore, the per-class parameters can be aggregated into per-Class-Type parameters. The main motivation for grouping a set of classes into a Class-Type is to improve the scalability of the IGP link state advertisements by propagating information on a per-Class-Type basis instead of on a per-class basis. This approach also has the benefit of allowing better bandwidth sharing between classes in the same Class-Type. A Class-Type [TEWG-FW] is defined as a set of classes that satisfy the following two conditions: 1) Classes in the same Class-Type possess common aggregate maximum and minimum bandwidth requirements to guarantee the required performance level. 2) There is no maximum or minimum bandwidth requirement to be enforced at the level of an individual class within the Class- Type. One can still implement some "priority" policies for classes within the same Class-Type in terms of accessing the Class-Type bandwidth (e.g. via the use of preemption priorities). An example of Class-Type comprising multiple Diff-Serv classes is a low-loss Class-Type that includes both AF1-based and AF2-based Ordering Aggregates. Note that with per Class-Type TE, Constraint-Based Routing is performed with bandwidth constraints on a per Class-Type basis but LSPs may carry a single Diff-Serv class (Ordered Aggregate) with Diff-Serv scheduling (i.e. PHB) performed separately for each class. Diff-Serv scheduling parameters for a given class within a Class- Type may be automatically adjusted by the LSRs based on the bandwidth of all LSPs currently established for each class within the Class-Type. Le Faucheur et. al 2 Requirements for Diff-Serv Traffic Engineering July 2000 In this document, we will only discuss "per Class-Type TE" because "per Class TE" can be viewed as a special case of per Class-Type TE (where each Class-Type is degenerated into a single Diff-Serv class). This document focuses on intra-domain operations. Inter-domain operations is for further study. The following sections detail the requirements on OSPF/ISIS, RSVP/ CR-LDP, Constraint Based Routing and MPLS MIBs for support of MPLS Traffic Engineering on a per-Class-Type basis. 2. Requirements for ISIS/OSPF Extensions [OSPF-TE] and [ISIS-TE] define extensions to OSPF and ISIS for support of (aggregate) MPLS Traffic Engineering. In this section we define the requirements on OSPF and ISIS for support of Diff-Serv Traffic Engineering on a per-Class-Type basis. These requirements are expected to require further extensions to OSPF and ISIS. Such extensions are proposed in [DIFF-TE-EXT]. Given that there are hard limits imposed by ISIS/OSPF TLVs, the TLV space must be used frugally. An additional concern is that the amount of information advertised by the IGP directly affects the scalability of the solution. These considerations strongly influence the requirements defined in this section. As pointed out in [TEWG-FW], the IGP needs to advertise separate "TE information" for each Class-Type. We focus now on detailing what this "TE information" should be. For Constraint Based Routing to be able to compute paths which satisfy different bandwidth constraints for each Class-Type, the IGP needs to advertise different "Unreserved Bandwidth" information for each Class-Type. Moreover, we propose that the preemption attribute defined in [TE-REQ] be retained for all Class-Types. Thus, the IGP needs to advertise "Unreserved Bandwidth" at each preemption level for each Class-Type. For the bandwidth constraints to be effectively different for each Class-Type, LSRs need to allow configuration for every link of a "Maximum Reservable Bandwidth" for each Class-Type. Clearly, the "Unreserved Bandwidth" advertised for each Class-Type takes into account the "Maximum Reservable Bandwidth" configured for the corresponding Class-Type. Consequently, Constraint Based Routing can compute paths for the different Class-Types without receiving the "Maximum Reservable Bandwidth" for each Class-Type from the IGP. Thus we feel that the IGP need not advertise the Maximum Reservable Bandwidth for each Class-Type. We note that the Maximum Reservable Bandwidth for each Class-Type could have been used by Constraint Based Routing to enhance route computation in some situations (e.g. Le Faucheur et. al 3 Requirements for Diff-Serv Traffic Engineering July 2000 as a tie breaker), but we feel this does not justify the extra overhead in IGP advertisement. Current IGP extensions for (aggregate) TE [OSPF-TE][ISIS-TE] specify advertisement of the Maximum Reservable Bandwidth for (aggregate) TE. Note that this document does not propose that this be changed. Other TE attributes already advertised by the IGP (i.e. resource/color) need not be advertised per Class-Type as those will be applicable to all Class-Types. It is desirable to be able to avoid under-utilizing aggregate resource. To achieve this, it is necessary to allow the sum of the configurable Maximum Reservable Bandwidth of all Class-Types be larger than a configurable Maximum Reservable Aggregate Bandwidth (i.e. aggregate across all Class-Types). At the same time, it is desirable to be able to avoid over-utilizing the aggregate resource. To achieve this, it is necessary to be able to enforce this Maximum Reservable Aggregate Bandwidth; in other words it is necessary to ensure that the sum of all LSPs across all Class-Types never exceeds the Maximum Reservable Aggregate Bandwidth. For example, a 10Gb/s link may be configured to allow: - Class-Type 0 (BE) to reserve up to 9 Gb/s - Class-Type 1 (e.g. real time including EF) to reserve up to 5 Gb/s - Class-Type 2 (eg low loss including AF1 and AF2) to reserve up to 8 Gb/s and at the same may be configured to allow: - on an aggregate basis, the sum of all Class-Types to reserve up to 10 Gb/s. Therefore, a path computed by the Constraint Based Routing for an LSP of Class-Type N must ensure that this LSP fits within the remaining Class-Type N bandwidth AND that this LSP fits within the remaining Aggregate bandwidth. One way to achieve this, would be: - for each Class-Type, that IGP uses the "Unreserved Bandwidth for Class-Type N" to advertise the Class-Type N bandwidth currently unreserved (i.e. the difference between the Maximum Reservable Bandwidth for Class-Type N and the bandwidth reserved by existing Class-Type N LSPs), - in addition, that IGP separately advertises the "Unreserved Aggregate Bandwidth" (i.e. the difference between the Maximum Reservable Aggregate Bandwidth and the bandwidth reserved by existing LSPs of all Class-Types) Le Faucheur et. al 4 Requirements for Diff-Serv Traffic Engineering July 2000 - have Constraint Based Routing ensure that a new Class-Type N LSP fits both in the received "Unreserved Bandwidth for Class-Type N" and in the "Unreserved Aggregate Bandwidth". Such an approach has the drawbacks that it would require that N+1 "unreserved bandwidth" information be advertised by the IGP when N Class-Types are supported, and that it requires the node performing Constraint Based Routing to meet a double bandwidth constraints. Instead we propose that: - for each Class-Type, that IGP uses the "Unreserved Bandwidth for Class-Type N" to directly advertise the amount of bandwidth that is effectively useable by Class-Type N. This is computed as the smaller of these two values: o The Class-Type N bandwidth currently unreserved (i.e. the difference between the Maximum Reservable Bandwidth for Class-Type N and the bandwidth reserved by existing Class- Type N LSPs). o The aggregate bandwidth currently unreserved (i.e. the difference between the Maximum Reservable Aggregate Bandwidth and the bandwidth reserved by existing LSPs of all Class-Types). - have Constraint Based Routing ensure that a new Class-Type N LSP simply fits in the received "Unreserved Bandwidth for Class-Type N". Such an approach only requires that N "unreserved bandwidth" information be advertised by the IGP when N Class-Types are supported, and only requires that the node performing Constraint Based Routing meets a single bandwidth constraints. We propose to begin by allowing a total of 4 Class-Types (i.e., 3 beyond the existing one aka. Class-Type 0). This is expected to be sufficient for practical deployments in the foreseeable future. As an example, a total of three Class-Types already allow support of separate bandwidth control for Real-Time, Low-Loss and Best Effort, while allowing multiple classes within each Class-Type (e.g. AF1 and AF2 flavors of "Low-Loss"). More Class-Types could be defined in the future if required. Implementations of Diff-Serv Traffic Engineering in compliance with this specification MUST support at least a total of 2 Class-Types and MAY support a total of 3 or 4 Class-Types. The IGP must be able to only advertise the Bandwidth Information for the subset of Class-Types actually used in the network (i.e. not always advertise the Unreserved Bandwidth information for all the new Class-Types). It may be desirable to prevent a Class-Type from being starved by others. In the example given above where we defined three Class- Types, it may be useful to be able to always ensure that some amount of Class-Type 0 LSPs can be routed over that link (i.e. to prevent Le Faucheur et. al 5 Requirements for Diff-Serv Traffic Engineering July 2000 Class-Type 1 LSPs and Class-Type 2 LSPs from reserving up to 100% of the maximum reservable aggregate bandwidth which would result in Class-Type 0 LSPs not having any access to the capacity of that link). Such capability would require the ability from the IGP to advertise an optional "minimum reservable bandwidth" per Class-Type. This is not seen as an immediate requirement but could be defined in the future if required. 3. Requirements for RSVP/CR-LDP Extensions [RSVP-TE] and [CR-LDP] define extensions to RSVP and LDP for support of (aggregate) MPLS Traffic Engineering. [DIFF-MPLS] defines the extensions to RSVP and LDP for support of Diff-Serv over MPLS. In this section we define the requirements on RSVP and CR-LDP for support of Diff-Serv Traffic Engineering on a per-Class-Type basis. These requirements are expected to require further extensions to RSVP and CR-LDP. Such extensions are proposed in [DIFF-TE-EXT]. In order for an LSR to perform resource availability checking for an LSP that belongs to a certain Class-Type, the LSR needs to be made aware through RSVP/CR-LDP signaling of the Class-Type associated with the LSP. To that end, we propose that RSVP/CR-LDP be extended to be able to signal the Class-Type. We identify the following backward compatibility requirements for the RSVP/CR-LDP extensions: - operations in heterogeneous environments need to be supported for smooth migration, where some LSRs are Diff-Serv-TE-capable (as defined in this specification) while some other LSRs are not Diff-Serv-TE-capable (i.e. support (aggregate) TE only) - in heterogeneous environments, the solution needs to allow establishment of Class-Type 0 LSPs across paths combining Diff- Serv-TE-capable LSRs and non-Diff-Serv-TE-capable LSRs - in heterogeneous environments, the solution needs to ensure that a non-Diff-Serv-TE-capable LSR would reject establishment of a Class-Type N (N=1,2,3) LSP. The admission control algorithm implemented for LSP establishment must locally maintain different variables which keep track of the currently unreserved bandwidth for each Class-Type. These unreserved bandwidth variables must be updated in accordance with the approach discussed in the previous section for enforcement of the Maximum Reservable Aggregate Bandwidth across all Class-Types, if so configured on an LSR. In particular, when admitting a Class-Type N LSP, the LSR must take into account this Class-Type N LSP to update the variables tracking the unreserved bandwidth for Class-Type N, as well as to potentially update the variables tracking the unreserved bandwidth for the other Class-Types (since the new LSP eats-up Le Faucheur et. al 6 Requirements for Diff-Serv Traffic Engineering July 2000 Aggregate bandwidth which in turn may reduce the amount of LSP that may be established in other Class-Types). 4. Requirements for Constraint Based Routing Extensions In order for Constraint Based Routing to support Diff-Serv TE on a per-Class-Type basis, the Constraint Based Routing algorithm need to be capable of taking into account the "Unreserved Bandwidth for Class-Type N" when computing a path for a Class-Type N LSP. 5. Requirements for MIB Extensions In order for an LSR to support the configuration and monitoring of Diff-Serv Traffic Engineering certain enhancements to some of the existing MPLS Management Information Bases (MIBs) will be required. [LSRMIB] defines the MPLS Label Switch Router MIB (LSR MIB) which contains objects useful for the management and configuration of MPLS LSPs. [TE MIB] defines the MPLS Traffic Engineering MIB (TE MIB) which contains objects useful for the management and configuration of MPLS Traffic Engineered Tunnels. In particular, the MIB extensions need to: - track for each MPLS interface, the Maximum Reservable Bandwidth configured for each Class-Type. - track for each MPLS interface, the Maximum Reservable Aggregate Bandwidth configured. - track for each LSP, the Class-Type associated with the LSP. On the Head-End LSRs, the Class-Type is configured as part of the tunnel configuration. On other LSRs, the Class-Type is associated with the LSP at establishment time based on signaled information. Additional details of these changes will be provided in forthcoming versions of this draft. It is the authors' intent to transfer these MIB requirements to future versions of the MPLS TE and the MPLS LSR MIBs. It is not the intent of this document to define the SMI required for the MIB enhancements; rather, it is to flesh out and define the details of these changes in the context of this document. 6. Security Considerations The solution developed to address the requirements defined in this document must address security aspects. 7. Acknowledgments This document has benefited from discussions with Carol Iturralde and Rob Goguen. Le Faucheur et. al 7 Requirements for Diff-Serv Traffic Engineering July 2000 References [TE-REQ] Awduche et al, Requirements for Traffic Engineering over MPLS, RFC2702, September 1999. [TEWG-FW] Awduche et al, A Framework for Internet Traffic Engineering, draft-ietf-tewg-framework-01.txt, May 2000. [DIFF-TE-EXT] Le Faucheur et al, Extensions to IS-IS, OSPF, RSVP, CR-LDP and MPLS MIBs for support of Diff-Serv-aware MPLS Traffic Engineering, draft-lefaucheur-diff-te-ext-00.txt, July 2000. [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-katz-yeung-ospf-traffic-01.txt, April 2000. [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- ietf-isis-traffic-01.txt, May 1999. [RSVP-TE] Awduche et al, "Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February 2000. [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", draft- ietf-mpls-diff-ext-05.txt, June 2000 [LDP] Andersson et al., "LDP Specification", draft-ietf-mpls-ldp- 06.txt, October 1999 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", draft-ietf-mpls-cr-ldp-03.txt, October 1999 [TEMIB] Srinivansan, C., and A. Viswanathan, "MPLS Traffic Engineering Management Information Base Using SMIv2", draft-ietf- mpls-te-mib-03.txt, March 10, 2000. [LSRMIB] Srinivansan, C., Viswanathan, A., and T. Nadeau "MPLS Label Switch Router Management Information Base Using SMIv2", draft- ietf-mpls-lsr-mib-04.txt, April 26, 2000. Authors' Address: Francois Le Faucheur Cisco Systems, Inc. Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France Phone: +33 4 92 96 75 64 Email: flefauch@cisco.com Angela Chiu AT&T Labs Le Faucheur et. al 8 Requirements for Diff-Serv Traffic Engineering July 2000 Rm 4-204,100 Schulz Dr., Red Bank, NJ 07701 USA Phone: +1 (732) 345-3441 Email: alchiu@att.com William Townsend Tenor Networks 100 Nagog Park Acton, MA 01720 Phone: +1-978-264-4900 Email: btownsend@tenornetworks.com Thomas D. Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9 Phone: +1-613-765-2252 Email: dareks@nortelnetworks.com Le Faucheur et. al 9