Network Working Group Jerry Ash Internet Draft Chuck Dvorak Wai Sum Lai Expiration Date: December 2002 Al Morton Percy Tarapore AT&T June, 2002 Proposed MPLS/DiffServ TE Class Types 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: Service Provider requirements for support of DiffServ aware MPLS Traffic Engineering (MPLS-DS-TE) are presented in [MPLS-DS-TE-REQ]. This initiative includes the definition of MPLS-DiffServ-TE class types (CTs), wherein CTs are defined as aggregations of individual service classes. Instead of having per-class parameters being configured and propagated on each LSR interface, classes are aggregated into CTs having common per-CT parameters (e.g., minimum bandwidth) to satisfy required performance levels, however, no bandwidth requirements are enforced for classes within a CT. The main motivation for grouping a set of classes into a CT is to improve the scalability of IGP LSAs by propagating information on a per-CT basis instead of on a per-class basis, and also to allow better bandwidth sharing between classes in the same CT. In order to further improve scalability through the introduction of CTs, we propose to a) limit the number of CTs to 6, and b) to generalize the notion of CTs and consider them to be a combination of i) DiffServ/queuing priority per-hop-behaviors (PHBs), ii) QoS classes (e.g., as specified in [Y.1541]), iii) admission-control priority classes, and iv) restoration priority classes at both the MPLS-LSP and transport link level. Table of Contents 1. Introduction 2. Description of Proposed Class Types 3. Discussion of Proposed Class Type Definitions (Table 1) 4. Conveying Class-Type Designation in MPLS Signaling 5. Security Considerations 6. Acknowledgments 7. References 8. Authors' Addresses 9. Full Copyright Statement 1. Introduction Service Provider requirements for support of DiffServ aware MPLS Traffic Engineering (MPLS-DS-TE) are presented in [MPLS-DS-TE-REQ]. DS-TE is discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. DS-TE requirements are defined for class types (CTs), where CTs are defined in [TEWG-FW] as aggregations of individual service classes. Instead of having per-class parameters being configured and propagated on each LSR interface, classes are aggregated into CTs having common per-CT parameters (e.g., minimum bandwidth) to satisfy required performance levels, however, no bandwidth requirements are enforced for classes within a CT. The main motivation for grouping a set of classes into a CT is to improve the scalability of IGP LSAs by propagating information on a per-CT basis instead of on a per-class basis, and also to allow better bandwidth sharing between classes in the same CT. A CT is a set of classes that satisfy the following two conditions: 1) Classes in the same CT have common aggregate maximum bandwidth requirements (and, if applicable, common minimum bandwidth requirements) to satisfy required performance levels. 2) There is no maximum or minimum bandwidth requirement to be enforced at the level of individual class in the CT. An example of the CT can be a low-loss CT that includes both AF1-based and AF2-based Ordering Aggregates. [DS-TE-SOLN] describes a proposed technical solution for meeting the DS-TE requirements. The draft proposes complex IGP extensions of per-CT link-state advertisements (LSA) to communicate per-CT available bandwidth, etc. It already gets so complex that the draft proposes to compress the advertisements. There is concern about scalability of the IGP overhead, and particularly the IGP response to overloads and failures [IGP-SCALE]. Hence there is concern about further significant extensions to increase IGP overhead, which will further exacerbate the problem identified in [IGP-SCALE]. Furthermore we think the extensions are unnecessary, because there are other, equally effective ways to do DS-TE without the IGP TE extensions, as described in [IGP-ALTERNATIVE]. In order to achieve further scalability through the introduction of CTs, we propose to a) limit the number of CTs to 6, and b) to generalize the notion of CTs and consider them to be a combination of i) DiffServ/queuing priority per-hop behaviors (PHBs), ii) QoS classes (e.g., as specified in [Y.1541]), iii) admission-control priority classes, and iv) restoration priority classes at both the MPLS-LSP and transport link level. Admission control priority is a way of giving preference to admit higher priority LSPs ahead of lower priority LSPs. A high-priority service LSP can be admitted in preference over a normal-priority service LSP. Restoration priority is a way of giving preference to protect higher priority LSPs ahead of lower priority LSPs. A high-priority service LSP can be protected in preference over a normal-priority service LSP. For both admission control and restoration, no preemption of existing LSPs is assumed beyond what is specified for the proposed CT for control traffic, as described in the next Section. 2. Description of Proposed Class-Types We suggest that it might be useful to generalize CTs and consider them to be a combination of 1. DiffServ/queuing priority PHBs, 2. QoS classes (e.g., as specified in Draft Recommendation Y.1541), 3. MPLS/CAC priority classes, 4. restoration priority classes at both the MPLS-LSP and transport link level, and 5. preemption priority classes. The above categories are inclusive of the CT definition given in [TEWG-FW], but go beyond to include considerations of restoration priority. Within this more general context, we propose definitions of 5 user-traffic CTs and 1 control-traffic CT, as summarized in Table 1. Note that the proposed CTs are mapped to DiffServ PHBs, as well as to the corresponding QoS classes specified in the current Draft Recommendation Y.1541. CAC priority and restoration priority are also defined. The rationale for these designations is discussed in the next Section. Table 1. Proposed Class-Type Definitions Class-Type | User-Traffic Control-Traffic Characteristics | Class Type Class Type ----------------|-------------------------------------------------------- | 1 2 3 4 5 1 ----------------|-------------------------------------------------------- DiffServ PHB; | EF; EF; AFxy; AFxy; BE; AFxy | Inter- Inter Non- Non- Non- | active; active; inter- inter- inter- | Real- Real- active; active; active; | time; time; Low- Low- Low- | loss; loss; loss; Y.1541 QoS | 0,1 0,1 2,3,4 2,3,4 5 2 Class; | ----------------|-------------------------------------------------------- Priority: | High Normal High Normal Best- High; MPLS CAC; | Effort LSP MPLS-restoration| Preemption (per-LSP); | allowed Transport | restoration | (per-transport- | link) | ----------------|------------------------------------------------------ 3. Discussion of Proposed Class-Type Definitions (Table 1) Draft Recommendation [Y.1541] describes QoS classes and IP performance objectives that support a wide range of user applications. The classes group objectives for one-way IP packet delay, IP packet delay variation, IP packet loss ratio, etc. Classes 0 and 1, which generally correspond to the DiffServ EF PHB, support interactive real-time applications by specifying mean delay of 100ms and 400ms, respectively, delay variation less than 50ms, and loss ratio less than 10^-3. Classes 2, 3, and 4, which generally correspond to the DiffServ AFxy PHB Group, support non-interactive applications by specifying mean delay of 100ms, 400ms, and 1s, respectively, unspecified delay variation, and loss ratio less than 10^-3. Class 5, which generally corresponds to the DiffServ best-effort PHB, has all these parameters unspecified. See [Y.1541] for more detail. Admission control priority is a way of giving preference to admit higher priority LSPs ahead of lower priority LSPs. In Table 1 we define high, normal, and BE admission control priorities. A high-priority service LSP can be admitted in preference over a normal-priority service LSP by reserving the last-available, minimum-level of bandwidth (called the "reserved bandwidth") for high-priority service LSP admissions vs. normal-priority service LSP admissions. That is, the higher priority LSP gets the reserved bandwidth when that is all the bandwidth left. This concept is widely used in practice today for voice and data services (e.g., "800 gold service", "emergency communication service", key-switched-digital-service, etc.). These are examples of real-world services that we offer now and that we may want to carry forward in the future to an MPLS-DS-TE architecture. There have also been several other drafts posted on priority needs for emergency communication services [FOLTS, SCHULZRINNE, BROWN]. In Table 1, we define restoration priority as either high, normal, or best-effort. Note that restoration priority is a requirement from the output of the traffic engineering working group (TEWG) design team's output [TEWG-REQ]. Restoration priority is achieved by provisioning sufficient backup capacity, as necessary, and allowing relative priority for access to available bandwidth when there is contention for restoration bandwidth. For example, a high restoration priority LSP can take precedence over a normal priority LSP in accessing bandwidth, if there is contention. LSP preemption might also be used, such as for high restoration priority, in which active best-effort priority LSPs could be bumped to provide available bandwidth for LSP restoration of high priority LSPs. It is useful to minimize preemption so as not to interrupt established service. As optical networks evolve, service providers will have the capability to offer transport links with various restoration classes of service [OIF2001.514]. For example, a service provider may chose to offer three types of transport links with unique transport restoration characteristics: high-priority (e.g., < 1 second restoration), normal-priority (e.g., < 10 seconds restoration), and unprotected (no restoration). From the perspective of packet layers, different traffic classes (and their prospective customer SLAs) will require to be fitted into one of these three types of restoration classes. Hence, the high-priority traffic class may require routing exclusively over links which have the highest restoration class of service (e.g., restoration within 200 milliseconds). Conversely, the low (unprotected) priority traffic class may not require any transport restoration at all. Hence there is a need for selecting an LSP based on the designated restoration priorities of the transport links. A class type can contain the traffic of a subset of a DiffServ behavior aggregate (BA) [DIFF-NEW], an example being the EF BA. The class-type definition therefore relates the interactions of two levels: packet level and LSP level. Packet level behaviors are governed by DiffServ forwarding treatment, which is responsible for packet-level QoS such as delay/jitter, while LSP level is for link bandwidth allocation, which is responsible for LSP level QoS such as ensuring that bandwidth requests can be met. For the EF-high priority CT 1 and EF-normal priority CT 2, the 'high' priority and 'normal' priority refer to admission/CAC priority for gaining access to bandwidth, and not packet-level priority. Packet-level priority is to differentiate between EF, AF, and BE. At the packet level, there is only 1 EF queue that is being used by both EF-high and EF-normal priority LSPs. MPLS-DS-TE is used to allocate and manage bandwidth at the LSP level and this is why we can distinguish between EF-high and EF-normal for bandwidth access. Once bandwidth access is gained and the respective LSP is set up, there is no distinction any more in terms of packet-level QoS and hence there is only 1 EF queue. The point of doing this is so that we can have separate bandwidth pools for CT 1 (EF-high) and CT 2 (EF-normal). Furthermore, depending on implementation, in some specific links, we may want to limit the combined bandwidth pool available to both EF CTs to some maximum bandwidth. However, such actions can be done purely internal to a router. Hence, no advertisement of the combined limitation on bandwidth information needs to be propagated. The inclusion of DiffServ PHBs, QoS classes, admission-control priority classes, restoration priority, and preemption priority classes into a combined set of 6 CT definitions is intended to minimize the number of possible CTs across these 4 levels of priority classes. That is, if the number of DiffServ/QoS PHBs = W number of admission-control priority levels = X number of restoration priority levels = Y number of preemption priority levels = Z Then the combination of the possible number of CTs when considering all 4 dimensions independently would be number of independent CTs = WXYZ This number of independent CTs could therefore be a very large number. Hence in Table 1 we propose 6 CTs, which combine the 4 dimensions into a smaller number (6) of combinations. We feel that this approach is more scalable than allowing a very large number of CT combinations. A separate CT is defined for network control traffic [LAI]. This is for control traffic generated by routing protocols, network management, and signaling to support service requests. This class of traffic has the following characteristics: 1. must have a very low drop precedence: e.g., dropped control traffic may cause routing to fail or flap, leading to network instability or even prolonged and widespread network failure, 2. a relatively small bandwidth guarantee under normal network conditions: to minimize overhead (control traffic is usually designed to consume a relatively small amount of bandwidth), 3. high priority: large user packets on slow links may cause significant delays that will reduce the responsiveness needed by control traffic, 4. preemption of all other traffic under overload or failed conditions: to ensure that control traffic gets through with minimal loss and delay. 4. Conveying Class-Type Designation in MPLS Signaling A particular CT designation would be associated with each MPLS LSP. As such, each of the parameters proposed in Table 1 would need to be signaled to define the CT. DiffServ/QoS PHB, CAC priority, and preemption priority information can be conveyed in LSP setup using existing MPLS DiffServ extensions [DIFF-MPLS] and Priority TLVs already being specified [RSVP-TE, CR-LDP]. Conveying the restoration priority information could be done in the Restoration TLV being defined. Through the use of constraint-based LSP routing, color or "resource class" [TSVP-TE, CR-LDP] is an MPLS mechanism that could be used to route packets with a given priority on links/facilities with a given restoration priority. The use of color or resource classes for transport level restoration is illustrated with the following simple example. Consider a small network of four LSRs: A, B, C, and D. Assume that the bulk of the class-type traffic fits into the normal-priority transport restoration class and the remainder requires the high-priority transport restoration class. Accordingly, with the use of traffic engineering, four OC-48 links marked normal-priority are implemented with one OC-48 linking LSRs A and B, one OC-48 linking LSRs B and C, one OC-48 linking LSRs C and D, and one OC-48 linking LSRs D and A. Further, six OC-3 links marked high-priority are implemented in a fully meshed design: one OC-3 between each of the LSR pairs A and B, B and C, C and D, D and A, A and C, B and D. For class types requiring a high-priority path between LSR A and C, the LSP setup would be over the high-priority-OC-3 between LSR A and C. For class types requiring a normal-priority path between LSRs A and C, the LSP setup would be over the normal-priority-OC-48 between LSRs A and B followed by the normal-priority-OC-48 between LSRs B and C. 5. Security Considerations There are no new security considerations based on proposals in this draft. 6. Acknowledgements We appreciate comments and suggestions from Kwangil Lee of NIST and Tricci So of Caspian Networks. 7. References [BROWN] Brown, I., et. al., "Securing prioritised emergency traffic," work in progress. [CR-LDP] Jamoussi, B., et. al., RFC 3212, "Constraint-Based LSP Setup using LDP". [DIFF-MPLS] Le Faucheur, F., et. al., RFC 3270, "MPLS Support of Diff-Serv". [DIFF-NEW] Grossman, D., "New Terminology for Diffserv", work in progress. [FOLTS] Folts, H., "Emergency Telecommunications Service in Next-Generation Networks ," work in progress. [IGP-SCALE] Ash, G., et. al., "Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks," work in progress. [IGP-ALTERNATIVE] Ash, G., et. al., "Alternative Technical Solution for MPLS DiffServ TE," work in progress. [ISIS-TE] Li, T., et. al., "IS-IS extensions for Traffic Engineering," work in progress. [MPLS-ARCHITECTURE] Rosen, E., et. al., RFC 3031, "Multiprotocol Label Switching Architecture". [MPLS-DS-TE-REQ] Le Faucheur, F., et. al., "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering," work in progress. [OSPF-TE] Katz, D., et. al., "Traffic Engineering Extensions to OSPF," work in progress. [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", work in progress. [SCHULZRINNE] Schulzrinne, H., "Emergency Call Services for SIP-based Internet Telephony," work in progress. [TE-REQ] Awduche, D., et. al., "Requirements for Traffic Engineering over MPLS," RFC2702, September 1999. [TEWG-FW] Awduche, D., et. al., RFC 3272, "Overview and Principles of Internet Traffic Engineering." [TEWG-REQ] Lai, W. S., et. al., "Network Hierarchy and Multilayer Survivability," work in progress. [LAI] Lai, W. S., "Traffic Measurement for Dimensioning and Control of IP Networks," Internet Performance and Control of Network Systems II Conference, SPIE Proceedings Vol. 4523, Denver Colorado, 21-22 August 2001. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services. 8. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Fax: +1-(732)-368-8659 Email: gash@att.com Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: + 1 973-236-6700 Fax:+1 973-236-7453 E-mail: cdvorak@att.com Wai Sum Lai AT&T Room D5-3D18 200 S. Laurel Avenue Middletown, NJ 07748 Phone: +1 732 420-3712 Fax:+1 732 368-1919 E-mail: wlai@att.com Al Morton AT&T Room D3-3C06 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-1571 Fax: +.1 732 368-1192 E-mail: acmorton@att.com Percy Tarapore AT&T Room D1-3D33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-4172 E-mail: tarapore@.att.com 9. Full Copyright Statement Copyright (C) The Internet Society (1998). 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 implementation 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.