Internet Draft Paola Iovanna October 2001 Roberto Mameli Expiration Date: April 2002 Giovanna Piantanida Ericsson Lab Italy Stefano Salsano CoRiTeL/ Univ. of Rome "Tor Vergata" Document: draft-iovanna-rsvp-mpls-flowspec-00.txt Definition of the MPLS FlowSpec for RSVP-TE 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. Distribution of this memo is unlimited. Abstract The support of QoS Differentiation in MPLS is based on the definition of two types of LSP, respectively E-LSP and L-LSP (see [11]). Both E-LSP and L-LSP can be established with bandwidth reservation. In this case bandwidth requirements for the LSP must be signaled at LSP establishment time, in order to perform admission control in the LSRs in the path. If RSVP-TE is used as setup protocol, it has to support the signaling of bandwidth requirements for the LSPs. In this document we extend the RSVP-TE capability by defining a new type of Sender_Tspec (and FlowSpec), explicitly designed to allow signaling of bandwidth requirements for E-LSP and L-LSP set up. This new type, called MPLS Sender_Tspec (MPLS FlowSpec), can include bandwidth requirements for different classes inside the LSP. Many folks Expires April 2002 1 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 Table of Contents 1. Introduction...............................................3 2. Definition of the MPLS Sender_Tspec (MPLS FlowSpec) object.3 3. Handling of the MPLS Sender_Tspec (MPLS FlowSpec) object in the DiffServ over MPLS scenario....................................8 4. Security Considerations....................................9 5. IANA Considerations........................................10 6. Acknowledgements...........................................10 7. Example scenario requiring per-OA admission control........10 8. References.................................................11 9. AuthorsÆ Addresses.........................................11 Acronyms The reader is assumed to be familiar with the terminology used in this document. A list of the acronyms used is reported below. AF Assured Forwarding BA Behavior Aggregate BE Best Effort CLS Controlled Load Service CS Class Selector DF Default Forwarding DSCP Differentiated Services Code Point EF Expedited Forwarding EXP EXPerimental (bits) E-LSP EXP-inferred-PSC LSP GS Guaranteed Service LSP Label Switched Path LSR Label Switched Router L-LSP Label-only-inferred-PSC LSP MPLS Multi Protocol Label Switching OA Ordered Aggregate PHB Per Hop Behavior PHBID PHB IDentification code PSC Packet Scheduling Class RSVP-TE RSVP Traffic Engineering extension SLS Service Level Specification TE Traffic Engineering Tspec Traffic specification Many folks Expires April 2002 2 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 1. Introduction MPLS support of Differentiated Services is based on the definition of two types of LSP (see [11]). They are commonly referred to as L-LSP (Label-only-inferred-PSC LSP) and E-LSP (EXP-inferred-PSC LSP). L-LSPs are used to carry traffic belonging to a single OA; they support a single PSC, explicitly signaled at LSP establishment time, while additional information useful for the packet treatment (e.g. the drop precedence) are conveyed by the EXP bits. E-LSPs, instead, are thought for the support of multiple OAs; in this case the EXP bits in the MPLS shim header indicate the PHB to be applied to the packet. Both L-LSP and E-LSP can be established with bandwidth reservation. In the first case bandwidth requirements for the LSP are signaled at LSP establishment time; they are used by LSRs along the path to perform admission control over the provisioned DiffServ resources. The current specification of RSVP-TE states that bandwidth reservation for both E- LSP and L-LSP can be obtained by using IntServ Controlled Load Service, or possibly Guaranteed Service (see [9]); in this case the bandwidth requirements are signaled in the Sender_Tspec object of the PATH message (respectively FlowSpec of the RESV message). This current approach for signaling bandwidth requirements is not completely satisfactory. First of all it is not correct from a conceptual point of view; in fact we use an IntServ Sender_Tspec (respectively IntServ FlowSpec) to signal bandwidth requirements for a scenario other than Integrated Service. Moreover in the case of E-LSP, the current specification does not allow to signal bandwidth requirements separately and independently for the different OAs carried by the E-LSP (bandwidth specification can only be given on aggregate basis). There are some scenarios in which signaling and reservation of resources on a per-OA basis within an E-LSP could be desirable, e.g. to allow per- class resource management and admission control (see 7). This document defines a new type of Sender_Tspec (respectively FlowSpec), explicitly designed to allow signaling of bandwidth requirements for E-LSP and L- LSP set up. The new type is called MPLS Sender_Tspec (respectively MPLS FlowSpec). It supports the signaling of bandwidth requirements for a set of OAs independently. The proposed solution applies to the MPLS support of Differentiated Service as defined in [11], but it can also be used for other scenarios where a MPLS network supports a set of traffic classes. 2. Definition of the MPLS Sender_Tspec (MPLS FlowSpec) object In [13] the problem of signaling bandwidth requirements separately for the different OAs transported over a single E-LSP is examined. As stated there, at least three possible solutions exist, namely: (1) Creation of a new object; Many folks Expires April 2002 3 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 (2) Extension of the existing DiffServ object (defined in [11]); (3) Extension of the existing Sender_Tspec (FlowSpec) to signal multiple FlowSpecs. The first approach is the one followed in [13]; it consists in the creation of the new ELSP object at the purpose of signaling bandwidth requirements per OA. The second approach seems to be the least desirable, for several reasons. First of all, it would change the original meaning of the DiffServ object, on a second-hand it would be applicable only in the DiffServ over MPLS scenario and finally it would require the DiffServ object to be present in the RESV message. In this document, instead, we propose to follow the third approach, i.e. to extend the existing Sender_Tspec (FlowSpec) with the introduction of a new C-Type. This is motivated by several reasons: first of all the introduction of a new Sender_Tspec (FlowSpec) type is more correct from a conceptual point of view. In fact it allows preserving the functionality of the Sender_Tspec (FlowSpec), since it keeps its original meaning of signaling traffic characteristics (with a finer granularity level of the reservation, i.e. on a per-OA basis). In addition the new object type can be used for both E-LSP and L-LSP, and also for QoS over MPLS scenarios other than DiffServ. It can be designed in a flexible way, in order to allow signaling of bandwidth requirements in different ways, i.e. in accordance to different traffic models (possibly not only based on Tspec). Moreover the coexistence between a new object for bandwidth reservation (as proposed by the first solution) and the current Sender_Tspec (FlowSpec) object could lead to conflicts. Finally the introduction of a new C-Type does not raise particular problems in terms of backward compatibility with existing implementations that do not support it. The following paragraph describes the object in more details. 2.1 MPLS Sender_Tspec (MPLS FlowSpec) In this section the structure of the new MPLS Sender_Tspec (FlowSpec) type is defined. It is exactly the same in both cases, with the obvious difference of the Class value. Class = 9 (FlowSpec class) Class = 12 (Sender_Tspec class) C-type = 3 (MPLS Sender_Tspec/FlowSpec object) The content and the encoding rules for this object are specified in the following. ::= [] Many folks Expires April 2002 4 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 ::= | :== 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Flags | Reserved | Num-of-SubObjs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: 8 bits It specifies the version of the object and it is used for future extensions. Current value for Version is 1. Flags: 8 bits Can be used to define flags. Currently set to 0. Reserved: 8 bits Set to 0. Num-of-SubObjs: 8 bits Specifies the number of SubObjects in the the MPLS Tspec Body. In the case of absence of the MPLS Tspec Body, this is set to 0. This means that no bandwidth reservation is related to the LSP setup. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubObj-num | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SubObj-num: 8 bits Specifies the type of SubObject. Currently two types of SubObjects are defined: SubObj-num = 1 : OA-Traffic Profile PHBID SubObj-num = 2 : OA-Traffic Profile Simple Exp Many folks Expires April 2002 5 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 OA-TP PHBID SubObject will be used in the MPLS/Diffserv scenario. Reserved: 16 bits Currently set to 0. It could contain SubObj specific information. Length: 8 bits Specifies the length of the SubObject body in 32bit words. The is specific for each SubObj-num as follows: for OA-Traffic Profile PHBID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHBID | TP-style | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Profile Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // . . . . . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Profile Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ for OA-Traffic Profile Simple Exp 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exp | Reserved | TP-style | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Profile Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // . . . . . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Profile Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 8 bits This field indicates the length of the in 32 bit words. PHBID: 16 bits This field contains the Per Hop Behavior Identification Code, encoded as specified in [12]. Many folks Expires April 2002 6 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 Exp: 3 bits This field contains the Exp field. TP-Style: 8 bits This field indicates the bandwidth requirement type. Different representations for the bandwidth requirements can be used, according to the traffic models available. Currently two possible TP-Style values are defined, but other values could be introduced in the future if needed. TP-style = 1 (Tspec parameters as defined for RSVP) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TP-style = 2 (Simple bandwidth parameter) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An example of a complete MPLS Sender Tspec object is given hereafter. It represents the bandwidth requirements for an E-LSP which supports two OA. Therefore, it includes the bandwidth requirements for two different PHBIDs, respectively expressed with a Token Bucket representation and with a Simple bandwidth parameter. Many folks Expires April 2002 7 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 Example of a complete MPLS Tspec object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (bytes) | C-Num=12 | C-Type=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version=1 | Flags=0 | Reserved |Num-of-SubObj=2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubObj-num=1 | Reserved | Length=6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHBID= xx | TP-style=1 | Length=5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubObj-num=1 | Reserved | Length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHBID= yy | TP-style=2 | Length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Handling of the MPLS Sender_Tspec (MPLS FlowSpec) object in the DiffServ over MPLS scenario This paragraph describes in details all the operations related to the new Sender_Tspec (FlowSpec) handling in the particular scenario of DiffServ over MPLS. In this case the object is intended to support signaling of bandwidth requirements on a per-OA basis for both E-LSP and L-LSP. However, for backward compatibility, Sender_Tspec (FlowSpec) objects with IntServ C-type can still be used in PATH (RESV) messages to signal bandwidth requirements for the entire flow, as specified in [9] and [11]. It is worth to observe that in the case of L-LSP the new MPLS C-type does not add new information with respect to the classical IntServ C-type; in fact there is no need to signal per-OA bandwidth requirements in such situations. Nevertheless the use of the MPLS Sender_Tspec (FlowSpec) is preferred for at least two reasons. First it is more correct from a conceptual point of view, as stated before, and second it allows signaling such bandwidth requirements in a more flexible way (e.g. representing only the bandwidth value instead of the 5-tuple Tspec). Many folks Expires April 2002 8 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 A node that receives a PATH (RESV) message containing a MPLS Sender_Tspec (FlowSpec) but does not support it, must generate a PATH ERR (RESV ERR) message corresponding to ôUnknown object C-Typeö (Error Code = 14, see Appendix B of [1]). To signal per-OA traffic requirements the ingress LSR must include a MPLS Sender_Tspec object in the PATH message. Correspondingly the receiver must include a MPLS FlowSpec object in the RESV message. Each PSC signaled in the MPLS Sender_Tspec (MPLS FlowSpec) must be supported. In the case of E-LSP a corresponding set of EXP<->PHB mapping must exist. Of course this means that all the PHB associated to each PSC signaled in the MPLS Sender_Tspec (FlowSpec) must be supported, either pre-configured on every node or signaled by means of the DIFFSERV object ([11]). In the case of L-LSP the Encaps<->PHB mapping specified in the DIFFSERV object must coincide with the PSC signaled in the MPLS Sender_Tspec (FlowSpec) (Of course for a L-LSP this object must include only a single SubObject). A node that receives a PATH (RESV) message with MPLS Sender_Tspec (FlowSpec) object containing one or more unsupported PSC must fail the reservation request and send a PATH_ERR (RESV ERR) message of the type ôDiff-Serv Errorö (Error code to be assigned by the IANA, see section 5.5 of [11]) and error value 2 (ôUnsupported PHBö) or 4 (ôUnsupported PSCö). A node that receives a RESV message with per-OA traffic profiles signaled in the MPLS FlowSpec object must perform Admission Control on every aggregate. If resources available for one or more OA signaled in MPLS FlowSpec are deemed insufficient, the node must fail the entire resource reservation. In this case it must send a RESV_ERR message with Error Code = 01 (ôAdmission Control Failureö) and Error Value of the form 0000cccccccccccc (ôAdmission Control Failure for an OAö, TBD). If all the PHB/PSC signaled in the MPLS Sender_Tspec (MPLS FlowSpec) are supported and sufficient resources are available for each of them, then the node must carry out proper actions in order to let the reservation succeed (i.e. proper configuration of schedulers, classifiers and traffic conditioning elements). A node must handle all the situations where a LSP cannot be accepted for other reason than the ones discussed in this section, in accordance to [1], [9] and [11]. 4. Security Considerations This document does not introduce additional security issues beyond those discussed in [1], [3], [7], [9] and [11]. As a consequence it may use the same mechanisms described in the references above. Many folks Expires April 2002 9 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 5. IANA Considerations This document defines a new object type with implications for IANA. A new C-type is defined for the MPLS Sender_Tspec (MPLS FlowSpec) object. The value (C-type = 3) has been chosen according to the First Come First Served policy defined in [14]. The new RSVP error code (ôDiffServ Errorö) should also be assigned from IANA (see section 5.5 of [11]). Finally a new error sub-code related to the ôAdmission Control Failureö error must be assigned. 6. Acknowledgements Authors would like to thank all the people that participated to the revision of this document contributing with comments and suggestions. 7. Example scenario requiring per-OA admission control There are many scenarios in which an MPLS network could support Differentiated Services by means of E-LSP. In such cases the provider would like to give service differentiation in its traffic engineered network without the complexity of managing different L-LSP for different services. Even if the provider is not interested in complex traffic engineering functionality (e.g. per class routing or per class protection/restoration), nevertheless it could be useful to manage resources on a per-OA basis, in order to allow better service provisioning and increased efficiency in network utilization. For example, consider an ISP network that provides only two classes of service (e.g. Best Effort and Premium) using E-LSP. Assume that a generic node within the network is connected to a link with 100Mbit total bandwidth; assume it is able to provide 20Mbit of its bandwidth to Premium Service and the remaining 80Mbit to Best Effort traffic. Now imagine that the node receives two requests for E-LSP setup: E-LSP A and E-LSP B. - E-LSP A requires 40Mbit of the link bandwidth (respectively 15Mbit for Premium Service and 25Mbit for Best Effort) - E-LSP B requires 50Mbit of the link bandwidth (respectively 15Mbit for Premium Service and 35Mbit for Best Effort) If the node does not support the MPLS Sender_Tspec (MPLS FlowSpec) extension described in this document, then it cannot perform per-OA admission control. In this case admission control is performed on aggregate basis. Since the total bandwidth requirement of the two E-LSPs is less than the link bandwidth, they are both accepted (90Mbit of link bandwidth, respectively 30Mbit for Premium Service and 60Mbit for Best Effort). Note however that the total amount of Premium traffic exceeds Many folks Expires April 2002 10 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 the pre-configured limit (set to 20Mbit) and, as a consequence, Premium traffic on both E-LSP will be adversely affected. In contrast, if the new object is supported and per-OA based Admission Control is performed, the node rejects one of the requests because it is able to control the bandwidth availability for each class of service. Upon rejection the network can react in various ways, from the simple choice of rerouting to more complex actions, such as resource provisioning and redistribution. 8. References [1] R. Braden et al., ôResource Reservation Protocol (RSVP) û Version 1, Functional Specificationö, RFC 2205, September 1997 [2] J. Wroclawsky, ôThe use of RSVP with IETF Integrated Servicesö, RFC 2210, September 1997 [3] R. Braden et al., ôResource Reservation Protocol (RSVP) û Version 1 Message Processing Rulesö, RFC 2209, September 1997 [4] J. Wroclawsky, ôSpecification of the Controlled-Load Network Element Serviceö, RFC 2211, September 1997 [5] S. Shenker et al., ôSpecification of Guaranteed Quality of Serviceö, RFC 2212, September 1997 [6] Y. Bernet et al., ôSpecification of the Null Service Typeö, RFC 2997, November 2000 [7] E. Rosen et al., ôMultiprotocol Label Switching Architectureö, RFC 3031, January 2001 [8] D. Awduche et al., ôRequirements for Traffic Engineering over MPLSö, RFC 2702, September 1999 [9] D. Awduche et al., ôRSVP-TE: Extensions to RSVP for LSP Tunnelsö, draft-ietf-mpls-rsvp-lsp-tunnel-09.txt, February 2001 [10] D. Awduche et al., ôApplicability Statement for Extensions to RSVP for LSP-Tunnelsö, draft-ietf-mpls-rsvp-tunnel-applicability- 02.txt, April 2001 [11] F. Le Faucheur et al., ôMPLS Support of Differentiated Servicesö, draft-ietf-mpls-diff-ext-09.txt, April 2001 [12] D.Black et al., ôPer Hop Behavior Identification Codeö, RFC 3140, June 2001 [13] S. Ganti et al., ôMPLS Support of Differentiated Services using E-LSPö, draft-ganti-mpls-diffserv-elsp-00.txt, April 2001 [14] T. Narten et al., ôGuidelines for writing an IANA Considerations Section in RFCsö, RFC 2434, October 1998 9. AuthorsÆ Addresses Paola Iovanna Ericsson Lab Italy S.p.A. Via Anagnina 203 00040 - Morena (Rome) û Italy Tel. +39 06 72582814 Many folks Expires April 2002 11 Definition of the MPLS FlowSpec for RSVP-TE Apr-02 E-mail: paola.iovanna@eri.ericsson.se Roberto Mameli Ericsson Lab Italy S.p.A. Via Anagnina 203 00040 - Morena (Rome) û Italy Tel. +39 06 72589119 E-mail: roberto.mameli@eri.ericsson.se Giovanna Piantanida Ericsson Lab Italy S.p.A. Via Anagnina 203 00040 - Morena (Rome) û Italy Tel. +39 06 72583537 E-mail: giovanna.piantanida@eri.ericsson.se Stefano Salsano University of Rome Tor Vergata CoRiTeL û Consorzio di Ricerca sulle Telecomunicazioni c/o Ericsson - Via Anagnina 203 00040 - Morena (Rome) û Italy Tel. +39 06 72582540 E-mail: salsano@coritel.it Many folks Expires April 2002 12