IETF Internet Draft NSIS Working Group                        Jerry Ash
Internet Draft                                                     AT&T
<draft-ietf-nsis-qspec-04.txt>                             Attila Bader
Expiration Date: November 2005                                 Ericsson
                                                       Cornelia Kappler
                                                             Siemens AG

                                                               May 2005


                         QoS-NSLP QSPEC Template

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 26, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The QoS NSLP protocol 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 draft defines a template for
   the QSPEC, which contains both the QoS description and QSPEC control
   information. The QSPEC format is defined, as are a number of QSPEC
   parameters.  The QSPEC parameters provide a common language to be
   re-used in several QOSMs.  To a certain extent QSPEC parameters

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 1]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   ensure interoperability of QOSMs.  Optional QSPEC parameters aim to
   ensure the extensibility of QoS NSLP to other QOSMs in the future.
   The node initiating the NSIS signaling adds an Initiator QSPEC that
   must not be removed, thereby ensuring the intention of the NSIS
   initiator is preserved along the signaling path.

Table of Contents

   1. Conventions Used in This Document . . . . . . . . . . . . . . . 3
   2. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4. QSPEC Parameters, Processing, & Extensibility . . . . . . . . . 5
      4.1 QSPEC Parameters  . . . . . . . . . . . . . . . . . . . . . 5
      4.2 QSPEC Processing  . . . . . . . . . . . . . . . . . . . . . 6
      4.3 Example of NSLP QSPEC Operation . . . . . . . . . . . . . . 8
      4.4 Treatment of QSPEC Parameters   . . . . . . . . . . . . . . 11
          4.4.1 Mandatory & Optional QSPEC Parameters . . . . . . . . 11
          4.4.2 Read-only and Read-write QSPEC Parameters . . . . . . 11
      4.5 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 12
   5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 12
      5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 13
      5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 13
          5.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . 13
          5.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . 14
          5.2.3 QoS Reserved  . . . . . . . . . . . . . . . . . . . . 17
          5.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . 17
   6. QSPEC Functional Specification  . . . . . . . . . . . . . . . . 17
      6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 18
      6.2 <Excess Treatment> Parameter  . . . . . . . . . . . . . . . 18
      6.3 <Bandwidth> & <S> Parameters  . . . . . . . . . . . . . . . 19
      6.4 <Token Bucket> Parameters . . . . . . . . . . . . . . . . . 19
      6.5 <QoS Class> Parameters  . . . . . . . . . . . . . . . . . . 20
          6.5.1 <PHB Class> Parameter . . . . . . . . . . . . . . . . 20
          6.5.2 <Y.1541 QoS Class> Parameter  . . . . . . . . . . . . 21
          6.5.3 <DSTE Class Type> Parameter . . . . . . . . . . . . . 22
      6.6 <Priority> Parameters . . . . . . . . . . . . . . . . . . . 22
          6.6.1 <Preemption Priority> & <Defending Priority>
                Parameters  . . . . . . . . . . . . . . . . . . . . . 22
          6.6.2 <Reservation Priority> Parameter  . . . . . . . . . . 23
      6.7 <Path Latency> Parameter  . . . . . . . . . . . . . . . . . 24
      6.8 <Path Jitter> Parameter . . . . . . . . . . . . . . . . . . 25
      6.9 <Path BER> Parameter  . . . . . . . . . . . . . . . . . . . 25
      6.10 <Ctot> <Dtot> <Csum> <Dsum> Parameters . . . . . . . . . . 26
      6.11 <Path Latency Flag>, <Path Jitter Flag>,
           <Path BER Flag>, <Ctot Flag>, <Dtot Flag>, <Csum Flag>,
           <Dsum Flag> <Slack Term Flag>  . . . . . . . . . . . . . . 27
   7. QSPEC Procedures & Examples . . . . . . . . . . . . . . . . . . 29
      7.1 QSPEC Procedures  . . . . . . . . . . . . . . . . . . . . . 29
          7.1.1 Sender-Initiated Reservations . . . . . . . . . . . . 29
          7.1.2 Receiver-Initiated Reservations . . . . . . . . . . . 30
          7.1.3 Setting Optional Parameter Flags  . . . . . . . . . . 31
      7.2 QOSM & QSPEC Examples . . . . . . . . . . . . . . . . . . . 31
          7.2.1 QOSM & QSPEC for DiffServ Admission Control . . . . . 31
          7.2.2 QOSM & QSPEC for IntServ Controlled Load Service  . . 33

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 2]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


          7.2.3 QOSM & QSPEC for IntServ Guaranteed Services  . . . . 33
   8. Security Considerations   . . . . . . . . . . . . . . . . . . . 34
   9. IANA Considerations   . . . . . . . . . . . . . . . . . . . . . 34
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
   11. Normative References   . . . . . . . . . . . . . . . . . . . . 34
   12. Informative References   . . . . . . . . . . . . . . . . . . . 35
   13. Authors' Addresses   . . . . . . . . . . . . . . . . . . . . . 36
   Appendix A QoS Models and QSPECs . . . . . . . . . . . . . . . . . 37
   Appendix B Mapping of QoS Desired, QoS Available, and QoS
   Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ . . 38
   Intellectual Property Statement  . . . . . . . . . . . . . . . . . 38
   Full Copyright Notice  . . . . . . . . . . . . . . . . . . . . . . 39
   Disclaimer of Validity   . . . . . . . . . . . . . . . . . . . . . 39

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

   The QoS NSLP establishes and maintains state at nodes along the path
   of a data flow for the purpose of providing forwarding resources
   (QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually
   similar to RSVP [RFC2205], and meets the requirements of [RFC3726].

   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.  It defines the behavior
   of the resource management function (RMF), including inputs and
   outputs, and how QSPEC information is interpreted on traffic
   description, resources required, resources available, and control
   information required by the RMF.  A QOSM also specifies a set of
   mandatory and optional QSPEC parameters that describe the QoS and how
   resources will be managed by the RMF.  QoS NSLP can support signaling
   for different QOSMs, such as for IntServ, DiffServ admission control,
   and those specified in [Y.1541-QOSM, INTSERV-QOSM, RMD-QOSM].  For
   more information on QOSMs see Section 7.2 and Appendix A.

   One of the major differences between RSVP and QoS-NSLP is that
   QoS-NSLP supports signaling for different QOSMs along the data path,
   all with one signaling message.  For example, the data path may start
   in a domain supporting DiffServ and end in a domain supporting
   Y.1541.  However, because some typical QoS parameters are
   standardized and can be reused in different QOSMs, some degree of
   interoperability between QOSMs exists.

   The QSPEC travels in QoS-NSLP messages and is opaque to the
   QoS NSLP.  The content of the QSPEC is QOSM specific.  Since
   QoS-NSLP signaling operation can be different for different QOSMs,

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 3]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   the QSPEC contains two kinds of information, QSPEC control
   information and QoS description.

   QSPEC control information contains parameters that governs the RMF.
   An example of QSPEC control information is how the excess traffic is
   treated in the RMF queuing functions.

   The QoS description is composed of QSPEC objects loosely
   corresponding to the TSpec, RSpec and AdSpec objects specified in
   RSVP.  This is, the QSPEC may contain a description of QoS desired
   and QoS reserved.  It can also collect information about available
   resources.  Going beyond RSVP functionality, the QoS description
   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.

