doc: Add RFC documents

1 files changed, 3587 insertions, 0 deletions

diff --git a/doc/rfc/rfc5975.txt b/doc/rfc/rfc5975.txt
new file mode 100644
index 0000000..add4f19
--- /dev/null
+++ b/doc/rfc/rfc5975.txt
@@ -0,0 +1,3587 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+Ash, et al.                   Experimental                      [Page 1]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                      [Page 2]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+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
+
+
+
+Ash, et al.                   Experimental                      [Page 3]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+           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].
+
+
+
+
+
+
+Ash, et al.                   Experimental                      [Page 4]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   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.
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                      [Page 5]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+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.
+
+
+
+Ash, et al.                   Experimental                      [Page 6]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   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.
+
+3. QSPEC Framework
+
+   The overall framework for the QoS NSLP is that [RFC5974] defines QoS
+   signaling and semantics, the QSPEC template defines the container and
+   semantics for QoS parameters and objects, and informational
+   specifications define QoS methods and procedures for using QoS
+   signaling and QSPEC parameters/objects within specific QoS
+   deployments.  QoS NSLP is a generic QoS signaling protocol that can
+   signal for many QOSMs.
+
+3.1.  QoS Models
+
+   A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ
+   Controlled Load [CL-QOSM], Resource Management with Diffserv
+   [RFC5977], and QoS signaling for Y.1541 QoS classes [RFC5976].  A
+   QOSM specifies a set of QSPEC parameters that describe the QoS
+   desired and how resources will be managed by the RMF.  The RMF
+   implements functions that are related to resource management and
+   processes the QSPEC parameters.
+
+   QOSMs affect the operation of the RMF in NSIS-capable nodes and the
+   information carried in QSPEC objects.  Under some circumstances
+   (e.g., aggregation), they may cause a separate NSLP session to be
+   instantiated by having the RMF as a QNI.  QOSM specifications may
+   define RMF triggers that cause the QoS NSLP to run semantics within
+   the underlying QoS NSLP signaling state and messaging processing
+   rules, as defined in Section 5.2 of [RFC5974].  New QoS NSLP message
+   processing rules can only be defined in extensions to QoS NSLP.  If a
+   QOSM specification defines triggers that deviate from existing QoS
+   NSLP processing rules, the fallback for QNEs not supporting that QOSM
+   are the QoS NSLP state transition/message processing rules.
+
+   The QOSM specification includes how the requested QoS resources will
+   be described and how they will be managed by the RMF.  For this
+   purpose, the QOSM specification defines a set of QSPEC parameters it
+   uses to describe the desired QoS and resource control in the RMF, and
+   it may define additional QSPEC parameters.
+
+
+
+Ash, et al.                   Experimental                      [Page 7]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   When a QoS NSLP message travels through different domains, it may
+   encounter different QOSMs.  Since QOSMs use different QSPEC
+   parameters for describing resources, the QSPEC parameters included by
+   the QNI may not be understood in other domains.  The QNI therefore
+   can flag those QSPEC parameters it considers vital with the M flag.
+   QSPEC parameters with the M flag set must be interpreted by the
+   downstream QNEs, or the reservation fails.  QSPEC parameters without
+   the M flag set should be interpreted by the downstream QNEs, but may
+   be ignored if not understood.
+
+   A QOSM specification SHOULD include the following:
+
+   - role of QNEs, e.g., location, frequency, statefulness, etc.
+   - QSPEC definition including QSPEC parameters
+   - QSPEC procedures applicable to this QOSM
+   - QNE processing rules describing how QSPEC information is treated
+     and interpreted in the RMF, e.g., admission control, scheduling,
+     policy control, QoS parameter accumulation (e.g., delay)
+   - at least one bit-level QSPEC example
+   - QSPEC parameter behavior for new QSPEC parameters that the QOSM
+     specification defines
+   - a definition of what happens in case of preemption if the default
+     QNI behavior (teardown preempted reservation) is not followed (see
+     Section 4.3.5)
+
+   A QOSM specification MAY include the following:
+
+   - definitions of additional QOSM-specific error codes, as discussed
+     in Section 4.2.3
+   - the QoS-NSLP options a QOSM wants to use, when several options are
+     available for a QOSM (e.g., Local QSPEC to either a) hide the
+     Initiator QSPEC within a local domain message, or b) encapsulate
+     the Initiator QSPEC).
+
+   QOSMs are free, subject to IANA registration and review rules, to
+   extend QSPECs by adding parameters of any of the kinds supported by
+   the QSPEC.  This includes traffic description parameters, constraint
+   parameters, and traffic handling directives.  QOSMs are not
+   permitted, however, to reinterpret or redefine the QSPEC parameters
+   specified in this document.  Note that signaling functionality is
+   only defined by the QoS NSLP document [RFC5974] and not by this
+   document or by QOSM specification documents.
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                      [Page 8]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+3.2.  QSPEC Objects
+
+   The QSPEC is the object of QoS NSLP containing QSPEC objects and
+   parameters.  QSPEC objects are the main building blocks of the QSPEC
+   parameter set that is input or output of an RMF operation.  QSPEC
+   parameters are the parameters appearing in a QSPEC, which must
+   include the traffic model parameter (TMOD), and may optionally
+   include constraints (e.g., path latency), traffic handling directives
+   (e.g., excess treatment), and traffic classifiers (e.g., PHB class).
+   The RMF implements functions that are related to resource management
+   and processes the QSPEC parameters.
+
+   The QSPEC consists of a QSPEC version number and QSPEC objects.  IANA
+   assigns a new QSPEC version number when the current version is
+   deprecated or deleted (as required by a specification).  Note that a
+   new QSPEC version number is not needed when new QSPEC parameters are
+   specified.  Later QSPEC versions MUST be backward compatible with
+   earlier QSPEC versions.  That is, a version n+1 device must support
+   QSPEC version n (or earlier).  On the other hand, if a QSPEC version
+   n (or earlier) device receives an NSLP message specifying QSPEC
+   version n+1, then the version n device responds with an 'Incompatible
+   QSPEC' error code (0x0f) response, as discussed in Section 4.2.3,
+   allowing the QNE that sent the NSLP message to retry with a lower
+   QSPEC version.
+
+   This document provides a template for the QSPEC in order to promote
+   interoperability between QOSMs.  Figure 1 illustrates how the QSPEC
+   is composed of up to 4 QSPEC objects, namely QoS Desired, QoS
+   Available, QoS Reserved, and Minimum QoS.  Each of these QSPEC
+   objects consists of a number of QSPEC parameters.  A given QSPEC may
+   contain only a subset of the QSPEC objects, e.g., QoS Desired.  The
+   QSPEC objects QoS Desired, QoS Available, QoS Reserved and Minimum
+   QoS MUST all be supported by QNEs and MAY appear in any QSPEC object
+   carried in any QoS NSLP message (RESERVE, QUERY, RESPONSE, NOTIFY).
+   See [RFC5974] for descriptions of the QoS NSLP RESERVE, QUERY,
+   RESPONSE, and NOTIFY messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                      [Page 9]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   +---------------------------------------+
+   |            QSPEC Objects              |
+   +---------------------------------------+
+
+   \________________ ______________________/
+                    V
+   +----------+----------+---------+-------+
+   |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
+   +----------+----------+---------+-------+
+
+   \____ ____/\___ _____/\___ ____/\__ ___/
+        V         V          V        V
+
+   +-------------+...     +-------------+...
+   |QSPEC Para. 1|        |QSPEC Para. n|
+   +-------------+...     +-------------+...
+
+       Figure 1: Structure of the QSPEC
+
+   Use of the 4 QSPEC objects (QoS Desired, QoS Available, QoS Reserved,
+   and Minimum QoS) is described in Section 4.3 for 3 message sequences
+   and 7 object combinations.
+
+   The QoS Desired Object describe the resources the QNI desires to
+   reserve, and hence this is a read-only QSPEC object in that the QSPEC
+   parameters carried in the object may not be overwritten.  QoS Desired
+   is always included in a RESERVE message and sometimes included in the
+   QUERY message (see Section 4.3 for details).
+
+   As described in Section 4.3, the QoS Available object may travel in a
+   RESERVE message, RESPONSE Message, or QUERY message and may collect
+   information on the resources currently available on the path.  In
+   this case, QoS Available is a read-write object, which means the
+   QSPEC parameters contained in QoS Available may be updated, but they
+   cannot be deleted.  As such, each QNE MUST inspect all parameters of
+   this QSPEC object, and if resources available to this QNE are less
+   than what a particular parameter says currently, the QNE MUST adapt
+   this parameter accordingly.  Hence, when the message arrives at the
+   recipient of the message, <QoS Available> reflects the bottleneck of
+   the resources currently available on a path.  It can be used in a
+   QUERY message, for example, to collect the available resources along
+   a data path.
+
+   When QoS Available travels in a RESPONSE message, it in fact just
+   transports the result of a previous measurement performed by a
+   RESERVE or QUERY message back to the initiator.  Therefore, in this
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 10]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   case, QoS Available is read-only.  In one other instance described in
+   Section 4.3.2 (Case 3), QoS Available is sent by the QNI in a RESERVE
+   message as a read-only QSPEC object (see Section 4.3.2 for details).
+
+   The QoS Reserved object reflects the resources that are being
+   reserved.  It is a read-only object and is always included in a
+   RESPONSE message if QoS Desired is included in the RESERVE message
+   (see Section 4.3 for details).
+
+   Minimum QoS does not have an equivalent in RSVP.  It allows the QNI
+   to define a range of acceptable QoS levels by including both the
+   desired QoS value and the minimum acceptable QoS in the same message.
+   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.  It is a read-only object, and may be
+   included in a RESERVE message, RESPONSE message, or QUERY message
+   (see Section 4.3 for details).  The desired QoS is included with a
+   QoS Desired and/or a QoS Available QSPEC object seeded to the desired
+   QoS value.  The minimum acceptable QoS value MAY be coded in the
+   Minimum QoS QSPEC object.  As the message travels towards the QNR,
+   QoS Available is updated by QNEs on the path.  If its value drops
+   below the value of Minimum QoS, the reservation fails and is aborted.
+   When this method is employed, the QNR signals back to the QNI the
+   value of QoS Available attained in the end, because the reservation
+   may need to be adapted accordingly (see Section 4.3 for details).
+
+   Note that the relationship of QSPEC objects to RSVP objects is
+   covered in Appendix A.
+
+3.3.  QSPEC Parameters
+
+   QSPEC parameters provide a common language for building QSPEC
+   objects.  This document defines a number of QSPEC parameters;
+   additional parameters may be defined in separate QOSM specification
+   documents.  For example, QSPEC parameters are defined in [RFC5976]
+   and [RFC5977].
+
+   One QSPEC parameter, <TMOD>, is special.  It provides a description
+   of the traffic for which resources are reserved.  This parameter must
+   be included by the QNI, and it must be interpreted by all QNEs.  All
+   other QSPEC parameters are populated by a QNI if they are applicable
+   to the underlying QoS desired.  For these QSPEC parameters, the QNI
+   sets the M flag if they must be interpreted by downstream QNEs.  If
+   QNEs cannot interpret the parameter, the reservation fails.  QSPEC
+   parameters populated by a QNI without the M flag set should be
+   interpreted by downstream QNEs, but may be ignored if not understood.
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 11]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   In this document, the term 'interpret' means, in relation to RMF
+   processing of QSPEC parameters, that the RMF processes the QSPEC
+   parameter according to the commonly accepted normative procedures
+   specified by references given for each QSPEC parameter.  Note that a
+   QNE need only interpret a QSPEC parameter if it is populated in the
+   QSPEC object by the QNI; if not populated in the QSPEC, the QNE does
+   not interpret it of course.
+
+   Note that when an ingress QNE in a local domain defines a Local QSPEC
+   and encapsulates the Initiator QSPEC, the QNEs in the interior local
+   domain need only process the Local QSPEC and can ignore the Initiator
+   (encapsulated) QSPEC.  However, edge QNEs in the local domain indeed
+   must interpret the QSPEC parameters populated in the Initiator QSPEC
+   with the M flag set and should interpret QSPEC parameters populated
+   in the Initiator QSPEC without the M flag set.
+
+   As described in the previous section, QoS parameters may be
+   overwritten depending on which QSPEC object and which message they
+   appear in.
+
+3.3.1.  Traffic Model Parameter
+
+   The <Traffic Model> (TMOD) parameter is mandatory for the QNI to
+   include in the Initiator QSPEC and mandatory for downstream QNEs to
+   interpret.  The traffic description specified by the TMOD parameter
+   is a container consisting of 5 sub-parameters [RFC2212]:
+
+   o  rate (r) specified in octets per second
+   o  bucket size (b) specified in octets
+   o  peak rate (p) specified in octets per second
+   o  minimum policed unit (m) specified in octets
+   o  maximum packet size (MPS) specified in octets
+
+   The TMOD parameter takes the form of a token bucket of rate (r) and
+   bucket size (b), plus a peak rate (p), minimum policed unit (m), and
+   maximum packet size (MPS).
+
+   Both b and r MUST be positive.  The rate, r, is measured in octets of
+   IP packets per second, and can range from 1 octet per second to as
+   large as 40 teraoctets per second.  The bucket depth, b, is also
+   measured in octets and can range from 1 octet to 250 gigaoctets.  The
+   peak rate, p, is measured in octets of IP packets per second and has
+   the same range and suggested representation as the bucket rate.
+
+   The peak rate is the maximum rate at which the source and any
+   reshaping (defined below) may inject bursts of traffic into the
+   network.  More precisely, it is a requirement that for all time
+   periods the amount of data sent cannot exceed MPS+pT, where MPS is
+
+
+
+Ash, et al.                   Experimental                     [Page 12]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   the maximum packet size and T is the length of the time period.
+   Furthermore, p MUST be greater than or equal to the token bucket
+   rate, r.  If the peak rate is unknown or unspecified, then p MUST be
+   set to infinity.
+
+   The minimum policed unit, m, is an integer measured in octets.  All
+   IP packets less than size m will be counted, when policed and tested
+   for conformance to the TMOD, as being of size m.
+
+   The maximum packet size, MPS, is the biggest packet that will conform
+   to the traffic specification; it is also measured in octets.  The
+   flow MUST be rejected if the requested maximum packet size is larger
+   than the MTU of the link.  Both m and MPS MUST be positive, and m
+   MUST be less than or equal to MPS.
+
+   Policing compares arriving traffic against the TMOD parameters at the
+   edge of the network.  Traffic is policed to ensure it conforms to the
+   token bucket.  Reshaping attempts to restore the (possibly distorted)
+   traffic's shape to conform to the TMOD parameters, and traffic that
+   is in violation of the TMOD is discovered because the reshaping fails
+   and the reshaping buffer overflows.
+
+   The token bucket and peak rate parameters require that traffic MUST
+   obey the rule that over all time periods, the amount of data sent
+   cannot exceed MPS+min[pT, rT+b-MPS], where r and b are the token
+   bucket parameters, MPS is the maximum packet size, and T is the
+   length of the time period (note that when p is infinite, this reduces
+   to the standard token bucket requirement).  For the purposes of this
+   accounting, links MUST count packets that are smaller than the
+   minimum policing unit as being of size m.  Packets that arrive at an
+   element and cause a violation of the MPS + min[pT, rT+b-MPS] bound
+   are considered non-conformant.
+
+   All 5 of the sub-parameters MUST be included in the TMOD parameter.
+   The TMOD parameter can be set to describe the traffic source.  If,
+   for example, TMOD is set to specify bandwidth only, then set r = peak
+   rate = p, b = large, and m = large.  As another example, if TMOD is
+   set for TCP traffic, then set r = average rate, b = large, and p =
+   large.
+
+   When the 5 TMOD sub-parameters are included in QoS Available, they
+   provide information, for example, about the TMOD resources available
+   along the path followed by a data flow.  The value of TMOD at a QNE
+   is an estimate of the TMOD resources the QNE has available for
+   packets following the path up to the next QNE, including its outgoing
+   link, if this link exists.  Furthermore, the QNI MUST account for the
+   resources of the ingress link, if this link exists.  Computation of
+
+
+
+
+Ash, et al.                   Experimental                     [Page 13]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   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, as well as physical resources.
+
+   The output composed value is the minimum of the QNE's value and the
+   input composed value for r, b, p, and MPS, and the maximum of the
+   QNE's value and the input composed value for m.  This quantity, when
+   composed end-to-end, informs the QNR (or QNI in a RESPONSE message)
+   of the minimal TMOD resources along the path from QNI to QNR.
+
+   Two TMOD parameters are defined in Section 5, <TMOD-1> and <TMOD-2>,
+   where the second parameter (<TMOD-2>) is specified as could be needed
+   to support some Diffserv applications.  For example, it is typically
+   assumed that Diffserv Expedited Forwarding (EF) traffic is shaped at
+   the ingress by a single rate token bucket.  Therefore, a single TMOD
+   parameter is sufficient to signal Diffserv EF traffic.  However, for
+   Diffserv Assured Forwarding (AF) traffic, two sets of token bucket
+   parameters are needed -- one for the average traffic and one for the
+   burst traffic.  [RFC2697] defines a Single Rate Three Color Marker
+   (srTCM), which meters a traffic stream and marks its packets
+   according to three traffic parameters, Committed Information Rate
+   (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be
+   either green, yellow, or red.  A packet is marked green if it does
+   not exceed the CBS; yellow if it does exceed the CBS, but not the
+   EBS; and red otherwise.  [RFC2697] defines specific procedures using
+   two token buckets that run at the same rate.  Therefore, 2 TMOD
+   parameters are sufficient to distinguish among 3 levels of drop
+   precedence.  An example is also described in the Appendix to
+   [RFC2597].
+
+3.3.2.  Constraints Parameters
+
+   <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QSPEC
+   parameters describing the desired path latency, path jitter, packet
+   loss ratio, and path packet error ratio, respectively.  Since these
+   parameters are cumulative, an individual QNE cannot decide whether
+   the desired path latency, etc., is available, and hence they cannot
+   decide whether a reservation fails.  Rather, when these parameters
+   are included in <Desired QoS>, the QNI SHOULD also include
+   corresponding parameters in a QoS Available QSPEC object in order to
+   facilitate collecting this information.
+
+   The <Path Latency> parameter accumulates the latency of the packet
+   forwarding process associated with each QNE, where the latency is
+   defined to be the mean packet delay, measured in microseconds, added
+   by each QNE.  This delay results from the combination of link
+   propagation delay, packet processing, and queuing.  Each QNE MUST add
+   the propagation delay of its outgoing link, if this link exists.
+
+
+
+Ash, et al.                   Experimental                     [Page 14]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Furthermore, the QNI SHOULD add the propagation delay of the ingress
+   link, if this link exists.  The composition rule for the <Path
+   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 that provide
+   estimates or bounds on additional path delay [RFC2212].
+
+   The <Path Jitter> parameter accumulates the jitter of the packet
+   forwarding process associated with each QNE, where the jitter is
+   defined to be the nominal jitter, measured in microseconds, added by
+   each QNE.  IP packet jitter, or delay variation, is defined in
+   [RFC3393], Section 3.4 (Type-P-One-way-ipdv), and where the [RFC3393]
+   selection function includes the packet with minimum delay such that
+   the distribution is equivalent to 2-point delay variation in
+   [Y.1540].  The suggested evaluation interval is 1 minute.  This
+   jitter results from packet-processing limitations, and includes any
+   variable queuing delay that may be present.  Each QNE MUST add the
+   jitter of its outgoing link, if this link exists.  Furthermore, the
+   QNI SHOULD add the jitter of the ingress link, if this link exists.
+   The composition method for the <Path Jitter> parameter is the
+   combination of several statistics describing the delay variation
+   distribution with a clamp on the maximum value (note that the methods
+   of accumulation and estimation of nominal QNE jitter are specified in
+   clause 8 of [Y.1541]).  This quantity, when composed end-to-end,
+   informs the QNR (or QNI in a RESPONSE message) of the nominal packet
+   jitter along the path from QNI to QNR.  The purpose of this parameter
+   is to provide a nominal path jitter for use with services that
+   provide estimates or bounds on additional path delay [RFC2212].
+
+   The <Path PLR> parameter is the unit-less ratio of total lost IP
+   packets to total transmitted IP packets.  <Path PLR> accumulates the
+   packet loss ratio (PLR) of the packet-forwarding process associated
+   with each QNE, where the PLR is defined to be the PLR added by each
+   QNE.  Each QNE MUST add the PLR of its outgoing link, if this link
+   exists.  Furthermore, the QNI MUST add the PLR of the ingress link,
+   if this link exists.  The composition rule for the <Path PLR>
+   parameter is summation with a clamp on the maximum value. (This
+   assumes sufficiently low PLR values such that summation error is not
+   significant; however, a more accurate composition function is
+   specified in clause 8 of [Y.1541].)  This quantity, when composed
+   end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
+   minimal packet PLR along the path from QNI to QNR.
+
+   Packet error ratio [Y.1540, Y.1541] is the unit-less ratio of total
+   errored IP packet outcomes to the total of successful IP packet
+   transfer outcomes plus errored IP packet outcomes in a population of
+
+
+
+Ash, et al.                   Experimental                     [Page 15]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   interest, with a resolution of at least 10^-9.  If lesser resolution
+   is available in a value, the unused digits MUST be set to zero.  Note
+   that the number of errored packets observed is directly related to
+   the confidence in the result.  The <Path PER> parameter accumulates
+   the packet error ratio (PER) of the packet forwarding process
+   associated with each QNE, where the PER is defined to be the PER
+   added by each QNE.  Each QNE MUST add the PER of its outgoing link,
+   if this link exists.  Furthermore, the QNI SHOULD add the PER of the
+   ingress link, if this link exists.  The composition rule for the
+   <Path PER> parameter is summation with a clamp on the maximum value.
+   (This assumes sufficiently low PER values such that summation error
+   is not significant; however, a more accurate composition function is
+   specified in clause 8 of [Y.1541].)  This quantity, when composed
+   end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
+   minimal packet PER along the path from QNI to QNR.
+
+   The slack term parameter is the difference between desired delay and
+   delay obtained by using bandwidth reservation, and it is used to
+   reduce the resource reservation for a flow [RFC2212].
+
+3.3.3.  Traffic-Handling Directives
+
+   An application MAY like to reserve resources for packets and also
+   specify a specific traffic-handling behavior, such as <Excess
+   Treatment>.  In addition, as discussed in Section 3.1, an application
+   MAY like to define RMF triggers that cause the QoS NSLP to run
+   semantics within the underlying QoS NSLP signaling state / messaging
+   processing rules, as defined in Section 5.2 of [RFC5974].  Note,
+   however, that new QoS NSLP message processing rules can only be
+   defined in extensions to the QoS NSLP.  As with constraints
+   parameters and other QSPEC parameters, Traffic Handling Directives
+   parameters may be defined in QOSM specifications in order to provide
+   support for QOSM-specific resource management functions.  Such QOSM-
+   specific parameters are already defined, for example, in [RFC5976],
+   [RFC5977], and [CL-QOSM].  Generally, a Traffic Handling Directives
+   parameters is expected to be set by the QNI in <QoS Desired>, and to
+   not be included in <QoS Available>.  If such a parameter is included
+   in <QoS Available>, QNEs may change their value.
+
+   The <Preemption Priority> parameter is the priority of the new flow
+   compared with the <Defending Priority> of previously admitted flows.
+   Once a flow is admitted, the preemption priority becomes irrelevant.
+   The <Defending Priority> parameter is used to compare with the
+   preemption priority of new flows.  For any specific flow, its
+   preemption priority MUST always be less than or equal to the
+   defending priority.  <Admission Priority> and <RPH Priority> provide
+   an essential way to differentiate flows for emergency services,
+   Emergency Telecommunications Service (ETS), E911, etc., and assign
+
+
+
+Ash, et al.                   Experimental                     [Page 16]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   them a higher admission priority than normal priority flows and best-
+   effort priority flows.
+
+   The <Excess Treatment> parameter describes how the QNE will process
+   out-of-profile traffic.  Excess traffic MAY be dropped, shaped,
+   and/or re-marked.
+
+3.3.4.  Traffic Classifiers
+
+   An application MAY like to reserve resources for packets with a
+   particular Diffserv per-hop behavior (PHB) [RFC2475].  Note that PHB
+   class is normally set by a downstream QNE to tell the QNI how to mark
+   traffic to ensure the treatment that is designated by admission
+   control; however, setting of the parameter by the QNI is not
+   precluded.  An application MAY like to reserve resources for packets
+   with a particular QoS class, e.g., Y.1541 QoS class [Y.1541] or
+   Diffserv-aware MPLS traffic engineering (DSTE) class type [RFC3564,
+   RFC4124].  These parameters are useful in various QOSMs, e.g.,
+   [RFC5976], [RFC5977], and other QOSMs yet to be defined (e.g., DSTE-
+   QOSM).  This is intended to provide guidelines to QOSMs on how to
+   encode these parameters; use of the PHB class parameter is
+   illustrated in the example in the following section.
+
+3.4.  Example of QSPEC Processing
+
+   This section illustrates the operation and use of the QSPEC within
+   the NSLP.  The example configuration in shown in Figure 2.
+
+   +----------+      /-------\       /--------\       /--------\
+   | Laptop   |     |   Home  |     |  Cable   |     | Diffserv |
+   | Computer |-----| Network |-----| Network  |-----| Network  |----+
+   +----------+     | No QOSM |     |DQOS QOSM |     | RMD QOSM |    |
+                     \-------/       \--------/       \--------/     |
+                                                                     |
+                     +-----------------------------------------------+
+                     |
+                     |    /--------\      +----------+
+                     |   |    XG    |     | Handheld |
+                     +---| Wireless |-----|  Device  |
+                         | XG QOSM  |     +----------+
+                          \--------/
+
+      Figure 2: Example Configuration of QoS-NSLP/QSPEC Operation
+
+   In this configuration, a laptop computer and a handheld wireless
+   device are the endpoints for some application that has QoS
+   requirements.  Assume initially that the two endpoints are stationary
+   during the application session, later we consider mobile endpoints.
+
+
+
+Ash, et al.                   Experimental                     [Page 17]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   For this session, the laptop computer is connected to a home network
+   that has no QoS support.  The home network is connected to a
+   CableLabs-type cable access network with dynamic QoS (DQOS) support,
+   such as specified in the [DQOS] for cable access networks.  That
+   network is connected to a Diffserv core network that uses the
+   Resource Management in Diffserv QoS Model [RFC5977].  On the other
+   side of the Diffserv core is a wireless access network built on
+   generation "X" technology with QoS support as defined by generation
+   "X".  And finally, the handheld endpoint is connected to the wireless
+   access network.
+
+   We assume that the laptop is the QNI, and the handheld device is the
+   QNR.  The QNI will signal an Initiator QSPEC object to achieve the
+   QoS desired on the path.
+
+   The QNI sets QoS Desired, QoS Available, and possibly Minimum QoS
+   QSPEC objects in the Initiator QSPEC, and initializes QoS Available
+   to QoS Desired.  Each QNE on the path reads and interprets those
+   parameters in the Initiator QSPEC and checks to see if QoS Available
+   resources can be reserved.  If not, the QNE reduces the respective
+   parameter values in QoS Available and reserves these values.  The
+   minimum parameter values are given in Minimum QoS, if populated; they
+   are zero if Minimum QoS is not included.  If one or more parameters
+   in QoS Available fails to satisfy the corresponding minimum values in
+   Minimum QoS, the QNE generates a RESPONSE message to the QNI and the
+   reservation is aborted.  Otherwise, the QNR generates a RESPONSE to
+   the QNI with the QoS Available for the reservation.  If a QNE cannot
+   reserve QoS Desired resources, the reservation fails.
+
+   The QNI populates QSPEC parameters to ensure correct treatment of its
+   traffic in domains down the path.  Let us assume the QNI wants to
+   achieve QoS guarantees similar to IntServ Controlled Load service,
+   and also is interested in what path latency it can achieve.
+   Additionally, to ensure correct treatment further down the path, the
+   QNI includes <PHB Class> in <QoS Desired>.  The QNI therefore
+   includes in the QSPEC
+
+      QoS Desired = <TMOD> <PHB Class>
+      QoS Available = <TMOD> <Path Latency>
+
+   Since <Path Latency> and <PHB Class> are not vital parameters from
+   the QNI's perspective, it does not raise their M flags.
+
+   There are three possibilities when a RESERVE message is received at a
+   QNE at a domain border; they are described in the example:
+
+   - the QNE just leaves the QSPEC as is.
+
+
+
+
+Ash, et al.                   Experimental                     [Page 18]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   - the QNE can add a Local QSPEC and encapsulate the Initiator QSPEC
+     (see discussion in Section 4.1; this is new in QoS NSLP -- RSVP
+     does not do this).
+
+   - the QNE can 'hide' the initiator RESERVE message so that only the
+     edge QNE processes the initiator RESERVE message, which then
+     bypasses intermediate nodes between the edges of the domain and
+     issues its own local RESERVE message (see Section 3.3.1 of
+     [RFC5974]).  For this new local RESERVE message, the QNE acts as
+     the QNI, and the QSPEC in the domain is an Initiator QSPEC.  A
+     similar procedure is also used by RSVP in making aggregate
+     reservations, in which case there is not a new intra-domain
+     (aggregate) RESERVE for each newly arriving inter-domain (per-flow)
+     RESERVE, but the aggregate reservation is updated by the border QNE
+     (or QNI) as need be.  This is also how RMD works [RFC5977].
+
+   For example, at the RMD domain, a local RESERVE with its own RMD
+   Initiator QSPEC corresponding to the RMD-QOSM is generated based on
+   the original Initiator QSPEC according to the procedures described in
+   Section 4.5 of [RFC5974] and in [RFC5977].  The ingress QNE to the
+   RMD domain maps the TMOD parameters contained in the original
+   Initiator QSPEC to the equivalent TMOD parameter representing only
+   the peak bandwidth in the Local QSPEC.  The local RMD QSPEC for
+   example also needs <PHB Class>, which in this case was provided by
+   the QNI.
+
+   Furthermore, if the node can, at the egress to the RMD domain, it
+   updates QoS Available on behalf of the entire RMD domain.  If it
+   cannot (since the M flag is not set for <Path Latency>), it raises
+   the parameter-specific, Not Supported N flag, warning the QNR that
+   the final latency value in QoS Available is imprecise.
+
+   In the XG domain, the Initiator QSPEC is translated into a local
+   QSPEC using a similar procedure as described above.  The Local QSPEC
+   becomes the current QSPEC used within the XG domain, and the
+   Initiator QSPEC is encapsulated.  This saves the QNEs within the XG
+   domain the trouble of re-translating the Initiator QSPEC, and
+   simplifies processing in the local domain.  At the egress edge of the
+   XG domain, the translated Local QSPEC is removed, and the Initiator
+   QSPEC returns to the number one position.
+
+   If the reservation was successful, eventually the RESERVE request
+   arrives at the QNR (otherwise, the QNE at which the reservation
+   failed aborts the RESERVE and sends an error RESPONSE back to the
+   QNI).  If the RII was included in the QoS NSLP message, the QNR
+   generates a positive RESPONSE with QSPEC objects QoS Reserved and QoS
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 19]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Available.  The parameters appearing in QoS Reserved are the same as
+   in QoS Desired, with values copied from QoS Available.  Hence, the
+   QNR includes the following QSPEC objects in the RESPONSE:
+
+      QoS Reserved = <TMOD> <PHB Class>
+      QoS Available = <TMOD> <Path Latency>
+
+   If the handheld device on the right of Figure 2 is mobile, and moves
+   through different XG wireless networks, then the QoS might change on
+   the path since different XG wireless networks might support different
+   QOSMs.  As a result, QoS NSLP/QSPEC processing will have to
+   renegotiate the QoS Available on the path.  From a QSPEC perspective,
+   this is like a new reservation on the new section of the path and is
+   basically the same as any other rerouting event -- to the QNEs on the
+   new path, it looks like a new reservation.  That is, in this mobile
+   scenario, the new segment may support a different QOSM than the old
+   segment, and the QNI would now signal a new reservation explicitly
+   (or implicitly with the next refreshing RESERVE message) to account
+   for the different QOSM in the XG wireless domain.  Further details on
+   rerouting are specified in [RFC5974].
+
+   For bit-level examples of QSPECs, see the documents specifying QOSMs:
+   [CL-QOSM], [RFC5976], and [RFC5977].
+
+4.  QSPEC Processing and Procedures
+
+   Three flags are used in QSPEC processing, the M flag, E flag, and N
+   flag, which are explained in this section.  The QNI sets the M flag
+   for each QSPEC parameter it populates that MUST be interpreted by
+   downstream QNEs.  If a QNE does not support the parameter, it sets
+   the N flag and fails the reservation.  If the QNE supports the
+   parameter but cannot meet the resources requested by the parameter,
+   it sets the E flag and fails the reservation.
+
+   If the M flag is not set, the downstream QNE SHOULD interpret the
+   parameter.  If the QNE does not support the parameter, it sets the N
+   flag and forwards the reservation.  If the QNE supports the parameter
+   but cannot meet the resources requested by the parameter, it sets the
+   E flag and fails the reservation.
+
+4.1.  Local QSPEC Definition and Processing
+
+   A QNE at the edge of a local domain may either a) translate the
+   Initiator QSPEC into a Local QSPEC and encapsulate the Initiator
+   QSPEC in the RESERVE message, or b) 'hide' the Initiator QSPEC
+   through the local domain and reserve resources by generating a new
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 20]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   RESERVE message through the local domain containing the Local QSPEC.
+   In either case, the Initiator QSPEC parameters are interpreted at the
+   local domain edges.
+
+   A Local QSPEC may allow a simpler control plane in a local domain.
+   The edge nodes in the local domain must interpret the Initiator QSPEC
+   parameters.  They can either initiate a parallel session with Local
+   QSPEC or define a Local QSPEC and encapsulate the Initiator QSPEC, as
+   illustrated in Figure 3.  The Initiator/Local QSPEC bit identifies
+   whether the QSPEC is an Initiator QSPEC or a Local QSPEC.  The QSPEC
+   Type indicates, for example, that the initiator of the local QSPEC
+   uses to a certain QOSM, e.g., CL-QSPEC Type.  It may be useful for
+   the QNI to signal a QSPEC Type based on some QOSM (which will
+   necessarily entail populating certain QOSM-related parameters) so
+   that a downstream QNE can chose amongst various QOSM-related
+   processes it might have.  That is, the QNI populates the QSPEC Type,
+   e.g., CL-QSPEC Type and sets the Initiator/Local QSPEC bit to
+   'Initiator'.  A local QNE can decide, for whatever reasons, to insert
+   a Local QSPEC Type, e.g., RMD-QSPEC Type, and set the local QSPEC
+   Type = RMD-QSPEC and set the Initiator/Local QSPEC bit to 'Local'
+   (and encapsulate the Initiator QSPEC in the RESERVE or whatever NSLP
+   message).
+
+   +--------------------------------+\
+   |   QSPEC Type, QSPEC Procedure  | \
+   +--------------------------------+ / Common QSPEC Header
+   |   Init./Local QSPEC bit=Local  |/
+   +================================+\
+   |  Local-QSPEC Parameter 1       | \
+   +--------------------------------+  \
+   |             ....               |   Local-QSPEC Parameters
+   +--------------------------------+  /
+   |  Local-QSPEC Parameter n       | /
+   +--------------------------------+/
+   | +----------------------------+ |
+   | | QSPEC Type, QSPEC Procedure| |
+   | +----------------------------+ |
+   | | Init./Local QSPEC bit=Init.| |
+   | +============================+ |
+   | |                            | | Encapsulated Initiator QSPEC
+   | |          ....              | |
+   | +----------------------------+ |
+   +--------------------------------+
+
+                 Figure 3: Defining a Local QSPEC
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 21]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Here the QoS-NSLP only sees and passes one QSPEC up to the RMF.
+   Thus, the type of the QSPEC may change within a local domain.  Hence:
+
+   o  the QNI signals its QoS requirements with the Initiator QSPEC,
+
+   o  the ingress edge QNE in the local domain translates the Initiator
+      QSPEC parameters to equivalent parameters in the local QSPEC,
+
+   o  the QNEs in the local domain only interpret the Local QSPEC
+      parameters, and
+
+   o  the egress QNE in the local domain processes the Local QSPEC and
+      also interprets the QSPEC parameters in the Initiator QSPEC.
+
+   The Local QSPEC MUST be consistent with the Initiator QSPEC.  That
+   is, it MUST NOT specify a lower level of resources than specified by
+   the Initiator QSPEC.  For example, in RMD the TMOD parameters
+   contained in the original Initiator QSPEC are mapped to the
+   equivalent TMOD parameter representing only the peak bandwidth in the
+   Local QSPEC.
+
+   Note that it is possible to use both a) hiding a QSPEC through a
+   local domain by initiating a new RESERVE at the domain edge, and b)
+   defining a Local QSPEC and encapsulating the Initiator QSPEC, as
+   defined above.  However, it is not expected that both the hiding and
+   encapsulating functions would be used at the same time for the same
+   flow.
+
+   The support of Local QSPECs is illustrated in Figure 4 for a single
+   flow to show where the Initiator and Local QSPECs are used.  The QNI
+   initiates an end-to-end, inter-domain QoS NSLP RESERVE message
+   containing the Initiator QSPEC for the Y.1541 QOSM.  As illustrated
+   in Figure 4, the RESERVE message crosses multiple domains supporting
+   different QOSMs.  In this illustration, the Initiator QSPEC arrives
+   in a QoS NSLP RESERVE message at the ingress node of the local-QOSM
+   domain.  At the ingress edge node of the local-QOSM domain, the end-
+   to-end, inter-domain QoS-NSLP message triggers the generation of a
+   Local QSPEC, and the Initiator QSPEC is encapsulated within the
+   messages signaled through the local domain.  The local QSPEC is used
+   for QoS processing in the local-QOSM domain, and the Initiator QSPEC
+   is used for QoS processing outside the local domain.
+
+   In this example, the QNI sets <QoS Desired>, <Minimum QoS>, and <QoS
+   Available> objects to include objectives for the <Path Latency>,
+   <Path Jitter>, and <Path PER> parameters.  The QNE / local domain
+   sets the cumulative parameters, e.g., <Path Latency>, that can be
+   achieved in the <QoS Available> object (but not less than specified
+   in <Minimum QoS>).  If the <QoS Available> fails to satisfy one or
+
+
+
+Ash, et al.                   Experimental                     [Page 22]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   more of the <Minimum QoS> objectives, the QNE / local domain notifies
+   the QNI and the reservation is aborted.  If any QNE cannot meet the
+   requirements designated by the Initiator QSPEC to support a QSPEC
+   parameter with the M bit set to zero, the QNE sets the N flag for
+   that parameter to one.  Otherwise, the QNR notifies the QNI of the
+   <QoS Available> for the reservation.
+
+   |------|   |------|                           |------|   |------|
+   | e2e  |<->| e2e  |<------------------------->| e2e  |<->| e2e  |
+   | QOSM |   | QOSM |                           | QOSM |   | QOSM |
+   |      |   |------|   |-------|   |-------|   |------|   |      |
+   | NSLP |   | NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP |   | NSLP |
+   |Y.1541|   |local |   |local  |   |local  |   |local |   |Y.1541|
+   | QOSM |   | QOSM |   | QOSM  |   | QOSM  |   | QOSM |   | QOSM |
+   |------|   |------|   |-------|   |-------|   |------|   |------|
+   -----------------------------------------------------------------
+   |------|   |------|   |-------|   |-------|   |------|   |------|
+   | NTLP |<->| NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP |<->| NTLP |
+   |------|   |------|   |-------|   |-------|   |------|   |------|
+     QNI         QNE        QNE         QNE         QNE       QNR
+   (End)  (Ingress Edge) (Interior)  (Interior) (Egress Edge)  (End)
+
+     Figure 4: Example of Initiator and Local Domain QOSM Operation
+
+4.2.  Reservation Success/Failure, QSPEC Error Codes, and INFO-SPEC
+      Notification
+
+   A reservation may not be successful for several reasons:
+
+   - a reservation may fail because the desired resources are not
+     available.  This is a reservation failure condition.
+
+   - a reservation may fail because the QSPEC is erroneous or because of
+     a QNE fault.  This is an error condition.
+
+   A reservation may be successful even though some parameters could not
+   be interpreted or updated properly:
+
+   - a QSPEC parameter cannot be interpreted because it is an unknown
+     QSPEC parameter type.  This is a QSPEC parameter not supported
+     condition.  However, the reservation does not fail.  The QNI can
+     still decide whether to keep or tear down the reservation depending
+     on the procedures specified by the QNI's QOSM.
+
+   The following sections provide details on the handling of
+   unsuccessful reservations and reservations where some parameters
+   could not be met, as follows:
+
+
+
+
+Ash, et al.                   Experimental                     [Page 23]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   - details on flags used inside the QSPEC to convey information on
+     success or failure of individual parameters.  The formats and
+     semantics of all flags are given in Section 5.
+
+   - the content of the INFO-SPEC [RFC5974], which carries a code
+     indicating the outcome of reservations.
+
+   - the generation of a RESPONSE message to the QNI containing both
+     QSPEC and INFO-SPEC objects.
+
+   Note that when there are routers along the path between the QNI and
+   QNR where QoS cannot be provided, then the QoS-NSLP generic flag
+   BREAK (B) is set.  The BREAK flag is discussed in Section 3.3.5 of
+   [RFC5974].
+
+4.2.1.  Reservation Failure and Error E Flag
+
+   The QSPEC parameters each have a 'reservation failure error E flag'
+   to indicate which (if any) parameters could not be satisfied.  When a
+   resource cannot be satisfied for a particular parameter, the QNE
+   detecting the problem raises the E flag in this parameter.  Note that
+   the TMOD parameter and all QSPEC parameters with the M flag set MUST
+   be examined by the RMF, and all QSPEC parameters with the M flag not
+   set SHOULD be examined by the RMF, and the E flag set to indicate
+   whether the parameter could or could not be satisfied.  Additionally,
+   the E flag in the corresponding QSPEC object MUST be raised when a
+   resource cannot be satisfied for this parameter.  If the reservation
+   failure problem cannot be located at the parameter level, only the E
+   flag in the QSPEC object is raised.
+
+   When an RMF cannot interpret the QSPEC because the coding is
+   erroneous, it raises corresponding reservation failure E flags in the
+   QSPEC.  Normally, all QSPEC parameters MUST be examined by the RMF,
+   and the erroneous parameters appropriately flagged.  In some cases,
+   however, an error condition may occur and the E flag of the error-
+   causing QSPEC parameter is raised (if possible), but the processing
+   of further parameters may be aborted.
+
+   Note that if the QSPEC and/or any QSPEC parameter is found to be
+   erroneous, then any QSPEC parameters not satisfied are ignored and
+   the E Flags in the QSPEC object MUST NOT be set for those parameters
+   (unless they are erroneous).
+
+   Whether E flags denote reservation failure or error can be determined
+   by the corresponding error code in the INFO-SPEC in QoS NSLP, as
+   discussed below.
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 24]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+4.2.2.  QSPEC Parameter Not Supported N Flag
+
+   Each QSPEC parameter has an associated 'Not Supported N flag'.  If
+   the Not Supported N flag is set, then at least one QNE along the data
+   transmission path between the QNI and QNR cannot interpret the
+   specified QSPEC parameter.  A QNE MUST set the Not Supported N flag
+   if it cannot interpret the QSPEC parameter.  If the M flag for the
+   parameter is not set, the message should continue to be forwarded but
+   with the N flag set, and the QNI has the option of tearing down the
+   reservation.
+
+   If a QNE in the path does not support a QSPEC parameter, e.g., <Path
+   Latency>, and sets the N flag, then downstream QNEs that support the
+   parameter SHOULD still update the parameter, even if the N flag is
+   set.  However, the presence of the N flag will indicate that the
+   cumulative value only provides a bound, and the QNI/QNR decides
+   whether or not to accept the reservation with the N flag set.
+
+4.2.3.  INFO-SPEC Coding of Reservation Outcome
+
+   As prescribed by [RFC5974], the RESPONSE message always contains the
+   INFO-SPEC with an appropriate 'error' code.  It usually also contains
+   a QSPEC with QSPEC objects, as described in Section 4.3 ("QSPEC
+   Procedures").  The RESPONSE message MAY omit the QSPEC in case of a
+   successful reservation.
+
+   The following guidelines are provided for setting the error codes in
+   the INFO-SPEC, based on the codes provided in Section 5.1.3.6 of
+   [RFC5974]:
+
+   - NSLP error class 2 (Success) / 0x01 (Reservation Success):
+     This code is set when all QSPEC parameters have been satisfied.  In
+     this case, no E Flag is set; however, one or more N flags may be
+     set.
+
+   - NSLP error class 4 (Transient Failure) / 0x07 (Reservation
+     Failure):
+     This code is set when at least one QSPEC parameter could not be
+     satisfied, or when a QSPEC parameter with M flag set could not be
+     interpreted.  E flags are set for the parameters that could not be
+     satisfied at each QNE up to the QNE issuing the RESPONSE message.
+     The N flag is set for those parameters that could not be
+     interpreted by at least one QNE.  In this case, QNEs receiving the
+     RESPONSE message MUST remove the corresponding reservation.
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 25]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   - NSLP error class 3 (Protocol Error) / 0x0c (Malformed QSPEC):
+     Some QSPEC parameters had associated errors, E Flags are set for
+     parameters that had errors, and the QNE where the error was found
+     rejects the reservation.
+
+   - NSLP error class 3 (Protocol Error) / 0x0f (Incompatible QSPEC):
+     A higher version QSPEC is signaled and not supported by the QNE.
+
+   - NSLP error class 6 (QoS Model Error):
+     QOSM error codes can be defined by QOSM specification documents.  A
+     registry is defined in Section 7, IANA Considerations.
+
+4.2.4.  QNE Generation of a RESPONSE Message
+
+   - Successful Reservation Condition
+
+     When a RESERVE message arrives at a QNR and no E Flag is set, the
+     reservation is successful.  A RESPONSE message may be generated
+     with INFO-SPEC code 'Reservation Success' as described above and in
+     Section 4.3 ("QSPEC Procedures").
+
+   - Reservation Failure Condition
+
+     When a QNE detects that a reservation failure occurs for at least
+     one parameter, the QNE sets the E Flags for the QSPEC parameters
+     and QSPEC object that failed to be satisfied.  According to
+     [RFC5974], the QNE behavior depends on whether it is stateful or
+     not.  When a stateful QNE determines the reservation failed, it
+     formulates a RESPONSE message that includes an INFO-SPEC with the
+     'reservation failure' error code and QSPEC object.  The QSPEC in
+     the RESPONSE message includes the failed QSPEC parameters marked
+     with the E Flag to clearly identify them.
+
+     The default action for a stateless QoS NSLP QNE that detects a
+     reservation failure condition is that it MUST continue to forward
+     the RESERVE message to the next stateful QNE, with the E Flags
+     appropriately set for each QSPEC parameter.  The next stateful QNE
+     then formulates the RESPONSE message as described above.
+
+   - Malformed QSPEC Error Condition
+
+     When a stateful QNE detects that one or more QSPEC parameters are
+     erroneous, the QNE sets the error code 'malformed QSPEC' in the
+     INFO-SPEC.  In this case, the QSPEC object with the E Flags
+     appropriately set for the erroneous parameters is returned within
+     the INFO-SPEC object.  The QSPEC object can be truncated or fully
+     included within the INFO-SPEC.
+
+
+
+
+Ash, et al.                   Experimental                     [Page 26]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+     According to [RFC5974], the QNE behavior depends on whether it is
+     stateful or not.  When a stateful QNE determines a malformed QSPEC
+     error condition, it formulates a RESPONSE message that includes an
+     INFO-SPEC with the 'malformed QSPEC' error code and QSPEC object.
+
+     The QSPEC in the RESPONSE message includes, if possible, only the
+     erroneous QSPEC parameters and no others.  The erroneous QSPEC
+     parameter(s) are marked with the E Flag to clearly identify them.
+     If QSPEC parameters are returned in the INFO-SPEC that are not
+     marked with the E flag, then any values of these parameters are
+     irrelevant and MUST be ignored by the QNI.
+
+     The default action for a stateless QoS NSLP QNE that detects a
+     malformed QSPEC error condition is that it MUST continue to forward
+     the RESERVE message to the next stateful QNE, with the E Flags
+     appropriately set for each QSPEC parameter.  The next stateful QNE
+     will then act as described in [RFC5974].
+
+     A 'malformed QSPEC' error code takes precedence over the
+     'reservation failure' error code, and therefore the case of
+     reservation failure and QSPEC/RMF error conditions are disjoint,
+     and the same E Flag can be used in both cases without ambiguity.
+
+4.2.5.  Special Case of Local QSPEC
+
+     When an unsuccessful reservation problem occurs inside a local
+     domain where a Local QSPEC is used, only the topmost (local) QSPEC
+     is affected (e.g., E flags are raised, etc.).  The encapsulated
+     Initiator QSPEC is untouched.  However, when the message (RESPONSE
+     in case of stateful QNEs; RESERVE in case of stateless QNEs)
+     reaches the edge of the local domain, the Local QSPEC is removed.
+     The edge QNE must update the Initiator QSPEC on behalf of the
+     entire domain, reflecting the information received in the Local
+     QSPEC.  This update concerns both parameter values and flags.  Note
+     that some intelligence is needed in mapping the E flags, etc., from
+     the local QSPEC to the Initiator QSPEC.  For example, even if there
+     is no direct match between the parameters in the local and
+     Initiator QSPECs, E flags could still be raised in the latter.
+
+4.3.  QSPEC Procedures
+
+     While the QSPEC template aims to put minimal restrictions on usage
+     of QSPEC objects, interoperability between QNEs and between QOSMs
+     must be ensured.  We therefore give below an exhaustive list of
+     QSPEC object combinations for the message sequences described in
+     QoS NSLP [RFC5974].  A specific QOSM may prescribe that only a
+     subset of the procedures listed below may be used.
+
+
+
+
+Ash, et al.                   Experimental                     [Page 27]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+     Note that QoS NSLP does not mandate the usage of a RESPONSE
+     message.  A positive RESPONSE message will only be generated if the
+     QNE includes an RII (Request Identification Information) in the
+     RESERVE message, and a negative RESPONSE message is always
+     generated in case of an error or failure.  Some of the QSPEC
+     procedures below, however, are only meaningful when a RESPONSE
+     message is possible.  The QNI SHOULD in these cases include an RII.
+
+4.3.1.  Two-Way Transactions
+
+     Here, the QNI issues a RESERVE message, which may be replied to by
+     a RESPONSE message.  The following 3 cases for QSPEC object usage
+     exist:
+
+     MESSAGE  | OBJECT      | OBJECTS INCLUDED   | OBJECTS INCLUDED
+     SEQUENCE | COMBINATION | IN RESERVE MESSAGE | IN RESPONSE MESSAGE
+     -----------------------------------------------------------------
+     0        | 0           | QoS Desired        | QoS Reserved
+              |             |                    |
+     0        | 1           | QoS Desired        | QoS Reserved
+              |             | QoS Available      | QoS Available
+              |             |                    |
+     0        | 2           | QoS Desired        | QoS Reserved
+              |             | QoS Available      | QoS Available
+              |             | Minimum QoS        |
+
+       Table 1: Message Sequence 0: Two-Way Transactions
+                Defining Object Combinations 0, 1, and 2
+
+     Case 1:
+
+     If only QoS Desired is included in the RESERVE message, the
+     implicit assumption is that exactly these resources must be
+     reserved.  If this is not possible, the reservation fails.  The
+     parameters in QoS Reserved are copied from the parameters in QoS
+     Desired.  If the reservation is successful, the RESPONSE message
+     can be omitted in this case.  If a RESPONSE message was requested
+     by a QNE on the path, the QSPEC in the RESPONSE message can be
+     omitted.
+
+     Case 2:
+
+     When QoS Available is included in the RESERVE message also, some
+     parameters will appear only in QoS Available and not in QoS
+     Desired.  It is assumed that the value of these parameters is
+     collected for informational purposes only (e.g., path latency).
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 28]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+     However, some parameters in QoS Available can be the same as in QoS
+     Desired.  For these parameters, the implicit message is that the
+     QNI would be satisfied by a reservation with lower parameter values
+     than specified in QoS Desired.  For these parameters, the QNI seeds
+     the parameter values in QoS Available to those in QoS Desired
+     (except for cumulative parameters such as <Path Latency>).
+
+     Each QNE interprets the parameters in QoS Available according to
+     its current capabilities.  Reservations in each QNE are hence based
+     on current parameter values in QoS Available (and additionally
+     those parameters that only appear in QoS Desired).  The drawback of
+     this approach is that, if the resulting resource reservation
+     becomes gradually smaller towards the QNR, QNEs close to the QNI
+     have an oversized reservation, possibly resulting in unnecessary
+     costs for the user.  Of course, in the RESPONSE the QNI learns what
+     the actual reservation is (from the QoS RESERVED object) and can
+     immediately issue a properly sized refreshing RESERVE.  The
+     advantage of the approach is that the reservation is performed in
+     half-a-roundtrip time.
+
+     The QSPEC parameter IDs and values included in the QoS Reserved
+     object in the RESPONSE message MUST be the same as those in the QoS
+     Desired object in the RESERVE message.  For those QSPEC parameters
+     that were also included in the QoS Available object in the RESERVE
+     message, their value is copied from the QoS Available object (in
+     RESERVE) into the QoS Reserved object (in RESPONSE).  For the other
+     QSPEC parameters, the value is copied from the QoS Desired object
+     (the reservation would fail if the corresponding QoS could not be
+     reserved).
+
+     All parameters in the QoS Available object in the RESPONSE message
+     are copied with their values from the QoS Available object in the
+     RESERVE message (irrespective of whether they have also been copied
+     into the QoS Desired object).  Note that the parameters in the QoS
+     Available object can be overwritten in the RESERVE message, whereas
+     they cannot be overwritten in the RESPONSE message.
+
+     In this case, the QNI SHOULD request a RESPONSE message since it
+     will otherwise not learn what QoS is available.
+
+     Case 3:
+
+     This case is handled as case 2, except that the reservation fails
+     when QoS Available becomes less than Minimum QoS for one parameter.
+     If a parameter appears in the QoS Available object but not in the
+     Minimum QoS object, it is assumed that there is no minimum value
+     for this parameter.
+
+
+
+
+Ash, et al.                   Experimental                     [Page 29]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+     Regarding Traffic Handling Directives, the default rule is that all
+     QSPEC parameters that have been included in the RESERVE message by
+     the QNI are also included in the RESPONSE message by the QNR with
+     the value they had when arriving at the QNR.  When traveling in the
+     RESPONSE message, all Traffic Handling Directives parameters are
+     read-only.  Note that a QOSM specification may define its own
+     Traffic Handling Directives parameters and processing rules.
+
+4.3.2.  Three-Way Transactions
+
+     Here, the QNR issues a QUERY message that is replied to by the QNI
+     with a RESERVE message if the reservation was successful.  The QNR
+     in turn sends a RESPONSE message to the QNI.  The following 3 cases
+     for QSPEC object usage exist:
+
+     MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED   |OBJECTS INCLUDED
+     SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
+     -------------------------------------------------------------------
+     1   |0   |QoS Desired      |QoS Desired        |QoS Reserved
+         |    |                 |                   |
+     1   |1   |QoS Desired      |QoS Desired        |QoS Reserved
+         |    |(Minimum QoS)    |QoS Available      |QoS Available
+         |    |                 |(Minimum QoS)      |
+         |    |                 |                   |
+     1   |2   |QoS Desired      |QoS Desired        |QoS Reserved
+         |    |QoS Available    |QoS Available      |
+
+       Table 2: Message Sequence 1: Three-Way Transactions
+                Defining Object Combinations 0, 1, and 2
+
+     Cases 1 and 2:
+
+     The idea is that the sender (QNR in this scenario) needs to inform
+     the receiver (QNI in this scenario) about the QoS it desires.  To
+     this end, the sender sends a QUERY message to the receiver
+     including a QoS Desired QSPEC object.  If the QoS is negotiable, it
+     additionally includes a (possibly zero) Minimum QoS object, as in
+     Case 2.
+
+     The RESERVE message includes the QoS Available object if the sender
+     signaled that QoS is negotiable (i.e., it included the Minimum QoS
+     object).  If the Minimum QoS object received from the sender is
+     included in the QUERY message, the QNI also includes the Minimum
+     QoS object in the RESERVE message.
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 30]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+     For a successful reservation, the RESPONSE message in case 1 is
+     optional (as is the QSPEC inside).  In case 2, however, the
+     RESPONSE message is necessary in order for the QNI to learn about
+     the QoS available.
+
+     Case 3:
+
+     This is the 'RSVP-style' scenario.  The sender (QNR in this
+     scenario) issues a QUERY message with a QoS Desired object
+     informing the receiver (QNI in this scenario) about the QoS it
+     desires, as above.  It also includes a QoS Available object to
+     collect path properties.  Note that here path properties are
+     collected with the QUERY message, whereas in the previous case, 2
+     path properties were collected in the RESERVE message.
+
+     Some parameters in the QoS Available object may be the same as in
+     the QoS Desired object.  For these parameters, the implicit message
+     is that the sender would be satisfied by a reservation with lower
+     parameter values than specified in QoS Desired.
+
+     It is possible for the QoS Available object to contain parameters
+     that do not appear in the QoS Desired object.  It is assumed that
+     the value of these parameters is collected for informational
+     purposes only (e.g., path latency).  Parameter values in the QoS
+     Available object are seeded according to the sender's capabilities.
+     Each QNE remaps or approximately interprets the parameter values
+     according to its current capabilities.
+
+     The receiver (QNI in this scenario) signals the QoS Desired object
+     as follows: For those parameters that appear in both the QoS
+     Available object and QoS Desired object in the QUERY message, it
+     takes the (possibly remapped) QSPEC parameter values from the QoS
+     Available object.  For those parameters that only appear in the QoS
+     Desired object, it adopts the parameter values from the QoS Desired
+     object.
+
+     The parameters in the QoS Available QSPEC object in the RESERVE
+     message are copied with their values from the QoS Available QSPEC
+     object in the QUERY message.  Note that the parameters in the QoS
+     Available object can be overwritten in the QUERY message, whereas
+     they cannot be overwritten in the RESERVE message.
+
+     The advantage of this model compared to the sender-initiated
+     reservation is that the situation of over-reservation in QNEs close
+     to the QNI (as described above) does not occur.  On the other hand,
+     the QUERY message may find, for example, a particular bandwidth is
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 31]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+     not available.  When the actual reservation is performed, however,
+     the desired bandwidth may meanwhile have become free.  That is, the
+     'RSVP style' may result in a smaller reservation than necessary.
+
+     The sender includes all QSPEC parameters it cares about in the
+     QUERY message.  Parameters that can be overwritten are updated by
+     QNEs as the QUERY message travels towards the receiver.  The
+     receiver includes all QSPEC parameters arriving in the QUERY
+     message also in the RESERVE message, with the value they had when
+     arriving at the receiver.  Again, QOSM-specific QSPEC parameters
+     and procedures may be defined in QOSM specification documents.
+
+     Also in this scenario, the QNI SHOULD request a RESPONSE message
+     since it will otherwise not learn what QoS is available.
+
+     Regarding Traffic Handling Directives, the default rule is that all
+     QSPEC parameters that have been included in the RESERVE message by
+     the QNI are also included in the RESPONSE message by the QNR with
+     the value they had when arriving at the QNR.  When traveling in the
+     RESPONSE message, all Traffic Handling Directives parameters are
+     read-only.  Note that a QOSM specification may define its own
+     Traffic Handling Directives parameters and processing rules.
+
+4.3.3.  Resource Queries
+
+     Here, the QNI issues a QUERY message in order to investigate what
+     resources are currently available.  The QNR replies with a RESPONSE
+     message.
+
+     MESSAGE  | OBJECT      | OBJECTS INCLUDED   | OBJECTS INCLUDED
+     SEQUENCE | COMBINATION | IN QUERY MESSAGE   | IN RESPONSE MESSAGE
+     -----------------------------------------------------------------
+     2        | 0           | QoS Available      | QoS Available
+
+           Table 3: Message Sequence 2: Resource Queries
+                    Defining Object Combination 0
+
+     Note that the QoS Available object when traveling in the QUERY
+     message can be overwritten, whereas in the RESPONSE message it
+     cannot be overwritten.
+
+     Regarding Traffic Handling Directives, the default rule is that all
+     QSPEC parameters that have been included in the RESERVE message by
+     the QNI are also included in the RESPONSE message by the QNR with
+     the value they had when arriving at the QNR.  When traveling in the
+     RESPONSE message, all Traffic Handling Directives parameters are
+     read-only.  Note that a QOSM specification may define its own
+     Traffic Handling Directives parameters and processing rules.
+
+
+
+Ash, et al.                   Experimental                     [Page 32]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+4.3.4.  Bidirectional Reservations
+
+     On a QSPEC level, bidirectional reservations are no different from
+     unidirectional reservations, since QSPECs for different directions
+     never travel in the same message.
+
+4.3.5.  Preemption
+
+     A flow can be preempted by a QNE based on QNE policy, where a
+     decision to preempt a flow may account for various factors such as,
+     for example, the values of the QSPEC preemption priority and
+     defending priority parameters as described in Section 5.2.8.  In
+     this case, the reservation state for this flow is torn down in the
+     QNE, and the QNE sends a NOTIFY message to the QNI, as described in
+     [RFC5974].  The NOTIFY message carries an INFO-SPEC with the error
+     code as described in [RFC5974].  A QOSM specification document may
+     specify whether a NOTIFY message also carries a QSPEC object.  The
+     QNI would normally tear down the preempted reservation by sending a
+     RESERVE message with the TEAR flag set using the SII of the
+     preempted reservation.  However, the QNI can follow other
+     procedures as specified in its QOSM specification document.
+
+4.4.  QSPEC Extensibility
+
+     Additional QSPEC parameters MAY need to be defined in the future
+     and are defined in separate informational documents.  For example,
+     QSPEC parameters are defined in [RFC5977] and [RFC5976].
+
+     Guidelines on the technical criteria to be followed in evaluating
+     requests for new codepoint assignments for QSPEC objects and QSPEC
+     parameters are given in Section 7, IANA Considerations.
+
+5.  QSPEC Functional Specification
+
+     This section defines the encodings of the QSPEC parameters.  We
+     first give the general QSPEC formats and then the formats of the
+     QSPEC objects and parameters.
+
+     Network octet order ('big-endian') for all 16- and 32-bit integers,
+     as well as 32-bit floating point numbers, is as specified in
+     [RFC4506], [IEEE754], and [NETWORK-OCTET-ORDER].
+
+5.1.  General QSPEC Formats
+
+     The format of the QSPEC closely follows that used in GIST [RFC5971]
+     and QoS NSLP [RFC5974].  Every object (and parameter) has the
+     following general format:
+
+
+
+
+Ash, et al.                   Experimental                     [Page 33]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   o  The overall format is Type-Length-Value (in that order).
+
+   o  Some parts of the type field are set aside for control flags.
+
+   o  Length has the units of 32-bit words, and measures the length of
+      Value.  If there is no Value, Length=0.  The Object length
+      excludes the header.
+
+   o  Value is a whole number of 32-bit words.  If there is any padding
+      required, the length and location MUST be defined by the object-
+      specific format information; objects that contain variable-length
+      types may need to include additional length subfields to do so.
+
+   o  Any part of the object used for padding or defined as reserved
+      ("r") MUST be set to 0 on transmission and MUST be ignored on
+      reception.
+
+   o  Empty QSPECs and empty QSPEC Objects MUST NOT be used.
+
+   o  Duplicate objects, duplicate parameters, and/or multiple
+      occurrences of a parameter MUST NOT be used.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Common QSPEC Header                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      //                       QSPEC Objects                         //
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.1.1.  Common Header Format
+
+   The Common QSPEC Header is a fixed 4-octet object containing the
+   QSPEC Version, QSPEC Type, an identifier for the QSPEC Procedure (see
+   Section 4.3), and an Initiator/Local QSPEC bit:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vers.|I|QSPECType|r|r|  QSPEC Proc.  |        Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vers.: Identifies the QSPEC version number.  QSPEC Version 0 is
+          assigned by this specification in Section 7 (IANA
+          Considerations).
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 34]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   QSPEC Type: Identifies the particular type of QSPEC, e.g., a QSPEC
+               Type corresponding to a particular QOSM.  QSPEC Type 0
+               (default) is assigned by this specification in Section 7
+               (IANA Considerations).
+
+   QSPEC Proc.: Identifies the QSPEC procedure and is composed of two
+                times 4 bits.  The first field identifies the Message
+                Sequence; the second field identifies the QSPEC Object
+                Combination used for this particular message sequence:
+
+                 0 1 2 3 4 5 6 7
+                +-+-+-+-+-+-+-+-+
+                |Mes.Sq |Obj.Cmb|
+                +-+-+-+-+-+-+-+-+
+
+                The Message Sequence field can attain the following
+                values:
+
+                0: Sender-Initiated Reservations
+                1: Receiver-Initiated Reservations
+                2: Resource Queries
+
+                The Object Combination field can take the values between
+                1 and 3 indicated in the tables in Section 4.3:
+
+                Message Sequence: 0
+                Object Combination: 0, 1, 2
+                Semantic: see Table 1 in Section 4.3.1
+
+                Message Sequence: 1
+                Object Combination: 0, 1, 2
+                Semantic: see Table 2 in Section 4.3.2
+
+                Message Sequence: 2
+                Object Combination: 0
+                Semantic: see Table 3 in Section 4.3.3
+
+   I: Initiator/Local QSPEC bit identifies whether the QSPEC is an
+      initiator QSPEC or a Local QSPEC, and is set to the following
+      values:
+
+               0: Initiator QSPEC
+               1: Local QSPEC
+
+   Length: The total length of the QSPEC (in 32-bit words) excluding the
+           common header
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 35]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   The QSPEC Objects field is a collection of QSPEC objects (QoS
+   Desired, QoS Available, etc.), which share a common format and each
+   contain several parameters.
+
+5.1.2.  QSPEC Object Header Format
+
+   QSPEC objects share a common header format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |E|r|r|r|       Object Type     |r|r|r|r|         Length        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   E Flag: Set if an error occurs on object level
+
+   Object Type = 0: QoS Desired (parameters cannot be overwritten)
+               = 1: QoS Available (parameters may be overwritten; see
+                    Section 3.2)
+               = 2: QoS Reserved (parameters cannot be overwritten)
+               = 3: Minimum QoS (parameters cannot be overwritten)
+
+   The r bits are reserved.
+
+   Each QSPEC or QSPEC parameter within an object is encoded in the same
+   way in TLV format using a similar parameter header:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|     Parameter ID      |r|r|r|r|         Length        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   M Flag: When set, indicates the subsequent parameter MUST be
+           interpreted.  Otherwise, the parameter can be ignored if not
+           understood.
+
+   E Flag: When set, indicates either a) a reservation failure where the
+           QSPEC parameter is not met, or b) an error occurred when this
+           parameter was being interpreted (see Section 4.2.1).
+
+   N Flag: Not Supported QSPEC parameter flag (see Section 4.2.2).
+
+   Parameter ID: Assigned consecutively to each QSPEC parameter.
+                 Parameter IDs are assigned to each QSPEC parameter
+                 defined in this document in Sections 5.2 and 7 (IANA
+                 Considerations).
+
+
+
+
+Ash, et al.                   Experimental                     [Page 36]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Parameters are usually coded individually, for example, the <Excess
+   Treatment> parameter (Section 5.2.11).  However, it is also possible
+   to combine several sub-parameters into one parameter field, which is
+   called 'container coding'.  This coding is useful if either a) the
+   sub-parameters always occur together (as for example the 5 sub-
+   parameters that jointly make up the TMOD), or b) in order to make
+   coding more efficient when the length of each sub-parameter value is
+   much less than a 32-bit word (as for example described in [RFC5977])
+   and to avoid header overload.  When a container is defined, the
+   Parameter ID and the M, E, and N flags refer to the container.
+   Examples of container parameters are <TMOD> (specified below) and the
+   PHR (Per Hop Reservation) container parameter specified in [RFC5977].
+
+5.2.  QSPEC Parameter Coding
+
+   The references in the following sections point to the normative
+   procedures for processing the QSPEC parameters and sub-parameters.
+
+5.2.1.  <TMOD-1> Parameter
+
+   The <TMOD-1> parameter consists of the <r>, <b>, <p>, <m>, and <MPS>
+   sub-parameters [RFC2212], which all must be populated in the <TMOD-1>
+   parameter.  Note that a second TMOD QSPEC parameter <TMOD-2> is
+   specified below in Section 5.2.2.
+
+   The coding for the <TMOD-1> parameter is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |1|E|0|r|           1           |r|r|r|r|          5            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  TMOD Rate-1 (r) (32-bit IEEE floating point number)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  TMOD Size-1 (b) (32-bit IEEE floating point number)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Peak Data Rate-1 (p) (32-bit IEEE floating point number)     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Minimum Policed Unit-1 (m) (32-bit unsigned integer)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Maximum Packet Size-1 (MPS) (32-bit unsigned integer)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The <TMOD-1> parameters are represented by three floating point
+   numbers in single-precision IEEE floating point format [IEEE754]
+   followed by two 32-bit integers in network octet order.  The first
+   floating point value is the rate (r), the second floating point value
+   is the bucket size (b), the third floating point is the peak rate
+
+
+
+Ash, et al.                   Experimental                     [Page 37]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   (p), the first unsigned integer is the minimum policed unit (m), and
+   the second unsigned integer is the maximum packet size (MPS).  The
+   values of r and p are measured in octets per second; b, m, and MPS
+   are measured in octets.  When r, b, and p 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.
+
+5.2.2.  <TMOD-2> Parameter
+
+   A second QSPEC <TMOD-2> parameter is specified as could be needed,
+   for example, to support some Diffserv applications.
+
+   The coding for the <TMOD-2> parameter is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           2           |r|r|r|r|          5            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  TMOD Rate-2 (r) (32-bit IEEE floating point number)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  TMOD Size-2 (b) (32-bit IEEE floating point number)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Peak Data Rate-2 (p) (32-bit IEEE floating point number)     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Minimum Policed Unit-2 (m) (32-bit unsigned integer)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Maximum Packet Size-2 (MPS) (32-bit unsigned integer)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The <TMOD-2> parameters are represented by three floating point
+   numbers in single-precision IEEE floating point format [IEEE754]
+   followed by two 32-bit integers in network octet order.  The first
+   floating point value is the rate (r), the second floating point value
+   is the bucket size (b), the third floating point is the peak rate
+   (p), the first unsigned integer is the minimum policed unit (m), and
+   the second unsigned integer is the maximum packet size (MPS).  The
+   values of r and p are measured in octets per second; b, m, and MPS
+   are measured in octets.  When r, b, and p 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
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 38]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   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.
+
+5.2.3.  <Path Latency> Parameter
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           3           |r|r|r|r|          1            |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |                Path Latency (32-bit unsigned integer)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Path Latency [RFC2215] is a single 32-bit unsigned integer in
+   network octet order.  The intention of the Path Latency parameter is
+   the same as the Minimal Path Latency parameter defined in Section 3.4
+   of [RFC2215].  The purpose of this parameter is to provide a baseline
+   minimum path latency for use with services that provide estimates or
+   bounds on additional path delay, such as in [RFC2212].  Together with
+   the queuing delay bound offered by [RFC2212] and similar services,
+   this parameter gives the application knowledge of both the minimum
+   and maximum packet delivery delay.
+
+   The composition rule for the <Path Latency> parameter is summation
+   with a clamp of (2^32) - 1 on the maximum value.  The latencies are
+   average values reported in units of one microsecond.  A system with
+   resolution less than one microsecond MUST set unused digits to zero.
+   An individual QNE can add a latency value between 1 and 2^28
+   (somewhat over two minutes), and the total latency added across all
+   QNEs can range as high as (2^32)-2.  If the sum of the different
+   elements delays exceeds (2^32)-2, the end-to-end cumulative delay
+   SHOULD be reported as indeterminate = (2^32)-1.  A QNE that cannot
+   accurately predict the latency of packets it is processing MUST raise
+   the Not Supported N flag and either leave the value of Path Latency
+   as is, or add its best estimate of its lower bound.  A raised not-
+   supported flag indicates the value of Path Latency is a lower bound
+   of the real Path Latency.  The distinguished value (2^32)-1 is taken
+   to mean indeterminate latency because the composition function limits
+   the composed sum to this value; it indicates the range of the
+   composition calculation was exceeded.
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 39]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+5.2.4.  <Path Jitter> Parameter
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           4           |r|r|r|r|          4            |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |    Path Jitter STAT1(variance) (32-bit unsigned integer)      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer)     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Path Jitter STAT3(minimum Latency) (32-bit unsigned integer)  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Path Jitter STAT4(Reserved)     (32-bit unsigned integer)  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Path Jitter is a set of four 32-bit unsigned integers in network
+   octet order [RFC3393, Y.1540, Y.1541].  As noted in Section 3.3.2,
+   the Path Jitter parameter is called "IP Delay Variation" in
+   [RFC3393].  The Path Jitter parameter is the combination of four
+   statistics describing the Jitter distribution with a clamp of (2^32)
+   - 1 on the maximum of each value.  The jitter STATs are reported in
+   units of one microsecond.  A system with resolution less than one
+   microsecond MUST set unused digits to zero.  An individual QNE can
+   add jitter values between 1 and 2^28 (somewhat over two minutes), and
+   the total jitter computed across all QNEs can range as high as
+   (2^32)-2.  If the combination of the different element values exceeds
+   (2^32)-2, the end-to-end cumulative jitter SHOULD be reported as
+   indeterminate.  A QNE that cannot accurately predict the jitter of
+   packets it is processing MUST raise the not-supported flag and either
+   leave the value of Path Jitter as is, or add its best estimate of its
+   STAT values.  A raised not-supported flag indicates the value of Path
+   Jitter is a lower bound of the real Path Jitter.  The distinguished
+   value (2^32)-1 is taken to mean indeterminate jitter.  A QNE that
+   cannot accurately predict the jitter of packets it is processing
+   SHOULD set its local Path Jitter parameter to this value.  Because
+   the composition function limits the total to this value, receipt of
+   this value at a network element or application indicates that the
+   true Path Jitter is not known.  This MAY happen because one or more
+   network elements could not supply a value or because the range of the
+   composition calculation was exceeded.
+
+   NOTE: The Jitter composition function makes use of the <Path Latency>
+   parameter.  Composition functions for loss, latency, and jitter may
+   be found in [Y.1541].  Development continues on methods to combine
+   jitter values to estimate the value of the complete path, and
+   additional statistics may be needed to support new methods (the
+   methods are standardized in [RFC5481] and [COMPOSITION]).
+
+
+
+Ash, et al.                   Experimental                     [Page 40]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+5.2.5.  <Path PLR> Parameter
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           5           |r|r|r|r|          1            |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |             Path Packet Loss Ratio (32-bit floating point)    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Path PLR is a single 32-bit single precision IEEE floating point
+   number in network octet order [Y.1541].  As defined in [Y.1540], Path
+   PLR is the ratio of total lost IP packets to total transmitted IP
+   packets.  An evaluation interval of 1 minute is suggested in
+   [Y.1541], in which the number of losses observed is directly related
+   to the confidence in the result.  The composition rule for the <Path
+   PLR> parameter is summation with a clamp of 10^-1 on the maximum
+   value.  The PLRs are reported in units of 10^-11.  A system with
+   resolution less than 10^-11 MUST set unused digits to zero.  An
+   individual QNE adds its local PLR value (up to a maximum of 10^-2) to
+   the total Path PLR value (up to a maximum of 10^-1) , where the
+   acceptability of the total Path PLR value added across all QNEs is
+   determined based on the QOSM being used.  The maximum limit of 10^-2
+   on a QNE's local PLR value and the maximum limit (clamp value) of
+   10^-1 on the accumulated end-to-end Path PLR value are used to
+   preserve the accuracy of the simple additive accumulation function
+   specified and to avoid more complex accumulation functions.
+   Furthermore, if these maximums are exceeded, then the path would
+   likely not meet the QoS objectives.  If the sum of the different
+   elements' values exceeds 10^-1, the end-to-end cumulative PLR SHOULD
+   be reported as indeterminate.  A QNE that cannot accurately predict
+   the PLR of packets it is processing MUST raise the not-supported flag
+   and either leave the value of Path PLR as is, or add its best
+   estimate of its lower bound.  A raised not-supported flag indicates
+   the value of Path PLR is a lower bound of the real Path PLR.  The
+   distinguished value 10^-1 is taken to mean indeterminate PLR.  A QNE
+   that cannot accurately predict the PLR of packets it is processing
+   SHOULD set its local path PLR parameter to this value.  Because the
+   composition function limits the composed sum to this value, receipt
+   of this value at a network element or application indicates that the
+   true path PLR is not known.  This MAY happen because one or more
+   network elements could not supply a value or because the range of the
+   composition calculation was exceeded.
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 41]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+5.2.6.  <Path PER> Parameter
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           6           |r|r|r|r|          1            |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |             Path Packet Error Ratio (32-bit floating point)   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Path PER is a single 32-bit single precision IEEE floating point
+   number in network octet order [Y.1541].  As defined in [Y.1540], Path
+   PER is the ratio of total errored IP packets to the total of
+   successful IP Packets plus errored IP packets, in which the number of
+   errored packets observed is directly related to the confidence in the
+   result.  The composition rule for the <Path PER> parameter is
+   summation with a clamp of 10^-1 on the maximum value.  The PERs are
+   reported in units of 10^-11.  A system with resolution less than
+   10^-11 MUST set unused digits to zero.  An individual QNE adds its
+   local PER value (up to a maximum of 10^-2) to the total Path PER
+   value (up to a maximum of 10^-1) , where the acceptability of the
+   total Path PER value added across all QNEs is determined based on the
+   QOSM being used.  The maximum limit of 10^-2 on a QNE's local PER
+   value and the maximum limit (clamp value) of 10^-1 on the accumulated
+   end-to-end Path PER value are used to preserve the accuracy of the
+   simple additive accumulation function specified and to avoid more
+   complex accumulation functions.  Furthermore, if these maximums are
+   exceeded, then the path would likely not meet the QoS objectives.  If
+   the sum of the different elements' values exceeds 10^-1, the end-to-
+   end cumulative PER SHOULD be reported as indeterminate.  A QNE that
+   cannot accurately predict the PER of packets it is processing MUST
+   raise the Not Supported N flag and either leave the value of Path PER
+   as is, or add its best estimate of its lower bound.  A raised Not
+   Supported N flag indicates the value of Path PER is a lower bound of
+   the real Path PER.  The distinguished value 10^-1 is taken to mean
+   indeterminate PER.  A QNE that cannot accurately predict the PER of
+   packets it is processing SHOULD set its local path PER parameter to
+   this value.  Because the composition function limits the composed sum
+   to this value, receipt of this value at a network element or
+   application indicates that the true path PER is not known.  This MAY
+   happen because one or more network elements could not supply a value
+   or because the range of the composition calculation was exceeded.
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 42]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+5.2.7.  <Slack Term> Parameter
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           7           |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Slack Term (S)  (32-bit unsigned integer)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Slack term S MUST be nonnegative and is measured in microseconds
+   [RFC2212].  The Slack term, S, is represented as a 32-bit unsigned
+   integer.  Its value can range from 0 to (2^32)-1 microseconds.
+
+5.2.8.  <Preemption Priority> and <Defending Priority> Parameters
+
+   The coding for the <Preemption Priority> and <Defending Priority>
+   sub-parameters is as follows [RFC3181]:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           8           |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Preemption Priority        |      Defending Priority       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Preemption Priority: The priority of the new flow compared with the
+      defending priority of previously admitted flows.  Higher values
+      represent higher priority.
+
+   Defending Priority: Once a flow is admitted, the preemption priority
+      becomes irrelevant.  Instead, its defending priority is used to
+      compare with the preemption priority of new flows.
+
+   As specified in [RFC3181], <Preemption Priority> and <Defending
+   Priority> are 16-bit integer values, and both MUST be populated if
+   the parameter is used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 43]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+5.2.9.  <Admission Priority> Parameter
+
+   The coding for the <Admission Priority> parameter is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           9           |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Y.2171 Adm Pri.|Admis. Priority|        (Reserved)             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Two fields are provided for the <Admission Priority> parameter and
+   are populated according to the following rules.
+
+   <Y.2171 Admission Priority> values are globally significant on an
+   end-to-end basis.  High priority flows, normal priority flows, and
+   best-effort priority flows can have access to resources depending on
+   their admission priority value, as described in [Y.2171], as follows:
+
+   <Y.2171 Admission Priority>:
+
+   0 - best-effort priority flow
+   1 - normal priority flow
+   2 - high priority flow
+
+   If the QNI signals <Y.2171 Admission Priority>, it populates both the
+   <Y.2171 Admission Priority> and <Admission Priority> fields with the
+   same value.  Downstream QNEs MUST NOT change the value in the <Y.2171
+   Admission Priority> field so that end-to-end consistency is
+   maintained and MUST treat the flow priority according to the value
+   populated.  A QNE in a local domain MAY reset a different value of
+   <Admission Priority> in a Local QSPEC, but (as specified in Section
+   4.1) the Local QSPEC MUST be consistent with the Initiator QSPEC.
+   That is, the local domain MUST specify an <Admission Priority> in the
+   Local QSPEC that is functionally equivalent to the <Y.2171 Admission
+   Priority> specified by the QNI in the Initiator QSPEC.
+
+   If the QNI signals admission priority according to [EMERGENCY-RSVP],
+   it populates a locally significant value in the <Admission Priority>
+   field and places all ones in the <Y.2171 Admission Priority> field.
+   In this case, the functional significance of the <Admission Priority>
+   value is specified by the local network administrator.  Higher values
+   indicate higher priority.  Downstream QNEs and RSVP nodes MAY reset
+   the <Admission Priority> value according to the local rules specified
+   by the local network administrator, but MUST NOT reset the value of
+   the <Y.2171 Admission Priority> field.
+
+
+
+
+Ash, et al.                   Experimental                     [Page 44]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   A reservation without an <Y.2171 Admission Priority> parameter MUST
+   be treated as a reservation with an <Y.2171 Admission Priority> = 1.
+
+5.2.10.  <RPH Priority> Parameter
+
+   The coding for the <RPH Priority> parameter is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           10          |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         RPH Namespace         | RPH Priority  |   (Reserved)  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   [RFC4412] defines a resource priority header (RPH) with parameters
+   "RPH Namespace" and "RPH Priority", and if populated is applicable
+   only to flows with high admission priority.  A registry is created in
+   [RFC4412] and extended in [EMERG-RSVP] for IANA to assign the RPH
+   priority parameter.  In the extended registry, "Namespace Numerical
+   Values" are assigned by IANA to RPH Namespaces and "Priority
+   Numerical Values" are assigned to the RPH Priority.
+
+   Note that the <Admission Priority> parameter MAY be used in
+   combination with the <RPH Priority> parameter, which depends on the
+   supported QOSM.  Furthermore, if more than one RPH namespace is
+   supported by a QOSM, then the QOSM MUST specify how the mapping
+   between the priorities belonging to the different RPH namespaces are
+   mapped to each other.
+
+   Note also that additional work is needed to communicate these flow
+   priority values to bearer-level network elements
+   [VERTICAL-INTERFACE].
+
+   For the 4 priority parameters, the following cases are permissible
+   (procedures specified in references):
+
+   1 parameter:  <Admission Priority> [Y.2171]
+   2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
+   2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
+   3 parameters: <Preemption Priority>, <Defending Priority>,
+                 <Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
+   4 parameters: <Preemption Priority>, <Defending Priority>,
+                 <Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
+                 3GPP-3]
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 45]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   It is permissible to have <Admission Priority> without <RPH
+   Priority>, but not permissible to have <RPH Priority> without
+   <Admission Priority>.  (Alternatively, <RPH Priority> is ignored in
+   instances without <Admission Priority>.)
+
+   Functionality similar to enhanced Multi-Level Precedence and
+   Preemption service (eMLPP; as defined in [3GPP-1, 3GPP-2]) specifies
+   use of <Admission Priority> corresponding to the 'queuing allowed'
+   part of eMLPP, as well as <Preemption/Defending Priority>
+   corresponding to the 'preemption capable' and 'may be preempted'
+   parts of eMLPP.
+
+5.2.11.  <Excess Treatment> Parameter
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           11          |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Excess Trtmnt |Re-mark Val|             Reserved              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Excess Treatment: Indicates how the QNE SHOULD process out-of-profile
+      traffic, that is, traffic not covered by the <TMOD> parameter.
+      The Excess Treatment Parameter is set by the QNI.  Allowed values
+      are as follows:
+
+      0: drop
+      1: shape
+      2: re-mark
+      3: no metering or policing is permitted
+
+      If no Excess Treatment Parameter is specified, the default is that
+      there are no guarantees to excess traffic, i.e., a QNE can do
+      whatever it finds suitable.
+
+      When excess treatment is set to 'drop', all marked traffic MUST be
+      dropped by the QNE/RMF.
+
+      When excess treatment is set to 'shape', it is expected that the
+      QoS Desired object carries a TMOD parameter, and excess traffic is
+      shaped to this TMOD.  The bucket size in the TMOD parameter for
+      excess traffic specifies the queuing behavior, and when the
+      shaping causes unbounded queue growth at the shaper, any traffic
+      in excess of the TMOD for excess traffic SHOULD be dropped.  If
+      excess treatment is set to 'shape' and no TMOD parameter is given,
+      the E flag is set for the parameter and the reservation fails.  If
+
+
+
+
+Ash, et al.                   Experimental                     [Page 46]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+      excess treatment is set to 'shape' and two TMOD parameters are
+      specified, then the QOSM specification dictates how excess traffic
+      should be shaped in that case.
+
+      When excess treatment is set to 're-mark', the Excess Treatment
+      Parameter MUST carry the re-mark value, and the re-mark values and
+      procedures MUST be specified in the QOSM specification document.
+      For example, packets may be re-marked to pertain to a particular
+      QoS class (Diffserv Code Point (DSCP) value).  In the latter case,
+      re-marking relates to a Diffserv model where packets arrive marked
+      as belonging to a certain QoS class / DSCP, and when they are
+      identified as excess, they should then be re-marked to a different
+      QoS Class (DSCP value) indicated in the 'Re-mark Value', as
+      follows:
+
+   Re-mark Value (6 bits): indicates DSCP value [RFC2474] to re-mark
+      packets to when identified as excess
+
+   If 'no metering or policing is permitted' is signaled, the QNE should
+   accept the Excess Treatment Parameter set by the sender with special
+   care so that excess traffic should not cause a problem.  To request
+   the Null Meter [RFC3290] is especially strong, and should be used
+   with caution.
+
+   A NULL metering application [RFC2997] would not include the traffic
+   profile, and conceptually it should be possible to support this with
+   the QSPEC.  A QSPEC without a traffic profile is not excluded by the
+   current specification.  However, note that the traffic profile is
+   important even in those cases when the excess treatment is not
+   specified, e.g., in negotiating bandwidth for the best-effort
+   aggregate.  However, a "NULL Service QOSM" would need to be specified
+   where the desired QNE Behavior and the corresponding QSPEC format are
+   described.
+
+   As an example behavior for a NULL metering, in the properly
+   configured Diffserv router, the resources are shared between the
+   aggregates by the scheduling disciplines.  Thus, if the incoming rate
+   increases, it will influence the state of a queue within that
+   aggregate, while all the other aggregates will be provided sufficient
+   bandwidth resources.  NULL metering is useful for best-effort and
+   signaling data, where there is no need to meter and police this data
+   as it will be policed implicitly by the allocated bandwidth and,
+   possibly, active queue management mechanism.
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 47]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+5.2.12.  <PHB Class> Parameter
+
+   The coding for the <PHB Class> parameter is as follows [RFC3140]:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           12          |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           PHB Field           |            (Reserved)         |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   The above encoding is consistent with [RFC3140], and the following
+   four figures show four possible formats based on the value of the PHB
+   Field.
+
+   Single PHB:
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | DSCP      |0 0 0 0 0 0 0 0 0 0|
+      +---+---+---+---+---+---+---+---+
+
+   Set of PHBs:
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | DSCP      |0 0 0 0 0 0 0 0 1 0|
+      +---+---+---+---+---+---+---+---+
+
+   PHBs not defined by standards action, i.e., experimental or local use
+   PHBs as allowed by [RFC2474].  In this case, an arbitrary 12-bit PHB
+   identification code, assigned by the IANA, is placed left-justified
+   in the 16-bit field.  Bit 15 is set to 1, and bit 14 is zero for a
+   single PHB or 1 for a set of PHBs.  Bits 12 and 13 are zero.
+
+   Single non-standard PHB (experimental or local):
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      PHB ID CODE      |0 0 0 1|
+      +---+---+---+---+---+---+---+---+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 48]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Set of non-standard PHBs (experimental or local):
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      PHB ID CODE      |0 0 1 1|
+      +---+---+---+---+---+---+---+---+
+
+   Bits 12 and 13 are reserved either for expansion of the PHB
+   identification code, or for other use, at some point in the future.
+
+   In both cases, when a single PHBID is used to identify a set of PHBs
+   (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB
+   Scheduling Class (i.e., use of PHBs from the set MUST NOT cause
+   intra-microflow traffic reordering when different PHBs from the set
+   are applied to traffic in the same microflow).  The set of AF1x PHBs
+   [RFC2597] is an example of a PHB Scheduling Class.  Sets of PHBs that
+   do not constitute a PHB Scheduling Class can be identified by using
+   more than one PHBID.
+
+   The registries needed to use RFC 3140 already exist; see
+   [DSCP-REGISTRY] and [PHBID-CODES-REGISTRY].  Hence, no new registry
+   needs to be created for this purpose.
+
+5.2.13.  <DSTE Class Type> Parameter
+
+   A description of the semantic of the parameter values can be found in
+   [RFC4124].  The coding for the <DSTE Class Type> parameter is as
+   follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           13          |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |DSTE Cls. Type |                (Reserved)                     |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   DSTE Class Type: Indicates the DSTE class type.  Values currently
+   allowed are 0, 1, 2, 3, 4, 5, 6, and 7.
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 49]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+5.2.14.  <Y.1541 QoS Class> Parameter
+
+   The coding for the <Y.1541 QoS Class> parameter [Y.1541] is as
+   follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|E|N|r|           14          |r|r|r|r|          1            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Y.1541 QoS Cls.|                (Reserved)                     |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   Y.1541 QoS Class: Indicates the Y.1541 QoS Class.  Values currently
+   allowed are 0, 1, 2, 3, 4, 5, 6, and 7.
+
+      Class 0:
+      Real-time, highly interactive applications, sensitive to jitter.
+      Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <=
+      10^-3.  Application examples include VoIP and video
+      teleconference.
+
+      Class 1:
+      Real-time, interactive applications, sensitive to jitter.  Mean
+      delay <= 400 ms, delay variation <= 50 ms, and loss ratio <=
+      10^-3.  Application examples include VoIP and video
+      teleconference.
+
+      Class 2:
+      Highly interactive transaction data.  Mean delay <= 100 ms, delay
+      variation is unspecified, loss ratio <= 10^-3.  Application
+      examples include signaling.
+
+      Class 3:
+      Interactive transaction data.  Mean delay <= 400 ms, delay
+      variation is unspecified, loss ratio <= 10^-3.  Application
+      examples include signaling.
+
+      Class 4:
+      Low Loss Only applications.  Mean delay <= 1 s, delay variation is
+      unspecified, loss ratio <= 10^-3.  Application examples include
+      short transactions, bulk data, and video streaming.
+
+      Class 5:
+      Unspecified applications with unspecified mean delay, delay
+      variation, and loss ratio.  Application examples include
+      traditional applications of default IP networks.
+
+
+
+
+Ash, et al.                   Experimental                     [Page 50]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+      Class 6:
+      Applications that are highly sensitive to loss.  Mean delay <= 100
+      ms, delay variation <= 50 ms, and loss ratio <= 10^-5.
+      Application examples include television transport, high-capacity
+      TCP transfers, and Time-Division Multiplexing (TDM) circuit
+      emulation.
+
+      Class 7:
+      Applications that are highly sensitive to loss.  Mean delay <= 400
+      ms, delay variation <= 50 ms, and loss ratio <= 10^-5.
+      Application examples include television transport, high-capacity
+      TCP transfers, and TDM circuit emulation.
+
+6.  Security Considerations
+
+   QSPEC security is directly tied to QoS NSLP security, and the QoS
+   NSLP document [RFC5974] has a very detailed security discussion in
+   Section 7.  All the considerations detailed in Section 7 of [RFC5974]
+   apply to QSPEC.
+
+   The priority parameter raises possibilities for theft-of-service
+   attacks because users could claim an emergency priority for their
+   flows without real need, thereby effectively preventing serious
+   emergency calls to get through.  Several options exist for countering
+   such attacks, for example:
+
+   - only some user groups (e.g., the police) are authorized to set the
+     emergency priority bit
+
+   - any user is authorized to employ the emergency priority bit for
+     particular destination addresses (e.g., police)
+
+7.  IANA Considerations
+
+   This section defines the registries and initial codepoint assignments
+   for the QSPEC template, in accordance with BCP 26, RFC 5226
+   [RFC5226].  It also defines the procedural requirements to be
+   followed by IANA in allocating new codepoints.
+
+   This specification creates the following registries with the
+   structures as defined below:
+
+   Object Types (12 bits):
+   The following values are allocated as specified in Section 5:
+      0: QoS Desired
+      1: QoS Available
+      2: QoS Reserved
+      3: Minimum QoS
+
+
+
+Ash, et al.                   Experimental                     [Page 51]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Further values are as follows:
+      4-63: Unassigned
+      64-67: Private/Experimental Use
+      68-4095: Reserved
+      (Note: 'Reserved' just means 'do not give these out'.)
+   The registration procedure is Specification Required.
+
+   QSPEC Version (4 bits):
+   The following value is allocated by this specification:
+      0: Version 0 QSPEC
+   Further values are as follows:
+      1-15: Unassigned
+   The registration procedure is Specification Required.  (A
+   specification is required to depreciate, delete, or modify QSPEC
+   versions.)
+
+   QSPEC Type (5 bits):
+   The following values are allocated by this specification:
+      0: Default
+      1: Y.1541-QOSM [RFC5976]
+      2: RMD-QOSM [RFC5977]
+   Further values are as follows:
+      3-12: Unassigned
+      13-16: Local/Experimental Use
+      17-31: Reserved
+   The registration procedure is Specification Required.
+
+   QSPEC Procedure (8 bits):
+   The QSPEC Procedure object consists of the Message Sequence parameter
+   (4 bits) and the Object Combination parameter (4 bits), as discussed
+   in Section 4.3.  Message Sequences 0 (Two-Way Transactions), 1
+   (Three-Way Transactions), and 2 (Resource Queries) are explained in
+   Sections 4.3.1, 4.3.2, and 4.3.3, respectively.  Tables 1, 2, and 3
+   in Section 4.3 assign the Object Combination Number to Message
+   Sequences 0, 1, and 2, respectively.  The values assigned by this
+   specification for the Message Sequence parameter and the Object
+   Combination parameter are summarized here:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 52]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED   |OBJECTS INCLUDED
+   SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
+   -------------------------------------------------------------------
+   0   |0   |N/A              |QoS Desired        |QoS Reserved
+       |    |                 |                   |
+   0   |1   |N/A              |QoS Desired        |QoS Reserved
+       |    |N/A              |QoS Available      |QoS Available
+       |    |                 |                   |
+   0   |2   |N/A              |QoS Desired        |QoS Reserved
+       |    |N/A              |QoS Available      |QoS Available
+       |    |N/A              |Minimum QoS        |
+       |    |                 |                   |
+   1   |0   |QoS Desired      |QoS Desired        |QoS Reserved
+       |    |                 |                   |
+   1   |1   |QoS Desired      |QoS Desired        |QoS Reserved
+       |    |(Minimum QoS)    |QoS Available      |QoS Available
+       |    |                 |(Minimum QoS)      |
+       |    |                 |                   |
+   1   |2   |QoS Desired      |QoS Desired        |QoS Reserved
+       |    |QoS Available    |QoS Available      |
+       |    |                 |                   |
+   2   |0   |QoS Available    |N/A                |QoS Available
+
+   Further values of the Message Sequence parameter (4 bits) are as
+   follows:
+      3-15: Unassigned
+
+   Further values of the Object Combination parameter (4 bits) are as
+   follows:
+
+      Message  | Object
+      Sequence | Combination
+      ---------------------------
+        0      | 3-15: Unassigned
+        1      | 3-15: Unassigned
+        2      | 1-15: Unassigned
+        3-15   | 0-15: Unassigned
+
+   The registration procedure is Specification Required.  (A
+   specification is required to depreciate, delete, or modify QSPEC
+   Procedures.)
+
+   QoS Model Error Code (8 bits):
+   QoS Model Error Codes may be defined for NSLP error class 6 (QoS
+   Model Error), as described in Section 6.4 of [RFC5974].  Values are
+   as follows:
+      0-63: Unassigned
+      64-67: Private/Experimental Use
+
+
+
+Ash, et al.                   Experimental                     [Page 53]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+      68-255: Reserved
+   The registration procedure is Specification Required.  (A
+   specification is required to depreciate, delete, or modify QoS Model
+   Error Codes.)
+
+   Parameter ID (12 bits):
+   The following values are allocated by this specification:
+   1-14: assigned as specified in Section 5.2:
+      1: <TMOD-1>
+      2: <TMOD-2>
+      3: <Path Latency>
+      4: <Path Jitter>
+      5: <Path PLR>
+      6: <Path PER>
+      7: <Slack Term>
+      8: <Preemption Priority> and <Defending Priority>
+      9: <Admission Priority>
+      10: <RPH Priority>
+      11: <Excess Treatment>
+      12: <PHB Class>
+      13: <DSTE Class Type>
+      14: <Y.1541 QoS Class>
+   Further values are as follows:
+      15-255: Unassigned
+      256-259: Private/Experimental Use
+      260-4095: Reserved
+   The registration procedure is Specification Required. (A
+   specification is required to depreciate, delete, or modify Parameter
+   IDs.)
+
+   Y.2171 Admission Priority Parameter (8 bits):
+   The following values are allocated by this specification:
+   0-2: assigned as specified in Section 5.2.9:
+      0: best-effort priority flow
+      1: normal priority flow
+      2: high priority flow
+   Further values are as follows:
+      3-63: Unassigned
+      64-255: Reserved
+   The registration procedure is Specification Required.
+
+   RPH Namespace Parameter (16 bits):
+   Note that [RFC4412] creates a registry for RPH Namespace and Priority
+   values already (see Section 12.6 of [RFC4412]), and an extension to
+   this registry is created in [EMERG-RSVP], which will also be used for
+   the QSPEC RPH parameter.  In the extended registry, "Namespace
+   Numerical Values" are assigned by IANA to RPH Namespaces, and
+
+
+
+
+Ash, et al.                   Experimental                     [Page 54]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   "Priority Numerical Values" are assigned to the RPH Priority.  There
+   are no additional IANA requirements made by this specification for
+   the RPH Namespace Parameter.
+
+   Excess Treatment Parameter (8 bits):
+   The following values are allocated by this specification:
+   0-3: assigned as specified in Section 5.2.11:
+      0: drop
+      1: shape
+      2: re-mark
+      3: no metering or policing is permitted
+   Further values are as follows:
+      4-63: Unassigned
+      64-255: Reserved
+   The registration procedure is Specification Required.
+
+   Y.1541 QoS Class Parameter (8 bits):
+   The following values are allocated by this specification:
+   0-7: assigned as specified in Section 5.2.14:
+      0: Y.1541 QoS Class 0
+      1: Y.1541 QoS Class 1
+      2: Y.1541 QoS Class 2
+      3: Y.1541 QoS Class 3
+      4: Y.1541 QoS Class 4
+      5: Y.1541 QoS Class 5
+      6: Y.1541 QoS Class 6
+      7: Y.1541 QoS Class 7
+   Further values are as follows:
+      8-63: Unassigned
+      64-255: Reserved
+   The registration procedure is Specification Required.
+
+8.  Acknowledgements
+
+   The authors would like to thank (in alphabetical order) David Black,
+   Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger
+   Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock,
+   Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Tom Phelan,
+   James Polk, Alexander Sayenko, John Rosenberg, Hannes Tschofenig, and
+   Sven van den Bosch for their very helpful suggestions.
+
+9.  Contributors
+
+   This document is the result of the NSIS Working Group effort.  In
+   addition to the authors/editors listed in Section 12, the following
+   people contributed to the document:
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 55]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Roland Bless
+   Institute of Telematics, Karlsruhe Institute of Technology (KIT)
+   Zirkel 2, Building 20.20
+   P.O. Box 6980
+   Karlsruhe  76049
+   Germany
+   Phone: +49 721 608 6413
+   EMail: bless@kit.edu
+   URI: http://tm.kit.edu/~bless
+
+   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
+   EMail: cdvorak@research.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
+
+   Georgios Karagiannis
+   University of Twente
+   P.O. BOX 217
+   7500 AE Enschede
+   The Netherlands
+   EMail: g.karagiannis@ewi.utwente.nl
+
+   Andrew McDonald
+   Siemens/Roke Manor Research
+   Roke Manor Research Ltd.
+   Romsey, Hants SO51 0ZN
+   UK
+   EMail: andrew.mcdonald@roke.co.uk
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 56]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   Al Morton
+   AT&T
+   Room D3-3C06
+   200 S. Laurel Avenue
+   Middletown, NJ 07748
+   Phone: +1 732 420-1571
+   Fax: +1 732 368-1192
+   EMail: acmorton@att.com
+
+   Bernd Schloer
+   University of Goettingen
+   EMail: bschloer@cs.uni-goettingen.de
+
+   Percy Tarapore
+   AT&T
+   Room D1-33
+   200 S. Laurel Avenue
+   Middletown, NJ 07748
+   Phone: +1 732 420-4172
+   EMail: tarapore@.att.com
+
+   Lars Westberg
+   Ericsson Research
+   Torshamnsgatan 23
+   SE-164 80 Stockholm, Sweden
+   EMail: Lars.Westberg@ericsson.com
+
+10.  Normative References
+
+   [3GPP-1]        3GPP TS 22.067 V7.0.0 (2006-03) Technical
+                   Specification, 3rd Generation Partnership Project;
+                   Technical Specification Group Services and System
+                   Aspects; enhanced Multi Level Precedence and
+                   Preemption service (eMLPP) - Stage 1 (Release 7).
+
+   [3GPP-2]        3GPP TS 23.067 V7.1.0 (2006-03) Technical
+                   Specification, 3rd Generation Partnership Project;
+                   Technical Specification Group Core Network; enhanced
+                   Multi-Level Precedence and Preemption service (eMLPP)
+                   - Stage 2 (Release 7).
+
+   [3GPP-3]        3GPP TS 24.067 V6.0.0 (2004-12) Technical
+                   Specification, 3rd Generation Partnership Project;
+                   Technical Specification Group Core Network; enhanced
+                   Multi-Level Precedence and Preemption service (eMLPP)
+                   - Stage 3 (Release 6).
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 57]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2210]       Wroclawski, J., "The Use of RSVP with IETF Integrated
+                   Services", RFC 2210, September 1997.
+
+   [RFC2212]       Shenker, S., Partridge, C., and R. Guerin,
+                   "Specification of Guaranteed Quality of Service", RFC
+                   2212, September 1997.
+
+   [RFC2215]       Shenker, S. and J. Wroclawski, "General
+                   Characterization Parameters for Integrated Service
+                   Network Elements", RFC 2215, September 1997.
+
+   [RFC3140]       Black, D., Brim, S., Carpenter, B., and F. Le
+                   Faucheur, "Per Hop Behavior Identification Codes",
+                   RFC 3140, June 2001.
+
+   [RFC3181]       Herzog, S., "Signaled Preemption Priority Policy
+                   Element", RFC 3181, October 2001.
+
+   [RFC4124]       Le Faucheur, F., Ed., "Protocol Extensions for
+                   Support of Diffserv-aware MPLS Traffic Engineering",
+                   RFC 4124, June 2005.
+
+   [RFC4412]       Schulzrinne, H. and J. Polk, "Communications Resource
+                   Priority for the Session Initiation Protocol (SIP)",
+                   RFC 4412, February 2006.
+
+   [RFC4506]       Eisler, M., Ed., "XDR: External Data Representation
+                   Standard", STD 67, RFC 4506, May 2006.
+
+   [RFC5971]       Schulzrinne, H. and R. Hancock, "GIST: General
+                   Internet Signalling Transport", RFC 5971, October
+                   2010.
+
+   [RFC5974]       Manner, J., Karagiannis, G., and A. McDonald, "NSIS
+                   Signaling Layer Protocol (NSLP) for Quality-of-
+                   Service Signaling", RFC 5974, October 2010.
+
+   [Y.1541]        ITU-T Recommendation Y.1541, "Network Performance
+                   Objectives for IP-Based Services", February 2006.
+
+   [Y.2171]        ITU-T Recommendation Y.2171, "Admission Control
+                   Priority Levels in Next Generation Networks",
+                   September 2006.
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 58]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+11.  Informative References
+
+   [COMPOSITION]   Morton, A. and E. Stephan, "Spacial Composition of
+                   Metrics", Work in Progress, July 2010.
+
+   [DQOS]          CableLabs, "PacketCable Dynamic Quality of Service
+                   Specification", CableLabs Specification
+                   PKT-SP-DQOS-I12-050812, August 2005.
+
+   [EMERG-RSVP]    Le Faucheur, F., Polk, J., and K. Carlberg, "Resource
+                   ReSerVation Protocol (RSVP) Extensions for Admission
+                   Priority", Work in Progress, March 2010.
+
+   [G.711]         ITU-T Recommendation G.711, "Pulse code modulation
+                   (PCM) of voice frequencies", November 1988.
+
+   [IEEE754]       Institute of Electrical and Electronics Engineers,
+                   "IEEE Standard for Binary Floating-Point Arithmetic",
+                   ANSI/IEEE Standard 754-1985, August 1985.
+
+   [CL-QOSM]       Kappler, C., "A QoS Model for Signaling IntServ
+                   Controlled-Load Service with NSIS", Work in Progress,
+                   April 2010.
+
+   [DSCP-REGISTRY] IANA, "Differentiated Services Field Codepoints",
+                   http://www.iana.org.
+
+   [NETWORK-OCTET-ORDER]
+                   Wikipedia, "Endianness",
+                   http://en.wikipedia.org/wiki/Endianness.
+
+   [PHBID-CODES-REGISTRY]
+                   IANA, "Per Hop Behavior Identification Codes",
+                   http://www.iana.org.
+
+   [RFC1701]       Hanks, S., Li, T., Farinacci, D., and P. Traina,
+                   "Generic Routing Encapsulation (GRE)", RFC 1701,
+                   October 1994.
+
+   [RFC1702]       Hanks, S., Li, T., Farinacci, D., and P. Traina,
+                   "Generic Routing Encapsulation over IPv4 networks",
+                   RFC 1702, October 1994.
+
+   [RFC2003]       Perkins, C., "IP Encapsulation within IP", RFC 2003,
+                   October 1996.
+
+   [RFC2004]       Perkins, C., "Minimal Encapsulation within IP", RFC
+                   2004, October 1996.
+
+
+
+Ash, et al.                   Experimental                     [Page 59]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   [RFC2205]       Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
+                   and S. Jamin, "Resource ReSerVation Protocol (RSVP)
+                   -- Version 1 Functional Specification", RFC 2205,
+                   September 1997.
+
+   [RFC2473]       Conta, A. and S. Deering, "Generic Packet Tunneling
+                   in IPv6 Specification", RFC 2473, December 1998.
+
+   [RFC2474]       Nichols, K., Blake, S., Baker, F., and D. Black,
+                   "Definition of the Differentiated Services Field (DS
+                   Field) in the IPv4 and IPv6 Headers", RFC 2474,
+                   December 1998.
+
+   [RFC2475]       Blake, S., Black, D., Carlson, M., Davies, E., Wang,
+                   Z., and W. Weiss, "An Architecture for Differentiated
+                   Service", RFC 2475, December 1998.
+
+   [RFC2597]       Heinanen, J., Baker, F., Weiss, W., and J.
+                   Wroclawski, "Assured Forwarding PHB Group", RFC 2597,
+                   June 1999.
+
+   [RFC2697]       Heinanen, J. and R. Guerin, "A Single Rate Three
+                   Color Marker", RFC 2697, September 1999.
+
+   [RFC2997]       Bernet, Y., Smith, A., and B. Davie, "Specification
+                   of the Null Service Type", RFC 2997, November 2000.
+
+   [RFC3290]       Bernet, Y., Blake, S., Grossman, D., and A. Smith,
+                   "An Informal Management Model for Diffserv Routers",
+                   RFC 3290, May 2002.
+
+   [RFC3393]       Demichelis, C. and P. Chimento, "IP Packet Delay
+                   Variation Metric for IP Performance Metrics (IPPM)",
+                   RFC 3393, November 2002.
+
+   [RFC3550]       Schulzrinne, H., Casner, S., Frederick, R., and V.
+                   Jacobson, "RTP: A Transport Protocol for Real-Time
+                   Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3564]       Le Faucheur, F. and W. Lai, "Requirements for Support
+                   of Differentiated Services-aware MPLS Traffic
+                   Engineering", RFC 3564, July 2003.
+
+   [RFC4213]       Nordmark, E. and R. Gilligan, "Basic Transition
+                   Mechanisms for IPv6 Hosts and Routers", RFC 4213,
+                   October 2005.
+
+   [RFC4301]       Kent, S. and K. Seo, "Security Architecture for the
+
+
+
+Ash, et al.                   Experimental                     [Page 60]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+                   Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4303]       Kent, S., "IP Encapsulating Security Payload (ESP)",
+                   RFC 4303, December 2005.
+
+   [RFC5226]       Narten, T. and H. Alvestrand, "Guidelines for Writing
+                   an IANA Considerations Section in RFCs", BCP 26, RFC
+                   5226, May 2008.
+
+   [RFC5481]       Morton, A. and B. Claise, "Packet Delay Variation
+                   Applicability Statement", RFC 5481, March 2009.
+
+   [RFC5976]       Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak,
+                   C., and Y.  El Mghazli, "Y.1541-QOSM: Model for
+                   Networks Using Y.1541 Quality-of-Service Classes",
+                   RFC 5976, October 2010.
+
+   [RFC5977]       Bader, A., Westberg, L., Karagiannis, G., Kappler, C,
+                   and T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service
+                   Model for Resource Management in Diffserv", RFC 5977,
+                   October 2010.
+
+   [VERTICAL-INTERFACE]
+                   Dolly, M., Tarapore, P., and S. Sayers, "Discussion
+                   on Associating of Control Signaling Messages with
+                   Media Priority Levels", T1S1.7 and PRQC, October
+                   2004.
+
+   [Y.1540]        ITU-T Recommendation Y.1540, "Internet Protocol Data
+                   Communication Service - IP Packet Transfer and
+                   Availability Performance Parameters", December 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 61]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+Appendix A.  Mapping of QoS Desired, QoS Available, and QoS Reserved of
+             NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ
+
+   The union of QoS Desired, QoS Available, and QoS Reserved can provide
+   all functionality of the objects specified in RSVP IntServ; however,
+   it is difficult to provide an exact mapping.
+
+   In RSVP, the Sender TSpec specifies the traffic an application is
+   going to send (e.g., TMOD).  The AdSpec can collect path
+   characteristics (e.g., delay).  Both are issued by the sender.  The
+   receiver sends the FlowSpec that includes a Receiver TSpec describing
+   the resources reserved using the same parameters as the Sender TSpec,
+   as well as an RSpec that provides additional IntServ QoS Model
+   specific parameters, e.g., Rate and Slack.
+
+   The RSVP TSpec, AdSpec, and RSpec are tailored to the receiver-
+   initiated signaling employed by RSVP and the IntServ QoS Model.  For
+   example, to the knowledge of the authors, it is not possible for the
+   sender to specify a desired maximum delay except implicitly and
+   mutably by seeding the AdSpec accordingly.  Likewise, the RSpec is
+   only meaningfully sent in the receiver-issued RSVP RESERVE message.
+   For this reason, our discussion at this point leads us to a slightly
+   different mapping of necessary functionality to objects, which should
+   result in more flexible signaling models.
+
+Appendix B.  Example of TMOD Parameter Encoding
+
+   In an example VoIP application that uses RTP [RFC3550] and the G.711
+   Codec [G.711], the TMOD-1 parameter could be set as follows:
+
+   In the simplest case, the Minimum Policed Unit m is the sum of the
+   IP, UDP, and RTP headers + payload.  The IP header in the IPv4 case
+   has a size of 20 octets (40 octets if IPv6 is used).  The UDP header
+   has a size of 8 octets, and RTP uses a 12-octet header.  The G.711
+   Codec specifies a bandwidth of 64 kbit/s (8000 octets/s).  Assuming
+   RTP transmits voice datagrams every 20 ms, the payload for one
+   datagram is 8000 octets/s * 0.02 s = 160 octets.
+
+   IPv4 + UDP + RTP + payload: m = 20 + 8 + 12 + 160 octets = 200 octets
+   IPv6 + UDP + RTP + payload: m = 40 + 8 + 12 + 160 octets = 220 octets
+
+   The Rate r specifies the amount of octets per second.  50 datagrams
+   are sent per second.
+
+   IPv4: r = 50 1/s * m = 10,000 octets/s
+   IPv6: r = 50 1/s * m = 11,000 octets/s
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 62]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+   The bucket size b specifies the maximum burst.  In this example, a
+   burst of 10 packets is used.
+
+   IPv4: b = 10 * m = 2000 octets
+   IPv6: b = 10 * m = 2200 octets
+
+   A number of extra headers (e.g., for encapsulation) may be included
+   in the datagram.  A non-exhaustive list is given below.  For
+   additional headers, m, r, and b have to be set accordingly.
+
+   Protocol Header Size
+   --------------------------+------------
+   GRE [RFC1701]             |    8 octets
+   GREIP4 [RFC1702]          |  4-8 octets
+   IP4INIP4 [RFC2003]        |   20 octets
+   MINENC [RFC2004]          | 8-12 octets
+   IP6GEN [RFC2473]          |   40 octets
+   IP6INIP4 [RFC4213]        |   20 octets
+   IPsec [RFC4301, RFC4303]  |    variable
+   --------------------------+------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 63]
+
+RFC 5975                 QoS NSLP QSPEC Template            October 2010
+
+
+Authors' Addresses
+
+   Gerald Ash (Editor)
+   AT&T
+   EMail: gash5107@yahoo.com
+
+
+   Attila Bader (Editor)
+   Traffic Lab
+   Ericsson Research
+   Ericsson Hungary Ltd.
+   Laborc u. 1 H-1037
+   Budapest Hungary
+   EMail: Attila.Bader@ericsson.com
+
+
+   Cornelia Kappler (Editor)
+   ck technology concepts
+   Berlin, Germany
+   EMail: cornelia.kappler@cktecc.de
+
+
+   David R. Oran (Editor)
+   Cisco Systems, Inc.
+   7 Ladyslipper Lane
+   Acton, MA 01720, USA
+   EMail:  oran@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash, et al.                   Experimental                     [Page 64]
+