Network Working Group Jerry Ash Internet Draft Martin Dolly <draft-ash-nsis-y1541-qsp-00.txt> Chuck Dvorak Expiration Date: June 2005 Al Morton Percy Tarapore AT&T Yacine El Mghazli Sven Van den Bosch Alcatel December 2004 NSIS QoS Signaling Policy for Networks Using Y.1541 QoS Classes Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft describes a QoS-NSLP signaling policy based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QSP extensions include additional QSPEC parameters and QSP control processing guidelines. Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 1]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements . 3 2.1 Y.1541 QoS Classes . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Y.1541 Signaling Requirements . . . . . . . . . . . . . . . . . . 4 3. Additional QSPEC Parameters for Y.1541 QSP . . . . . . . . . . . . 5 3.1 <Token Bucket> Parameters . . . . . . . . . . . . . . . . . . . . 5 3.2 <Restoration Priority> Parameter . . . . . . . . . . . . . . . . 5 4. Control Processing for Y.1541 QSP . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Intellectual Property Considerations . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . . . 9 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 11 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 11 Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 2]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 1. Introduction This draft describes a QoS signaling policy (QSP) for QoS-NSIS signaling layer protocol (QoS-NSLP) application based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QSP extensions include additional QSPEC parameters and QSP control processing guidelines. The extensions are based on standardization work in the ITU-T on QoS signaling requirements [Y.1541, TRQ-QoS-SIG, E.361]. [QoS-SIG] defines message types and control information for the QoS-NSLP generic to all QSPs. A QSP is a defined mechanism for achieving QoS as a whole. The specification of a QSP includes a description of its QSPEC parameter information, as well as how that information should be treated or interpreted in the network. The QSPEC [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]. The QSPEC object contains control information and the QoS parameters defined by the QSP. A QSP provides a specific set of parameters to be carried in the QSPEC - [INTSERV], [DIFFSERV] and [Y.1541] are examples of QSPs. At each QNE its contents are interpreted by the resource management function (RMF) for the purposes of policy control and traffic control (including admission control and configuration of the packet classifier and scheduler). 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements 2.1 Y.1541 QoS Classes [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 Y.1451 QoS class are summarized here: Class 0: Real-time, highly interactive applications, sensitive to jitter. Mean delay upper bound is 100 ms, delay variation is less than 50 ms, and loss ratio is less than 10-3. Application examples include VoIP, Video Teleconference. Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 3]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 Class 1: Real-time, interactive applications, sensitive to jitter. Mean delay upper bound is 400 ms, delay variation 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 variation 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 variation 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 variation 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 variation, 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. 2.2 Y.1541 Signaling Requirements [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). To meet specific network performance requirements specified for the Y.1541 QoS classes, a network needs to provide specific user plane functionality at UNI, NNI, and INI interfaces. 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. The call/session control signaling includes an indication of the QoS requirements for each session. Obtaining user-to-user QoS 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 MUST be possible to derive the following service level parameters as part of the process of requesting service: a. Y.1541 QoS class b. peak data rate (p) c. peak bucket size (Bp) d. sustainable rate (Rs) Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 4]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 e. sustainable bucket size (b) f. token bucket rate (r) g. maximum allowed packet size (M) h. DiffServ field [RFC 2474] i. reservation priority class (urgency of establishing service connection) can be requested j. restoration priority class (urgency of restoring service connection under failure) can be requested All parameters except <Bp>, <Rs>, and <Restoration Priority> have already been specified in [QSPEC]. These additional parameters are specified in Section 3. It MUST be possible to perform the following QoS-NSLP signaling functions to enable Y.1541-QSP requirements: a. accumulate delay, delay variation and loss ratio across the end-to-end connection, which may span multiple domains b. enable negotiation of Y.1541 QoS class across domains. c. enable negotiation of delay, delay variation, and loss ratio across domains. Additional signaling functions beyond those already specified in [QSPEC] are discussed in Section 4. 3. Additional QSPEC Parameters for Y.1541 QSP 3.1 <Token Bucket> Parameters The <Token Bucket> parameters are represented by two floating point numbers in single-precision IEEE floating point format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Bucket Size [Bb] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sustainable Rate [Rs] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the Bp and Rs terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes. 3.2 <Restoration Priority> Parameter Restoration priority is the urgency with which a service requires successful restoration under failure conditions. 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. Restoration priority is defined as follows: Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 5]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Restoration | | Priority | +-+-+-+-+-+-+-+-+ Restoration Priority: 8 bits 3 priority values are listed here in the order of lowest priority to highest priority: 2 - best effort 1 - normal 0 - high Each restoration priority 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. 4. Control Processing for Y.1541 QSP The QNI in a Y.1541-QSP domain initiates, an end-to-end, inter-domain QoS NSLP RESERVE message containing the Initiator QSPEC, which specifies the <Y.1541 QOS Class>, <Token Bucket>, <Reservation Priority>, and perhaps other generic QSPEC parameters for the flow. The Initiator QSPEC also contains Y.1541-QSP-Specific parameters including <Bp>, <Rs>, and <Restoration Priority>. As illustrated in Figure 1, the RESERVE message may cross multiple domains supporting different QSPs. In this illustration, the Initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress node of the Local-QSP domain. At the ingress edge node of the Local-QSP domain, the end-to-end, inter-domain QoS-NSLP messages trigger the generation of local, intra-domain Local-QSP QoS-NSLP messages. The Initiator QSPEC of the end-to-end, inter-domain QoS-NSLP message is translated into a Local-QSP QSPEC. The original QoS-NSLP messages are sent directly to the egress edge node. The Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 6]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 local, intra-domain QoS-NSLP messages are processed and interpreted in all interior NSLP routers along the path, hop-by-hop, up to the egress edge node. The ingress edge node uses the Initiator QSPEC to construct the Local-QSPEC for intra-domain Local-QSP specific signaling, and sends it in a RESERVE message to the egress node. For example, if the Local-QSP is the RMD-QSP [RMD], then the <Y.1541 QOS Class> parameter would be translated to the <PHB Class> parameter. Each node on the data path checks the availability of resources and accumulating the delay, delay variation, and loss ratio parameters, as described below. If an intermediate node cannot accommodate the new request, it indicates it by marking a single bit in the message, and continues forwarding the message. When the message reaches the egress edge node of the Local-QSP domain, if no intermediate node has denied the reservation, the generic RESERVE message with the Initiator QSPEC is forwarded to the next domain. If an intermediate node has denied the reservation, the reservation is denied. If any QNE cannot meet the requirements designated by the Initiator QSPEC, for example, it cannot meet the specified Y.1541 QOS Class delay variation parameter, then it marks a <Y.1541 QOS Class Flag> bit to 1 to indicate that the Y.1541 QOS Class constraints cannot be met. The <Y.1541-QSC Flag> bit is normally set to zero. |------| |------| |------| |------| | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | | QoS | | QoS | | QoS | | QoS | | | |------| |-------| |-------| |------| | | | | | local|<->| local |<->| local |<->| local| | | | | | QoS | | QoS | | QoS | | QoS | | | | | | | | | | | | | | | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | |Y.1541| |local | |local | |local | |local | |Y.1541| | QSP | | QSP | | QSP | | QSP | | QSP | | QSP | |------| |------| |-------| |-------| |------| |------| ----------------------------------------------------------------- |------| |------| |-------| |-------| |------| |------| | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | |------| |------| |-------| |-------| |------| |------| QNI QNE QNE QNE QNE QNR (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) Figure 1 Protocol Model of Y.1541-QSP Operation A QNI requests the Y.1541 QoS class and enables the processing of the <Available Bandwidth> and <Min Latency> QSPEC parameter, to determine the <QoS Available> for the REQUEST, as described in [QSPEC]. The <Min Latency> parameter accumulates the latency of the packet forwarding process associated with each QNE, where the latency is defined to be the smallest possible packet delay added by each QNE. This delay results from speed-of-light propagation delay, from packet processing limitations, or both. It does not include any variable queuing delay which may be present. Each QNE MUST add the propagation Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 7]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 delay of its outgoing link, which includes the QNR adding the associated delay for the egress link. Furthermore, the QNI MUST add the propagation delay of the ingress link. The composition rule for the <Min Latency> parameter is summation with a clamp of (2**32 - 1) on the maximum value. This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal packet delay along the path from QNI to QNR. The purpose of this parameter is to provide a minimum path latency for use with services which provide estimates or bounds on additional path delay [RFC 2212]. Together with the queuing delay bound, this parameter gives the application knowledge of both the minimum and maximum packet delivery delay. Knowing both the minimum and maximum latency experienced by data packets allows the receiving application to know the bound on delay variation and de-jitter buffer requirements. The <Available Bandwidth> parameter provides information about the bandwidth available along the path followed by a data flow. The local parameter is an estimate of the bandwidth the QNE has available for packets following the path. Computation of the value of this parameter should take into account all information available to the QNE about the path, taking into consideration administrative and policy controls on bandwidth, as well as physical resources. The composition rule for this parameter is the MIN function. The composed value is the minimum of the QNE's value and the previously composed value. This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal bandwidth link along the path from QNI to QNR. Further details and requirements for Y.1541 QSP processing will be included in future releases of this document. 5. Security Considerations There are no new security considerations based on this draft. 6. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. [QoS-SIG] requires IANA to create a new registry for QoS Signaling Policy Identifiers. The QoS Signaling Policy Identifier (QSP ID) is a 32 bit value carried in a QSPEC object. The allocation policy for new QSP IDs is TBD. This document also defines 3 new objects for the QSPEC Template, as Detailed in Section 3. Values are to be assigned for them from the GIMPS Object Type registry. 7. Acknowledgements 8. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 8]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 9. Normative References [INTSERV] Braden, B., et. al., "Integrated Services in the Internet Architecture: an Overview," RFC 1633, June 1994. [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service Signaling," work in progress. [QSPEC], Ash, J., et. al., "QoS-NSLP QSPEC Template," 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. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services," May 2002. 10. Informative References [DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [E.361] ITU-T Recommendation, "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies," May 2003. 11. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Email: gash@att.com Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 9]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 Martin Dolly AT&T Room E3-3A14 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-4574 E-mail: mdolly@att.com Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: + 1 973-236-6700 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 E-mail: acmorton@att.com Percy Tarapore AT&T Room D1-33 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 Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 10]
Internet Draft NSIS QSP for Y.1541 QoS Classes December 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Ash, et. al. <draft-ash-nsis-y1541-qsp-00.txt> [Page 11]