3. Terminology

   Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD populate
   if applicable to the underlying QOSM and a QNE MUST interpret, if
   populated.

   Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by
   any QNE.  Together with a description of QoS Desired or QoS
   Available, it 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.

   Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate
   if applicable to the underlying QOSM, and a QNE SHOULD interpret if
   populated and applicable to the QOSM(s) supported by the QNE. (A QNE
   MAY ignore if it does not support a QOSM needing the optional QSPEC
   parameter).

   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 Description: Describes the actual QoS in QSPEC objects QoS
   Desired, QoS Available, QoS Reserved, and Minimum QoS.  These QSPEC
   objects are input or output parameters of the RMF.  In a valid QSPEC,
   at least one QSPEC object of the type QoS Desired, QoS Available or
   QoS Reserved MUST be included.

   QoS Available: QSPEC object containing parameters describing the
   available resources.  They are used to collect information along a

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 4]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   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.  A QOSM specifies a set of mandatory and
   optional QSPEC parameters that describe the QoS and how resources
   will be managed by the RMF. It furthermore specifies how to use QoS
   NSLP to signal for this QOSM.

   QoS Reserved: QSPEC object containing parameters describing the
   reserved resources and related QoS parameters, for example,
   bandwidth.

   QSPEC Control Information: Control information that is specific to a
   QSPEC, and contains parameters that govern the RMF.

   QSPEC: QSPEC is the object of QoS-NSLP containing all QOSM-specific
   information.

   QSPEC parameter: Any parameter appearing in a QSPEC; includes both
   QoS description and QSPEC control information parameters, for
   example, bandwidth, token bucket, and excess treatment parameters.

   QSPEC Object: Main building blocks of QoS Description containing a
   parameter set that is input or output of an RMF operation.

   Resource Management Function (RMF): Functions that are related to
   resource management, specific to a QOSM.  It processes the QoS
   description parameters and QSPEC control parameters.

   Read-only Parameter: Parameter that is set by initiating or
   responding QNE and is not changed during the processing of the QSPEC
   along the path.

   Read-write Parameter: Parameter that can be changed during the
   processing of the QSPEC by any QNE along the path.

4. QSPEC Parameters, Processing, & Extensibility

4.1 QSPEC Parameters

   The definition of a QOSM includes the specification of how the
   requested QoS resources will be described and how they will be
   managed by the RMF.  For this purpose, the QOSM specifies a set of
   QSPEC parameters that describe the QoS and QoS resource control in
   the RMF.  A given QOSM defines which of the mandatory and optional
   QSPEC parameters it uses, and it MAY define additional optional QSPEC
   parameters.  Mandatory and optional QSPEC parameters provide a common
   language for QOSM developers to build their QSPECs and are likely to

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 5]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   be re-used in several QOSMs.  Mandatory and optional QSPEC parameters
   are defined in this document, and additional optional QSPEC
   parameters can be defined in separate documents.  Specification of
   additional optional QSPEC parameters requires standards action, as
   defined in Section 4.5.

4.2 QSPEC Processing

   The QSPEC is opaque to the QoS-NSLP processing.  The QSPEC control
   information and the QoS description are interpreted and MAY be
   modified by the RMF in a QNE (see description in [QoS-SIG]).

   A QoS-enabled domain supports a particular QOSM, e.g. DiffServ
   admission control.  If this domain supports QoS-NSLP signaling, its
   QNEs MUST support the DiffServ admission control QOSM. The QNEs MAY
   also support additional QOSMs.

   A QoS NSLP message can contain a stack of 2 or more QSPECs (note: it
   is an open issue in QoS-NSLP if more than 2 QSPECs are allowed in the
   stack).  The first on the stack is the Initiator QSPEC.  This is a
   QSPEC provided by the QNI, which travels end-to-end, and therefore
   the stack always has at least depth 1.  QSPEC parameters MUST NOT be
   deleted from or added to the Initiator QSPEC.  In addition, the stack
   MAY contain a Local QSPEC stacked on top of the Initiator QSPEC.  A
   QNE only considers the topmost QSPEC.

   At the ingress edge of a local QoS domain, a Local QSPEC MAY be
   pushed on the stack in order to describe the requested resources in a
   domain-specific manner.  Also, the Local QSPEC is popped from the
   stack at the egress edge of the local QoS domain.

   This draft provides a template for the QSPEC, which is needed in
   order to help define individual QOSMs and in order to promote
   interoperability between QOSMs.  Figure 1 illustrates how the QSPEC
   is composed of QSPEC control information and QoS description.  QoS
   description in turn is composed of up to four QSPEC objects (not all
   of them need to be present), namely QoS desired, QoS available, QoS
   reserved and Minimum QoS.  Each of these QSPEC objects, as well as
   QSPEC control information, consists of a number of mandatory and
   optional QSPEC parameters.


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 6]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   +-------------+---------------------------------------+
   |QSPEC Control|              QoS                      |
   | Information |           Description                 |
   +-------------+---------------------------------------+

                 \________________ ______________________/
                                  V
                 +----------+----------+---------+-------+ \
                 |QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|  > QSPEC
                 +----------+----------+---------+-------+ / Objects

   \_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/
           V          V         V          V        V

    +-------------+...     +-------------+...
    |QSPEC Para. 1|        |QSPEC Para. n|
    +-------------+...     +-------------+...

                  Figure 1: Structure of the QSPEC

   The internal structure of each QSPEC object and the QSPEC control
   information, with mandatory and optional parameters, is illustrated
   in Figure 2.

   +------------------+-----------------+---------------+
   |QSPEC Parameter ID| Mandatory QSPEC |Optional QSPEC |
   |                  |   Parameters    | Parameters    |
   +------------------+-----------------+---------------+

   Figure 2: Structure of QSPEC Objects & Control Information


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 7]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


4.3 Example of NSLP/QSPEC Operation

   This Section illustrates the operation and use of the QSPEC within
   the NSLP.  The example configuration in shown in Figure 3.

