Internet Engineering Task Force (IETF) G. Ash, Ed. Request for Comments: 5975 AT&T Category: Experimental A. Bader, Ed. ISSN: 2070-1721 Ericsson C. Kappler, Ed. ck technology concepts D. Oran, Ed. Cisco Systems, Inc. October 2010 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)Abstract
The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5975. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4 1.1. Conventions Used in This Document ..........................6 2. Terminology .....................................................6 3. QSPEC Framework .................................................7 3.1. QoS Models .................................................7 3.2. QSPEC Objects ..............................................9 3.3. QSPEC Parameters ..........................................11 3.3.1. Traffic Model Parameter ............................12 3.3.2. Constraints Parameters .............................14 3.3.3. Traffic-Handling Directives ........................16 3.3.4. Traffic Classifiers ................................17 3.4. Example of QSPEC Processing ...............................17 4. QSPEC Processing and Procedures ................................20 4.1. Local QSPEC Definition and Processing .....................20 4.2. Reservation Success/Failure, QSPEC Error Codes, and INFO-SPEC Notification ................................23 4.2.1. Reservation Failure and Error E Flag ...............24 4.2.2. QSPEC Parameter Not Supported N Flag ...............25 4.2.3. INFO-SPEC Coding of Reservation Outcome ............25 4.2.4. QNE Generation of a RESPONSE Message ...............26 4.2.5. Special Case of Local QSPEC ........................27 4.3. QSPEC Procedures ..........................................27 4.3.1. Two-Way Transactions ...............................28 4.3.2. Three-Way Transactions .............................30 4.3.3. Resource Queries ...................................32 4.3.4. Bidirectional Reservations .........................33 4.3.5. Preemption .........................................33 4.4. QSPEC Extensibility .......................................33 5. QSPEC Functional Specification .................................33 5.1. General QSPEC Formats .....................................33 5.1.1. Common Header Format ...............................34 5.1.2. QSPEC Object Header Format .........................36 5.2. QSPEC Parameter Coding ....................................37 5.2.1. <TMOD-1> Parameter .................................37 5.2.2. <TMOD-2> Parameter .................................38 5.2.3. <Path Latency> Parameter ...........................39 5.2.4. <Path Jitter> Parameter ............................40 5.2.5. <Path PLR> Parameter ...............................41 5.2.6. <Path PER> Parameter ...............................42 5.2.7. <Slack Term> Parameter .............................43 5.2.8. <Preemption Priority> and <Defending Priority> Parameters .........................................43 5.2.9. <Admission Priority> Parameter .....................44 5.2.10. <RPH Priority> Parameter ..........................45 5.2.11. <Excess Treatment> Parameter ......................46 5.2.12. <PHB Class> Parameter .............................48
5.2.13. <DSTE Class Type> Parameter .......................49 5.2.14. <Y.1541 QoS Class> Parameter ......................50 6. Security Considerations ........................................51 7. IANA Considerations ............................................51 8. Acknowledgements ...............................................55 9. Contributors ...................................................55 10. Normative References ..........................................57 11. Informative References ........................................59 Appendix A. Mapping of QoS Desired, QoS Available, and QoS Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ .62 Appendix B. Example of TMOD Parameter Encoding ....................621. Introduction
The QoS NSIS signaling layer protocol (NSLP) [RFC5974] is used to signal QoS reservations for a data flow, provide forwarding resources (QoS) for that flow, and establish and maintain state at nodes along the path of the flow. The design of QoS NSLP is conceptually similar to the decoupling between RSVP [RFC2205] and the IntServ architecture [RFC2210], where a distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). [RFC5974] describes the signaling protocol, while this document describes the RMF-related information carried in the QSPEC (QoS Specification) object carried in QoS NSLP messages. [RFC5974] defines four QoS NSLP messages -- RESERVE, QUERY, RESPONSE, and NOTIFY -- each of which may carry the QSPEC object, while this document describes a template for the QSPEC object. The QSPEC object carries information on traffic descriptions, resources required, resources available, and other information required by the RMF. Therefore, the QSPEC template described in this document is closely tied to QoS NSLP, and the reader should be familiar with [RFC5974] to fully understand this document. A QoS-enabled domain supports a particular QoS model (QOSM), which is a method to achieve QoS for a traffic flow. A QOSM incorporates QoS provisioning methods and a QoS architecture, and defines the behavior of the RMF that reserves resources for each flow, including inputs and outputs. The QoS NSLP protocol is able to signal QoS reservations for different QOSMs, wherein all information specific to a QOSM is encapsulated in the QSPEC object, and only the RMF specific to a given QOSM will need to interpret the QSPEC. Examples of QOSMs are IntServ, Diffserv admission control, and those specified in [CL-QOSM], [RFC5976], and [RFC5977].
QSPEC parameters include, for example: o a mandatory traffic model (TMOD) parameter, o constraints parameters such as path latency and path jitter, o traffic handling directives such as excess treatment, and o traffic classifiers such as PHB class. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. QSPEC objects loosely correspond to the TSpec, RSpec, and AdSpec objects specified in RSVP and may contain, respectively, a description of QoS Desired, QoS Reserved, and QoS Available. Going beyond RSVP functionality, the QSPEC also allows indicating a range of acceptable QoS by defining a QSPEC object denoting minimum QoS. Usage of these QSPEC objects is not bound to particular message types, thus allowing for flexibility. A QSPEC object collecting information about available resources may travel in any QoS NSLP message, for example, a QUERY message or a RESERVE message, as defined in [RFC5974]. The QSPEC travels in QoS NSLP messages but is opaque to the QoS NSLP and is only interpreted by the RMF. Interoperability between QoS NSIS entities (QNEs) in different domains is enhanced by the definition of a common set of QSPEC parameters. A QoS NSIS initiator (QNI) initiating the QoS NSLP signaling adds an Initiator QSPEC object containing parameters describing the desired QoS, normally based on the QOSM it supports. QSPEC parameters flagged by the QNI must be interpreted by all QNEs in the path, else the reservation fails. In contrast, QSPEC parameters not flagged by the QNI may be skipped if not understood. Additional QSPEC parameters can be defined by informational specification documents, and thereby ensure the extensibility and flexibility of QoS NSLP. A Local QSPEC can be defined in a local domain with the Initiator QSPEC encapsulated, where the Local QSPEC must be functionally consistent with the Initiator QSPEC in terms of defined source traffic and other constraints. That is, a domain-specific local QSPEC can be defined and processed in a local domain, which could, for example, enable simpler processing by QNEs within the local domain. In Section 3.4, an example of QSPEC processing is provided.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].2. Terminology
Initiator QSPEC: The Initiator QSPEC is included in a QoS NSLP message by the QNI/QNR. It travels end-to-end to the QNR/QNI and is never removed. Local QSPEC: A Local QSPEC is used in a local domain and is domain specific. It encapsulates the Initiator QSPEC and is removed at the egress of the local domain. Minimum QoS: QSPEC object that, together with a description of QoS Desired or QoS Available, allows the QNI to specify a QoS range, i.e., an upper and lower bound. If the QoS Desired cannot be reserved, QNEs are going to decrease the reservation until the minimum QoS is hit. Note that the term "minimum" is used generically, since for some parameters, such as loss rate and latency, what is specified is the maximum acceptable value. QNE: QoS NSIS Entity, a node supporting QoS NSLP. QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling. QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling. QoS Available: QSPEC object containing parameters describing the available resources. They are used to collect information along a reservation path. QoS Desired: QSPEC object containing parameters describing the desired QoS for which the sender requests reservation. QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load; specifies the subset of QSPEC QoS constraints and traffic handling directives that a QNE implementing that QOSM is capable of supporting and how resources will be managed by the RMF. QoS Reserved: QSPEC object containing parameters describing the reserved resources and related QoS parameters. QSPEC: the object of QoS NSLP that contains all QoS-specific information.
QSPEC parameter: Any parameter appearing in a QSPEC; for example, traffic model (TMOD), path latency, and excess treatment parameters. QSPEC Object: Main building blocks containing a QSPEC parameter set that is the input or output of an RMF operation. QSPEC Type: Identifies a particular QOSM used in the QSPEC Resource Management Function (RMF): Functions that are related to resource management and processing of QSPEC parameters.