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 ....................62

1.  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.