+----------+      /-------\       /--------\       /--------\
| Laptop   |     |   Home  |     |  Cable   |     | DiffServ |
| Computer |-----| Network |-----| Network  |-----| Network  |----+
+----------+     | No QOSM |     |DQOS QOSM |     | RMD QOSM |    |
                  \-------/       \--------/       \--------/     |
                                                                  |
                  +-----------------------------------------------+
                  |
                  |    /--------\      +----------+
                  |   |  "X"G    |     | Handheld |
                  +---| Wireless |-----|  Device  |
                      | XG QOSM  |     +----------+
                       \--------/

      Figure 3: Example Configuration to Illustrate 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.
   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 'CMS to CMS Signaling Specification' [CMSS]
   for cable access networks.  That network is connected to a DiffServ
   core network that uses the RMD QOSM [RMD-QOSM].  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 handheld device is the QNR.

   The QNI will populate an Initiator QSPEC to achieve the QoS desired
   on the path.  In this example we consider two different ways to
   signal for QoS:

   Case 1) The QNI sets <QoS Desired>, <Available QoS> and possibly
   <Minimum QoS> QSPEC objects in the Initiator QSPEC, and initializes
   <QoS Available> to <QoS Desired>.  Since this is a reservation in a
   heterogenic network with different QOSMs supported in different
   domains, each QNE on the path reads and interprets those parameters
   in the Initiator QSPEC that it needs to implement the QOSM within its
   domain (as described below). Each QNE along the path checks to see if
   <QoS Available> resources can be reserved, and if not, the QNE

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 8]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   reduces the parameter values in <QoS Available> and reserves these
   values.  The minimum parameter values are given in <Minimum QoS>, if
   populated, otherwise zero if <Minimum QoS> is not included.  If the
   <Available QoS> fails to satisfy one or more of the objectives, the
   QNE notifies the QNI and the reservation is aborted.  Otherwise, the
   QNR notifies the QNI of the <QoS Available> for the reservation.

   Case 2) The QNI populated the Initiator QSPEC with <QoS Desired>.
   Since this is a reservation in a heterogenic network with different
   QOSMs supported in different domains, each QNE on the path reads and
   interprets those parameters in the Initiator QSPEC that it needs to
   implement the QOSM within its domain (as described below).  If a QNE
   cannot reserve <QoS Desired> resources, the reservation fails.

   In both cases, the QNI populates mandatory and optional QSPEC to
   ensure correct treatment of its traffic in domains down the path.
   Since the QNI does not know the QOSM used in downstream domains, it
   includes values for those mandatory and optional QSPEC parameters it
   cares about.  Let us assume the QNI wants to achieve IntServ-like QoS
   guarantees, and also is interested in what path latency it can
   achieve.  The QNI therefore includes in the QSPEC the QOSM ID for
   IntServ Controlled Load Service. The QSPEC objects are populated with
   all parameters necessary for IntServ Controlled Load and additionally
   to enable the QoS Class parameter to be derived, as follows:

   <QoS Desired> = <Token Bucket>
   <QoS Available> = <Token Bucket> <Path Latency>

   In both cases, each QNE on the path reads and interprets those
   parameters in the Initiator QSPEC that it needs to implement the QOSM
   within its domain.  It may need additional parameters for its QOSM,
   which are not specified in the Initiator QSPEC.  These parameters
   must be inferred from those that are present according to rules
   defined in the QOSM implemented by this QNE.

   There are two possibilities when a RESERVE message is received at a
   QNE at a domain border (we illustrate both possibilities in the
   example):

   - the QNE can stack a local QSPEC on top of the Initiator QSPEC (this
   is new in QoS NSLP, RSVP does not do this).

   - the QNE can tunnel the RESERVE message through its domain and issue
   its own RESERVE message.  For this new RESERVE message, the QNE acts
   as the QNI, and the QSPEC in the domain is an Initiator QSPEC.  This
   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 interdomain (per-flow) RESERVE, but the aggregate
   reservation is updated by the border QNE (QNI) as need be.  This is
   also how RMD works [RMD-QOSM].


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 9]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   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 [QoS-SIG] and in [RMD-QOSM].  That is, the ingress QNE
   to the RMD domain must map the QSPEC parameters contained in the
   original Initiator QSPEC into the RMD QSPEC.  The RMD QSPEC for
   example needs <Bandwidth> and <QoS Class>.  <Bandwidth> is generated
   from the <Token Bucket> parameter.  Information on <QoS Class>,
   however, is not provided.  According to the rules laid out in the RMD
   QOSM, the ingress QNE infers from the fact that an IntServ Controlled
   Load QOSM was signaled that the EF PHB is appropriate to set the <PHB
   Class> parameter.  These RMD QSPEC parameters are populated in the
   RMD Initiator QSPEC generated within the RMD domain.

   Furthermore, the node at the egress to the RMD domain updates <QoS
   Available> on behalf of the entire RMD domain.  It must have the
   knowledge to update the mandatory parameters <Bandwidth> and <MTU>.
   If it happens to additionally support the optional parameter <Path
   Latency>, it also updates it.  Otherwise it sets a <Path Latency
   Flag> parameter specific to the <Path Latency> parameter warning the
   QNR that the final value in <Path Latency> is a lower bound.

   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, that is, the
   translated Initiator QSPEC becomes the first (Local) QSPEC, and the
   Initiator QSPEC is second.  This saves the QNEs within the XG domain
   the trouble of re-translating the Initiator QSPEC.  At the egress
   edge of the XG domain, the translated Local QSPEC is popped, 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
   would have aborted the RESERVE and sent an error RESPONSE back to the
   QNI). The QNR generates a positive RESPONSE with QSPEC objects <QoS
   Reserved> - and for case 1 - additionally <QoS Available>.  The
   parameters appearing in <QoS Reserved> are the same as in <QoS
   Desired>, with values copied from <QoS Available> in case 1, and with
   the original values from <QoS Desired> in case 2. The <QoS Available>
   QSPEC object is copied from the RESERVE message except that the
   parameters that also appear in <QoS Desired> are deleted because they
   are redundant.  That is, it is not necessary to transport the <QoS
   Desired> object back to the QNI since the QNI knows what it signaled
   originally, and the information is not useful for QNEs in the reverse
   direction.  The <QoS Reserved> object should transport all necessary
   information, although the <QoS Available> and <QoS Reserved> objects
   may end up transporting some of the same information.

   Hence, the QNR populates the following QSPEC objects:


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 10]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   <QoS Reserved> = <Token Bucket> <QoS Class>
   <QoS Available> = <MTU> <QoS Class> <Path Latency>

   If the handheld device on the right of Figure 3 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 [QoS-SIG].

4.4 Treatment of QSPEC Parameters

4.4.1 Mandatory and Optional QSPEC Parameters

   Mandatory and optional QSPEC parameters are defined in this document
   and are applicable to a number of QOSMs.  Mandatory QSPEC parameters
   are treated as follows:

   o A QNI SHOULD populate mandatory QSPEC parameters if applicable to
     the underlying QOSM.
   o QNEs MUST interpret mandatory QSPEC parameters, if populated.

   Optional QSPEC parameters are treated as follows:

   o A QNI SHOULD populate optional QSPEC parameters if applicable to
     the QOSM for which it is signaling.

   o QNEs SHOULD interpret optional QSPEC parameters, if populated and
     applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore
     the optional QSPEC parameter if it does not support a QOSM needing
     the optional QSPEC parameter).

4.4.2 Read-only and Read-write QSPEC Parameters

   Both mandatory and optional QSPEC parameters can be read-only or
   read-write. Read-write parameters can be changed by any QNE, whereas
   read-only parameters are fixed by the QNI and/or QNR. For example in
   a RESERVE message, all parameters in <QoS Available> are read-write
   parameters, which are updated by intermediate QNEs.  Read-only
   parameters are, for example, all parameters in <QoS Desired> as sent
   by the QNI.

   QoS description parameters can be both read-only or read-write,
   depending on which QSPEC object, and which message, they appear in.

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 11]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   In particular, all parameters in <QoS Desired> and <Minimum QoS> are
   read-only for all messages.  Parameters in <QoS Available> are
   read-write in a RESERVE and QUERY message, and they are read-only in
   a RESPONSE or NOTIFY message.  Parameters in <QoS Reserved> are
   read-write in a RESERVE message, and read-only in a response message.


   If it needs to be ensured that read-only parameters are indeed not
   changed along the path, it is possible to apply selective protection
   of these parameters only.  The verification is based on cryptographic
   procedures.  Future versions of this draft will contain more details.

   In the QSPEC Control Information Object, the property of being
   read-write or read-only is parameter specific.

4.5 QSPEC Extensibility

   Additional optional QSPEC parameters MAY need to be defined in the
   future.  Additional optional QSPEC parameters are defined in separate
   Informational documents specific to a given QOSM.  For example,
   optional QSPEC parameters are defined in [RMD-QOSM] and
   [Y.1541-QOSM].

5. QSPEC Format Overview

   QSPEC = <QSPEC Control Information> <QoS Description>

   As described above, the QSPEC contains the actual resource
   description (QoS description) as well as QSPEC control information.
   Note that all QSPEC parameters defined in the following Sections are
   mandatory QSPEC parameters unless specifically designated as optional
   QSPEC parameters.  Each optional QSPEC parameter has an associated
   flag.  If such a flag is set, at least one QNE along the data
   transmission path between the QNI and QNR can not support the
   specified optional parameter.

   A QSPEC object ID identifies whether the object is <QSPEC Control
   Information> or <QoS Description>.  As described below, the <QoS
   Description is further broken down into <QoS Desired>, <QoS
   Available>, <QoS Reserved>, and <Minimum QoS> objects.  A QSPEC
   parameter ID is assigned to identify each QSPEC parameter defined
   below.

   A QOSM ID is included in the QSPEC and tells a QNE which parameters
   to expect.  This may simplify processing and error analysis.
   Furthermore, it may be helpful for a QNE or a domain supporting more
   than one QOSM to learn which QOSM the QNI would like to have in order
   to use the most suitable QOSM.  Note that the QSPEC parameters do not
   uniquely define the QNI QOSM since more parameters than required by
   the QNI QOSM can be included by the QNI.


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 12]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


5.1. QSPEC Control Information

   QSPEC control information is used for signaling QOSM RMF functions
   not defined in QoS-NSLP.  It enables building new RMF functions
   required by a QOSM within a QoS-NSLP signaling framework, such as
   specified, for example, in [RMD-QOSM] and [Y.1541-QOSM].

   <QSPEC Control Information> = <QOSM Hops> <NON QOSM Hop>
                                 <Excess Treatment>

   Note that <QOSM Hops> and <NON QOSM Hop> are read-write parameters
   and <Excess Treatment> is a read-only parameter.

   The <QOSM Hops> parameter indicates the number of QoS-NSLP peers
   along the path that support the relevant QOSM specification, and if
   it does not it MUST correctly set the <NON QOSM Hop> flag parameter.
   The composition rule for this parameter is to increment the counter
   by one at each QOSM-aware hop.  This quantity, when composed from the
   QNI to QNR, informs the QNR (or QNI in a RESPONSE message) of the
   number of QOSM-aware QNEs traversed along the path.  In a local
   QSPEC, <QOSM Hops> and <NON QOSM Hop> refer to the QoS-NSLP peers of
   the local QOSM domain.

   <NON QOSM Hop> is a flag bit telling the QNR (or QNI in a RESPONSE
   message) whether or not a particular QOSM is supported by each QNE
   in the path between the QNI and QNR.  If the QNR finds this bit set,
   at least one QNE along the data transmission path between the QNI and
   QNR can not support the specified QOSM.

   The <Excess Treatment> parameter describes how the QNE will process
   excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
   be dropped, shaped and/or remarked. The excess treatment parameter is
   initially set by the QNI and is read-only.

