Network Working Group Jerry Ash Internet Draft Chuck Dvorak Al Morton Expiration Date: August 2004 Percy Tarapore AT&T Yacine El Mghazli Sven Van den Bosch Alcatel February 2004 NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept 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: This draft describes a proof-of-concept example of NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. The example is based on standardization work in the ITU-T of QoS signaling requirements. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. Together with the NSIS Transport Layer Protocol (NTLP), the NSLP provides functionality similar to RSVP and extends it. This draft provides a proof-of-concept example of the NSIS NSLP for QoS signaling. The example is based on standardization work in the ITU-T on QoS signaling requirements [E.361, TRQ-QoS-SIG], and is specified in terms of the QoS-signaling model and Qspec template given in the 'NSLP for QoS Signaling' specification [QoS-SIG]. Table of Contents 1. Introduction 2. NSIS NSLP QoS Signaling Model 3. Qspec Template for Proof-of-Concept Example of NSIS NSLP QoS-Signaling Model 4. Security Considerations 5. Acknowledgments 6. References 7. Authors' Addresses Appendix A. Summary of ITU-T Recommendation E.361 "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies" Appendix B. Summary of ITU-T Recommendation TRQ-QoS-SIG "Signaling Requirements for IP-QoS" 10. Full Copyright Statement 1. Introduction This draft describes a proof-of-concept example of NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. The example is based on standardization work in the ITU-T of QoS signaling requirements. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. Together with the NSIS Transport Layer Protocol (NTLP), the NSLP provides functionality similar to RSVP and extends it. This draft provides a proof-of-concept example of the NSIS NSLP for QoS signaling. The example is based on standardization work in the ITU-T on QoS signaling requirements [E.361, TRQ-QoS-SIG], and is specified in terms of the QoS-signaling model and Qspec template given in the 'NSLP for QoS Signaling' specification [QoS-SIG]. The QoS-signaling NSLP protocol establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. It is intended to satisfy the QoS-related requirements of [NSIS-REQ]. This QoS-NSLP is part of a larger suite of signaling protocols, whose structure is outlined in [NSIS-FRAMEWORK]; this defines a common NTLP which QoS-NSLP uses to carry out many aspects of signaling message delivery. The design of QoS-signaling NSLP is conceptually similar to RSVP [RSVP], and uses soft-state peer-to-peer refresh messages as the primary state management mechanism. The QoS-signaling NSLP extends the set of reservation mechanisms to meet the requirements of [NSIS-REQ], in particular, support of sender or receiver-initiated reservations, as well as a type of bi-directional reservation and support of reservations between arbitrary nodes, e.g. edge-to-edge, end-to-access, etc. QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular QoS provisioning method or QoS architecture; this is similar to (but stronger than) the decoupling between RSVP and the IntServ architecture [INTSERV]. It should be able to carry information for various QoS models; the specification of Integrated Services for use with RSVP given in [RSVP-INTSERV] could form the basis of one QoS model. This draft provides another proof-of-concept example of NSIS NSLP for QoS signaling, and is based on standardization work in the ITU-T of QoS signaling requirements [E.361, TRQ-QoS-SIG]. The QoS-signaling model is described in Section 2, and is based on the Qspec template given in [QoS-SIG]. 2. NSIS NSLP QoS Signaling Model [QoS-SIG] defines message types and control information for the QoS-NSLP generic to all QoS models. A QoS model is a defined mechanism for achieving QoS as a whole. The specification of a QoS model includes a description of its QoS parameter information, as well as how that information should be treated or interpreted in the network. In that sense, the QoS model goes beyond the QoS-NSLP protocol level in that it could also describe underlying assumptions, conditions and/or specific provisioning mechanisms appropriate for it. Messages are normally passed from the NSLP to the NTLP via an API, which also specifies the signaling application (as QoS-NSLP), the flow/session identifier, and an indication of the intended direction - towards data sender or receiver. On reception, the NTLP provides the same information to the QoS-NSLP. The NSIS NSLP protocol specifies four message types (RESERVE, QUERY, RESPONSE and NOTIFY) and two objects (QSpec and Policy object). Each protocol message includes header information that identifies the message type and determines which objects it may carry. A protocol message also contains Control Information (CI), which is a group of objects that qualify and/or restrict the action that an NSIS entity may perform on the QoS message. Control Information is always associated to a QSpec, i.e. CI and QSpec always come in pairs. The QSpec object contains the QoS parameters defined by the QoS model, and describes the QoS that is being reserved. The Policy object authenticates and authorizes the requester of the QoS reservation. A QoS model provides a specific set of parameters to be carried in the QSpec, or restricts the values these parameters can take. Integrated Services [INTSERV], Differentiated Services DIFFSERV] and RMD [RMD] are all examples of QoS models. There is no restriction on the number of QoS models. QoS models may be local, meaning that they are private to one network, implementation or vendor specific or global, meaning that they must be implementable by different networks and vendors. The QSpec contains a set of parameters and values describing the requested resources. It is opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and AdSpec specified in [RSVP,RSVP-INTSERV]. At each NSIS entity which supports the QoS-signaling NSLP, its content is interpreted by the resource management function for the purposes of policy control and traffic control (including admission control and configuration of the packet classifier and scheduler). Different QoS models may share a common set of QoS parameters. A QSpec template is proposed in [QoS-SIG], which would allow for a consistent specification of common QoS parameters in different QoS models. Flow identification information is also needed but is not part of the QSpec template, rather it is made available over the API between the QoS-signaling NSLP and the NTLP. It is not the intention that all QoS models support all fields and sub objects defined in [QoS-SIG]. The definition of a QoS model entails a selection of one or more of these fields and/or sub objects. For instance, one QoS model could only allow QSpec ID and DSCP to be specified. 3. Qspec Template for Proof-of-Concept Example of NSIS NSLP QoS-Signaling Model The Qspec template [QoS-SIG] for the proof-of-concept example of the NSIS NSLP QoS-signaling model is given in this Section. The individual parameters given in the template are based on the QoS signaling requirements specified in ITU-T Recommendations [E.361] and [TRQ-QoS-SIG]. Please refer to Appendices A and B for summaries of these two Recommendations. The proof-of-concept example has the following Qspec template: 1. QSpec ID (allows IANA reservation of QSpec parameter combinations): IANA specified. 2. Traffic Envelope/Conformance: The traffic envelope describes the traffic (conformance) characteristics of the data stream identified by the QoS NSLP Session ID. The traffic envelope is a set of Traffic Conformance Parameters, describing how the packet stream should look to get the guarantees indicated by the performance parameters (defined below). The Traffic Conformance Parameters are the basic input for the Traffic Conformance Algorithm. Traffic Conformance Testing is the combination of the Traffic Conformance Parameters and the Traffic Conformance Algorithm. This will usually be done at a boundary node. The algorithm and the conformance test can be binary-based or multi-level based. The traffic conformance algorithm used for this model is token-bucket, with conformance parameters Token Bucket Rate (Br) and Token Bucket Size (Bp and Bs) TRAF-PAR (peak rate (Rp), peak bucket size (Bp), sustainable rate (Rs), sustainable bucket size (Bs), token bucket rate (Br), maximum allowed packet size (M)). See Section A.3. 3. Excess Treatment: This parameter describes how the network provider will process excess traffic, i.e. out-of-profile traffic (in case of binary conformance testing) or n-level traffic (in case of n-level conformance testing). The process takes place after Traffic Conformance Testing, described previously. Excess traffic may be dropped, shaped and/or remarked. Excess Treatment (EXTR) 4. Offered Guarantees: The performance parameters describe the service guarantees the network offers to the customer for the packet stream described by the QoS NSLP Session ID and within the limits of the geographical/topological extent given by the scope. QoS-REQUEST-PAR (Y.1541 QoS class, DIFFSERV, service identity (SI), class type (CT), link capability (LC)) are qualitative guarantees. See Section A.3. QoS-ACCUM-PAR (transfer delay, delay variation, packet loss) are quantitative guarantees, which are used in the QUERY or RESPONSE message to collect information along the path. See Section A.3. The QoS-ACCUM-PAR should only be used in the QUERY message to collect information along the path and determine if the numerical objectives of Y.1541 classes are met, and MUST NOT be part of the QoS-REQUEST-PAR. QoS-ACCUM-PAR MAY also be used in the RESPONSE message to indicate or convey the estimate of end-end achieved performance. 5. Service Schedule: The service schedule indicates the start time and end time of the service, i.e. when is the service available. As specified in Appendix B/[TRQ-QoS-SIG]. See example in Section B.5. 6. Priority and Reliability: CAC Priority (CAC-PRTY), Restoration Priority (RES-PRTY). See Sections A.3 and B.4. 7. Monitoring requirements: Information required about reservation, related to AdSpec functionality and may contain QUERY parameters. As specified in Appendix B/[TRQ-QoS-SIG]. See example in Section B.5. 4. Security Considerations There are no new security considerations based on proposals in this draft. 5. Acknowledgements 6. References [DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [DS-TE] Le Faucheur, F., et. al., Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering , RFC 3564, July 2003 [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [E.361] ITU-T Recommendation, "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies," May 2003. [INTSERV] Braden, B., et. al., "Integrated Services in the Internet Architecture: an Overview," RFC 1633, June 1994. [NSIS-REQ] Brunner, M., et. al., "Requirements for QoS Signaling Protocols," work in progress. [NSIS-FRAMEWORK] Hancock, R., et. al., "Next Steps in Signaling: Framework," work in progress. [RMD] Westberg, L., "Resource Management in Diffserv (RMD) Framework," work in progress. [RSVP] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," RFC 2205, September 1997. [RSVP-INTSERV] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC 2210, September 1997. [TRQ-QoS-SIG] ITU-T Recommendation, "Signaling Requirements for IP-QoS," January 2004. [QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service Signaling," work in progress. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services," May 2002. 7. 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 Yacine El Mghazli Alcatel Route de Nozay 91460 Marcoussis cedex - FRANCE Phone: +33 1 69 63 41 87 Email: yacine.el_mghazli@alcatel.fr 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 Sven Van den Bosch Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium E-mail: sven.van_den_bosch@alcatel.be Appendix A. Summary of ITU-T Recommendation E.361 "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies" A.1. Introduction QoS routing is an indispensable network function which controls a network's response to traffic demands and other stimuli, such as network failures. To support the ability to carry all types of telecommunications traffic (voice, data, video, etc.) over a single network, networks are evolving beyond best effort capabilities to provide a variety of performance and reliability options. Transport backbones are incorporating new optical technologies enabling flexible and cost-effective solutions for carrying various grades of telecommunications traffic. It is important for service providers to satisfy customer expectations for end-to-end reliability and QoS, for all types of transactions and services. QoS requirements include performance parameters such as delay, jitter, packet loss, etc, and are related to the type of transaction (e.g., voice, data, video). Reliability on the other hand represents expectations on adequate service availability over a specified period for the desired transaction types. Further, services may have different reliability expectations depending on the type of service. For example, a voice over IP (VoIP) packet stream for emergency services calls would require high priority reliability treatment. Other VoIP services may have lower reliability expectations and hence their network reliability treatment may be less stringent. To satisfy reliability and QoS considerations for all transaction and service types, a service provider needs to ensure that all network protocol layers are equipped to recognize and satisfy the QoS and reliability requirements for the service classes. QoS Service Classes (QSCs) are defined as aggregations of individual service classes. Instead of having per-class parameters being configured and propagated on each network interface, classes are aggregated into QSCs having common per-QSC parameters (e.g., maximum bandwidth) to satisfy required performance levels. There is no maximum or minimum bandwidth requirement to be enforced at the level of individual class in the QSC. QSCs are known as class types (CTs) in IP/DiffServ-enabled MPLS Traffic Engineering (DS-TE) networks [DS-TE], virtual networks (VNETs) in TDM networks, and QoS classes in ATM networks. Recommendation E.361 identifies QoS routing functions and associated parameters, and proposes means of signaling these QoS routing parameters across networks employing different routing technologies, including IP-, ATM-, and TDM-based routing technologies. It proposes extensions to signaling protocols such as SIP and RSVP-TE to support signaling of QoS routing parameters within and across networks. A.2 QoS Routing Functions & Parameters QoS routing functions and associated parameters include: a. bandwidth allocation/protection (traffic and QoS parameters); b. routing priority; c. queuing priority; and d. class-of-service identification (service, CT, and capability parameters). Bandwidth allocation and protection includes connection admission and bandwidth reservation. Typically, the connection admission control for each link in the path is performed based on the status of the link. CT bandwidth is managed to meet the overall bandwidth requirements of QSC service needs. Individual flows are allocated bandwidth within CTs accordingly, as bandwidth is available. Bandwidth reservation gives preference to the preferred traffic by allowing it to seize any idle bandwidth in a link, while allowing the non- preferred traffic to only seize bandwidth if there is a minimum level of idle bandwidth available, where the minimum-bandwidth threshold is called the reservation level. Routing priority can give preference to admit and/or restore higher priority connections ahead of lower priority connections. A high-priority service can be admitted in preference over a normal-priority service. Restoration priority can assign a priority to traffic streams for restoration. As in the case for connection admission, certain services may require higher restoration priority over others. Bandwidth allocation/protection and priority routing reflect reliability expectations/objectives such as loss probability, time-to-restore, and extent of restoration. Priority queuing considers packet level objectives and performance expectations such as delay, loss, and delay variation. ITU-T Recommendation Y.1541 groups services into six QoS classes defined according to the desired QoS performance objectives (see Appendix B). [DIFFSERV] specifies several types of DiffServ PHBs, including EF, AF, and BE. Class-of-service identification entails: a. service identity (SI); b. class type (CT); c. link capability (LC). The SI describes the actual service associated with the connection. The CT describes the bandwidth allocation and routing table parameters to be used by the connection. The LC describes the desired connection capabilities such as fiber, radio, satellite, and digital circuit multiplexing equipment, that the connection should require, prefer, or avoid. LC is similar to the concept of 'color' in [RSVP-TE]. A.2 Signaling of QoS Routing Information QoS control includes the following functions: a) application or 'call' control (SIP/SDP, H.323, etc.); b) vertical control (H.248/MEGACO, etc.); and c) bearer control (MPLS, RSVP-TE, DiffServ, DS-TE, etc.). While these functions are not all in the scope of NSIS, they are briefly discussed in this Section to show some complementary routing considerations for this proof-of-concept. A.2.1. Application/Call Control End-to-end QoS control is negotiated/communicated end-to-end at the call control level. The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate the associated QoS routing parameters (bandwidth/CT, Y.1541 QoS class, etc.). Such an end-to-end QoS control mechanism is defined independent of the underlying technology (IP, ATM, etc.) and operates across network domains. These QoS routing parameters need to be mapped to specific IP, TDM, and ATM QSCs (CT, VNET, and QoS class, respectively) and these mappings should be made available to the appropriate control elements. Such enhancements are applicable to call-control protocols like SIP/SDP, H.323, etc. A.2.2. Vertical Control QoS routing control is also negotiated/communicated at the vertical control level. The proposed signaling requirements include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS parameters (bandwidth, Y.1541 QoS class, etc.) in the bearer network based on H.248/MEGACO extensions. These QoS parameters are defined independent of the underlying technology (IP, ATM, etc.) of the bearer network. The vertical interface then maps the application QoS routing parameters into the bearer QoS routing parameters. A.2.3. Bearer Control Bearer network QoS is negotiated/communicated at the bearer control level. IP bearer control protocols are enhanced with a mechanism to negotiate the network QoS by using QoS routing parameters and transfer capabilities. Bearer network QoS is negotiated/communicated at the bearer level, i.e., as part of the protocols associated with the bearers in the core network. QoS routing and transfer capabilities are used to enhance existing IP mechanisms like MPLS, RSVP-TE, DiffServ, DS-TE, etc. A.3. Proposed Signaling Protocol Extensions Table 1 summarizes the required signaling and information exchange parameters supported within each routing technology which are required to be supported across network types. Table 1 identifies the required information-exchange parameters to support the QoS routing functions and parameters. Table 1. Required Signaling & Information-Exchange Parameters to Support QoS Routing Functions & Parameters QoS Routing Function Supported Signaling & Information Exchange Parameters BW Allocation and Protection Y.1541 QoS Class, DS-TE class type, QoS-PAR, TRAF-PAR Priority Routing CAC-PRTY, REST-PRTY Priority Queuing DIFFSERV Class-of-Service Identification SI, CT, LC These QoS routing information-exchange parameters are required: 1. QoS parameters (QoS-PAR): The QoS-PAR includes the DS-TE class type [DS-TE], and QoS thresholds such as transfer delay, delay variation, and packet loss. Preferably, the Y.1541 QoS class is specified requiring the QoS performance objectives specified for the selected class. Alternatively, the QoS-PAR performance thresholds are individually specified. The QoS-PAR parameters are used by each node to compare the link QoS performance to the requested QoS threshold to determine if the connection/bandwidth-allocation request is admitted or blocked on that link. The QoS parameters could also specify tail distribution values (percentiles). This may allow combining QoS values from different domains. 2. Traffic parameters (TRAF-PAR): The TRAF-PAR include DS-TE class type, and traffic parameters such as peak rate (Rp), peak bucket size (Bp), sustainable rate (Rs), sustainable bucket size (Bs), token bucket rate (Br), and maximum allowed packet size (M). The TRAF-PAR parameters are used by each node to compare the link traffic characteristics to the requested TRAF-PAR thresholds to determine if the connection/bandwidth-allocation request is admitted or blocked on that link. 3. Connection admission control priority (CAC-PRTY) parameter: The CAC-PRTY parameter is used by each node to determine the priority of the connection/bandwidth-allocation request being admitted on that link. 4. Restoration priority (REST-PRTY) parameter: The REST-PRTY parameter is used by each node to determine the priority of the connection/bandwidth-allocation request being restored on a given VP/LSP and/or transport link. 5. Differentiated services (DIFFSERV) parameter: The DIFFSERV parameter is used in ATM-based and IP-based networks to support priority queuing. The DIFFSERV parameter is used at the queues associated with each link to designate the relative priority and management policy for each queue. 6. Service Identity (SI) parameter: The SI parameter describes the actual service associated with the call. 7. Class Type (CT) parameter: The CT parameter describes the bandwidth allocation and routing table parameters to be used by the call. 8. Link Capability (LC) parameter: The LC parameter describes the link hardware capabilities such as fiber, radio, satellite, and digital circuit multiplexing equipment (DCME), that the call should require, prefer, or avoid. It is required that these parameters be included (as appropriate) in the signaling messages within TDM-, ATM-, and IP-based networks. These parameters are used to control the routing, bandwidth allocation, and routing/queuing priorities. Appendix B. Summary of ITU-T Recommendation TRQ-QoS-SIG "Signaling Requirements for IP-QoS" B.1. Introduction Recommendation TRQ-QoS-SIG provides the requirements for signaling information regarding IP-based QoS at the interface between the user and the network (UNI) and across interfaces between different networks (NNI). These requirements and the signaling information elements identified will enable the development of a signaling protocol(s) capable of the request, negotiation and ultimately delivery of known IP QoS classes from UNI to UNI, spanning NNIs as required. The signaling requirements also address signal information related to traffic priority and admission control, as these are also central to truly comprehensive QoS. To meet specific network performance requirements such as those specified for the QoS classes of Y.1541, a network needs to provide specific user plane functionality at UNI, NNI, and INI interfaces. A network may be provisioned to meet the performance requirements of Y.1541 either statically or dynamically on a per flow basis using a protocol that meets the requirements specified in the Recommendation. Static network provisioning is typically performed by a network engineering team using a network management system. Static provisioning typically takes into account both overall network performance requirements and performance requirements for individual customers based on traffic contracts between the customer and the network provider. Dynamic network provisioning at a UNI and/or NNI node allows the ability to dynamically request a traffic contract for an IP flow from a specific source node to one or more destination nodes. In response to the request, the network determines if resources are available to satisfy the request and provision the network. True QoS goes beyond just the delay and loss that can occur in the transport of IP packets. The requirements include the bandwidth/capacity needed by the application, and the priority with which such bandwidth will be maintained during congestion and restored after various failure events. As these aspects of QoS can be related to routing, they go beyond the resource management of the packet transport. Requirements on priority and admission controls are also considered. B.2. QoS Signaling Requirements The call/session control signaling includes an indication of the QoS requirements for each session. The QoS requirements are realized using various mechanisms, e.g. packet fragmentation, over-provisioning, resource reservation (RSVP) or DiffServ. Different QoS mechanisms may be used on different sections of a session packet-forwarding path. There may be communicated between call/session control nodes and packet-forwarding devices using a 'gate' control protocol to control the QoS mechanism. QoS signaling requirements are expressed in terms of attributes related to User-Network Signaling as well as Network-Network signaling. Major attributes include the following: a. network QoS Class (i.e., Y.1541/Table 1); b. network capacity required; c. reliability/priority with which the service is to be sustained. Obtaining user-to-user QoS on IP Networks, and on combinations of various network technologies, will require standard signaling protocols for communicating the requirements among the major entities. These entities include users and their end terminal equipment, and network service providers and their equipment, especially equipment implementing the inter-working and signaling function between networks, and between users and networks. It shall be possible to derive the following service level parameters as part of the process of requesting service: a. QoS class from Y.1541, which includes IP Loss Ratio, IP Transfer Delay, and IP Delay Variation (see Section B.3 below), b. peak rate (Rp) c. peak bucket size (Bp) d. sustainable rate (Rs) e. sustainable bucket size (Bs) f. token bucket rate (Br) g. maximum allowed packet size (M) h. DiffServ field as specified in RFC 2474 i. reliability/priority of the service (see Section B.4 below) j. optional attributes include user application type & quality categories. B.3 Y.1541 QoS Class Performance Objectives [Y.1541] proposes grouping services into six QoS classes defined according to the desired QoS performance objectives. These QoS classes 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. Classes 2, 3, and 4, which generally correspond to the DiffServ AFxy PHB Group, support non-interactive applications. Class 5, which generally corresponds to the DiffServ best-effort PHB, has all the QoS parameters unspecified. These classes serve as a basis for agreements between end-users and service providers, and between service providers. They support a wide range of traffic applications including point-to-point telephony, data transfer, multimedia conferencing, and others. The limited number of classes supports the requirement for feasible implementation, particularly with respect to scale in global networks. The QoS classes apply to a packet flow, where [Y.1541] defines a packet flow as the traffic associated with a given connection or connectionless stream having the same source host, destination host, class of service, and session identification. The characteristics of each class are summarized here: Class 0: Real-time, highly interactive applications, sensitive to jitter. Mean delay upper bound is 100 ms, delay variance is less than 50 ms, and loss ratio is less than 10-3. Application examples include VoIP, Video Teleconference. Class 1: Real-time, interactive applications, sensitive to jitter. Mean delay upper bound is 400 ms, delay variance is less than 50 ms, and loss ratio is less than 10-3. Application examples include VoIP, Video Teleconference. Class 2: Highly interactive transaction data. Mean delay upper bound is 100 ms, delay variance is unspecified, and loss ratio is less than 10-3. Application examples include signaling. Class 3: Interactive transaction data. Mean delay upper bound is 400 ms, delay variance is unspecified, and loss ratio is less than 10-3. Application examples include signaling. Class 4: Low Loss Only applications. Mean delay upper bound is 1s, delay variance is unspecified, and loss ratio is less than 10-3. Application examples include Short Transactions, Bulk Data, Video Streaming Class 5: Unspecified applications with unspecified mean delay, delay variance, and loss ratio. Application examples include traditional applications of Default IP Networks These six classes enable SLAs to be defined between customers and network service providers with respect to QoS requirements. The service provider then needs to ensure that the requirements are recognized and receive appropriate treatment across network layers. B.4 Support of Priority & Reliability Attributes Priority and reliability attributes are the same for User-Network and Network-Network signaling requirements. No standards exist with respect to the qualitative (e.g., number of priority classes) or quantitative (e.g., time-to-restore) aspects of reliability. To that extent, the following assumptions are made in determining reliability attributes: a. Reliability can be requested in the form of a Priority Class for a specific network function, such as CAC priority. b. There are a limited number of Priority Classes to ensure scalability (e.g., 3 classes). Two types of Priority Class attributes are defined: a. CAC Priority Class: The urgency with which a service connection is desired (e.g., High, Normal, Best Effort). b. Restoration Priority Class: The urgency with which a service requires successful restoration under failure conditions (e.g., High, Normal, Best Effort). We suggest a mechanism consistent with setup and holding priority similar to what exists in DiffServ TE [DS-TE]. Perhaps this could be specified as a priority object in [QoS-SIG]. B.4.1 CAC Priority Class Admission control policies give preference to traffic streams deemed to be more critical by a service provider under conditions of congestion. CAC priority class is a way of giving preference to admit higher priority flows ahead of lower priority flows. A high-priority service flow can be admitted in preference over a normal-priority service flow, and in Table 2 three CAC priorities are given - high, normal, and best effort - along with example service applications: Table 2. CAC Priority Class High CAC Priority: Critical services such as emergency communications services, key business services, control traffic Normal CAC Priority: Non-critical services such as normal VoIP consumer services, normal email data traffic Best Effort CAC Priority: Lower priority services such as WWW/HTTP transactions B.4.2. Restoration Priority Class Table 3 defines restoration priority class as either high, normal, or best-effort. Table 3. Restoration Priority Class High Restoration Priority: Critical Services such as emergency communications services, key business services, control traffic Normal Restoration Priority: Non-critical services such as normal VoIP consumer services, normal email data traffic Best Effort Restoration Priority: Lower priority services such as WWW/HTTP transactions 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. Optical transport networks, wavelength division multiplexing, and automatic switched optical networks (ASON) promise fast provisioning of a wide range of bandwidths (OC-3, OC-12, OC-48, OC-192). A network operator may flexibly choose to provide different protection/restoration options at various multiple transport levels (e.g. OTN, SONET section level, SONET path level), for different physical areas within the network. Restoration is broadly defined here as the response from a network under conditions of failure. Potential methods for failure recovery include automatic protection switching for line/path protections and shared mesh restoration methods. A service provider can assign a priority to traffic streams for restoration. Each restoration class has two parameters: a. Time-to-Restore: Total amount of time to restore traffic streams belonging to a given restoration class impacted by the failure. This time period depends on the technology deployed for restoration. A fast recovery period of < 200 ms is based on current experience with SONET rings and a slower recovery period of 2 seconds is suggested in order to enable a voice call to recover without being dropped. Accordingly, candidate restoration objectives are: High Restoration Priority: Time-to-Restore <= 200 ms Normal Restoration Priority: Time-to-Restore <= 2 s. Best Effort Restoration Priority: Time-to-Restore == Unspecified b. Extent of Restoration: Percentage of traffic belonging to the restoration class that can be restored. This percentage depends on the amount of spare capacity engineered. All high priority restoration priority traffic, for example, may be "guaranteed" at 100% by the service provider. Other classes may offer lesser chances for successful restoration. The restoration extent for these lower priority classes depend on SLA agreements developed between the service provider and the customer. B.5. Examples of QoS Signaling Requirements Based on Y.1541 QoS Classes B.5.1. User-Network Signaling An example of the network response for 'QoS Class acceptance and parameter level indication' is a case where the network provider commits to the requested Class and indicates the achieved performance for Delay and Delay Variation supporting the Class 0 objectives. The values indicated are simply estimates of performance, and the only binding commitment is to the QoS Class. In the following tables, acceptance of the QoS Class indicates commitment to its objectives. Table 4. Example of QoS Class Acceptance with Specified Parameter Indications Field Name Value MandatoryField? QoS Class Requested Class 0 Yes QoS Class Response Accept Yes Mean Transfer Delay (IPTD) 80 ms No 99.9% - min Delay Var. (IPDV) 20 ms No Loss (IPLR) No Errored Packets (IPER) No An example of the network response for 'QoS Class rejection and alternate class commitment and indications' is a case where the network provider rejects the requested Class and offers another Class with a specified parameter indication for Delay. Table 5. Example of QoS Class rejection with alternative offer and indications Field Name Value MandatoryField? QoS Class Requested Class 0 Yes QoS Class Response Reject Yes QoS Class Offered Class 1 No Mean Transfer Delay (IPTD) 180 ms No 99.9% - min Delay Var. (IPDV) No Loss (IPLR) No Errored Packets (IPER) No B.5.2. Network-Network Signaling Signaling must communicate the consumption of the network (source-UNI to destination-UNI) QoS objectives. The fields used in signaling may take several forms: Table 6. Example of Accumulating & Signaling Current Performance Requested Currently Achieved QoS Class Class 0 Class 0 Mean Transfer Delay (IPTD) 100 ms 20 ms 99.9% - min Delay Var. (IPDV) 50 ms 10 ms Loss (IPLR) 10^-3 <10^-3 Errored Packets (IPER) 10^-4 <10^-4 Status of Parameter Indications Allowed Note that the requested parameter values are fully specified by the QoS Class, but are included in this table for simple comparison. Only the achieved values and the requested/achieved Class number require signaling fields. The network receiving this message determines its performance from entrance node to the destination, or to the most likely exit node to the best-next network. The network would add its contribution to the Currently Achieved fields (according to a specified set of summation rules for each parameter), and send these fields on to the next network or back toward the requesting user. Participating networks can indicate their willingness to indicate specific parameter values (where a single negative preference overrides others). In case the requested QoS Class is not achieved, the response can contain the committed performance in excess of the offered Class, using the Currently Achieved values. The ability for each network to enter and communicate its contribution to the achieved performance level is a network option, an example is shown below: Table 7. Example of Accumulating & Signaling Current Performance Requested Network 1 Network 2 Currently Achieved QoS Class Class 0 Class 0 Class 0 Class 0 Mean Transfer Delay 100 ms 20 ms 10 ms 30 ms (IPTD) 99.9% - min Delay Var. 50 ms 10 ms 10 ms 15 ms (IPDV) Loss (IPLR) 10^-3 <10^-3 <10^-3 <10^-3 Errored Packets (IPER) 10^-4 <10^-4 <10^-4 <10^-4 Status of Parameters Allowed Allowed Allowed Indications A complete tabulation of the accumulated performance would allow corrective network actions if the Requested Class were not achieved. Summation rules are simple for transfer delay. Average values for each network are added to the currently achieved value. More study is needed to determine the summation rules for delay variation and other parameters. 10. Full Copyright Statement Copyright (C) The Internet Society (2004). 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.