INTERNET DRAFT S. Ganti Internet Engineering Task Force N. Seddigh Differentiated Services Working Group B. Nandy Expires May, 2002 Tropic Networks November, 2001 MPLS Support of Differentiated Services using 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 (Diffserv Traffic Engineering) approach can only be used with a single OA (Ordered Aggregate) per E-LSP or with L-LSP. It cannot be used to carry multiple OAs per E-LSP. This document motivates reasons where it is desirable to carry multiple OAs per E-LSP. In addition, the document proposes RSVP-TE and CR-LDP extensions to facilitate signalling of multiple traffic parameters for a single E-LSP. ID Summary SUMMARY This document addresses an open issue in providing Diffserv Traffic Engineering solution using E-LSP. The proposal outlines methods to signal bandwidth requirements for multiple OAs when setting up E- LSPs. Ganti, Seddigh, Nandy [Page 1] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 RELATED DOCUMENTS draft-ietf-tewg-diff-te-reqts-01.txt draft-bitar-rao-diffserv-mpls-01.txt draft-boyle-tewg-ds-nop-00.txt draft-kompella-tewg-bw-acct-00.txt WHERE DOES IT FIT IN THE PICTURE OF SUB-IP WORK It belongs in the TE WG WHY IS IT TARGETED AT THIS WG This document describes Diffserv Traffic Engineering possibilities using E-LSP. JUSTIFICATION Current Diffserv Traffic Engineering solutions are restricted to L- LSP or E-LSPs which carry only a single Ordered Aggregate (OA). There is a clear need to extend these DS-TE solutions to include carrying of multiple OAs per E-LSP. This document proposes possible alternatives to address this. 1.0 Introduction Diffserv over MPLS [DIFF-MPLS] describes methods to setup diffserv- aware traffic engineering tunnels in an MPLS network. The solution approaches discussed in [DIFF-MPLS] uses two types of LSPs to setup the TE tunnels. These are commonly referred to as E-LSPs (EXP- inferred-LSPs) and L-LSPs (Label-Only-Inferred-LSPs). The L-LSP approach is intended to carry a single OA per LSP. E-LSPs allow multiple OAs to be carried over a single LSP. In this case, the MPLS Label-Stack-Entry EXP bits indicate the PHB (Per Hop Behavior) to be applied against a particular packet. 1.1 Existing Diffserv Traffic Engineering (DS-TE) Framework The existing DS-TE requirements document [DS-TE-REQ] makes two key assumptions: (1) That DS-TE will be deployed using L-LSPs or E-LSPs with a single OA. (2) That IGP route advertisement scalability issues can only be solved if bandwidth accounting and advertisement is done on an aggregate basis which combines classes. 1.1.1 Single OA per E-LSP The first point above assumes that SPs are not interested in using E-LSPs with multiple OAs in a DS-TE framework. The justification given for this restriction is that Service Providers desire only per-class routing. i.e. Service providers would like to send different classes of traffic on different LSPs (different routes). The implicit assumption is that Service Providers would never choose to send multiple classes of traffic along the same LSP. e.g. They Ganti, Seddigh, Nandy [Page 2] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 would never choose to send EF-based traffic and BE-based traffic for a customer on the same LSP. 1.1.2 Support of Class-Type The second point in section 1.1 is addressed through the [DS-CT] draft. In this draft, the notion of classtype (CT) is proposed as a means of addressing scalability issues. Thus, the IGP protocol route advertisements are done at the granularity of a CT and the signalling protocol would also reserve bandwidth at the granularity of a CT. For example, voice would constitute a first CT and data a second CT. A class could directly map to a PHB Scheduling class (PSC) while a CT could be an aggregation of a few PSCs together for bandwidth accounting and advertisement purposes. While use of CT is one means of addressing scalability issues, it comes at the cost of flexibility. Use of CT instead of classes means that a provider is unable to route different classes on different LSPs should they wish to do so. e.g. routing of AF1x and AF2x on separate LSPs. Two recent drafts propose alternative solutions that should facilitate routing of different classes on different LSPs. [KIREETI] discusses bandwidth accounting for DS-TE solutions. The document proposes a bandwidth accounting solution per-class admission control and per-class route advertisements. The proposal relies on a reuse of the existing 8 priority levels, making them synonymous with 8 classes of service. [BOYLE] proposes a DS-TE scheme that seeks to reuse existing protocol specifications. The draft recognizes the need for per-class or per- class-type bandwidth accounting as limited by the implementation (section 4.3). 1.2 The Need to support E-LSP based DS-TE with Multiple OAs This document asserts that there is a viable requirement for deploying complete E-LSP based DS-TE solutions. i.e a DS-TE solution where multiple classes of traffic (OAs) are carried over a single LSP. The E-LSP DS-TE solution should be complementary to L-LSP DS-TE solutions. The following are examples where E-LSPs can be used in a DS-TE framework to carry multiple OAs. Example 1: VoIP data and signalling are carried on the same LSP but treated as different classes. The easiest way of doing this is to transport the data and signalling on different OAs in a single LSP. It can be argued that if the ratio of two different traffic types is known 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. Ganti, Seddigh, Nandy [Page 3] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 Example 2: A key emerging application for E-LSPs with multiple OAs is L2VPN. In this context, service providers in the Metro space are looking to provide TLAN (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 aggregate while specifying multiple classes of service within the VPN. 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. Example 3: Path protection and restoration mechanisms 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 the 50ms restoration time is 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. Example 4: Earlier it was mentioned that service providers may want to provide SLA gurantees for each of the OAs 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. Example 5: A small service provider with a simple network topology and a limited set of service classes 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. Example 6: 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. 1.3 Technical Requirements & Solutions for E-LSP based DS-TE It is desirable to facilitate an E-LSP DS-TE approach where (i) resources are reserved and signaled on a per-OA basis within an E-LSP (ii) EXP bits are used to signal the PHB treatment for individual Ganti, Seddigh, Nandy [Page 4] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 packets within the E-LSP (iii) Diffserv PHB mechanisms are used in LSR routers to differentially treat the traffic within a single E- LSP. (iv) IGP extensions to advertise reserved or available bandwidth on a per-OA, PSC or per-class basis for each link. [BITAR] addresses requirement (iv) above. It proposes IGP protocol extensions that allow OSPF to advertise TE information either on a per-class or per-class-type basis. The actual flooded information corresponds to PSCs and groups of PSCs. The strength of this draft is its flexibility. Thus, it allows advertisement of BW information for EF, AF1x, AF2x etc, which can correspond to three different classes. At the same time, it allows advertisement of aggregate BW information for EF, AF and BE, which can correspond to 3 class types. The currently missing piece is a proposal to address per-OA signalling of bandwidth on a single E-LSP - requirement (i) above. 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. This document proposes RSVP-TE and CR-LDP extensions to facilitate signaling of multiple per-OA traffic profiles on a single E-LSP. This document uses the terms BA, OA, PSC, E-LSP, L-LSP, and PHB as they are defined in [DIFF-MPLS] and [DIFFTERM]. 2.0 Potential Solutions 2.1 Possible Solutions for RSVP-TE To extend per-OA signaling of E-LSPs for RSVP, there are at least three possible approaches. These are: 1) Creating a new E-LSP object, 2) Extending flowspec to signal Multiple FlowSpecs in a path message and 3) Extending the existing DiffServ object [DIFF-MPLS] definition. The first approach defines a new ELSP RSVP object to carry the traffic profile parameters. This object must be present in both the PATH and RESV messages. The second approach defines new SENDER_TSPEC and FLOWSPEC object types (using a new C-Type) [RSVP] and allows multiple such objects to be carried in the respective PATH and RESV messages. The third approach modifies and extends the specification of the DIFFSERV object as defined in [DIFFSERV-MPLS]. In addition, it requires this object to be present in both the PATH and RESV messages. 2.2 Possible Solutions for CR-LDP To extend per-OA signaling of E-LSPS for CR-LDP, there are at least two possible approaches: (i) Define a new ELSP TLV (ii) Modify the existing Traffic Parameters TLV. The first approach would simply Ganti, Seddigh, Nandy [Page 5] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 define a new optional TLV that would carry the per-OA traffic parameters being signalled. In this approach, the new TLV could co- exist with the old Traffic Parameter TLV which could be used to signal traffic profiles for the entire E-LSP. The second approach would require modifications to the CR-LDP specification to allow multiple Traffic Parameter TLVs and would also require a modification to the Traffic Parameter TLV itself. 2.3 Preferred Solution For CR-LDP, the approach of defining a new optional ELSP TLV is the preferred approach because it does not require any changes to the existing Traffic Parameter TLV. Thus, implementations that do not wish to signal per-OA traffic parameters can simply use the Traffic Parameter TLV to signal per-LSP traffic parameters as is currently the case. For RSVP, the first approach of creating a new ELSP object will ensure full backwards compatibility with previous definitions of RSVP. The second approach of defining new object types for the SENDER_TSPEC and FLOWSPEC objects warrants consideration as it reuses an existing object by extending a new C-Type. These new objects can also co-exist with a traditional SENDER_TSPEC and FLOWSPEC objects of C-Type 1. However, there is a slight potential that it may break existing RSVP implementations and in fact, the new object types have slight differences with the old object types for SENDER_TSPEC and FLOWSPEC. The third approach of modifying the proposed DIFFSERV object [DIFF-MPLS] appears to be the least desirable. This last approach would change the intended purpose of the DIFFSERV object, would require significant modifications to the object and would require the object to be present in the RESV message - something that is not currently required. Thus, the preferred approach to supporting per-OA signaling is to specify a new ELSP object for RSVP and a new ELSP TLV for CR-LDP. Such an approach would ensure a common solution for the two protocols and appears to be the most likely way of ensuring backwards compatibility with the existing protocol specification. Subsequent sections define the proposed ELSP object and TLV for RSVP and CR-LDP respectively. For completeness, the two alternative solutions for RSVP extensions are captured in the Appendix. (These solutions are described only for the sake of current reference and may be deleted in future versions of this document.) 3. RSVP Extensions To Support Per-OA signaling on E-LSPs In this section we describe RSVP extensions to support signaling of per-OA traffic profiles in an E-LSP. A single PATH/RESV message pair is used to signal traffic profiles for all the OAs in an E-LSP. The extensions specified in this section only relate to E-LSPs and do not apply to L-LSPs. 3.1 ELSP Object Definition Ganti, Seddigh, Nandy [Page 6] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 To signal traffic profiles for multiple OAs in a single E-LSP, a new ELSP object is defined. This object must be present in both the PATH and RESV messages. E-LSPs that do not wish to signal traffic profiles on a per-OA basis do not include this object. The ELSP object specification is captured below. ELSP Object: class = TBD, C_Type = 1 (need to get an official class num from the IANA with the form 0bbbbbbb) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | numTP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TP (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TP (numTP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 28 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. numTP : 4 bits Indicates the number of TrafficProfile entries included in the E-LSP Object. This can be set to any value from 0 to 8. Each TP entry provides the Traffic Profile associated with a PSC reservation for that E-LSP. The TP entry has the following format: Ganti, Seddigh, Nandy [Page 7] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | Reserved | PSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The PSC is encoded as specified in [PHBID]. The traffic profile parameters are the same as the basic Token Bucket parameters originally defined for RSVP. Since this is a Diffserv enabled network it is assumed that traffic profiles are only applied at the edge. Thus, there is no need to convey the exact parameters used by the marker at the domain edge. The parameters are signalled for admission control purposes only. If desired, the existing SENDER_TSPEC and FLOWSPEC objects MAY be used to signal bandwidth requirements for the entire traffic aggregate transmitted on an E-LSP. The ELSP specification does not preclude this type of signaling. 3.2 Handling of ELSP Object The ELSP object is optional with respect to RSVP. To signal per-OA traffic profiles on an ELSP, a sender MUST include the ELSP object in the PATH message. If the PATH message includes an ELSP object, the receiver MUST insert an ELSP object in the RESV message. The receiver MUST not include an ELSP object in the RESV message if the PATH message did not include an ELSP object. Each OA signaled in the ELSP object MUST have a corresponding set of EXP<->PHB mappings that were either pre-configured or signaled via the DIFFSERV object. If a node receives a PATH message with a ELSP object containing one or more OA traffic profiles without existing EXP<->PHB mappings, it should fail the reservation request for all the signaled OAs. In this case, the node SHOULD generate a PATH_ERR message with error value of 'Unsupported PSC'. A TE solution seeking to use preconfigured EXP<->PHB mapping with signaled per-OA traffic profiles would send a PATH message without the DIFFSERV object but with the ELSP object. A TE solution with signaled EXP<->PHB mapping and signaled per-OA traffic profiles would send a PATH message with both the DIFFSERV and ELSP objects. The DIFFSERV object should include a corresponding Ganti, Seddigh, Nandy [Page 8] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 entry for each signaled OA in the ELSP object. A sender SHOULD not include an ELSP object with 0 TP entries in the PATH message. Such an object SHOULD be ignored by intermediate LSRs and the receiving LER. A node that receives a PATH message with an ELSP object but which does not support per-OA resource reservation SHOULD generate a PATH_ERR message with error value: "Unsupported object". If an LSR rejects a resource reservation for a particular OA signaled in an ELSP, it SHOULD consider the resource reservation to have failed for the entire ELSP. In this case, it SHOULD generate a RESV_ERR message with error value "Admission Control Failure for an OA". 3.3 RSVP Error Codes Related to the ELSP Object The errors described in the previous section should be reported with the error code for an 'ELSP Error' - this code is to be allocated by IANA. The following error values are valid for the 'ELSP Error' error code: Value Error ----- ----- 1 Admission Control Failure for an OA 2 Unsupported ELSP Object 3 Unsupported PSC for per-OA signaled E-LSP 4.0 LDP Extensions The [DIFF-MPLS] draft extended the LDP messages by defining a new Diff-Serv TLV. This draft introduces a new optional TLV called ELSP TLV for the purpose of per-OA signaling with E-LSPs. The TLV is intended to be used only with E-LSPs and not with L-LSPs. The ELSP TLV is optional with respect to LDP. Handling of the Diff- Serv TLV should follow the rules specified in [DIFF-MPLS]. It is expected that for each OA signaled in the ELSP TLV there will be a corresponding set of EXP<->PHB mappings that were either pre- configured or signaled via the DIFFSERV TLV. 4.1 ELSP TLV The ELSP TLV has the following format: Ganti, Seddigh, Nandy [Page 9] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| ELSP (0x910) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | numTP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TP (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TP (numTP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 28 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. numTP : 4 bits Indicates the number of TrafficProfile entries included in the ELSP TLV. This can be set to any value from 0 to 8. TP entry: Each TP entry provides the Traffic Profile associated with a PSC reservation for that E-LSP. The TP entry has the following format (similar to Traffic parameters TLV of [CR-LDP]): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | PSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Frequency | Reserved | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate (PDR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Burst Size (PBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Data Rate (CDR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Excess Burst Size (EBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PSC is encoded as specified in [PHBID]. The remaining parameters are as specified in the traffic parameters TLV of CR-LDP [CR-LDP]. 4.2 LDP Messages The Label Request, Label Mapping and Notification messages are Ganti, Seddigh, Nandy [Page 10] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 extended to optionally contain the ELSP TLV. In addition, new status codes are defined in the status code field of the Status TLV. 4.3 Handling of the ELSP TLV 4.3.1 Handling of the ELSP TLV in Downstream Unsolicited Mode The ELSP TLV is only meaningful in Downstream on Demand mode and so should not be used with Downstream Unsolicited mode 4.3.2 Handling of the ELSP TLV in Downstream on Demand Mode This section describes operations when the Downstream on Demand Mode is used. The ELSP TLV should be used only if the EXP<->PHB mapping is either pre-configured or signaled via the DIFFSERV TLV. An upstream LSR seeking to use preconfigured EXP<-->PHB mapping and signaled per-OA traffic profiles, would send a Label Request message without the Diff-Serv TLV, but with an ELSP TLV. An upstream LSR seeking to use signaled EXP<-->PHB mapping and signaled per-OA traffic profiles, would send a Label Request message with both the Diff-Serv and ELSP TLVs included. The DIFFSERV TLV should include one MAP entry for each corresponding traffic profile signalled via the ELSP TLV. A downstream Diff-Serv LSR sending a Label Mapping message in response to a Label Request message for an E-LSP should include the ELSP TLV. A downstream Diff-Serv LSR receiving a Label Request message with the ELSP TLV for an E-LSP containing a PSC value which is not supported, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PSC'. A downstream Diff-Serv LSR that recognizes the ELSP TLV Type in a Label Request message but is unable to grant the reservation request for one of the OAs signaled in the ELSP TLV, must reject the entire request and send a Notification message which includes the Status TLV with a Status Code of `Resource Unavailable for an OA reservation request'. A downstream Diff-Serv LSR that recognizes the ELSP TLV Type in a Label Request message and supports the requested PSC but is not able to satisfy the label request for other reasons (e.g. no label available), must send a Notification message in accordance with existing LDP procedures [LDP] (e.g. with a `No Label Resource' Status Code). This Notification message must include the requested ELSP TLV. 4.4 Non-Handling of the ELSP TLV An LSR that does not recognize the ELSP TLV Type, on receipt of a Label Request message or a Label Mapping message containing the ELSP Ganti, Seddigh, Nandy [Page 11] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 TLV, must behave in accordance with the procedures specified in [LDP] for an unknown TLV whose U Bit and F Bit are set to 0 i.e. it must ignore the message, return a Notification message with `Unknown TLV' Status. 4.5 E-LSP Status Code Values The following values are defined for the Status Code field of the Status TLV: Status Code E Status Data Unexpected ELSP TLV 0 0x01000010 Unsupported PSC 0 0x01000011 Resource Unavailable for an OA resv req 0 0x01000012 5.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. 6.0 Acknowledgements This work has benefitted from mailing list and offline discussion involving Jim Boyle, Shahram Davari, Neil Harrison and Roberto Mameli. 7.0 References [BITAR] Bitar N et al, "Traffic Engineering Extensions to OSPF", Internet Draft, , July 2001 [RSVP] Braden et al, "Resource Reservation Protocol - Version 1 Functional Specification", RFC 2205, September 1997 [INTSERV] Wroclawski J, "Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 [INTCHAR] Shenker S et al, "General Characterization Parameters for Integrated Services Network Elements", RFC 2215, September 1997 [DIFF-MPLS] 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 Ganti, Seddigh, Nandy [Page 12] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 [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. [DS-TE-REQ] Le Faucheur F et al, "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te-reqts-01.txt, June 2001. [DS-CT] Le Faucheur F et al, "Protocol Extensions for support of Diffserv-Aware MPLS Traffic Engineering, draft-lefaucheur-diff-te-proto-00.txt, July 2001 [KOMPELLA] Kireeti Kompella, "Bandwidth Accounting for Traffic Engineering", draft-kompella-tewg-bw-acct-00.txt, July 2001. [BOYLE] Jim Boyle, "Accomplishing Diffserv TE needs with current specifications", draft-boyle-tewg-ds-nop-00.txt, July 2001. 7.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 A.0 Appendix: Other approaches to signal E-LSP This appendix captures the two other ways in which RSVP can be extended to support per-OA signaling for E-LSPs. The approaches are described below. A.1 First Approach - New object type for FLOWSPEC & SENDER_TSPEC Objects In this second approach to signaling multiple OAs on single E-LSP, we propose an extension to the FLOWSPEC and SENDER_TSPEC objects. Ganti, Seddigh, Nandy [Page 13] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 Specifically, new object types (C-Type) are defined for both of these objects. Thus, a PATH message would have one such new SENDER_TSPEC object per OA for which it wishes to signal bandwidth requirements. Conversely, a RESV message would have one such new FLOWSPEC object per OA for which bandwidth is being signaled. The PATH and RESV messages can still use a single SENDER_TSPEC and FLOWSPEC object with Intserv C-Type to signal the bandwidth requirement for the entire traffic aggregate of this E-LSP. Such an object will be relevant to admission control for the entire aggregate and will not be related to a specific PSC, PHB or OA. A description of the new SENDER_TSPEC and FLOWSPEC types is given below. New Object Type for FLOWSPEC FLOWSPEC class = 9. o Reserved (obsolete) flowspec object: Class = 9, C-Type = 1 o Int-serv Flowspec object: Class = 9, C-Type = 2 o E-LSP Per PSC Flowspec object: Class=9; C-Type=3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | (c) | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - PSC - Indicates the PHB Scheduling Class the traffic profile applies to; Encoding as specified in [PHBID] (d) - Length of service 1 data, 6 words not including header (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including header Essentially, the above data structure is similar to the original Intserv Ganti, Seddigh, Nandy [Page 14] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 FLOWSPEC object except that the service field is replaced with the PSC field. New Object Type for SENDER_TSPEC SENDER_TSPEC class = 12 o Intserv Sender_Tspec object: Class = 9, C-Type = 2 o E-LSP Per PSC Sender_Tspec object: Class=9; C-Type=3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | (c) | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - PSC - Indicates the PHB Scheduling Class the traffic profile applies to; Encoding as specified in [PHBID] (d) - Length of service 1 data, 6 words not including header (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including header Essentially, the above data structure is similar to the original Intserv SENDER_TSPEC object except that the service field is replaced with the PSC field. A.2 Third Approach - Modifying the DIFFSERV object The third approach to signal bandwidth requirements for multiple OAs in a single E-LSP relies on extensions to the DIFFSERV object. Currently, the DIFFSERV object specifies mapping between EXP bits and PHBs. We extend it to specify traffic profiles on a per PSC basis. Flexibility occurs because the solution allows for support of multiple configuration options as described in [DIFFSERV-MPLS]. In addition, where desired, the DIFFSERV object will contain a number of Ganti, Seddigh, Nandy [Page 15] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 entries to indicate the traffic profiles on a per-PSC basis. The only other requirement is that when signaling per-OA bandwidth requirements, the DIFFSERV object must be included in both the PATH and the RESV message. As with the previous two approaches, the SENDER_TSPEC and FLOWSPEC objects can still be used to signal the bandwidth requirements for the entire aggregate E-LSP traffic. This section describes the changes to the object of an E- LSP [Diff-MPLS]. All the message formats or other object definitions remain the same. The DIFFSERV object formats are shown below. Currently there are two possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2 is a DIFFSERV object for an L-LSP. DIFFSERV object for an E-LSP: class = TBD, C_Type = 1 (need to get an official class num from the IANA with the form 0bbbbbbb) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | nTP | nb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAP (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAP (MAPnb) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TP (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TP (nTP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved : 26 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt. nb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 8. Ganti, Seddigh, Nandy [Page 16] INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-01.txt May 2002 nTP: 4 bits Indicates the number of Traffic Profile entries (each Traffic Profile signals the bandwidth requirement for an OA. MAP : 32 bits The MAP entry remains as defined in [MPLS-DIFFSERV]. TP : 256 bits The format of each TP is as follows: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | (c) | 6 (d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (e) | 0 (f) | 5 (g) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - PSC - Indicates the PHB Scheduling Class the traffic profile applies to; Encoding as specified in [PHBID] (d) - Length of service 1 data, 6 words not including header (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec) (f) - Parameter 127 flags (none set) (g) - Parameter 127 length, 5 words not including header Ganti, Seddigh, Nandy [Page 17]