Internet Draft F. Tommasi S. Molendini A. Tricco Document: draft-tommasi-mpls-intserv-00.txt University of Lecce, ITALY Expiration date: September 2000 March 2001 Integrated Services across MPLS domains using CR-LDP signaling 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 The Integrated Services (IntServ) architecture [RFC1633] defines QoS services and reservation parameters to be used to obtain for an Internet flow the required QoS. After a reservation has been established using the RSVP protocol [RFC2205], a router classifies each incoming IP packet to determine whether it belongs to a QoS flow. The MultiProtocol Label Switching (MPLS) allows high-performing label switching of packets [RFC3031]. Network traffic is forwarded using a simple label. The CR-LDP protocol allows the definition of a Label Switched Path (LSP) with QoS constraints [CR-LDP], that is to perform QoS classification using a single valued label. Tommasi/Molendini/Tricco Expires September 2001 [Page 1] draft-tommasi-mpls-intserv-00.txt March 2001 This draft efficiently combines the application-oriented IntServ QoS with the power of MPLS label switching, that is it defines IntServ- like QoS services in MPLS domains. Using the mechanisms defined in this draft, a homogeneous end-to-end QoS is reached. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. Table of contents 1. Introduction.........................................3 2. Integration of RSVP and CR-LDP signaling ...........4 2.1 Path Messages.......................................5 2.2 Resv Messages.......................................6 2.3 Setup of the CR-LSP.................................6 2.4 Path & Resv refresh messages........................8 2.5 Teardown messages...................................8 2.6 Error messages......................................8 2.7 Classification......................................9 2.7.1 Fixed-Filter Style................................9 2.7.2 Shared-Explicit Style............................10 2.7.3 Wildcard-Filter Style............................11 2.7.4 Shared option and multiple Ingress LSRs..........12 2.7.5 Shared TLV.......................................13 3. Mapping between IntServ and CR-LDP services.........14 3.1 Controlled Load service ...........................15 3.2 Guaranteed service ................................15 3.3 Non-conformant packets.............................16 4. Caching and Aggregation techniques..................17 4.1 Caching of CR-LSPs.................................18 4.2 Aggregation of CR-LSPs.............................20 4.3 The ABC control parameters.........................21 4.3.1 Parameter A......................................22 4.3.2 Parameter B......................................22 4.3.3 Parameter C......................................22 4.4 Examples of CR-LSP management strategies...........23 Future Work............................................24 Security Considerations................................24 References.............................................25 Tommasi/Molendini/Tricco Expires September 2001 [Page 2] draft-tommasi-mpls-intserv-00.txt March 2001 1. Introduction The Integrated Services (IntServ) architecture [RFC1633] defines QoS services and reservation parameters to be used to obtain for an Internet flow the required QoS. RSVP [RFC2205] is the signaling protocol used to convey these parameters from one or multiple senders towards a unicast or multicast destination. RSVP assigns QoS with the granularity of single application's flows. An heavy signaling traffic is then exchanged between routers belonging to a core area of the Internet, as they must serve an high number of flows and their reservation requests. Moreover, after a reservation has been established, each router must classify each incoming IP packet to determine whether it belongs to a QoS flow or not and, in the former case, to assign the needed resources to the flow. The IntServ classifier is a based on a MultiField classification, because it checks five parameters in each IP packet (Source IP address, Destination IP address, Protocol ID, Source transport port, Destination transport port). Hence, together with the publication of the basic RSVP documents, an informational document [RFC2208] bewares potential users of RSVP of the scalability issues posed by signaling, classification and scheduling mechanisms. An important consequence of this problem is that IntServ-level QoS can be provided only within peripheral areas of the Internet, preventing its extension inside core areas and the implementation of end-to-end QoS. Some work has been devoted to overcome these problems. The RSVP WG is publishing an RFC that describes a set of techniques [ROREXT] that reduce the overhead of RSVP signaling but don't even deal with the classification problem, which still remains unfaced. Another draft [RAGGR] of the ISSLL WG discusses the possibility of aggregation of RSVP sessions into a larger one, signaling a DiffServ DSCP to be used for this aggregated traffic. This solution wastes the undoubted benefits given by the granularity of IntServ reservations. The MultiProtocol Label Switching (MPLS) protocol allows high- performing label switching of packets [RFC3031]. Network traffic is forwarded using a simple label. The CR-LDP protocol allows the definition of a Label Switched Path (LSP) with QoS constraints [CR- LDP], that is to perform QoS classification using a single valued label (not a MultiField one). Tommasi/Molendini/Tricco Expires September 2001 [Page 3] draft-tommasi-mpls-intserv-00.txt March 2001 The main limitation of this approach is that currently it can't be used by end-hosts because they can't do CR-LDP signaling. On the other side IntServ has been designed to allow application to signal QoS requirements on their own; Reservation APIs are available and many operating systems allow applications to use them. The basic idea of this draft is to combine the application-oriented IntServ QoS with the power of MPLS label switching, that is to define IntServ-like QoS services in MPLS domains. Using the mechanisms defined in this draft, a homogeneous end-to-end QoS can be reached. At the same time, the number and the effects of the changes to the current CR-LDP specifications are minimal. The most part of the integration work is bounded into the Ingress LSR at the sender side of the MPLS domain's border. 2. Integration of RSVP and CR-LDP signaling Let us consider two RSVP applications exchanging RSVP messages along a path that crosses an MPLS domain. Path Path | (Path) (Path) | Path Path | | ---> ---> | ---> ---> | ---> ---> | | HS --- R1 --- IngressLSR --- LSR --- EgressLSR --- R2 --- HR | | <--- <--- | <--- <--- | <--- <--- Resv Resv | (Resv) (Resv) | Resv Resv | | | | | | IntServ Area -->|<----MPLS domain---->|<-- IntServ Area Figure 1 - A simple topology An LSR (Label Switching Router) is not an RSVP router. By the RSVP point of view, the whole MPLS domain is a non-RSVP region, crossed by RSVP end-to-end messages. As such, all RSVP basic messages (Path/Resv too) travel within MPLS as ordinary IP traffic without being intercepted by the LSRs. RSVP cannot then reserve network resources. One of the LSRs internal to the domain may happen to have an RSVP process. To the purposes of this document, it is important to avoid Tommasi/Molendini/Tricco Expires September 2001 [Page 4] draft-tommasi-mpls-intserv-00.txt March 2001 this router processes RSVP messages. Both the Ingress and Egress LSR modifies then the IP Protocol Number of all RSVP messages directed towards the MPLS domains form the RSVP value to the RSVP-E2E-IGNORE. The meaning and the usage of the latter value are discussed in [RAGGR]: all these messages are ignored by the LSR inside the domain. The Egress LSR that receives an RSVP message directed outside the domain with the Protocol field set to RSVP-E2E-IGNORE, swap this value back to RSVP. Using the mechanisms proposed in this draft, the MPLS domain may participate, using its native CR-LDP messages, to the realization of a level of service inside the domain comparable with the IntServ QoS requested by RSVP applications. This section covers the rules to generate proper CR-LDP messages. After the receipt of an RSVP message which reserves resources, the Ingress LSR establishes a CR-LSP (Constraint Routed LSP) towards the Egress LSRs. This CR-LSP is endowed with the QoS specified by the FLOWSPEC object carried by the Resv message. The RSVP sender's traffic crosses the MPLS domain using this CR-LSP. The Ingress LSR is the responsible to perform the message translation to create this CR-LSP. LSRs not on the edge of the MPLS domains will only process CR-LDP messages. In the following we will refer, for a given RSVP flow, to the last RSVP router upstream to the MPLS domain as an Edge PHop and to the first RSVP router downstream to the MPLS domain as an Edge NHop. In the topology of the Figure 1 the Edge PHop coincides with the Ingress LSR and the Edge NHop coincides with the Egress LSR. The CR-LSP is defined between the Ingress LSR and the Egress LSR. CR-LDP does not provide the signaling of multicast LSPs. Hence in this draft is not considered, at the moment, the possibility to reserve QoS inside the MPLS domain using RSVP multicast messages. 2.1 Path Messages RSVP is a receiver-oriented protocol. Before the receiver is enabled to transmit the reservation request the sender must send to it a Path message. Tommasi/Molendini/Tricco Expires September 2001 [Page 5] draft-tommasi-mpls-intserv-00.txt March 2001 A Path message does two main tasks. The first one is to trace the proper path from the sender towards the receiver. This path will be followed by the reserving Resv message traveling in the opposite direction. Inside the MPLS domain the route followed by the Path message is not important. The packets of the flow will use the CR-LSP to be created - perhaps on a path different from that followed by the Path message. The second one is to advertise the receiving application of the IntServ traffic parameters that characterize the flow (SENDER_TSPEC object) and the network elements on the path (ADSEPC object). The MPLS domain doesn't care the SENDER_TSPEC because this information has an end-to-end scope. The ADSPEC object is generated by the sender and updated along the Path instead. It would useful that the LSRs could cooperate to the collection of these parameters. According to this version of this document, the MPLS ignores Path messages and the Ingress LSR simply forwards them as regular IP traffic towards their destination. The same can be told for Path messages that change existing state in Ingress LSRs. In the case that a Path message of a given session enters the domain through a different Ingress LSR, the Ingress LSR ignores this new message - as well as the old one. The associated Resv message will create new RSVP state into the new Ingress LSR and the old Ingress LSR will delete old RSVP state (perhaps via a time- out.) 2.2 Resv Messages After having received the Path message an application may send a Resv message. This message tracks the RSVP routers traversed by the Path message (in the opposite direction) and reserves resources on them. The Resv message will reach the Egress LSR, which is also the last RSVP node after the MPLS domain. After this node, the message will travel inside the MPLS domain. The Resv message will reach the Ingress LSR through the MPLS domain. The Ingress LSR transmits the Resv message upstream towards its interface over the IntServ area. 2.3 Setup of the CR-LSP Soon after having forwarded the Resv message the Ingress LSR sets up the CR-LSP. The Ingress node sends a Label Request message with an ER-TLV object directed towards the Egress LSR. Tommasi/Molendini/Tricco Expires September 2001 [Page 6] draft-tommasi-mpls-intserv-00.txt March 2001 | | HS --- R1 --- IngressLSR --- LSR --- EgressLSR --- R2 --- HR | | <--- <--- | <--- <--- | <--- <--- Resv Resv | (Resv) (Resv) | Resv Resv | | | LabelReq LabelReq | | ---> ---> | | | | LabelMap LabelMap | | <--- <--- | | | IntServ Area -->|<----MPLS domain---->|<-- IntServ Area Figure 2 - Messages exchange The ER-TLV object has an ER-Hop TLV whose Content field is the IP address of the Egress LSR taken from the NHOP object of the Resv Message. This object has a ER-Hop-Type field set to the "IPv4 prefix" type if this address is an IPv4 one, or to the "IPv6 prefix" type if this address is an IPv6 one. The L flag is set to allow the setup of a Loose Explicit Route. It is not important what route the Label Request message uses to reach the Egress LSR (the RSVP NHop). The only constraint is that the last ER-Hop TLV MUST be the RSVP NHOP. If an implementation wants to add more ER-Hops (that is to do Traffic Engineering) is free to do it. The same can be told for all the other optional TLV objects of the message. The Traffic Parameters TLV is mandatory as far as this specifications and its fields are set to specify a QoS level equivalent to that specified in the FLOWSPEC object of the Resv message. More on mapping mechanisms in Section 3. If no errors are found while forwarding the Label Request message, the Egress LSR forwards to the Ingress LSR a Label Mapping message that creates the CR-LSP. During the usage of the CR-LSP, if a new Resv message updates some of the traffic parameters in the FLOWSPEC object, the Ingress assigns to the flow enough resources to fit this request. The old CR-LSP should be released via a Label release message and a new one, with the changed Traffic Parameters TLV must be setup. An alternative Tommasi/Molendini/Tricco Expires September 2001 [Page 7] draft-tommasi-mpls-intserv-00.txt March 2001 technique may use the [LSPMOD] draft, which allows the modification of CR-LSPs without service interruption or disruption. If the NHop address in a Resv message changes, that is a new Egress LSR is selected, the CR-LDP must be adapted to reach the new exit point. The old path may be released and the new one setup, or the mechanisms in [LSPMOD] might be used. 2.4 Path & Resv refresh messages RSVP Resv and Path messages are periodically resent to maintain soft state, that is to confirm existing state. CR-LDP uses its own mechanisms to keep alive CR-LSPs. Thus, at the arrival of a refresh message, the Ingress LSR does not send any CR-LDP message into the MPLS domain. 2.5 Teardown messages RSVP uses PathTear and ResvTear to remove RSVP state. Some of these messages (e.g. PathTears to nodes which did not received any Resv) does not release any sort of resource, others do. This latter case only may cause the transmission of a CR-LDP Label Release message. More detailed specification in the case of multiple senders depends upon the reservation style and is given in the following. 2.6 Error messages PathErr and ResvErr RSVP messages between the Ingress LSR and the Egress LSR travel as regular IP traffic inside the MPLS domain. Error messages do not remove any RSVP state. They trigger Teardown messages responsible for the removal of state on upstream/downstream RSVP nodes. That is, MPLS is not interested on error messages that modify internal RSVP state. By the RSVP point of view, CR-LDP error messages generated inside the MPLS domain does not map into any RSVP error message. RSVP nodes treat LSRs as a non RSVP-routers that are not expected to provide QoS; whether additional QoS is reached inside the MPLS domain or not, this is a matter local to the domain itself. Tommasi/Molendini/Tricco Expires September 2001 [Page 8] draft-tommasi-mpls-intserv-00.txt March 2001 2.7 Classification Soon after the CR-LSP has been established by the LSRs, the Ingress LSR is ready to transmit into the MPLS domain the packets belonging to the original IntServ flow. It is necessary to accurately specify which packets may be mapped to the CR-LSP. Providing a FEC specification for the CR-LSP does this. Using the MPLS terminology, a FEC is a group of packets forwarded over the same path and with the same forwarding treatment. The way a FEC is determined depends upon the reservation style used by the Resv message. 2.7.1 Fixed-Filter Style The Fixed-Filter (FF) reservation style uses the "Distinct" reservation option, that is each single sender of the RSVP session uses resources distinct from the other senders. To keep this separation among senders' flows even in the MPLS domain, distinct CR- LSPs may be defined, each mapping one RSVP sender's traffic using a different FEC. | | HS1 --- R1 --- IngressLSR --- LSR --- EgressLSR --- R2 --- HR / | | HS2 --- R2 - | | | CR-LSP1: | | FEC=(HR,HS1) | | -----------------> | | | | CR-LSP2: | | FEC=(HR,HS2) | | -----------------> | | | | | IntServ Area -->|<----MPLS domain---->|<-- IntServ Area Figure 3 - FF reservation style All the packets belonging to the same RSVP flow have five common parameters in the IP/transport headers, that is IP Destination address, IP Source address, Protocol, TCP/UDP Destination port, TCP/UDP source port. Hence, the Ingress LSR checks these parameters to determine the FEC and to choose the related CR-LSP. When a Resv message incomes, the Ingress LSR takes from the SESSION and FILTER_SPEC objects these five parameters. It then associates Tommasi/Molendini/Tricco Expires September 2001 [Page 9] draft-tommasi-mpls-intserv-00.txt March 2001 each arriving packet to the FEC that matches these parameters. As a consequence, a different FEC is created for each different sender. If a Resv message that adds a FILTER_SPEC to the existing list arrives to the Ingress LSR, a new Label Request message is sent to setup the related CR-LSP. If an existing FILTER_SPEC is deleted the related LSP must be deleted using a Label Release message. A teardown message always deletes the CR-LSP associated with the sender torn down. In the case that a PathTear arrives, one only sender is removed that is specified by the SENDER_TEMPLATE object. Thus the (eventually) allocated CR-LSP is released. In the case that a ResvTear arrives, all CR-LSPs that match with the FILTER_SPECs specified in the message are released. 2.7.2 Shared-Explicit Style The Shared-Explicit (SE) reservation style uses the "Shared" reservation option, that is all the senders of the session share the resources over the common hops of the path. This style uses also the "Explicit" option, that is the Resv message contains in FILTER_SPEC objects the identity of each sender that uses the resources. | | HS1 --- R1 IngressLSR --- --- LSR --- EgressLSR --- R2 --- HR / | | HS2 --- R2 - | | | CR-LSP: | | FEC=(HR, HS1 & HS2) | | -----------------> | | | | | IntServ Area -->|<----MPLS domain---->|<-- IntServ Area Figure 4 - SE reservation style As in the FF style, each packet is classified matching the five parameters in its headers with the information contained in the SESSION and FILTER_SPEC objects. Differently by the FF style, the Ingress LSR uses a single FEC (i.e. a single CR-LSP) for the traffic generated by all the senders of the session identified by a FILTER_SPEC object. This way all these flows are merged inside the MPLS domain, which on its turn treats these packets in a single manner. Tommasi/Molendini/Tricco Expires September 2001 [Page 10] draft-tommasi-mpls-intserv-00.txt March 2001 If a Resv message that modifies the FILTER_SPEC list arrives to the Ingress LSR, this node updates the FEC associated to that RSVP session. No modifications to the CR-LSP are then needed. If the Ingress LSR receives a PathTear message, it modifies the FEC (if one has been defined because of the arrival of a Resv message) removing the sender specified by the SENDER_TEMPLATE object from the list of senders. A ResvTear removes the senders listed by the FILTER_SPECs objects from the list of the senders associated to the FEC. Both cases, if no more senders are available for that session, the associated CR-LSP is released via a Label Release message. 2.7.3 Wildcard-Filter Style The Wildcard-Filter (WF) reservation style uses the "Shared" and the "Wildcard" reservation options, that is all the traffic directed towards the receiver of the session receives the same treatment in the MPLS domain. No per-sender classification is then performed. | | HS1 --- R1 --- IngressLSR --- LSR --- EgressLSR --- R2 --- HR / | | HS2 --- R2 - | | | CR-LSP: | | FEC=(HR) | | -----------------> | | | | | IntServ Area -->|<----MPLS domain---->|<-- IntServ Area Figure 5 - WF reservation style A single FEC (i.e. a single CR-LSP) is then defined and used by all the packets which match the three parameters IP destination address, Protocol and Transport destination port contained in the SESSION object. A Resv message using the WF style does not contain any FILTER_SPEC object. When an Ingress LSR receives a PathTear message, it releases the CR- LSP only if no more senders are available for that session. The arrival of a ResvTear message always releases the CR-LSP. Tommasi/Molendini/Tricco Expires September 2001 [Page 11] draft-tommasi-mpls-intserv-00.txt March 2001 2.7.4 Shared option and multiple Ingress LSRs A modification of the mechanisms described in the paragraph 2.3 is needed when hosts sends Path messages to the MPLS domain through different Ingress LSRs but sharing some LSRs of the path. | | Resv | | <--- | | HS1 -------- Ingress LSR1 <-+ | | \ | (Resv) | Resv | \ +----<---- | <--- | \ | | LSR-----------Egress LSR ---- HR | / | Resv | / +----<---- | <--- | / | (Resv) | HS2 -------- Ingress LSR2 <-+ | / | | HS3 ---- | | <--- | | Resv | | | | IntServ Area -->|<------MPLS domain------>|<-- IntServ Area Figure 6 - Multiple Ingress LSRs topology Looking at Figure 3, three hosts HS1, HS2 and HS3 send (at different moments) a Path message each to the same session towards HR. The Path originated by HS1 enter the MPLS domain through Ingress LSR1 while the Paths originated by HS2 and HS3 enters through Ingress LSR2. The host HR sends a single Resv message towards the Egress LSR, which is the common PHop of the three senders. The Egress LSR sends two Resv messages towards the two PHop of the session, one being Ingress LSR1 for HS1, the other Ingress LSR2 for both HS2 and HS3. Both Ingress LSR1 and Ingress LSR2 forward these messages upstream inside the IntServ area. The problem posed by this topology is that, following the rules given in the previous paragraphs, Ingress LSR1 and Ingress LSR2 will create two different CR-LSPs for the same session inside the MPLS domain, one for HS1 and the other for HS2 and HS3, each reserving the Tommasi/Molendini/Tricco Expires September 2001 [Page 12] draft-tommasi-mpls-intserv-00.txt March 2001 resources requested with the Resv message. This situation leads to a waste of resources when the "Shared" reservation option (either the SE or the WF style) is used. In all the shared links there is a reservation of the resources twice than the needed amount. To overcome this issue, we add a new CR-LDP "Shared TLV" object to Label Request messages which signals to all the LSR along the path to share reservation requests. The Ingress LSR1 of the Figure 1 puts in the "Session" field of this TLV the three fields of the RSVP SESSION object that identify the receiver. The LSR inside the domain adds the value of this field to the local state and forwards the Label Request message towards the Egress LSR. Also the Ingress LSR2 sends its Label Request message to LSR with a Shared TLV. LSR finds an identical Shared TLV (the one from Ingress LSR1)in its state. Thus LSR does not forward the message and directly sends a Label Mapping message to Ingress LSR2. From LSR onward there is a single CR-LSP used by HS1, HS2 and HS3 which share there common resources. LSR will assign the same outgoing label to both the incoming labels identifying the traffic from Ingress LSR1 and Ingress LSR2. All the Ingress LSRs should put this object in the Label Request messages triggered by Resv messages using either WF or SE styles. The Shared TLV must not be used together with the FF style, because each flow needs different reservations. We underline that the use of this object is optional because the only side effect is a waste of resources. RSVP or CR-LDP message processing is not affected. 2.7.5 Shared TLV 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| Shared-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Session // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. As defined in [LDP]. F bit Tommasi/Molendini/Tricco Expires September 2001 [Page 13] draft-tommasi-mpls-intserv-00.txt March 2001 Forward unknown TLV bit. As defined in [LDP]. Shared-TLV This field indicates the type of the Shared TLV. Currently two types are defined: IPv4_RSVP_SESSION type: (Value TBA by IANA) IPv6_RSVP_SESSION type: (Value TBA by IANA) Length Specifies the length of the Session field in byte. Session This field contains an ID of the session for which resources are shared. The Session field is made up by three values taken from the RSVP SESSION object: IP Destination address, Protocol, Transport Destination port. When IPv4_RSVP_SESSION TLV is specified, the IP Destination address is an IPv4 (4 bytes) address; when IPv6_RSVP_SESSION TLV is specified, the IP Destination address is an IPv6 one (16 bytes). 3. Mapping between IntServ and CR-LDP services This section defines translation mechanisms between IntServ traffic parameters and CR-LDP ones. The target is to obtain a service inside the MPLS domain which is as similar as possible to thate provided by the IntServ areas. The Ingress LSR receives the QoS parameters inside the FLOWSPEC object of the Resv message. This LSR is responsible to translate these IntServ values into a Traffic Parameters TLV that the Ingress LSR will forward inside a Label Request message. The Integrated Services WG has defined three services which specify different packet treatments. The Null (N) service allows applications to identify themselves to network QoS policy agents using RSVP signaling. After this, packets are treated according to the DiffServ architecture. Thus, this document does not support this kind of service inside MPLS. When performing a reservation request an application specify the service's number and the values of the parameters it has chosen. CR- LDP uses peak rate, committed rate, and service granularity, to describe traffic characteristic of a path. Tommasi/Molendini/Tricco Expires September 2001 [Page 14] draft-tommasi-mpls-intserv-00.txt March 2001 In the following paragraphs rules to create the Traffic parameters TLV starting from the IntServ parameters are defined for each type of service. 3.1 Controlled Load service The Controlled Load (CL) service provides the application with service closely equivalent to that provided to best-effort traffic under lightly loaded conditions. A CL service request is characterized by five parameters (p, r, b, M, m). An Ingress LSR sets CR-LDP traffic parameters using the following rules: PDR = p PBS = M CDR = r CBS = b EBS = 0 The PDR is equal to the peek rate (p) CL value. The PBS is equal to the maximum packet size (M) because this way we control the maximum size of the IP packets: packets larger then M bytes can never enter this token bucket. The CDR is the average rate of the link and is equal to the data rate (r) of the CL service. The CBS is defined as the maximum size of a burst, hence it is equal to the bucket size (b). The EBS value is set to 0 because this service has not an equivalent parameter in the CL service. This does not prevent an Ingress LSR to choose a value different from 0. 3.2 Guaranteed service Guaranteed (G) service provides firm bounds on end-to-end datagram queueing delays. The G service makes it possible to provide a service that guarantees both delay and bandwidth. A G service request is characterized by seven parameters (p, r, b, M, m, R, S). An Ingress LSR sets CR-LDP traffic parameters using the following rules: PDR = p PBS = M CDR = R' CBS = b Tommasi/Molendini/Tricco Expires September 2001 [Page 15] draft-tommasi-mpls-intserv-00.txt March 2001 EBS = 0 This mapping is very similar to the CL service one, the only difference being that the CDR is set to R'. R' may be equal to the Rate (R) parameter. To keep packets delay below the bounds posed by the G service, the Ingress LSR (as all RSVP routers) must set the CR-LDP data-rate higher than the traffic data rate (r). According to [RFC2212], the R value guarantees that the end-to-end delay for each packet is not larger than the requested one. R' may be smaller than R (but bigger than r) only if a non null slack term is present. The R' value and the new slack term must be calculated as the [RFC2212] specifies. 3.3 Non-conformant packets Non-conformant packets are those that do not conform traffic specifications. The Ingress LSR may treat these packets in different ways, at least as in the followings: 1) Reducing the service to all packets The Ingress LSR labels all the conforming and non conforming packets with the label associated to the setup CR-LDP. LSRs internal to the domain may be able to forward the traffic with a QoS similar to that contracted or not. Each LSR may use its own rules to treat non- confoming packets. This means that the decision associated to the treatment of non-conformant packets is shifted to internal LSRs. 2) Assigning a best-effort treatment The Ingress LSR sorts the flow's packets into a conformant set and a nonconformant set. Those in the conformant set are given the label of the setup CR-LDP, those on the non-conformant are given the label of the best-effort LSP which connects the Ingress LSR and the Egress LSR. Internal LSRs are not aware of non-conforming traffic; they simply serve them with the best-effort queue. As a side effect the applications may receive packets greatly unordered. 3) Assigning a lower than best-effort treatment Non-conforming and conforming packets should be sorted into two sets, in this case too. Packets in the non-conforming set should be assigned a deliver treatment with a priority lower than best-effort one, not to congestion elastic applications. This option require the Tommasi/Molendini/Tricco Expires September 2001 [Page 16] draft-tommasi-mpls-intserv-00.txt March 2001 setup of a low priority path between the edge LSRs (and is not convenient.) 4) Dropping them The Ingress router drops all non-conforming packets. The most important drawback of this solution is that applications that requested to the network a service lighter than their traffic's requirements will experience strong losses. Each solution has pros and cons but there is not enough experience with QoS to suggest an optimal choice; the best choice depends on the characteristics of the domain. 4. Caching and Aggregation techniques This draft allows the setup of a CR-LDP inside the MPLS domain each time an Ingress LSR receives a new RSVP Resv messages. A major issue of the RSVP protocol is the overhead posed by messages' processing in network routers that host a great number of RSVP sessions. The MPLS domain (in the core of a network) is expected to serve a great number of RSVP sessions. We want to avoid that this complexity be imported in the MPLS domain. RSVP's messages may be trigger or refresh ones. Refresh messages are strictly related to the maintaining of the RSVP soft state. The [ROREXT] draft redesign such refresh mechanism to mitigate its effects. CR-LDP does not use soft state, that is its state needs not to be periodically refreshed. Thus, the Ingress LSR does not send any sort of refresh messages inside the domain. The complexity imported from RSVP still resides in the number of CR- LDP messages sent into the domain: a CR-LDP message is sent each time an RSVP trigger message setups or releases a reservation, according to what specified in Section 2. In the following paragraphs some techniques to reduce the number of CR-LDP messages sent inside the domain are discussed. Though used to reduce the message processing overhead, these mechanisms may be also used when the protocol triggering the setup/release of CR-LSPs is not RSVP. 4.1 Caching of CR-LSPs During the setup process, the Ingress LSR creates a CR-LSP and sends into it all the packets that match the associated FEC. The Tommasi/Molendini/Tricco Expires September 2001 [Page 17] draft-tommasi-mpls-intserv-00.txt March 2001 classification of packets is performed by the Ingress LSR only; all the LSR along the path schedule packets with the label associated to that path. Thus, when an RSVP teardown message incomes which releases a reservation for a flow F1, the Ingress LSR may decide not to send the Label Release message into the MPLS domain. It may wait for a given "C" time for another reservation request, let say for the flow F2, specifying the same Egress LSR and similar QoS. The Ingress LSR will only change the FEC associated to the CR-LSP and assign the same label to the packets belonging to this new RSVP flow. The benefit given by such a mechanism is that instead of sending two messages Label Request/Label Release for both F1 and F2, the Ingress LSR will only send a Label Request for F1 and Label Release for F2. This mechanism may be arbitrary generalized to N flows using, at different times, that CR-LSP with no signaling excepted the original Label request message. This mechanism looks very similar to a caching strategy. After an RSVP Teardown message has arrived, the Ingress LSR is expected to set a timer of "C" seconds. If this timer expires and no other flows are mapped to that CR-LSP in the meantime, the Ingress LSR sends the Release message and removes the FEC. As with all caching mechanisms, the one defined in this paragraph strongly depends on the "C" caching time. In the case that this value is a little one, the domain will not benefit of caching. On the other side, if the C value is a big one, the resources associated to the CR-LSP are held though not actually used by any traffic. There is then a trade-off between the reduction of the signaling conveyed by the Ingress LSR into the domain and the efficiency of the usage of network resources. After that the F2 flow has been transmitted through the CR-LSP created for the F1 flow, the traffic related to F2 will use the QoS setup per F1. F2 will receive inside the domain a service similar to what expected only if its traffic parameters are similar to those of F1. Therefore, another parameter which affects the behaviour of the cache is the affinity between the traffic characteristics associated to the CR-LSP during the original setup, and the traffic parameters of the flow wanting to use it. The affinity degree may be quantified through an "A" parameter, which is a sort of "distance" between the traffic parameters of F2 and the CR-LSP. As a second constraint, if no degradation of QoS is desired, the CR-LSP traffic parameters must not be less than those requested by F2. Tommasi/Molendini/Tricco Expires September 2001 [Page 18] draft-tommasi-mpls-intserv-00.txt March 2001 LSRs internal to the domain have no evidence of this mechanism. They only experience a reduction of the CR-LDP signaling load and an over- subscription of resources. CR-LSPs created using a Label Request message that specified a Shared TLV must not be cached. In order to allow sharing of resources by internal LSRs, such a CR-LSP has been mapped to a specific RSVP session via the Shared TLV. Hence, it cannot by used by another RSVP session. Shared reservations cannot use then the CR-LSP cache, but this should not impact the benefits of caching. Has been demonstrated that scalability issues are posed by large numbers of one-to-one audio/video conversations. Such sessions use the Distinct reservation option (i.e. the FF style) and then may be cached. Anyway it is possible, for shared reservations, not to use a Shared TLV inside the Label request message. This way distinct paths are created by different Ingress LSRs (see par. 2.7.4) and those CR-LSPs can be cached after their usage. Caching example: R(i) means a reservation request for the Fi; T(i) means a teardown request for the Fi. R(1) T(1) R(2) T(2) | | | | v v v v +----------------------------------------------------------------+ | F1 F1 F1 F1 | o o | F2 F2 F2 | o o o o | |----------------------------------------------------------------- ^ <-------> <----------------->^ | Wait Time Wait Time (= C) | | | Label Request Label Release Figure 7 - Caching In this example a CR-LSP is setup for a flow F1, with a Caching time, using a Label Request message. After the CR-LSP is setup, the flow F1 is released but no message is sent into the domain. The Ingress LSR waits for a new flow F2 similar to the CR-LSP, which arrives before that a timer of C seconds has expired. After that also this flow is released, the Ingress LSR waits Tommasi/Molendini/Tricco Expires September 2001 [Page 19] draft-tommasi-mpls-intserv-00.txt March 2001 for another flow but after an idle time of C seconds, the LSR release the CR-LSP from the domain. 4.2 Aggregation of CR-LSPs It has been discussed in the previous paragraph that the responsible for the association of RSVP flows with a CR-LDP is the Ingress LSR. Such a node may decide to map into a single CR-LDP more than one flow directed towards the same Egress LSR. Having a smaller number of CR- LSPs, less CR-LDP signaling is needed. Traffic parameters of this CR-LDP must satisfy the aggregated flows. The Ingress LSR should sum the traffic specifications of each flow and reserve a CR-LDP with the related Traffic Parameters (as described in Section 3). The sum operation depends upon the service being used, that is the aggregation can be only applied to flows specifying the same service. A basic sum operation is defined in [RFC2211] for the CL service or in [RFC2212] for the G one. The Ingress LSR may decide to use more "aggressive" aggregation algorithms than proposed in those basic specs, by defining an aggregating sum which takes into account the statistical properties of the flows. Aggregation may be used in a straightforward way at the arrival of an RSVP Bundle message from an Edge LSR. This message has been defined in [ROREXT]; it is a container of other RSVP messages. All Resv messages put in this Bundle come from the same Edge NHop (that is the same Egress LSR). Some of these reservation requests may be satisfied at once setting up a single aggregated CR-LSP. Another possibility is given by the arrival of Resv which uses FF style with more than one FILTER_SPEC (see Figure 3). Instead of defining a CR-LSP for each FILTER_SPEC, an aggregated one might be used. In the most general case, at the incoming of a Resv message an Ingress LSR may decide to setup a CR-LDP endowed with more resources than needed. At different moments, the Ingress LSR may aggregate other incoming flows to this CR-LDP, until this CR-LDP has available resources. The degree of bandwith oversubscription is quantified through a "B" parameter, which indicates how many flows with similar traffic parameters can be accommodated into the aggregated CR-LSP. To prevent a waste of resources as well as degradation of QoS, before being mapped to an aggregated CR-LSP a flow must be similar to it, that is with the proper affinity degree. Tommasi/Molendini/Tricco Expires September 2001 [Page 20] draft-tommasi-mpls-intserv-00.txt March 2001 Aggregation example: R(i) means a reservation request for the Fi; T(i) means a teardown request for the Fi. R(1) R(3) R(2) T(1) T(2) R(4) R(5) T(4) T(3) T(5) | | | | | | | | | | v v v v v v v v v v +----------------------------------------------------------------+ | F1 F1 F1 F1 | o o o | F4 F4 F4 | o o o | |----------------------------------------------------------------- | o o | F2 F2 F2 | o o o | F5 F5 F5 F5 F5 | |----------------------------------------------------------------+ | o | F3 F3 F3 F3 F3 F3 F3 F3 F3 F3 F3 | o | +----------------------------------------------------------------- ^ ^ | | Label Request Label Release Figure 8 - Aggregation In this example we suppose that a CR-LSP is setup for a flow F1, with a B parameter equal to 3, using a Label Request message. After the CR-LSP is setup, the flow F2 and F3 request resources and assigned to CR-LSP, if similar to it, with no signaling in the domain. When F1 is removed, its "slot" is unallocated until the F4 flow is mapped to it. After F5 is removed no flows occupy the CR-LSP, thus it is removed using a Label Release message. If caching is used, this CR-LSP is kept for a C time before being released. 4.3 The ABC control parameters In the previous paragraphs we have defined three A, B, C parameters. These parameters control all together the trade-off between the reduction of CR-LDP signaling and the time resources are hold though not used. We now discuss the meaning of the ABC parameters without giving, as far as of this version of the document, an exact definition. In the examples contained in this paragraph we will suppose, for simplicity sake, that a flow is characterized by a single parameter "r" and the CR-LDP by the single CDR. Tommasi/Molendini/Tricco Expires September 2001 [Page 21] draft-tommasi-mpls-intserv-00.txt March 2001 4.3.1 Parameter A The A ("Affinity degree") parameter is the similarity degree between two sets of traffic parameters. A flow can be assigned to an existing CR-LSP only if similar to it. Example: A = 90% and the CDR = 100 kbps. CDR is the data rate associated to the CR-LSP. A flow F is similar to the CR-LSP only if its parameter r is less than the CDR but not less than the 90% it. That is, F is similar only if its r belongs to the [90kbps, 100kpbs] interval. 4.3.2 Parameter B The B ("Bandwidth multiplier") parameter is the bandwith multiplier factor. When an incoming reservation request arrives, the Ingress LSR setups a CR-LSP enabled to contain B distinct flows with similar traffic parameters. Example: B=3 and the r = 50 kbps. The Ingress LSR will create a CR-LSP with a CDR parameter equal to B*r, that is 150 kbps. The reserving flow is mapped to this CR-LSP as well as future flows, similar to the original r rate. At any time, that CR-LSP cannot aggregate more than B flows. If the A parameter is equal to 95%, a flow with a rate r equal to 48 kbps may be aggregated to that CR-LSP, another flow with rate equal to 41 kbps (less than 47.5 kbps) cannot. 4.3.3 Parameter C The C ("Caching time") is the time a CR-LSP should be kept alive after it is no longer used by any flow. This way the Ingress LSR controls the await time for a new flow. Example: C= 10 min. The Ingress LSR, after having received a release request from the outside of the domain, does not tear down the CR-LSP. If a reservation request arrives from a flow in the following 10 minutes, this flow uses that CR-LSP only if it is similar to it. Otherwise, after 10 minutes expire, the Ingress LSR sends a Label Release message along the path. Tommasi/Molendini/Tricco Expires September 2001 [Page 22] draft-tommasi-mpls-intserv-00.txt March 2001 4.4 Examples of CR-LSP management strategies The choice of the ABC parameters greatly affects the dynamic of the management of the resources. The administrator of the network should set these parameter for all the interfaces of the LSRs in the domain. The values may change for each interface - someone may be connected to a well-provisioned network, someone else not. In a following version of this draft we will specify how the Ingress LSR collects the ABC parameters along the path, and choose the values to assign to a flow. To simplify the administration work, a default configuration should be given by the vendor which takes into account the features of the product. However we recommend to provide "conservative" values as defaults. We now discuss how the configuration of the ABC parameters modify the trade-off from a "conservative" (when less bandwidth is available) towards an "aggressive" one (when a strong reduction of signaling is desired). The following are some of the possible scenarios. o) One-to-one direct mapping: A=(any), B=1, C=0. Neither caching nor aggregation are enabled, hence no affinity value is needed. Each time a reservation request arrives, the Ingress LSR setups the CR-LSP with traffic parameters given in the FLOWSPEC of the message. When the related release request arrives, the CR-LSP is immediately released inside the domain. This scenario lead to a zero wasting of resources but with complete signaling inside the domain. This is the most conservative strategy. o) Isolated flows on cached paths: A=Low, B=1, C=High. Caching only is enabled, with a loose affinity value. This way CR-LSPs with large resources may be assigned to flows, that continue to be isolated from each other. The low affinity value grants a large usage of the cached paths. This leads to some wasting of resources, but grants a minimum of signaling in all the cases where reservation and deletion requests incomes with a regular rate. o) Aggregation of little flows: A=Low, B=High, C=0. Tommasi/Molendini/Tricco Expires September 2001 [Page 23] draft-tommasi-mpls-intserv-00.txt March 2001 Caching is disabled and aggregation heavily used. This scenario is useful when a number of requests is expected that reserve little resources each. This way, a path is defined for many flows with a single signaling per aggregated path. o) Multiplexing on fixed channels: A=Low, B=High, C=Infinite A set of large (B is High) static channels (infinite caching time) is created with traffic chosen traffic parameters. Incoming traffic is very likely (because of the loose affinity) aggregated to one of them. Otherwise, it will not receive QoS inside the domain. This configuration needs no signaling inside the domain, excepted from the initial one. Future Work This version of the draft is far from being a complete document. Future versions will: o) Discuss the cases were either the RSVP NHop not coincide with the Egress LSR or the RSVP PHop does not coincide with the Ingress LSR. o) Collect information on the path using ADSPEC-like CR-LDP TLVs. o) Contract information on ABC parameters along the path. o) Allow the usage of MPLS tunnels. o) Add processing rules for RSVP messages not considered in the current version document. o) Add detailed message processing rules. Security Considerations No additional security issues are introduced in this draft. RSVP and CR-LDP messages security problems are discussed in their specification documents. References [RFC1633] R. Braden, D. Clark, S. Shenker, "Integrated Services in the Internet Architecture: an Overview". June 1994. Tommasi/Molendini/Tricco Expires September 2001 [Page 24] draft-tommasi-mpls-intserv-00.txt March 2001 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification". September 1997. [RFC2208] A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O`Dell, A. Romanow, A. Weinrib, L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment". September 1997. [RFC2209] R. Braden, L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules". September 1997. [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated Services". September 1997. [RFC2211] J. Wroclawski, "Specification of the Controlled-Load Network Element Service". September 1997. [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of Guaranteed Quality of Service". September 1997. [RFC2215] S. Shenker, J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements". September 1997. [RFC2216] S. Shenker, J. Wroclawski, "Network Element Service Specification Template". September 1997. [RFC2997] Y. Bernet, A. Smith, B. Davie. "Specification of the Null Service Type". November 2000. [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture". January 2001. [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP Specification". January 2001. [CR-LDP] B. Jamoussi et al., "Constraint-Based LSP Setup using LDP", Work in progress, draft-ietf-mpls-cr-ldp-05. August 2001. [CR-LDPMOD] J. Ash et al., "LSP Modification Using CR-LDP", Work in progress, draft-ietf-mpls-crlsp-modify-03. March, 2001. Tommasi/Molendini/Tricco Expires September 2001 [Page 25] draft-tommasi-mpls-intserv-00.txt March 2001 [RAGGR] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of RSVP forIPv4 and IPv6 Reservations", Work in progress, draft-ietf-issll-rsvp-aggr-03. February 2001. [ROREXT] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, " RSVP Refresh Overhead Reduction Extensions", Work in progress, draft-ietf-rsvp-refresh-reduct-05. June, 2000. Author's Addresses Franco Tommasi University of Lecce, ITALY Phone: +39-832-320310 Email: franco.tommasi@unile.it Simone Molendini University of Lecce, ITALY Phone: +39-832-320310 Email: simone.molendini@unile.it Andrea Tricco University of Lecce, ITALY Phone: +39-832-320310 Email: atricco@libero.it Tommasi/Molendini/Tricco Expires September 2001 [Page 26]