5.2 QoS Description

   The QoS Description is broken down into the following QSPEC objects:

   <QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
                       <Minimum QoS>

   Of these QSPEC objects, QoS desired, QoS available and QoS reserved
   MUST be supported by QNEs.  Minimum QoS MAY be supported.

5.2.1 QoS Desired

   <QoS Desired> = <Traffic Description> <QoS Class> <Priority>
                   <Path Latency> <Path Jitter> <Path BER>

   These parameters describe the resources the QNI desires to reserve
   and hence this is a read-only QSPEC object.  <QoS Desired> includes a
   description of the traffic the QNI is going to inject into the
   network.

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 13]


Internet Draft          QoS-NSLP QSPEC Template                May 2005



   <Traffic Description> = <Bandwidth> <Token Bucket>

   <Bandwidth> = link bandwidth needed by flow [RFC 2212, RFC 2215]

   <Token Bucket> = <r> <b> <p> <m> <MTU> [RFC 2210]

   Note that the <Token Bucket> parameters, such as <MTU>, MAY be used
   separately or in combination.

   <QoS Class> = <PHB Class> <Y.1541 QoS Class> <DSTE Class Type>

   An application MAY like to reserve resources for packets with a
   particular QoS class, e.g. a DiffServ per-hop behavior (PHB)
   [RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class
   type [RFC3564].

   <Priority> = <Reservation Priority> <Preemption Priority>
                <Defending Priority>

   <Reservation priority> is an essential way to differentiate flows for
   emergency services, ETS, E911, etc., and assign them a higher
   admission priority than normal priority flows and best-effort
   priority flows.  <Preemption Priority> 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.  <Defending Priority> 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.

   Appropriate security measures need to be taken to prevent abuse of
   the <Priority> parameters, see Section 8 on Security Considerations.

   <Path Latency>, <Path Jitter> and <Path BER> are optional parameters
   describing the desired path latency, path jitter and path bit error
   rate 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.

5.2.2 <QoS Available>

   <QoS Available> = <Traffic Description> <QoS Class> <Priority>
                     <Path Latency> <Path Jitter> <Path BER> <Ctot>
                     <Dtot> <Csum> <Dsum>

   <Path Latency>, <Path Jitter>, <Path BER>, <Ctot>, <Dtot>, <Csum>,

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 14]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   and <Dsum> are optional QSPEC parameters.  As such, each of these
   optional QSPEC parameters has an associated flag, that is, <Path
   Latency Flag>, <Path Jitter Flag>, <Path BER Flag>, <Ctot Flag>,
   <Dtot Flag>, <Csum Flag>, and <Dsum Flag>.  If these flags are set,
   then at least one QNE along the data transmission path between the
   QNI and QNR can not support the specified optional parameter.  This
   means the value collected in the corresponding parameter is a lower
   bound to the "real" value.  A QNE MUST be able to set the optional
   parameter flag if it does not support the optional parameter, and as
   such the optional parameter flags are mandatory QSPEC parameters.

   The <QoS Available> parameters describe the resources currently
   available on the path and hence the QSPEC object is read-write.  Each
   QNE MUST inspect this QSPEC object, and if resources available to
   this QNE are less than what <QoS Available> says currently, the QNE
   MUST adapt it 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.

   The parameters <Token Bucket> and <Bandwidth> provide information,
   for example, about the bandwidth available along the path followed by
   a data flow.  The local parameter is an estimate of the bandwidth the
   QNE has available for packets following the path.  Computation of the
   value of this parameter SHOULD take into account all information
   available to the QNE about the path, taking into consideration
   administrative and policy controls on bandwidth, as well as physical
   resources.  The composition rule for this parameter is the MIN
   function.  The composed value is the minimum of the QNE's value and
   the previously composed value.  This quantity, when composed
   end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
   minimal bandwidth link along the path from QNI to QNR.

   The <Path Latency> parameter accumulates the latency of the packet
   forwarding process associated with each QNE, where the latency is
   defined to be the smallest possible packet delay added by each QNE.
   This delay results from speed-of-light propagation delay, from packet
   processing limitations, or both.  It does not include any variable
   queuing delay which may be present.  Each QNE MUST add the
   propagation delay of its outgoing link, which includes the QNR adding
   the associated delay for the egress link.  Furthermore, the QNI MUST
   add the propagation delay of the ingress link.  The composition rule
   for the <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 which provide estimates or bounds on additional path delay
   [RFC 2212].  Together with the queuing delay bound, this parameter
   gives the application knowledge of both the minimum and maximum

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 15]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   packet delivery delay.  Knowing both the minimum and maximum latency
   experienced by data packets allows the receiving application to know
   the bound on delay variation and de-jitter buffer requirements.

   The <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 added by each QNE.  IP packet
   jitter, or delay variation, is defined in RFC 3393 [RFC3393], Section
   4.6 (Type-P-One-way-peak-to-peak-ipdv), where the suggested
   evaluation interval is 1 minute.  Note that the method to estimate
   peak-to-peak IP delay variation without active measurements requires
   more study.  This jitter results from packet processing limitations,
   and includes any variable queuing delay which may be present.  Each
   QNE MUST add the jitter of its outgoing link, which includes the QNR
   adding the associated jitter for the egress link.  Furthermore, the
   QNI MUST add the jitter of the ingress link.  The composition rule
   for the <Path Jitter> parameter is summation of a large percentage of
   the peak-to-peak variation with a clamp on the maximum value (note
   that the methods of accumulation and estimation of nominal QNE jitter
   are under study).  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 [RFC 2212].  Together
   with the <Path Latency> and the queuing delay bound, this parameter
   gives the application knowledge of the typical packet delivery delay
   variation.

   The <Path BER> parameter accumulates the bit error rate (BER) of the
   packet forwarding process associated with each QNE, where the BER is
   defined to be the smallest possible BER added by each QNE.  Each QNE
   MUST add the BER of its outgoing link, which includes the QNR adding
   the associated BER for the egress link.  Furthermore, the QNI MUST
   add the BER of the ingress link.  The composition rule for the
   <Path BER> parameter is summation with a clamp on the maximum value
   (this assumes sufficiently low BER values such that summation error
   is not significant).  This quantity, when composed end-to-end,
   informs the QNR (or QNI in a RESPONSE message) of the minimal packet
   BER along the path from QNI to QNR.  As with <Jitter>, the method to
   estimate <Path BER> requires more study.

   <Ctot>, <Dtot>, <Csum>, <Dsum>: Error terms C and D represent how the
   element's implementation of the guaranteed service deviates from the
   fluid model.  These two parameters have an additive composition rule.
   The error term C is the rate-dependent error term.  It represents the
   delay a datagram in the flow might experience due to the rate
   parameters of the flow.  The error term D is the rate-independent,
   per-element error term and represents the worst case non-rate-based
   transit time variation through the service element.  If the
   composition function is applied along the entire path to compute the
   end-to-end sums of C and D (<Ctot> and <Dtot>) and the resulting

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 16]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   values are then provided to the QNR (or QNI in a RESPONSE message).
   <Csum> and <Dsum> are the sums of the parameters C and D between the
   last reshaping point and the current reshaping point.

5.2.3 <QoS Reserved>

   <QoS Reserved> = <Traffic Description> <QoS Class> <Priority> <S>

   These parameters describe the QoS reserved by the QNEs along the data
   path, and hence the QoS reserved QSPEC object is read-write.

   <Traffic Description>, <QoS Class> and <Priority> are defined above.

   <S> = slack term, which is the difference between desired delay and
   delay obtained by using bandwidth reservation, and which is used to
   reduce the resource reservation for a flow [RFC 2212].  This is an
   optional parameter.

5.2.4 <Minimum QoS>

   <Minimum QoS> = <Traffic Description> <QoS Class> <Priority>

   <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.
   It is a read-only QSPEC object.  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 SHOULD signal back to
   the QNI the value of <QoS Available> attained in the end, because the
   reservation MAY need to be adapted accordingly.

   Future versions of this document will describe how <Minimum QoS> can
   be used by the QNI to send a discrete set of desired parameters.

