S. Ganti N. Seddigh B. Nandy Tropic Networks N. Harrison BT INTERNET DRAFT S. Choudhury Internet Engineering Task Force Marconi Traffic Engineering Working Group Expires August, 2002 February, 2002 DS-TE Requirements for Support of multiple-COS on an E-LSP 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract The current DS-TE requirements document [DSTEREQ] focuses on solutions that enable carrying a single Class of Service on an LSP. This document extends the work in [DSTEREQ] by motivating the need to support a DS-TE solution that enables multiple COS on an E-LSP. The document further defines the requirements for such an approach. The requirements are developed such that this approach would be an optional extension to the existing DS-TE. 1.0 Introduction Recently there have emerged a number of initiatives with the goal of improving on the current best-effort service model delivered by IP networks. Traffic Engineering (TE) is one key element in the tool-kit to deliver such improved service. Initial TE solutions [TEREQ] used MPLS (Multi-Protocol Label Switching) [MPLSARCH] to steer best-effort traffic away from shortest-path congested links. Such an approach is intended to distribute load across the network and improve overall network performance. At the same time, DiffServ [DSARCH] has defined a number of traffic conditioning mechanisms and Per-Hop-Behaviour which can be combined to provide QoS assurance and multiple classes of service in IP networks. The Diff-Serv approach has recently been extended to enable multiple classes of service to be carried over a single LSP [DIFFMPLS]. [DIFFMPLS] defines two types of LSPs to support DiffServ over MPLS: E-LSPs (EXP-inferred-LSPs) and L-LSPs (Label-Only- Inferred-LSPs). The L-LSP approach is intended to carry a single class of traffic per LSP. LSRs use per-LSP state information to determine the PHB to apply against packets of an LSP. E-LSPs allow multiple classes of traffic to be carried over a single LSP. In this case, the MPLS Label-Stack-Entry EXP bits indicate the PHB to be applied against a particular packet. DS-TE using E-LSPs. DiffServ-Aware Traffic Engineering (DS-TE) combines Diffserv and Traffic Engineering in an effort to provide end-to-end service guarantees within an MPLS network. Incoming traffic is mapped to paths within the network that satisfy certain engineering constraints on a per-class basis. The current DS-TE Requirements document [DSTEREQ] focuses on the requirements to support carrying a single class of traffic on LSPs. This document expands on [DSTEREQ] to discuss the DS-TE requirements to carry multiple classes of traffic on an LSP. We also elaborate and consider various application scenarios where it may be desirable to support DS-TE with multiple classes of traffic on an LSP. It is understood that not all DS-TE networks will want to support multiple classes of traffic per LSP. As such the requirements defined herein are intended to be optional and to co-exist with [DSTEREQ]. The terms class and OA (ordered aggregate) are used inter-changeably throughout this document. 2.0 Current DS-TE Requirements [DSTEREQ] presents the service provider requirements for support of Diff-serv aware traffic engineering using the LSPs. While [DSTEREQ] discusses requirements for a network with multiple classes of service, it focuses on using LSPs that carry essentially a single class of service. In certain parts of the document it discusses use of LSP with multiple classes of service however, for the purposes of TE (route advertisements, MPLS signalling path computation and admission control), these multiple classes are treated as a single class. Five possible options exist in relation to the usage of L-LSPs and E-LSPs in a general DS-TE framework: a) Using E-LSPs to carry traffic entirely from a single OA b) Using E-LSPs to carry traffic for multiple OAs all sharing a single set of traffic parameters and with single set of pre-emption/protection attributes c) Using E-LSPs to carry traffic from multiple OAs, each with their own set of traffic parameters but with single set of pre-emption/protection attributes. d) Using E-LSPs to carry traffic from multiple OAs, each with their own set of traffic parameters and pre-emption/protection attributes. e) Using L-LSP to carry traffic from a single OA [DS-TE-REQ] describes mapping of single-OA traffic on to MPLS tunnnels using options (a) and (e). It allows support for carrying multiple-OA traffic using option (b) on an aggregate basis only. i.e with a single set of constraints and thus to treat all the OAs as a single class for the purposes of TE. The document does not discuss options (c) and (d). At the current time, it does not appear that there is any interest in supporting option (d) as pre-emption priorities apply to the entire LSP and not to a subset of traffic on that LSP. This document therefore presents the requirements to support option (c) above as an extension to [DSTEREQ]. The following section focuses on various application scenarios where it may be desirable to utilize the approach of (c). 3.0 DS-TE Application Scenarios - Multiple COS per LSP There are a number of good reasons why service providers are interested in using DS-TE to carry multiple classes of service on an LSP. The key reaons can be summarized as follows: a) Ability to carry multiple classes of a single customer traffic on the same LSP b) Reduction in number of LSPs in the network (one LSP instead of "x" LSPs to carry "x"classes) c) One DS traffic pipe that is easy to manage, apply path protection and restoration capabilities. The following are application scenarios where E-LSPs can be used in a DS-TE framework to carry multiple classes of traffic each with their own set of BW constraints. 3.1 Using E-LSPs based on aggregate traffic requirements: An MPLS/IP network may desire to carry its VoIP data and signalling on the same LSP yet treat the two traffic types as two different classes. For example, it may want to map its VoIP data to be treated by the EF PHB and the VoIP signaling to be treated by the AF1x PHB. In such cases, the provider will likely not want to send the VoIP data and signaling on different LSPs as they may have different delay behaviour. It can be argued that if the ratio of two different traffic types is known/constant then it can be carried on multiple OAs but signalled with a single traffic parameter and advertised with a single advertisement. However, such a scheme is extremely inflexible. Applications continually evolve as may the ratio of traffic mixes. Thus, it is unwise to embed assumptions about application behaviour in the DS-TE solutions. 3.2 Using E-LSPs with multiple class bandwidth requirements A second example involves the use of Layer 2 VPNs. In this context, service providers in the Metro space are looking to provide TLS (Transparent LAN) services. The SP may provide Layer 2 VPNs for its end customers where the key SLAs revolve around availability and QoS. In such cases, the SLA may specify a single protection level for the entire customer aggregate while specifying multiple classes of service within the VPN aggregate. In such networks, sending different classes of service on different LSPs will immensely complicate the ability to offer robust and measurable availability and QoS SLAs to such customers. Hence it is desirable to carry all the customer's classes of traffic on a single LSP and yet to treat each class differently. A third example relates to an application where a service provider wishes to provide bandwidth borrowing between the different classes of traffic for a specific customer. Thus, service providers may want to provide SLA gurantees for each of the classes carried in the E- LSP. In addition, at the same time, the provider may wish to apply queuing technology that allows bandwidth borrowing between the OAs of a customer. Thus, if a customer is not using his allocated AF capacity, he may wish to allow his BE traffic to use that capacity that he has purchased from the service provider. 3.3 Using E-LSPs to reduce number of LSPs in the network A fourth example relates to path protection and restoration which are 2 key requirements in next generation IP networks. Sending a single customer's traffic on multiple LSPs causes a larger number of LSPs in the network. It also causes issues with ensuring that the SONET like restoration times are met due to the sheer volume of LSPs that have to be resignalled or redialed when links go down. These mechanisms are more easily applied to a single LSP than to a group of LSPs. Yet another application scenario, as a fifth example could be, the case of a small service provider with a simple network topology and a limited set of service classes. Such a provider could be interested in limited DS-TE capabilities (i.e. simple aggregate load balancing). In this case, a simple path computation algorithm that routes all classes together can be used to select a single LSP (e.g. a shortest path applied on the pruned network). Limiting each LSP to only a single OA would, at minimum, double the number of LSPs in the network - which may be highly undesirable for the SP. Another key benefit of E-LSPs has to do with scalability. L-LSP or single OA per E-LSP will cause the number of LSPs in the network to increase by a factor of at least two and in some cases, three, four or larger. The number of LSPs is a scalability concern for a number of reasons. Firstly, it increases the time required during hitless restart. Secondly, it is of concern for RSVP state management.Another important advantage of E-LSPs is in the area of network maintenance and administration. When trouble-shooting issues related to a customer's traffic, it is easier for the network operator to examine a single LSP instead of multiple LSPs. 4.0 Technical Requirements To Support DS-TE with multiple COS per LSP In general, the requirements to support DS-TE with multiple COS can be considered as extensions to the existing requirements. To support such an approach, the following are required: (i) IGP extensions to advertise reserved or available bandwidth on a per-OA, PSC or per-class or per-ClassType basis for each link. (ii) A path computation algorithm that computes a path at the LER (iii) Extensions to allow signaling of per-class parameters within an E-LSP (iv) A Pre-emption priority (setup and hold) which is applied to the whole E-LSP together (not per-OA). (v) Admission Control is applied per-class per-link when the E-LSP is signalled. (vi) Traffic Conditioning is applied at the LER against traffic mapped to the E-LSP. (vii) EXP bits are used to signal the PHB treatment for individual packets within the E-LSP (viii) Diffserv PHB mechanisms are used in LSR routers to differentially treat the traffic within a single E-LSP. There are no new requirements for IGP protocol extensions other than the one already described in the document Protocol extensions for support of DS-TE [DSPROTO]. Requirement (ii) is typically satisfied by a proprietary implementation by vendor devices. When setting up an E-LSP, the path is computed based on the available resources in the network and the path that fits best the resource requirements of all the OAs together, i.e, the path computation procedure has to a take a bandwidth vector of all OAs, bandwidth vector of all available link bandwidths per-OA and compute the path based on certain constraints. Requirement (iii) is discussed in section 4.1 below. The per-OA signaling is needed for proper bandwidth accounting and to advertise available resources in the node to the network. Requirement (iv), (v), (vi), (vii) and (viii) are currently addressed by the mechanisms specified in [DIFF-MPLS]. 4.1 LSP Signalling Extensions The current Diffserv-MPLS extensions allow only a single set of traffic parameters to be signalled per LSP. e.g in RSVP-TE, it is allowable to signal only a single Tspec. To support E-LSP, the signalling protocols need to be extended to allow specification of multiple traffic parameters. Further, there needs to be a means of mapping these traffic parameters to an OA, PSC or class. There exist two current proposals to address this issue: [GANTI] and [IOVANNA]. This document uses the terms BA, OA, PSC, E-LSP, L-LSP, and PHB as they are defined in [DIFF-MPLS] and [DIFFTERM]. 5.0 Other Requirements The following are additional requirements for solutions to support multiple COS on DS-TE: (i) Any protocol extensions should be optional. (ii) The solution should be an extension of the current [DSTEREQ] documents (iii) The solution should be backwards compatible with DS-TE, TE and Diffserv (iv) It should not introduce major scalability issues above and beyond what is introduced by the current DS-TE (v) It should allow dynamic adjustment of parameters for the LSR's scheduler (vi) It should satisfy the application scenarios outlined in [DSTEREQ] 6.0 Security Considerations This document does not introduce any new security issues beyond those inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms proposed for those technologies. 7.0 References [TEREQ] Awduche D et al, "Requirements for Traffic Engineering Over MPLS", RFC 2702, January 2001 [DIFFMPLS] Rosen E et al, "MPLS Support of Differentiated Services" draft-ietf-mpls-diff-ext-08.txt, February 2001. [DIFFTERM] Grossman D, "New Terminology for Diffserv", Internet Draft, draft-ietf-diffserv-new-terms-04.txt, March 2001 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet draft, , February 2001 [CR-LDP] Jamoussi et al, "Constraint-Based LSP Setup using LDP", Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, February 2001. [PHBID] Brim S et al, "Per Hop Behaviour Identification Code", RFC 2836, May 2000. [MPLSARCH] Rosen E et al, "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001 [DSTEREQ] Le Faucheur F et al, "Requirements for support of Diff- Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te-reqts-03.txt, February 2002. [DS-PROTO] Le Faucheur F et al, "Protocol Extensions for support of Diffserv-Aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-proto-00.txt, February 2002 [GANTI] Ganti, Seddigh, Nandy, "MPLS Support of Differentiated Services using E-LSP", draft-ganti-mpls-diffserv-elsp-01.txt, November 2001. [IOVANNA] Iovanna, et al, "Definition of the MPLS FlowSpec for RSVP-TE", draft-iovanna-rsvp-mpls-flowspec-00.txt, October 2001. 8.0 Author's Address Sudhakar Ganti Tropic Networks Inc. 135 Michael Cowpland Drive Kanata, Ontario, Canada, K2M 2E9 Email: sganti@tropicnetworks.com Nabil Seddigh Tropic Networks Inc. 135 Michael Cowpland Drive Kanata, Ontario, Canada, K2M 2E9 Email: nseddigh@tropicnetworks.com Biswajit Nandy Tropic Networks Inc. 135 Michael Cowpland Drive Kanata, Ontario, Canada, K2M 2E9 Email: bnandy@tropicnetworks.com Sanjaya Choudhury Marconi Email: sanjaya.choudhury@marconi.com Neil Harrison British Telecom Heath Bank, Iugby Road, Harleston South Hampton, UK Email: neil.2.Harrison@bt.com