GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5975

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:
  1. role of QNEs, e.g., location, frequency, statefulness, etc.
  2. QSPEC definition including QSPEC parameters
  3. QSPEC procedures applicable to this QOSM
  4. 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:
  1. definitions of additional QOSM-specific error codes, as discussed

in Section 4.2.3

  1. 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:
  1. the QNE just leaves the QSPEC as is.

Ash, et al. Experimental [Page 18] RFC 5975 QoS NSLP QSPEC Template October 2010

  1. 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).
  1. 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:
  1. a reservation may fail because the desired resources are not

available. This is a reservation failure condition.

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

  1. 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.
  1. the content of the INFO-SPEC [RFC5974], which carries a code

indicating the outcome of reservations.

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

  1. 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.
  1. NSLP error class 3 (Protocol Error) / 0x0f (Incompatible QSPEC):

A higher version QSPEC is signaled and not supported by the QNE.

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

  1. 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").
  1. 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.
  1. 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:
  1. only some user groups (e.g., the police) are authorized to set the

emergency priority bit

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc5975.txt · Last modified: 2010/10/06 17:51 (external edit)