6. QSPEC Functional Specification

   This Section defines the encodings of the QSPEC parameters and QSPEC
   control information defined in Section 5.  We first give the general
   QSPEC formats and then the formats of the QSPEC objects and
   parameters.

   Note that all QoS Description parameters can be either read-write or
   read-only, depending on which object and which message they appear
   in.


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 17]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


6.1 General QSPEC Formats:

   Note: This section is in a draft state and further work is needed to
   define exact formats of objects.

   Type: QSPEC
   Length: Variable
   Value: This object contains a 2 byte QOSM ID and variable length
          QSPEC information, which is QOSM specific.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              QOSM ID          |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Object ID   | Parameter ID  |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                   Parameter Values                          //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Object ID   | Parameter ID  |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                   Parameter Values                          //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Object ID:
   0: control information
   1: QoS Desired
   2: QoS Available
   3: QoS Reserved
   4: Min QoS

6.2 <Excess Treatment> Parameter

   Object ID = 0
   Parameter ID = 0
   Length = 8 bits
   Mandatory QSPEC Parameter

   Parameter Values:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |     Excess    |
   |   Treatment   |
   +-+-+-+-+-+-+-+-+

   Excess Treatment: Indicates how the QNE SHOULD process out-of-profile
   traffic.  Allowed values are as follows:
   0: drop
   1: shape
   2: remark

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 18]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   The excess treatment parameter is set by the QNI.

6.3 <Bandwidth> & <S> Parameters [RFC 2212, RFC 2215]

   The <Bandwidth> parameter MUST be nonnegative and is measured in
   bytes per second and has the same range and suggested representation
   as the bucket and peak rates of the <Token Bucket>.  <Bandwidth> can
   be represented using single-precision IEEE floating point.  The
   representation MUST be able to express values ranging from 1 byte per
   second to 40 terabytes per second.  For values of this parameter only
   valid non-negative floating point numbers are allowed.  Negative
   numbers (including "negative zero"), infinities, and NAN's are not
   allowed.

   A QNE MAY export a local value of zero for this parameter.  A network
   element or application receiving a composed value of zero for this
   parameter MUST assume that the actual bandwidth available is unknown.

   Object ID = 1-4
   Bandwidth Parameter ID = 1
   Slack Term Parameter ID = 2
   Length = 32 bits
   Bandwidth is Mandatory QSPEC Parameter
   Slack Term is Optional QSPEC Parameter

   Parameter Values:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Bandwidth       (32-bit IEEE floating point number)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Slack Term [S]  (32-bit integer)                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Slack term S MUST be nonnegative and is measured in microseconds.
   The Slack term, S, can be represented as a 32-bit integer.  Its value
   can range from 0 to (2**32)-1 microseconds.

6.4 <Token Bucket> Parameters [RFC 2215]

   The <Token Bucket> parameters are represented by three floating
   point numbers in single-precision IEEE floating point format followed
   by two 32-bit integers in network byte 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 integer is the minimum policed unit (m), and the second integer
   is the maximum datagram size (MTU).

   Note that the <Token Bucket> parameters, such as <MTU>, MAY be used
   separately or in combination.

   Object ID = 1-4

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 19]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   Token Bucket Rate [r] Parameter ID = 3
   Token Bucket Size [b] Parameter ID = 4
   Peak Data Rate [p] Parameter ID = 5
   Minimum Policed Unit [m] Parameter ID = 6
   Maximum Packet Size [M] Parameter ID = 7
   Length = 32 bits
   Mandatory QSPEC Parameters

   Parameter Values:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Minimum Policed Unit [m] (32-bit integer)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Packet Size [MTU] (32-bit integer)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When r, b, p, and R 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.

6.5 <QoS Class> Parameters

6.5.1 <PHB Class> Parameter [RFC 3170]

   As prescribed in RFC 3170, the encoding for a single PHB is the
   recommended DSCP value for that PHB, left-justified in the 16 bit
   field, with bits 6 through 15 set to zero.

   Object ID = 1-4
   PHB Class Parameter ID = 9
   Length = 16 bits
   Mandatory QSPEC Parameter

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 20]


Internet Draft          QoS-NSLP QSPEC Template                May 2005



   Parameter Values:

     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |         DSCP          | 0   0   0   0   0   0   0   0   0   0 |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The registries needed to use RFC 3140 already exist, see [DSCP-
   REGISTRY, PHBID-CODES-REGISTRY].  Hence, no new registry needs to be
   created for this purpose.

6.5.2 <Y.1541 QoS Class> Parameter [Y.1541]

   Y.1541 QoS classes are defined as follows:

   Object ID = 1-4
   Y.1541 QoS Class Parameter ID = 10
   Length = 8 bits
   Mandatory QSPEC Parameter

   Parameter Values:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |    Y.1541     |
      |  QoS Class    |
      +-+-+-+-+-+-+-+-+

   Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently
   allowed are 0, 1, 2, 3, 4, 5.

   Class 0:
   Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3.
   Real-time, highly interactive applications, sensitive to jitter.
   Application examples include VoIP, Video Teleconference.

   Class 1:
   Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3.
   Real-time, interactive applications, sensitive to jitter.
   Application examples include VoIP, Video Teleconference.

   Class 2:
   Mean delay <= 100 ms, delay variation unspecified, loss ratio <=
   10^-3.  Highly interactive transaction data.  Application examples
   include signaling.

   Class 3:
   Mean delay <= 400 ms, delay variation unspecified, loss ratio <=
   10^-3.  Interactive transaction data.  Application examples include
   signaling.

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 21]


Internet Draft          QoS-NSLP QSPEC Template                May 2005



   Class 4:
   Mean delay <= 1 sec, delay variation unspecified, loss ratio <=
   10^-3.  Low Loss Only applications.  Application examples include
   short transactions, bulk data, video streaming.

   Class 5:
   Mean delay unspecified, delay variation unspecified, loss ratio
   unspecified.  Unspecified applications.  Application examples include
   traditional applications of default IP networks.

6.5.3 <DSTE Class Type> Parameter [RFC3564]

   DSTE class type is defined as follows:

   Object ID = 1-4
   DSTE Class Type Parameter ID = 11
   Length = 8 bits
   Mandatory QSPEC Parameter

   Parameter Values:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |     DSTE      |
   |  Class Type   |
   +-+-+-+-+-+-+-+-+

   DSTE Class Type: Indicates the DSTE class type. Values currently
   allowed are 0, 1, 2, 3, 4, 5, 6, 7.

6.6 Priority Parameters

6.6.1 <Preemption Priority> & <Defending Priority> Parameters
      [RFC 3181]

   Object ID = 1-4
   Preemption Priority Parameter ID = 12
   Defending Priority Parameter ID = 13
   Length = 16 bits (unsigned)
   Mandatory QSPEC Parameter

   Parameter Values:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Preemption Priority        |      Defending Priority       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Preemption Priority: The priority of the new flow compared with the

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 22]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   defending priority of previously admitted flows.  Higher values
   represent higher priority.

   Defending Priority:

6.6.2 <Reservation Priority> Parameter [SIP-PRIORITY]

   Object ID = 1-4
   Reservation Priority Parameter ID = 14
   Length = 16 bits
   Mandatory QSPEC Parameter

   Parameter Values
    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reservation  |  Reservation  |
   |   Priority    |   Priority    |
   |   Namespace   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   High priority flows, normal priority flows, and best-effort priority
   flows can have access to resources depending on their {"Namespace",
   "Reservation Priority"} combination as follows:

   Reservation Priority Namespace: 8 bits

   0 - dsn high priority
   1 - drsn high priority
   2 - q735 high priority
   3 - ets high priority
   4 - wps high priority
   5 - normal priority
   6 - best-effort priority

   Reservation Priority: 8 bits
   Each namespace has a finite list of relative priority-values.  Each
   is listed here in the order of lowest priority to highest priority:

   4 - dsn.routine
   3 - dsn.priority
   2 - dsn.immediate
   1 - dsn.flash
   0 - dsn.flash-override

   5 - drsn.routine
   4 - drsn.priority
   3 - drsn.immediate
   2 - drsn.flash
   1 - drsn.flash-override
   0 - drsn.flash-override-override

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 23]


