Internet Draft MPLS Working Group O. Aboul-Magd B. Jamoussi Internet Draft Nortel Networks Document: draft-aboulmagd-srvc-def-crldp-00.txt October 1999 Category: Informational A Framework for Service Definition and Interworking Using CR-LDP 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. 1. Abstract Label-distribution protocol (LDP) is defined in [1] for the distribution of labels inside one MPLS domain. CR-LDP is defined in [2] to work in conjunction with the LDP for establishing label switched paths with prescribed QoS requirements. The establishment of those paths is called constraint-based routing (CR) and it offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. To facilitate the establishment of CR paths, the CR-LDP specification include the essential entries (TLVs) to allow the characterization of the traffic requirements and service expectations. The objectives of this draft are to establish a general framework for service definition using the mechanisms specified in [2] and to illustrate how service interworking could be achieved between an MPLS domain using CR-LDP and other domains that might employ similar or different networking technologies. 2. Introduction Aboul-Magd Expires April, 2000 1 A Framework for Srvc Def using CR-LDP October, 1999 In an MPLS domain [3], when a stream of data traverses a common path, a label switching path (LSP) can be established using LDP signaling protocol. To facilitate the assignment of QoS properties to an LSP the LDP methods and procedures are extended in CR-LDP to allow for this association. With the introduction of the QoS capabilities, planning for new services, other than the traditional best effort service, is now possible. While CR-LDP allows for signaling a number of QoS-related parameters, it does not specify or explicitly provide for the signaling of pre-defined services. This approach, of not explicitly defining or signaling services, is a departure from other QoS architectures such as the ATM service categories defined in [4]. The CR-LDP approach for service definition borrows from, and is consistent with, that suggested for the differentiated services (Diffserv) architecture [5]. The salient feature of that approach is the separation between the edge rules, implemented at the edge LSR, and the local behavior, implemented at the various nodes of the networks. The adaptation of this approach achieves two main objectives: - A network operator has the flexibility to define those services that fit his business. - Services are not `hardwired' by correlating the edge rules to the local behavior (e.g. the GS [6] and the CLS [7] in Intserv model). With this recognized flexibility, interworking between different MPLS domains employing different services becomes essential. Of equal importance is the interworking between MPLS/CR-LDP QoS architectures and those of other QoS architectures such as ATM, Intserv, FR, etc. 3. Overview of CR-LDP QoS Capabilities The traffic parameters TLV of the CR-LDP is shown below 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Traf. Param. TLV (0x0810)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Frequency | Reserved | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate (PDR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Burst Size (PBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Data Rate (CDR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Committed Burst Size (CBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboul-Magd Expires April, 2000 2 A Framework for Srvc Def using CR-LDP October, 1999 | Excess Burst Size (EBS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In a nutshell the traffic parameters TLV allows for: - The signaling of parameters relevant to traffic characteristics - Indication of the required service frequency - The assignment of different weights to different LSPs, and - The ability to renegotiate each of the traffic parameters and the LSP weight TLV parameters that are relevant to traffic characteristics are peak date rate (PDR) and committed data rate (CDR). Both PDR and CDR are measured over specified time intervals as defined by the peak burst size (PBS) and the committed burst size (CBS). In addition to CBS, an LSP could burst at its CDR up to a level specified by an excess burst size (EBS). From the user perspective, those traffic related parameters are useful in signaling to the MPLS domain of the user desired parameters, e.g. a certain CDR. To the network those parameters are used to execute the local admission control function at each of the LSR along the path. If specified by the user, a simple token bucket algorithm could monitor each of PDR and CDR. For instance for the PDR could be monitored by a token bucket with, token rate = PDR and maximum token size = PBS. For the CDR, and if EBS is specified, two token buckets, C and E, are proposed. The C and E token buckets are incremented at the CDR. The C bucket, when full, overflows into the E. The specification of the service frequency is an indication to the network of the delay characteristics that are required from the network. For services with stringent delay requirements that are not able to tolerate large delay variations, a VeryFrequent granularity of the CDR is to be used. This implies that the rate assigned to the service should average at least its CDR when measured over any time interval equal to or longer than the shortest packet time at CDR. This assignment ensures that the transmission resources, as governed by the packet scheduler, are available to a particular LSP at a rate that is at least equal to its data arriving rate, assuming the shortest possible packet size. Hence data are expected to be served as they arrive and accumulation of delay greater than L/CDR is not permitted where L is the shortest packet size. For applications [8] that can tolerate some amount of delay variations, the service frequency can be assigned the value Frequent. This implies that the available rate should average at least the CDR measured over any time interval equal to or longer than a small number of shortest packet times at CDR. Hence packets are served after a delay that is bounded by a few packet times measured at CDR. The number of packets is Aboul-Magd Expires April, 2000 3 A Framework for Srvc Def using CR-LDP October, 1999 a configurable parameter that is set to meet the service delay requirement. Other services such as elastic service [8] can be assigned the value Unspecified. This implies that the CDR may be provided at any granularity. Thus CDR might be guaranteed over a longer time scale than that offered by VeryFrequent or Frequent assignments. CR-LDP allows for resource sharing among a number of CR-LSPs sharing the same interface. The Weight parameter determines the CR-LSP relative priority when assigning excess nodal bandwidth or under congestion conditions. The implementation of a particular fairness criterion is MPLS domain specific. Negotiation allows the network to offer a CR-LSP a set of revised parameters and Weight that are more suitable for the current network state. Parameter negotiation is allowed only if indicated by the appropriate Flag. Flags are provided for PDR, PBS, CDR, CBS, EBS, and Weight. Negotiation is only allowed in that direction where the parameter values are lowered from those defined in the original signaling message. If modified, the node MUST overwrite the modified parameters before forwarding the message to the next node. A node might elect to change its reservation level based on the new parameter values carried in the traffic parameters TLV in the label mapping message. While not the concern of this draft, procedures for user-initiation re- negotiation of the CR-LSP parameters are outlined in [9]. This capability, if implemented, is useful to introduce changes to the reservation level of an LSP as a function of the actual usage. 4. Service Definition Framework 4.1 Service Model A CR-LDP service model could have supported three categories of applications that are classified by their delay requirements [8]. The most demanding group of applications are those that cannot tolerate delay or loss such as circuit emulation services or intolerant real time applications. The second categories of applications are applications that can tolerate some loss or delay. Examples of these applications are tolerant real time systems or real time data applications that require reasonably quick response to function. The support of those applications requires the definition of real time service (RTS) to meet the delay objective of the applications. Elastic applications are those that are traditionally handled using best effort service. One important nature of elastic applications is the absence of a packet due time and each received packet is used immediately without the need to buffer for some later time [8]. Those applications rely on the sustained flow of packets, no matter how long Aboul-Magd Expires April, 2000 4 A Framework for Srvc Def using CR-LDP October, 1999 they are delayed (as long as the delay is not excessive), and could be considered as throughput sensitive (TS) applications. In that respect a CR-LDP domain is expected be able to support a minimum of two broad classes of services, RTS and TS service, in addition to the traditional best effort service. As mentioned before, the CR-LDP service model goes beyond that of specifying particular services. The CR-LDP model provides a set of building blocks that allows the construction and the definition of many services. This model is fundamentally sound, as it does not require changes to the basic paradigm every time the need for a new service arises. This model is also flexible, as it does not mandate the use of particular services for which operational experience might show that they are useless or inadequate. This model also facilitates the service interworking between different domain employing different networking technologies, as it will be discussed later. The main building blocks for QoS-based services support using CR-LDP is the definition of edge rules to be implemented at the edge LSR and the definition of local behaviors in terms of resource allocation and packet forwarding. Edge rules are specifically defined as not signaled in the CR-LDP. Edge rules are left as part of the contract between network providers and customers and are configured using node management system. Those rules might include policing with some specified policing actions in terms of packet drop or marking for discard eligibility. CR-LDP signals parameters that are sufficient to characterize the local behavior in terms of packet forwarding. Traffic parameters such as PDR, PBS, etc. are useful in deciding the allocation level for a particular CR-LSP. Frequency and Weight are useful indication to show how often packets of a given CR-LSP must be serviced and how to share resources among a number of competing CR-LSPs. This approach is similar to the PHB concept in the Diffserv architecture [5]. 4.2. Nodal Mechanisms There are minimum requirements that must be satisfied before a network becomes QoS-enabled [8]. One of those requirements is the availability of an adequately defined signaling mechanism. In the context of this draft this requirement is fulfilled by CR-LDP. Other requirements include admission control and packet dropping and scheduling as shown in the figure. Admission control and packet scheduling are local issues pertaining to the nodal architecture. ------------------------ | | | | CR_LDP | +-------+ | Aboul-Magd Expires April, 2000 5 A Framework for Srvc Def using CR-LDP October, 1999 ===============>|Admis |=============> | |Control| | | +-------+ | | | | +--+ +--+ +--+ | =======> | |---->| |->| |=========> Data Path | +--+ +--+ +--+ | | TC buffer scheduling | mgmt | |-----------------------| The admission control module acts on the traffic parameters TLV. Based on the supplied parameters values the module computes the amount of resources needed to be reserved. If those resources could be supplied given the current nodal state, then the admission control module forwards the signaling message to its peer in the next hop. If no sufficient resources exist, then the admission control function sends a notification message indicating that resources are not available. The controlled dropping of packets is important for some services. The MPLS packet header does not explicitly provide for a drop precedence field. It has been proposed [10] that the Exp field in the MPLS header is used for indicating the drop precedence for each packet. The Exp field can also be used for differently scheduling packets that belong to the same CR-LSP. 4.3. Service Definition Model and Examples Service definition in an MPLS domain using CR-LDP follows the same paradigm as in the Diffserv architecture [5]. The service definition task is carried out by identifying the rules enforced at the network edges and the local behavior expected at the LSR. Service definition is often referred to as [11-12]: Services = Rules + Behavior Edge rules are equivalent to traffic conditioning in the Diffserv architecture. Edge rules include those functions related to metering, policing, shaping, etc. Edge rules also define actions of the edge LSR regarding CR-LSP packets that are deemed non-conformant to its traffic contract. Those actions could include drop, forward, forward with a maximum limit, etc. The edge rules are not explicitly specified or signaled in CR-LDP. It is expected that those rules will be part of the traffic contract between the customer and the operator. This part of the contract defines the traffic conditioning function and its action and it could be modified only by mutual agreement of the parties involved. The actual parameters used for traffic conditioning could be extracted from the CR-LDP signaling message or could be permanently configured. Aboul-Magd Expires April, 2000 6 A Framework for Srvc Def using CR-LDP October, 1999 The discussion about the edge rules should not imply that traffic conditioning is only recommended at the edge of the network. Traffic conditioning functions such as shaping and policing could also be implemented anywhere in the network the network provider deemed necessary. The local behavior is determined by the traffic parameters in the signaling message. Those traffic parameters define how packets belonging to a CR-LSP will be treated. For instance, packets of a CR- LSP requesting a VeryFrequent frequency of service will be directed the appropriate queue, e.g. the highest emission priority queue in an link scheduler. The service definition paradigm described here can be used to describe two RTS and TS services introduced in section 4.1. For RTS service with CBR-like traffic the traffic parameters TLV entries could be set at: PDR: service rate (e.g. coding rate in voice applications) PBS: few packets to account for the multiplexing effect CDR: PDR CBS: PBS EBS: 0 Service Frequency: VeryFrequent or Frequent depends on the tolerance level of the application Edge rules: token bucket policing with parameters (PDR, PBS) Drop non-conformant packets The dropping of non-conformant packets is included in the edge rules to avoid the region of the queue operation where a small increase in the load leads to large delay. Allowing non-conformant packets with potentially uncontrolled load could lead to a situation where the delay objectives of the service are not satisfied. For the TS service, the traffic parameters TLV entries could be set at: PDR: Service rate (could be set at the access rate) PBS: few packets to account for the multiplexing effect (note that PBS = 1 if PDR = access rate) CDR: Committed rate (e.g. n*64 Kbps) CBS: maximum expected burst (e.g. some multiple of the maximum protocol data unit) EBS: 0 Service Frequency: Unspecified Edge rules: Two token buckets policing with parameters (PDR, PBS) and (CDR, CBS) Packets non-conformant to (CDR, CBS) token bucket are marked for high discard precedence using the Exp filed. Packets non-conformant to (PDR, PBS) token bucket are dropped. Aboul-Magd Expires April, 2000 7 A Framework for Srvc Def using CR-LDP October, 1999 4.4 LSP Merging LSP merging is an important MPLS feature that is necessary for the support of scalable networks. The service definition model described here allows LSP merging as long as LSPs of the same service and QoS parameters are merged together. In that respect the service definition paradigm described here is equivalent to overlaying a service layer on top of the MPLS region. The minimum requirement is to have a single LSP provisioned for each service supported. 5. Interworking Model Networking is not a homogeneous environment. Packets traverse multiple domains (under the same or different administration authorities) with different networking technologies. Interworking between the QoS architecture of various technologies is needed to ensure the homogeneity of the end-to-end services. With the service definition paradigm adapted for the CR-LDP, mapping between different MPLS domains becomes essential because different MPLS domains might support different services. A general architecture for service inter-working is shown in the figure. +---------------+ +-----+ +--------------+ | | | | | | | Domain 1 |--+IWU +--| Domain 2 | | | | | | | +---------------+ +-----+ +--------------+ The Interworking unit (IWU) is responsible for service and/or packet mapping from one domain to the other. Therefore the IWU must be aware of the services offered on its interfaces and be capable of performing the appropriate parameter transformation. The IWU should also initiate the appropriate signaling procedure, if required, to establish a session with adequate service in the corresponding domain. At the IWU, the incoming packets on a certain interface are classified according to the services they belong to. Packets are then mapped to the appropriate services supported by the other domain. The selected mapping is pre-configured at the IWU. Needless to say that mapping between services MUST be performed between services of the same characteristics. 5.1 Interworking Between Different MPLS/CR-LDP domains The interworking between two MPLS domains using CR-LDP is a straight forward. The service definition methodology described in the last section could be used to construct similar services at the two domains. Aboul-Magd Expires April, 2000 8 A Framework for Srvc Def using CR-LDP October, 1999 Service and parameter mapping from one domain to the other is done on a one-to-one basis. 5.2 CR-LDP Interworking with Diffserv As it has been mentioned before, CR-LDP employs a compatible service definition paradigm to that of Diffserv. There are two possible ways for interworking. The first one is to overlay the Diffserv PHB model on top of MPLS. In that case extensions to LDP [10] are needed to signal the desired PHB to be offered by the MPLS domain. Those extensions are discussed in more details in [13]. The advantage of this interworking model is it allows the network operator to carry the Diffserv traffic transparently through the MPLS region irrespective of the service they belong to in the Diffserv domain. It also allows the network operator to service qualitative QoS applications (applications that are not able to are not able quantify their traffic and QoS requirements) [14] using Diffserv CoS. The disadvantage of this approach is that different Diffserv domains might use the same PHB coding for constructing of different services with different objectives. Carrying those packets transparently in the MPLS region could result in service degradation. The second method of interworking is to overlay a service layer on top of the MPLS region and it relies on mapping services between the Diffserv and the CR-LDP domains. This method is a service aware model that preserves the integrity of the end-to-end service as long as services with the same characteristics are mapped from one domain to the other. 5.3 CR-LDP Interworking with ATM Service Categories The ATM QoS architecture offers a number of end-to-end services with defined traffic and QoS parameters. Each ATM service category is defined by a conformance definition [4] that is equivalent to the edge rules discussed earlier. The local behavior is not explicitly defined but is implied by the performance objectives of the service categories. For instance, the CBR service category imposes the most delay stringent requirement and it cells are handled in the node accordingly. The conformance definition specifies the relevant traffic parameters and to what streams they are applied. It also specifies the policing options at the edge, e.g. tagging or dropping. By varying the conformance definition at the edge variant subclasses of the same service category are possible, e.g. VBR.1, VBR.2, and VBR.3. Using CR-LDP, the ATM service categories can be constructed by matching the edge rules in MPLS region to the conformance definition in ATM. The examples below show how to construct the CBR and the VBR.3 services using CR-LDP. Aboul-Magd Expires April, 2000 9 A Framework for Srvc Def using CR-LDP October, 1999 CBR Service =========== PDR: PCR CDVT PBS: = |_ 1 + -----------_| Where T=1/PCR and d = 1/link_rate T _ d CDR: PDR CBS: 0 EBS: 0 Service Frequency: VeryFrequent Edge rules: token bucket policing with parameters (PDR, PBS) Drop non-conformant packets VBR.3 Service ============== PDR: PCR CDVT PBS: = |_ 1+ -----------_| Where T=1/PCR and d = 1/link_rate T _ d CDR: SCR CBS: MBS EBS: 0 Service Frequency: Frequent or Unspecified Edge rules: token bucket policing with parameters (PDR, PBS) Drop non-conformant packets Token bucket policing with parameters (CDR, CBS) Non-conformant packets are marked for high discard precedence The choice of the service frequency depends on the whether the VBR.3 service is real-time or non real-time. 5.4 MPLS Interworking with Frame Relay (FR) Service FR defines up to four classes of service that covers real-time and non- real-time services. The default service class is the one that provides rate assurances without delay requirements. AT the user-network interface the services is defined by the a set of parameters that include CIR, EIR, Bc and Be. The mapping of the default FR service to MPLS/CR-LDP can be achieved as: PDR: EIR (could be set at the access rate) PBS: few packets to account for the multiplexing effect (note that PBS = 1 if PDR = access rate) CDR: CIR CBS: Bc Aboul-Magd Expires April, 2000 10 A Framework for Srvc Def using CR-LDP October, 1999 EBS: Be Service Frequency: Unspecified Edge rules: Two token buckets policing with parameters (EIR, PBS) and (CIR, Bc+Be) Packets non-conformant to CIR, CBS, but within Be, token bucket are marked for high discard precedence using the Exp filed. Packets non-conformant to (EIR, PBS) token bucket are dropped. While an Unspecified service frequency is adequate for the default FR service, VeryFrequent or Frequent are also possible for the support of real-time applications such as VoFR. 5.5 MPLS Interworking with Integrated Service The integrated service model supports two services, GS [6] and CLS [7]. The QoS objective of the GS is provide a strict upper bound on the end- to-end delay. The CLS service ensures a level of performance that is equivalent to a non-congested IP network (no specific delay requirements). Both the GS and The CLS services are defined in terms of token bucket parameters (r, b), peak rate (p), minimum policed unit (m), and a maximum policed unit (M). However their policing functions are different. For GS service, the amount of data sent over any time interval should not exceed M+min[pT, rT+b-M]. For CLS, the amount of data should not exceed rT+b independent of p. Data that exceeds the specified amount could be marked as non-conformant. The interworking between MPLS/CR-LDP and integrated service can be achieved as: GS Service ========== PDR: p PBS: M CDR: r CBS: b EBS: 0 Service Frequency: VeryFrequent or Frequent Edge rules: p and r policing Traffic in excess of M+min[pT, rT+b-M] are dropped or or marked for discard The specification of the service frequency as either VeryFrequent or Frequent depends on the stringent of the delay bound. CLS Service Aboul-Magd Expires April, 2000 11 A Framework for Srvc Def using CR-LDP October, 1999 ============ PDR: p PBS: M CDR: r CBS: b EBS: 0 Service Frequency: Frequent Edge rules: (r,b) policing with marking option Traffic in excess of rT+b should be marked as non- conformant 6. Security Considerations This document does not introduce any new security issues 7. References Aboul-Magd Expires April, 2000 12 [1] Andersson et. al., _Label Distribution Protocol Specification_ work in progress (draft-ietf-mpls-ldp-05), June 1999 [2] Jamoussi, _Constraint-Based LSP Setup using LDP_ work in progress (draft-ietf-mpls-cr-ldp-03.txt), Sept. 1999 [3] Rosen, et. al., _Multiprotocol Label Switching Architecture_ work in progress (draft-ietf-mpls-arch-06.txt), August 1999 [4] ATM Forum, _Traffic Management Specification: Version 4.1_, March 1999 [5] S. Blake, _An Architecture for Differentiated Service_ RFC 2475, December 1999 [6] S. Shenker, et. al., _Specification of Guaranteed Quality of Service_ RFC 2212, Sept. 1997 [7] J. Wroclawski, _Specification of the Controlled-Load Network Element Service_ RFC 2211, Sept. 1997 [8] R. Braden, et. al, _Integrated Services in the Internet Architecture: an Overview_, RFC 1633, July 1994 [9] J. Ash, et. al., _LSP Modification using CR-LDP_, work in progress (draft-ash-crlsp-modify-00.txt), July 1999 [10] J. Heinanen, _Differentiated Services in MPLS Networks_, work in progress (draft-heinanen-diffserv-mpls-00,txt), June 1999 [11] J. Wroclawski, _Applications, Flexibility, and Differentiated Services_, Internet 2 Joint Application/Engineering Workshop, May 1998 [12] V. Jacobson, _Differentiated Services for the Internet_, Internet 2 Joint Application/Engineering Workshop, May 1998 [13] Faucheur, et. al., _MPLS Support of Differentiated Service_ work in progress (draft-ietf-mpls-diff-ext-02.txt), October 1999 [14] Y. Bennet, et. al., _Framework for Integrated Services Operation over Diffserv Networks_, work in progress (draft-ietf- issll-diffserv-rsvp-03.txt), September 1999. 8. Acknowledgement The authors would like to thank Don Fedyk for his comments on the draft. 9. Author's Addresses A Framework for Srvc Def using CR-LDP October, 1999 Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station _C_ Ottawa, Ontario, K1Y-4H7 Canada Phone: +1 613 763-5829 Email: osama@nortelnetworks.com Bilel Jamoussi Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288-4506 Email: jamoussi@nortelnetworks.com A Framework for Srvc Def using CR-LDP October, 1999 Full Copyright Statement "Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into A Framework for Srvc Def using CR-LDP October, 1999