Internet Draft F. Tommasi S. Molendini A. Tricco Document: draft-tommasi-mpls-intserv-01.txt University of Lecce, ITALY Expiration date: November 2001 May 2001 Integrated Services across MPLS domains using CR-LDP signalling 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 In this document a solution which efficiently combines the application-oriented IntServ QoS with the power of MPLS label switching is described. This document defines IntServ-like QoS services in MPLS domains targeting the following problems: *) Providing a user-driven MPLS QoS path setup. An application uses the standard IntServ Reservation API to allocate network resources. IntServ reservation (signaled using RSVP) are then mapped at the Ingress LSR of the MPLS domain into proper CR-LSPs. *) Reducing the CR-LDP signalling overhead providing caching and aggregation of CR-LSPs. Manual configuration of the Tommasi/Molendini/Tricco Expires November 2001 [Page 1] draft-tommasi-mpls-intserv-01.txt May 2001 bandwidth/signalling trade-off as well as automatic load discovery mechanisms both are allowed. The center of this solution is the MPLS Ingress LSR which acts like an MPLS/IntServ QoS gateway. 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 1.1 Why should MPLS people be interested in this draft?............4 2. Integration of RSVP and CR-LDP signalling.......................5 2.1 Path Messages..................................................7 2.2 Resv Messages..................................................7 2.3 CR-LSP setup...................................................8 2.4 Path & Resv refresh messages...................................9 2.5 Teardown messages..............................................9 2.6 Error messages.................................................9 2.7 Classification................................................10 2.7.1 Fixed-Filter Style..........................................10 2.7.2 Shared-Explicit Style.......................................11 2.7.3 Wildcard-Filter Style.......................................12 2.7.4 Shared option and multiple Ingress LSRs.....................13 2.7.5 Shared TLV..................................................15 3. Mapping between IntServ and CR-LDP services....................15 3.1 Controlled Load service.......................................16 3.2 Guaranteed service............................................17 3.3 Non-conformant packets........................................17 4. Caching and Aggregation techniques.............................18 4.1 Caching of CR-LSPs............................................19 4.2 Aggregation of CR-LSPs........................................21 4.3 The ABC control parameters....................................23 4.3.1 Parameter A.................................................23 4.3.2 Parameter B.................................................23 4.3.3 Parameter C.................................................24 4.4 CR-LSP management strategies..................................24 Future Work.......................................................26 Security Considerations...........................................26 References........................................................26 Authors' Addresses................................................28 Tommasi/Molendini/Tricco Expires November 2001 [Page 2] draft-tommasi-mpls-intserv-01.txt May 2001 1. Introduction The Integrated Services (IntServ) architecture [RFC1633] defines QoS services and reservation parameters to be used to obtain the required QoS for an Internet flow. RSVP [RFC2205] is the signalling 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 signalling 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 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 signalling, 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. IETF RSVP-related WGs have undertaken some work to overcome these problems. The RSVP WG has recently published the RFC2961 that describes a set of techniques to reduce the overhead of RSVP signalling which doesn't even deal with the classification problem, still unfaced. The [RAGGR] draft of the ISSLL WG discusses the possibility of aggregation of RSVP sessions into a larger one. The aggregated RSVP session uses a DiffServ DSCP for its traffic. Such a solution wastes the undoubted benefits given by the IntServ quantitative QoS approach. 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- Tommasi/Molendini/Tricco Expires November 2001 [Page 3] draft-tommasi-mpls-intserv-01.txt May 2001 LDP], that is to perform QoS classification using a single valued label (not a MultiField one). The main limitation of this current approach is that it can't be used by end-hosts because they can't do CR-LDP signalling. 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 document 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 here described end-to-end QoS is reached without service disruptions between MPLS domains and IntServ areas. The center of this solution is the MPLS Ingress LSR which acts like an MPLS/IntServ QoS gateway. At the same time, the number and the effects of the changes to the current CR-LDP specifications are minimal. Most of the integration work is bounded into the Ingress LSR at the sender side of the MPLS domain's border. 1.1 Why should MPLS people be interested in this draft? Sub-IP Area directors ask authors of individually submitted drafts to provide for a description of the targets they address. We insert here such information using a format compliant with the directors' requirements. NAME OF I-D http://www.ietf.org/internet-drafts/draft-tommasi-mpls-intserv-01.txt SUMMARY We propose in this draft a solution which 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. Our I-D targets the following problems: *) Providing a user-driven MPLS QoS path setup. An application uses the standard IntServ Reservation API to allocate network resources. IntServ reservation (signaled using RSVP) are then mapped at the Ingress LSR of the MPLS domain into proper CR-LSPs. *) Reducing the CR-LDP signalling overhead providing caching and aggregation of CR-LSPs. Manual configuration of the bandwidth/signalling trade-off as well as automatic load discovery Tommasi/Molendini/Tricco Expires November 2001 [Page 4] draft-tommasi-mpls-intserv-01.txt May 2001 mechanisms both are allowed. The center of this solution is the MPLS Ingress LSR which acts like an MPLS/IntServ QoS gateway. RELATED DOCUMENTS B. Jamoussi et al., "Constraint-Based LSP Setup using LDP", Work in progress, draft-ietf-mpls-cr-ldp-05. August 2001. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK mpls WHY IS IT TARGETED AT THIS WG This draft defines the behaviour of an Ingress LSR and provides guidelines for the creation a CR-LSPs according to a bandwidth/signalling trade-off. Hence the I-D belongs to MPLS. JUSTIFICATION The I-D provides mechanisms for an automatic and efficient setup of CR-LSPs. It faces with the uncovered problem of interfacing the IntServ reservations with CR-LDP ones. We already received positive feed-back from interested people of the WG. 2. Integration of RSVP and CR-LDP signalling 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 5] draft-tommasi-mpls-intserv-01.txt May 2001 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 that this router processes RSVP messages. Both the Ingress and Egress LSR modifies after that 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, swaps this value back to RSVP. Using the mechanisms proposed in this document, the MPLS domain may participate, using its native CR-LDP messages, to obtain a level of service inside the domain comparable with the IntServ QoS requested by RSVP applications. This section covers the rules to generate adequate 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. The values of the Traffic Parameters TLV (i.e. QoS parameters associated to the CR-LSP) are derived from 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 responsible for performing the message translation to create this CR-LSP. LSRs that are 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. Tommasi/Molendini/Tricco Expires November 2001 [Page 6] draft-tommasi-mpls-intserv-01.txt May 2001 CR-LDP does not provide the signalling 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. A Path message performs two main tasks. The first one is to trace the path from the sender to the receiver. This path will be followed by the reserving Resv message travelling in the opposite direction. It is not important the route followed by the Path message inside the MPLS domain. The second one is to notify to the receiving application 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 as this piece of information has an end-to-end scope. The ADSPEC object is generated by the sender and updated along the Path instead. According to this document 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 the new RSVP state into the new Ingress LSR and the old Ingress LSR will delete the 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 travels across 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 7] draft-tommasi-mpls-intserv-01.txt May 2001 Ingress LSR through the MPLS domain. The Ingress LSR transmits the Resv message upstream towards its interface over the IntServ area. 2.3 CR-LSP setup 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. | | 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 "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 which route the Label Request message uses to reach the Egress LSR (the RSVP NHop). The only needed constraint is that the last ER-Hop TLV MUST be the RSVP NHOP. An implementation is free to add more ER-Hops (that is to do Traffic Engineering). The same can be told for all other optional TLV objects in the message. The Traffic Parameters TLV is mandatory as far as this specifications. 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). Tommasi/Molendini/Tricco Expires November 2001 [Page 8] draft-tommasi-mpls-intserv-01.txt May 2001 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 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-LSP 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 details for multiple senders case are 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 in error messages that modify internal RSVP state. Tommasi/Molendini/Tricco Expires November 2001 [Page 9] draft-tommasi-mpls-intserv-01.txt May 2001 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 provided inside the MPLS domain or not, it is a matter local to the domain itself. 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 accomplishes this goal. 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 senders use resources different from each other. 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 to 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 10] draft-tommasi-mpls-intserv-01.txt May 2001 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 reads from the SESSION and FILTER_SPEC objects these five parameters. It then associates 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 case a PathTear arrives, only the sender specified by the SENDER_TEMPLATE object is removed. Thus the (possibly) allocated CR-LSP is released. In the case 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 carries 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 by matching the five parameters in its headers with the information contained in the SESSION and FILTER_SPEC objects. What changes is the use of a single Tommasi/Molendini/Tricco Expires November 2001 [Page 11] draft-tommasi-mpls-intserv-01.txt May 2001 FEC for all the senders. 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 the sender's flows are merged inside the MPLS domain, which on its turn applies to these packets the same treatment. 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 of 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 12] draft-tommasi-mpls-intserv-01.txt May 2001 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. 2.7.4 Shared option and multiple Ingress LSRs A modification of the mechanisms described in the paragraph 2.3 is needed when hosts send Path messages to the MPLS domain through different Ingress LSRs while 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 In Figure 3 each of three hosts HS1, HS2 and HS3 sends (at different times) a Path message 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 to the Egress LSR, which is the common PHop of the three senders. The Egress LSR sends two Resv messages to the two PHop of the session, one being Ingress LSR1 for HS1, the other Ingress LSR2 for both HS2 and HS3. Both Tommasi/Molendini/Tricco Expires November 2001 [Page 13] draft-tommasi-mpls-intserv-01.txt May 2001 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 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 resources twice the needed amount. To overcome this issue, a new CR-LDP "Shared TLV" object is added 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. 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. Tommasi/Molendini/Tricco Expires November 2001 [Page 14] draft-tommasi-mpls-intserv-01.txt May 2001 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 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 I-D 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 and CR- LDP traffic parameters. The target is to obtain a service inside the MPLS domain which is as similar as possible to that 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 15] draft-tommasi-mpls-intserv-01.txt May 2001 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 signalling. After this, packets are treated according to the DiffServ architecture. Thus, this document does not deal with this kind of service inside MPLS. When performing a reservation request an application specifies 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. 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. Tommasi/Molendini/Tricco Expires November 2001 [Page 16] draft-tommasi-mpls-intserv-01.txt May 2001 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 EBS = 0 This mapping is very similar to those of the previous section, 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 at least in the following ways: 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-LSP. 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- conforming 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 17] draft-tommasi-mpls-intserv-01.txt May 2001 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-LSP, 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 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-LSP 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 RFC2961 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 18] draft-tommasi-mpls-intserv-01.txt May 2001 an RSVP trigger message sets up 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 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 signalling 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 signalling conveyed by the Ingress LSR into the domain and the efficiency of the usage of network resources. Tommasi/Molendini/Tricco Expires November 2001 [Page 19] draft-tommasi-mpls-intserv-01.txt May 2001 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. LSRs internal to the domain have no evidence of this mechanism. They only experience a reduction of the CR-LDP signalling 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 | |----------------------------------------------------------------- Tommasi/Molendini/Tricco Expires November 2001 [Page 20] draft-tommasi-mpls-intserv-01.txt May 2001 ^ <-------> <----------------->^ | 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 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-LSP is the Ingress LSR. Such a node may decide to map into a single CR-LSP more than one flow directed towards the same Egress LSR. Having a smaller number of CR- LSPs, less CR-LDP signalling is needed. Traffic parameters of this CR-LSP must satisfy the aggregated flows. The Ingress LSR should sum the traffic specifications of each flow and reserve a CR-LSP 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 RFC2961; 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 Tommasi/Molendini/Tricco Expires November 2001 [Page 21] draft-tommasi-mpls-intserv-01.txt May 2001 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-LSP endowed with more resources than needed. At different moments, the Ingress LSR may aggregate other incoming flows to this CR-LSP, until this CR-LSP has available resources. The degree of bandwidth 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. 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 signalling 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. Tommasi/Molendini/Tricco Expires November 2001 [Page 22] draft-tommasi-mpls-intserv-01.txt May 2001 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 signalling 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-LSP by the single CDR. 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 bandwidth 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. Tommasi/Molendini/Tricco Expires November 2001 [Page 23] draft-tommasi-mpls-intserv-01.txt May 2001 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. 4.4 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 could set these parameter for LSRs in the domain. To simplify the administration work, a default configuration should be given by the vendor which takes into account the features of the product. 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 signalling 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 signalling 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. Tommasi/Molendini/Tricco Expires November 2001 [Page 24] draft-tommasi-mpls-intserv-01.txt May 2001 The low affinity value grants a large usage of the cached paths. This leads to some wasting of resources, but grants a minimum of signalling 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. 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 signalling 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 signalling inside the domain, excepted from the initial one. The proper choice of ABC parameters affects the bandwidth/signalling tradeoff. It would be useful to allow all the LSR along the path to cooperate to the choice of the ABC values. Each LSR may transmit to the Ingress LSR information about their CR-LDP signalling load, bandwidth availability and perhaps other characterizing values. The Ingress LSR may use these values to configure the ABC values to be used for this path. The Ingress LSR may send CR-LDP Query/Reply messages defined in [LSPQUERY]. These messages collect parameters (e.g. unused bandwidth) from the LSRs belonging to a given path. Tommasi/Molendini/Tricco Expires November 2001 [Page 25] draft-tommasi-mpls-intserv-01.txt May 2001 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) Refine the mechanism to collect 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. [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. Tommasi/Molendini/Tricco Expires November 2001 [Page 26] draft-tommasi-mpls-intserv-01.txt May 2001 [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. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, " RSVP Refresh Overhead Reduction Extensions' '. April, 2001. [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. [LSPQUERY] P. Ashwood-Smih, A. Paraschiv, "MPLS LDP Query Message Description ", Work in progress, draft-ietf-mpls-lsp-query-01. November, 2000. [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-04. April 2001. Tommasi/Molendini/Tricco Expires November 2001 [Page 27] draft-tommasi-mpls-intserv-01.txt May 2001 Authors' 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 November 2001 [Page 28]