Internet Draft          QoS-NSLP QSPEC Template                May 2005



   4 - q735.4
   3 - q735.3
   2 - q735.2
   1 - q735.1
   0 - q735.0

   4 - ets.4
   3 - ets.3
   2 - ets.2
   1 - ets.1
   0 - ets.0

   4 - wps.4
   3 - wps.3
   2 - wps.2
   1 - wps.1
   0 - wps.0

   0 - normal.0

   0 - best.effort.0

   Note that additional work is needed to communicate these flow
   priority values to bearer-level network elements
   [VERTICAL-INTERFACE].

6.7 <Path Latency> Parameter [RFC 2210, 2215]

   Object ID = 1-4
   Path Latency Parameter ID = 15
   Length = 32 bits
   Optional QSPEC Parameter

   Parameter Values:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Path Latency (32-bit integer)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The composition rule for the <Path Latency> parameter is summation
   with a clamp of (2**32 - 1) on the maximum value.  The latencies are
   reported in units of one microsecond. An individual QNE can advertise
   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 advertised delay SHOULD be reported as
   indeterminate.  A QNE that cannot accurately predict the latency of
   packets it is processing MUST raise the Path Latency Flag and either

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 24]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   leave the value of Path Latency as is, or add its best estimate of
   its lower bound.  A raised Path Latency 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.

6.8 <Path Jitter> Parameter

   Object ID = 1-4
   Path Jitter Parameter ID = 16
   Length = 32 bits
   Optional QSPEC Parameter

   Parameter Values:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Path Jitter (32-bit integer)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The composition rule for the <Path Jitter> parameter is summation
   with a clamp of (2**32 - 1) on the maximum value.  The jitters are
   reported in units of one microsecond. An individual QNE can advertise
   a jitter value between 1 and 2**28 (somewhat over two minutes) and
   the total jitter 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 advertised jitter SHOULD be reported as
   indeterminate.  A QNE that cannot accurately predict the jitter of
   packets it is processing MUST raise the Path Jitter Flag and either
   leave the value of Path Jitter as is, or add its best estimate of its
   lower bound.  A raised Path Jitter 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 which
   cannot accurately predict the jitter of packets it is processing
   SHOULD set its local 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 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.

6.9 <Path BER> Parameter

   Object ID = 1-4
   Path BER Parameter ID = 17
   Length = 32 bits
   Optional QSPEC Parameter


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 25]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   Parameter Values:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Path Bit Error Rate (32-bit integer)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The composition rule for the <Path BER> parameter is summation with
   a clamp of 10^-2 on the maximum value.  The BERs are reported in
   units of 10^-11. An individual QNE can advertise a BER value between
   1 and 2**28 and the total BER 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 advertised BER SHOULD be reported as
   indeterminate.  A QNE that cannot accurately predict the BER of
   packets it is processing MUST raise the Path BER Flag and either
   leave the value of Path BER as is, or add its best estimate of its
   lower bound.  A raised Path BER Flag indicates the value of Path BER
   is a lower bound of the real Path BER.  The distinguished value
   (2**32)-1 is taken to mean indeterminate BER.  A QNE which cannot
   accurately predict the BER of packets it is processing SHOULD set its
   local 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 BER 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.

6.10 <Ctot> <Dtot> <Csum> <Dsum> Parameters [RFC 2210, 2212, 2215]

   Object ID = 1-4
   Ctot Parameter ID = 18
   Dtot Parameter ID = 19
   Csum Parameter ID = 20
   Dsum Parameter ID = 21
   Length = 32 bits
   Optional QSPEC Parameters

   Parameter Values:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   End-to-end composed value for C [Ctot] (32-bit integer)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   End-to-end composed value for D [Dtot] (32-bit integer)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Since-last-reshaping point composed C [Csum] (32-bit integer) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Since-last-reshaping point composed D [Dsum] (32-bit integer) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 26]


Internet Draft          QoS-NSLP QSPEC Template                May 2005



   The error term C is measured in units of bytes.  An individual QNE
   can advertise a C value between 1 and 2**28 (a little over 250
   megabytes) and the total added over all QNEs can range as high as
   (2**32)-1.  Should the sum of the different QNEs delay exceed
   (2**32)-1, the end-to-end error term MUST be set to (2**32)-1.  The
   error term D is measured in units of one microsecond.  An individual
   QNE can advertise a delay value between 1 and 2**28 (somewhat over
   two minutes) and the total delay added over all QNEs can range as
   high as (2**32)-1.  Should the sum of the different QNEs delay
   exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1.

6.11 <Path Latency Flag>, <Path Jitter Flag>, <Path BER Flag>,
     <Ctot Flag>, <Dtot Flag>, <Csum Flag>, <Dsum Flag>
     <Slack Term Flag>

   Object ID = 1-4
   Path Latency Flag Parameter ID = 22
   Path Latency Flag Parameter ID = 23
   Path Latency Flag Parameter ID = 24
   Ctot Flag Parameter ID = 25
   Dtot Flag Parameter ID = 26
   Csum Flag Parameter ID = 27
   Dsum Flag Parameter ID = 28
   Slack Term Flag Parameter ID = 29
   Length = 8 bits
   Mandatory QSPEC Parameters

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |  Path Latency |
   |      Flag     |
   +-+-+-+-+-+-+-+-+

   Path Latency Flag: This field is set to 1 if a QNE is encountered
   that does not support the <Path Latency> parameter on the path from
   the QNI to the QNR.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |  Path Jitter  |
   |      Flag     |
   +-+-+-+-+-+-+-+-+

   Path Jitter Flag: This field is set to 1 if a QNE is encountered that
   does not support the <Path Jitter> parameter on the path from the QNI
   to the QNR.


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 27]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   | Path BER Flag |
   +-+-+-+-+-+-+-+-+

   Path BER Flag: This field is set to 1 if a QNE is encountered that
   does not support the <Path BER> parameter on the path from the QNI
   to the QNR.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |   Path Ctot   |
   |     Flag      |
   +-+-+-+-+-+-+-+-+

   Path Ctot Flag: This field is set to 1 if a QNE is encountered that
   does not support the <Path Ctot> parameter on the path from the QNI
   to the QNR.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |   Path Dtot   |
   |     Flag      |
   +-+-+-+-+-+-+-+-+

   Path Dtot Flag: This field is set to 1 if a QNE is encountered that
   does not support the <Path Dtot> parameter on the path from the QNI
   to the QNR.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |   Path Csum   |
   |     Flag      |
   +-+-+-+-+-+-+-+-+

   Path Csum Flag: This field is set to 1 if a QNE is encountered that
   does not support the <Path Csum> parameter on the path from the QNI
   to the QNR.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |   Path Dsum   |
   |     Flag      |
   +-+-+-+-+-+-+-+-+

   Path Dsum Flag: This field is set to 1 if a QNE is encountered that
   does not support the <Path Dsum> parameter on the path from the QNI
   to the QNR.


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 28]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |  Slack Term   |
   |     Flag      |
   +-+-+-+-+-+-+-+-+

   Slack Term Flag: This field is set to 1 if a QNE is encountered that
   does not support the <S> parameter on the path from the QNI to the
   QNR.

7. QSPEC Procedures & Examples

7.1 QSPEC Procedures

   While the QSPEC template aims to put minimal restrictions on usage of
   QSPEC objects in <QoS Description>, 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 [QOS-SIG].  A specific QOSM may impose more restrictions
   on the QNI or QNR freedom.

7.1.1 Sender-Initiated Reservations

   Here the QNI issues a RESERVE, which is replied to by a RESPONSE.
   This response is generated either by the QNR or, in case the
   reservation was unsuccessful, by a QNE.  The following possibilities
   for QSPEC object usage exist:

     | RESERVE                           | RESPONSE
   ---------------------------------------------------------------
   a.| QoS Desired                       | QoS Reserved
   b.| QoS Desired, QoS Avail.           | QoS Reserved, QoS Avail.
   c.| QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail.

   a.) If only QoS Desired is included in the RESERVE, 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.

   b.) When QoS Available is included in the RESERVE 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).

   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.  Each QNE
   adapts the parameters in QoS Available according to its current
   capabilities.  Reservations in each QNE are hence based on current

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 29]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   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 parameter types included in QoS Reserved in RESPONSE must be the
   same as those in QoS Desired in RESERVE.  For those parameters that
   were also included in QoS Available in RESERVE, their value is copied
   into QoS Desired.  For the other parameters, the value is copied from
   QoS Desired (the reservation would fail if the corresponding QoS
   could not be reserved).

   The parameters in the QoS Available QSPEC object in the RESPONSE are
   copied with their values from the QoS Available QSPEC object in the
   RESERVE.  Note that the parameters in QoS Available are read-write
   in the RESERVE message, whereas they are read-only in the RESPONSE.

   c.) this case is handled as case (b), except that the reservation
   fails when QoS Available becomes less than Minimum QoS for one
   parameter.  If a parameter appears in QoS Available but not in
   Minimum QoS it is assumed that the minimum value for this parameter
   is that given in QoS Desired.

7.1.2 Receiver-Initiated Reservations

   Here the QNI issues a QUERY which is replied to by the QNR with a
   RESERVE if the reservation was successful.  The QNI in turn sends a
   RESPONSE to the QNR.

   QUERY                | RESERVE                    | RESPONSE
   ---------------------------------------------------------------------
   a. QoS Des.          | QoS Des.                   | QoS Res.
   b. QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl.

   a.) and b.) 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, as
   in Case b.

   The RESERVE message includes QoS Available if the sender signaled QoS
   is negotiable (i.e. it included Minimum QoS).  If the Minimum QoS
   received from the sender is non-zero, the QNR also includes Minimum
   QoS.


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 30]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   Note we do not yet cover here a model where the sender issues a QUERY
   with QoS Available to collect path properties, and the QoS Desired in
   the RESERVE issued by the receiver is populated from the parameter
   values in QoS Available from the QUERY message.  This is in fact the
   model used in RSVP.  The advantage of this model is that situation of
   over-reservation in QNEs close to the QNI as described above does not
   occur.  On the other hand, the QUERY may find, for example, a
   particular bandwidth is not available.  When the actual reservation
is
   performed, however, the desired bandwidth may meanwhile have become
   free.  That is, the 'RSVP model' may result in a worse reservation
   than necessary.  What scenarios to include are TBD.

   Future versions of this draft will additionally contain procedures
   for bidirectional reservations and pure resource queries without
   subsequent reservations.

7.1.3 Setting Optional Parameter Flags

   An optional parameter is always accompanied by an optional parameter
   flag in all objects.  For example, if the QNI populates an optional
   parameter in QoS Desired, it MUST also populate the optional
   parameter flag in <QoS Available>.  Hence, if a QNE wants to check
   for support of optional parameters, it MUST include a <QoS Available>
   object and the optional parameter flags are only in that object.  If
   a QNE does not support the optional parameter, it MUST set the
   optional parameter flag in the QoS Available object.  Optional
   parameter flags SHOULD only travel in the <QoS Available> object, and
   are generally not included in the QoS Desired, Minimum QoS and QoS
   Reserved objects.

7.2 QOSM & QSPEC Examples

   This Section provides the QOSM and QSPECs for DiffServ admission
   control and IntServ.  Note that DiffServ and IntServ form the basis
   for the QSPEC template specification in this document.

7.2.1 QOSM & QSPEC for DiffServ Admission Control

   The QSPEC for DiffServ admission control is composed of the QSPEC
   objects <QoS Desired> and <QoS Available>, as well as <QoS
   Reserved>.  Which QSPEC object is present in a particular QSPEC
   depends on the message type (RESERVE, QUERY etc) in which the QSPEC
   travels.  Parameters in the QSPEC for DiffServ requesting bandwidths
   for different PHBs are as follows:

   For the DiffServ EF PHB [RFC3297]:

   <QSPEC Control Information> = <Excess Treatment>
   <QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
   <QoS Desired> = <Traffic Description> <QoS Class>

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 31]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   <Traffic Description> = <Token Bucket>
   <QoS class> = <PHB Class=EF>
   <QoS Available> = <Token Bucket>
   <QoS Reserved> = <Token Bucket>

   In general, the EF PHB is a property of the service that is NOT
   dependent on the input traffic characteristics.  A server of rate R
   and latency E that is compliant with the EF PHB must deliver at least
   the configured service rate R with at most latency E for any traffic
   characterization. Therefore, strictly speaking, there is no specific
   traffic descriptor required to deliver the EF PHB (which by
   definition is a local per-hop characterization).  However, in order
   to deliver a reasonable end-to-end delay, it is typically assumed
   that EF traffic is shaped at the ingress.  A typical assumption is
   that input traffic at any ingress is constrained by a single rate
   token bucket.  Therefore, a single rate token bucket is sufficient
   to signal in QoS-NSLP/QSPEC for the DiffServ-QOSM.

   For the DiffServ AFxy PHB [RFC2597]:

   <QSPEC Control Information> = <Excess Treatment>
   <QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
   <QoS Desired> = <Traffic Description> <QoS Class>
   <Traffic Description> = <Committed Burst Size (CBS) Token Bucket>
                           <Excess Burst Size (EBS) Token Bucket>
   <QoS class> = <PHB Class=AFxy>
   <QoS Available> = <CBS Token Bucket> <EBS Token Bucket>
   <QoS Reserved> = <CBS Token Bucket> <EBS Token Bucket>

   QNEs MUST process two sets of token bucket parameters to implement
   the DiffServ AF QOSM, one token bucket for the average (CBS) traffic
   and one token bucket for the burst (EBS) traffic.  These 2 token
   buckets are sufficient to cover most of the ways in which one would
   distinguish among 3 levels of drop precedence at the queuing
   mechanics level, as described in the Appendix to [RFC2597].

   QoS-NSLP/QSPEC can support signaling the parameters required for the
   DiffServ marker elements described in [RFC2697] and [RFC2698].
   [RFC2697] defines a Single Rate Three Color Marker (srTCM), which
   can be used as component in a DiffServ traffic conditioner [RFC2475,
   RFC2474].  The srTCM 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.

   RFC 2697 and RFC 2698 provide specific procedures, where in essence,
   RFC 2697 is using two token buckets that run at the same rate.
   TBD: Text to explain how to use the two token buckets to carry the
   configuration information needed for RFC 2697 and 2698.

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 32]


Internet Draft          QoS-NSLP QSPEC Template                May 2005



7.2.2 QOSM & QSPEC for IntServ Controlled Load Service

   The QOSM for IntServ Controlled Load is defined in [RFC2211].
   The QSPEC can be derived from usage of RSVP to signal for this QoS
   Model, as defined in [RFC2210] and [RFC2215].

   The QSPEC for IntServ Controlled Load is composed of the QSPEC
   objects <QoS Desired> and <QoS Available>, as well as <QoS Reserved>.
   Which QSPEC object is present in a particular QSPEC depends on the
   message type (RESERVE, QUERY etc) in which the QSPEC travels.
   Parameters in the QSPEC are as follows:

   <QSPEC Control Information> = <NON QOSM Hop> <QOSM Hops>
   <QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
   <QoS Desired> = <Token Bucket>
   <QoS Available> = <Bandwidth> <Path Latency> <MTU>
   <QoS Reserved> = <Token Bucket>

   An IntServ over DiffServ QSPEC is as follows:

   <QSPEC Control Information> = <NON NSLP Hop> <NSLP Hops>
   <QoS Desired> = <Token Bucket>
   <QoS Class> = <PHB Class>
   <QoS Available> = <Bandwidth> <Path Latency> <MTU>
   <QoS Reserved> = <Token Bucket>

7.2.3 QOSM & QSPEC for IntServ Guaranteed Services

   The QOSM is defined in [RFC 2212]. The required parameters to
   achieve guarantied service with RSVP are specified in [RFC 2210]
   and [RFC 2215].

   The QSPEC for guaranteed services is as follows:

   <QSPEC Control Information> = <NON NSLP Hop> <NSLP Hops>
   <QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
   <QoS Desired> = <Token Bucket>

   This QSPEC object contains token bucket parameters defined in
   [RFC 2210], equivalent to TSPEC defined in RSVP.

   <QoS Available> = <Bandwidth> <Path Latency> <MTU> <Ctot> <Dtot>
                     <Csum> <Dsum>

   These parameters are defined in [RFC 2212] and [RFC 2215]. This
   QSPEC object is equivalent to the ADSPEC of RSVP.

   <QoS Reserved> = <Token Bucket> <Bandwidth> <S>

   Requested Rate and Slack Term are defined in [RFC 2212], equivalent

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 33]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   to RSPEC of RSVP.

   Note that the Guaranteed Services QoS Model only works with receiver
   initiated reservation signaling, because <Bandwidth> and <S> are
   derived from parameters contained in <QoS Available>, and MAY be
   updated on the return paths.

8. Security Considerations

   The priority parameter raises possibilities for Theft of Service
   Attacks because users could claim an emergency priority for their
   flows without real need, thereby effectively preventing serious
   emergency calls to get through. Several options exist for countering
   such attacks, for example

   - only some user groups (e.g. the police) are authorized to set the
   emergency priority bit

   - any user is authorized to employ the emergency priority bit for
   particular destination addresses (e.g. police)

9.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the
   QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434].

   [QoS-SIG] requires IANA to create a new registry for QoS Signaling
   Policy Identifiers.  The QoS Signaling Policy Identifier (QOSM ID) is
   a 32 bit value carried in a QSPEC.  The allocation policy for
   new QOSM IDs is TBD.

   This document also defines 29 objects and parameters for the QSPEC
   Template, as Detailed in Section 6.  Values are to be assigned for
   them from the NTLP Object Type registry.

10.  Acknowledgements

   The authors would like to thank David Black, Anna Charny, Robert
   Hancock, Dave Oran, Tom Phelan, Hannes Tschofenig, and Sven van den
   Bosch, for their very helpful suggestions.

11.  Normative References

   [DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry
   [PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes
   [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service
   Signaling," work in progress.
   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.
   [RFC2205] B. Braden et. al., "Resource ReSerVation Protocol (RSVP)

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 34]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   -- Version 1 Functional Specification," RFC 2205, September 1997.
   [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated
   Services", RFC 2210, September 1997.
   [RFC2211] J. Wroclawski, "Specification of the Controlled-Load
   Network Element Service", RFC 2211, Sept. 1997.
   [RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality
   of Service," September 1997.
   [RFC2215] S. Shenker and J. Wroclawski, "General Characterization
   Parameters for Integrated Service Network Elements", RFC 2215, Sept.
   1997.
   [RFC2474] Nichols, K., et. al., "Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474,
   December 1998.
   [RFC2475] S. Blake et. al., "An Architecture for Differentiated
   Services", RFC 2475, December 1998.
   [RFC2597] J. Heinanen, et. al., "Assured Forwarding PHB Group," RFC
   2597, June 1999.
   [RFC2697] J. Heinanen, R. Guerin, "A Single Rate Three Color Marker,"
   RFC 2697, September 1999.
   [RFC2698] J. Heinanen, R. Guerin, "A Two Rate Three Color Marker,"
   RFC 2698, September 1999.
   [RFC3297] A. Charny, et. al., "Supplemental Information for the New
   Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior),"
   RFC 3297, March 2002.

12.  Informative References

   [CMSS] "PacketCable (TM) CMS to CMS Signaling Specification,
   PKT-SP-CMSS-103-040402, April 2004.
   [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines
   for DiffServ Service Classes," work in progress.
   [INTSERV-QOSM] C. Kappler, "A QoS Model for Signaling IntServ
   Controlled-Load Service with NSIS," work in progress.
   [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling
   Protocol - Capability Set 3" Sep. 2003
   [RFC1633] B. Braden et. al., "Integrated Services in the Internet
   Architecture: an Overview," RFC 1633, June 1994.
   [RFC3393] C. Demichelis, P. Chimento, "IP Packet Delay Variation
   Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002.
   [RFC3564] F. Le Faucheur et. al., Requirements for Support of
   Differentiated Services-aware MPLS Traffic Engineering, RFC 3564,
   July 2003
   [RFC3726] M. Brunner et. al., "Requirements for Signaling Protocols",
   RFC 3726, April 2004.
   [RMD-QOSM] A. Bader, et. al., " RMD-QOSM: An NSIS QoS Signaling
   Policy Model for Networks
   Using Resource Management in DiffServ (RMD)," work in progress.
   [SIP-PRIORITY] H. Schulzrinne, J. Polk, "Communications Resource
   Priority for the Session Initiation Protocol(SIP)." work in
   progress.
   [VERTICAL-INTERFACE] M. Dolly, P. S. Tarapore, S. Sayers,

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 35]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   "Discussion on Associating of Control Signaling Messages with Media
   Priority Levels," T1S1.7 & PRQC, October 2004.
   [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives
   for IP-Based Services," May 2002.
   [Y.1541-QOSM] J. Ash, et. al., "Y.1541-QOSM -- Y.1541 QoS Model for
   Networks Using Y.1541 QoS Classes," work in progress.

13. Authors' Addresses

   Jerry Ash
   AT&T
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578
   Fax:   +1-(732)-368-8659
   Email: gash@att.com

   Attila Bader
   Traffic Lab
   Ericsson Research
   Ericsson Hungary Ltd.
   Laborc u. 1 H-1037
   Budapest Hungary
   EMail: Attila.Bader@ericsson.com

   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
   E-mail: cdvorak@att.com

   Yacine El Mghazli
   Alcatel
   Route de Nozay
   91460 Marcoussis cedex
   FRANCE
   Phone: +33 1 69 63 41 87
   Email: yacine.el_mghazli@alcatel.fr

   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin 13627
   Germany
   Email: cornelia.kappler@siemens.com


Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 36]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   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

   Al Morton
   AT&T
   Room D3-3C06
   200 S. Laurel Avenue
   Middletown, NJ 07748
   Phone: + 1 732 420-1571
   Fax: +.1 732 368-1192
   E-mail: acmorton@att.com

   Percy Tarapore
   AT&T
   Room D1-33
   200 S. Laurel Avenue
   Middletown, NJ 07748
   Phone: + 1 732 420-4172
   E-mail: tarapore@.att.com

   Lars Westberg
   Ericsson Research
   Torshamnsgatan 23
   SE-164 80 Stockholm, Sweden
   EMail: Lars.Westberg@ericsson.com

Appendix A: QoS Models and QSPECs

   This Appendix gives a description of QoS Models and QSPECs and
   explains what is the relation between them. Once these descriptions
   are contained in a stable form in the appropriate IDs this Appendix
   will be removed.

   QoS NSLP is a generic QoS signaling protocol that can signal for many
   QOSMs. A QOSM is a particular QoS provisioning method or QoS
   architecture such as IntServ Controlled Load or Guaranteed Service,
   DiffServ, or RMD for DiffServ.

   The definition of the QOSM is independent from the definition of QoS
   NSLP.  Existing QOSMs do not specify how to use QoS NSLP to signal

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 37]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   for them. Therefore, we need to define the QOSM specific signaling
   functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM].

   A QOSM SHOULD include the following information:

   - Role of QNEs in this QOSM:
   E.g. location, frequency, statefulness...
   - QSPEC Definition:
   A QOSM SHOULD specify the QSPEC, including QSPEC parameters.
   Furthermore it needs to explain how QSPEC parameters not used in this
   QOSM are mapped onto parameters defined therein.
   - Message Format
   QSPEC objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY
   - State Management
   It describes how QSPEC info is treated and interpreted in the
   RMF and QOSM specific processing. E.g.
   admission control, scheduling, policy control, QoS parameter
   accumulation (e.g. delay).
   - Operation and Sequence of Events
   Usage of QoS-NSLP messages to signal the QOSM.

Appendix B: 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. token bucket). The AdSpec can collect path
   characteristics (e.g. delay). Both are issued by the sender. The
   receiver sends the FlowSpec which includes a Receiver TSpec
   describing the resources reserved using the same parameters as the
   Sender TSpec, as well as a RSpec which provides additional IntServ
   QoS Model specific parameters, e.g. Rate and Slack.

   The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated
   signaling employed by RSVP, and the IntServ QoS Model. E.g. 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.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 38]


Internet Draft          QoS-NSLP QSPEC Template                May 2005


   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Ash, et. al.         <draft-ietf-nsis-qspec-04.txt>            [Page 39]