[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 RFC 5975

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

                                                          December 2004


                         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 RFC 3668.

   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/1id-abstracts.html.

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

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   The QoS NSLP protocol is used to signal QoS reservations and is
   independent of a specific QoS model such as IntServ or DiffServ.
   Rather, all information specific to QoS models is encapsulated in a
   separate object, the QSPEC.  This draft defines a template for the
   QSPEC, which contains both the QoS description and control
   information specific to a given QoS model. The QSPEC format is
   defined as are a number of generic and optional parameters.
   Generic parameters provide a common language to be re-used in
   several QoS models, which are derived initially from the IntServ
   and DiffServ QoS models.  Optional parameters aim to ensure the
   extensibility of QoS NSLP to other QoS models.



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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Applicability  . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.1 Processing of QSPEC . . . . . . . . . . . . . . . . . . . . . 5
   3.2 Generic Parameters  . . . . . . . . . . . . . . . . . . . . . 6
   3.3 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6
   4. QSPEC Format Overview  . . . . . . . . . . . . . . . . . . . . 6
   4.1 QSP Specific Control Information  . . . . . . . . . . . . . . 7
   4.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . . 7
   4.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . . . . 8
   4.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . . . . 8
   4.2.3 QoS Reserved  . . . . . . . . . . . . . . . . . . . . . .  10
   4.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . . .  10
   5. QSPEC Functional Specification . . . . . . . . . . . . . . .  11
   5.1 <Hop Count> Parameter . . . . . . . . . . . . . . . . . . .  11
   5.2 <Excess Treatment> Parameter  . . . . . . . . . . . . . . .  11
   5.3 <NON QSP Hop> & <QSP Hops> Parameters . . . . . . . . . . .  11
   5.4 <R> & <S> Parameters  . . . . . . . . . . . . . . . . . . .  12
   5.5 <Token Bucket> Parameters . . . . . . . . . . . . . . . . .  12
   5.6 <QoS Class> Parameters  . . . . . . . . . . . . . . . . . .  12
   5.6.1 <PHB Class> Parameter . . . . . . . . . . . . . . . . . .  12
   5.6.2 <Y.1541 QoS Class> Parameter  . . . . . . . . . . . . . .  14
   5.6.3 <DSTE Class Type> Parameter . . . . . . . . . . . . . . .  15
   5.7 <Priority> Parameters . . . . . . . . . . . . . . . . . . .  15
   5.7.1 <Preemption Priority> & <Defending Priority> Parameters .  15
   5.7.2 <Reservation Priority> Parameter  . . . . . . . . . . . .  15
   5.8 <QoS Available> Parameters  . . . . . . . . . . . . . . . .  16
   5.8.1 <Available Bandwidth> Parameters  . . . . . . . . . . . .  16
   5.8.2 <Min Latency> Parameter . . . . . . . . . . . . . . . . .  17
   5.8.3 <Ctot> <Dtot> <Csum> <Dsum> Parameters  . . . . . . . . .  17
   6. Security Considerations  . . . . . . . . . . . . . . . . . .  18
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  18
   8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  18
   9. Intellectual Property Considerations . . . . . . . . . . . .  18
   10. Normative References  . . . . . . . . . . . . . . . . . . .  19
   11. Informative References  . . . . . . . . . . . . . . . . . .  19
   12. Authors' Addresses  . . . . . . . . . . . . . . . . . . . .  20
   Appendix A Example Qspecs . . . . . . . . . . . . . . . . . . .  21
   A.1 QSPEC for Admission Control for DiffServ  . . . . . . . . .  21
   A.2 QSPEC for IntServ Controlled Load Service . . . . . . . . .  21
   A.3 QSPEC for IntServ Guaranteed Services . . . . . . . . . . .  22
   Appendix B Example of NSLP QSPEC Operation  . . . . . . . . . .  22
   Appendix C QoS Models, QoS Signaling Policies and QSPECs  . . .  24
   Appendix D Mapping of QoS Desired, QoS Available, and QoS Reserved
   of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ . . . . .  24
   Full Copyright Notice . . . . . . . . . . . . . . . . . . . . .  25
   Disclaimer of Validity  . . . . . . . . . . . . . . . . . . . .  25


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


1.  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 [RSVP], and meets the requirements of
   [NSIS-REQ].

   QoS NSLP can signal for different QoS Models, i.e. QoS provisioning
   methods or QoS architectures. It should be able to support, for
   example, IntServ and signaling for DiffServ admission control, and
   satisfy the need of more complex control planes such as defined in
   [Q.2630, Y.1541].  The use of QoS NSLP to signal for a specific QoS
   Model is called a 'QoS Signaling Policy' (QSP). Examples of different
   QSPs for NSIS are specified in [Y.1541-QSP, INTSERV-QSP, RMD-QSP].
   For more information on QoS Models and QSPs see Appendix B.

   QSP-specific information is carried in the so-called QSPEC object,
   which travels in QoS-NSLP messages. The format of the QSPEC object
   is QSP specific. The QSPEC is opaque to QoS NSLP. It contains two
   types of information: QSP Control Information and a QoS Description.

   The QSP control information contains information not related to the
   actual resource management but rather to message processing. An
   example of QSP control information is the scope of the QSPEC.  QSP
   Control Information must not be confused with the Common Control
   Information, which is a set of objects defined in QoS NSLP. Whereas
   QSP Control Information is specific to the QSPEC, Common Control
   Information is specific to the QoS NSLP message.

   The QoS Description is composed of objects 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 an object denoting minimum QoS. Usage
   of these objects is not bound to particular message types thus
   allowing for flexibility. An object collecting information about
   available resources may travel in any QoS NSLP message, for example
   a QUERY message or a RESERVE message.

   This draft provides a template for the QSPEC, which is needed in
   order to help defining individual QSPs and in order to promote
   interoperability between QoS models.

2. Terminology

   Common NSLP Processing: Functions in a QNE that are related to NSLP
   message processing (common for each QoS Model)

   Generic-Mandatory Parameter: Parameter for which QNEs MUST provide
   meaningful interpretations.


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   Generic-Optional Parameter: QSPEC parameter for which QNEs SHOULD
   provide meaningful interpretations when applicable to the underlying
   technology.

   Minimum QoS: Minimum QoS is a functionality that MAY be supported by
   any QSP: Together with a description of desired QoS, it allows the
   QNI to specify a QoS range, i.e. an upper and lower bound. If the
   desired QoS is not available, QNFs are going to decrease the
   reservation until the minimum QoS is hit.

   QoS Description: Describes the actual QoS being reserved. May
   contain the objects QoS Desired, QoS Available, QoS Reserved and
   Minimum QoS. These objects are input or output parameters of the
   Resource Management Function

   QoS Available: Object containing parameters describing the
   available resources. They are used to collect information along a
   reservation path.

   QoS Desired: Object containing parameters describing the desired
   QoS and/or the traffic for which the sender request reservation.

   QoS Model: A methodology to achieve QoS for a traffic flow, e.g.
   IntServ Controlled Load.

   QoS Reserved: Object containing parameters describing the reserved
   resources and related QoS parameters (e.g. Slack Term)

   QoS Signaling Policy (QSP): A signaling policy describing how to use
   QoS NSLP to signal for a specific QoS Model

   QSPEC Control Information: Control information that is specific to a
   QSPEC, and processed in QSPEC-specific NSLP Processing.

   QSPEC-specific NSLP Processing: Functions in a QNE that process QSP
   Control Information and are specific to each QoS Model.

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

   QSPEC parameter: any parameter appearing in a QSPEC, for example,
   scope of QSPEC or token bucket.

   QSPEC object: Main building blocks of QoS Description containing
   a parameter set that is input or output of a Resource Management
   Function operation.

   QSP-Specific Parameter: QSPEC parameter defined for a specific QSP
   and for which QNEs SHOULD provide meaningful interpretations when
   applicable to the underlying technology.

   Resource Management Function: Functions that are related to resource
   management, specific to a QoS Model. It processes QoS Description.


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   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

3. Applicability

3.1 Processing of QSPEC

   The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control
   information is interpreted and perhaps modified by the QSPEC-specific

   NSLP processing, and the QoS description is interpreted and may be
   modified by the Resource Management Function (see Figure 1 and
   description in [QoS-SIG]).

   A domain that wishes to support QoS NSLP signaling decides on a
   number of QoS Signaling Policies (QSPs) that will be supported by its
   nodes. A QSP is a way of using QoS NSLP to achieve QoS reservations
   over the domain. Examples of QSPs are IntServ, DiffServ, RMD, UMTS,
   etc.

   The definition of a QSP includes the specification of how the
   Requested QoS resources will be described in the network and how they

   will be managed by the Resource Management Function (RMF).  For this
   purpose, the QSP specifies a set of QoS specification (QSPEC)
   parameters that describe the QoS traffic and a QoS resource control.
   QSPEC parameters are conceptually organized in three levels:
   generic-mandatory parameters, generic-optional parameters, and
   QSP-specific parameters.  These parameters form a tree structure with
   increasing specificity from the root to the leaves, and are carried
   in the QSPEC object in a QoS NSLP message.

   In order to provide end-to-end interoperability, generic QSPEC
   parameters are defined in a QSPEC template discussed in this
   document.  Generic-mandatory parameters MUST be understood by all QoS

   NSLP compliant nodes.  Generic-optional parameters SHOULD be used if
   they are appropriate for the QSP in use in a certain domain.
   Specification of additional generic QSPEC parameters requires
   standards action, as defined in this document.  QSP-specific
   parameters are defined in separate QSP (informational) documents.

   A QoS NSLP message can contains a stack of 1+n QSPECs. The top of the
   Stack is the Initiator QSPEC. This is an immutable QSPEC provided by
   the QNI which travels end-to-end, and therefore the stack always has
   at least depth 1. In addition, the stack may contain n local QSPECs,
   where n is the level of nested QSP regions in a domain. A QNE only
   considers the topmost QSPEC at each of its interfaces.

   The Initiator QSPEC contains up to three parts: generic mandatory
   parameters, generic optional parameters and QSP-specific parameters
   for up to two QSPs. The second set of QSP-specific parameters can be

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   used, for example, in a remote access network.  Local QSPECs have a
   structure similar to the Initiator QSPEC, except they can only
   contain QSP-specific parameters for a single QSP.  They may be
   pushed on the stack at the edge of a domain in order to describe the
   requested resources in a domain-specific manner. Also, the local
   QSPECs are popped from the stack at the edge of the domain. In most
   cases, we expect the stack to be no deeper than 2.

3.2 Generic Parameters

   The QSPEC template defines a format for the QSPEC, as well as a
   number of generic-mandatory and generic-optional QSPEC parameters.
   Generic parameters provide a common language for QSP developers to
   build their QSPECs and are likely to be re-used in several QSPs.
   All parameters used in DiffServ and IntServ QSPs are generic
   parameters.  A QSPEC is specific to a QSP and is identified by a QSP
   ID carried in QoS NSLP.

   As stated above, we define generic-mandatory parameters,
   generic-optional parameters, and QSP-specific parameters.  A QNI MUST
   populate and a QNE resource management function (RMF)MUST provide a
   meaningful interpretation of all generic-mandatory parameters for a
   given QSP.  A QNI SHOULD populate and a QNE RMF SHOULD provide a
   meaningful interpretation of a generic-optional parameter if the
   underlying technology supports it.  A specific QSP may, however, only

   use a subset or perhaps none of the generic-mandatory or
   generic-optional QSPEC parameters.  Furthermore, a QSP may define
   additional parameters called QSP-specific parameters, which are
   defined in separate Informational documents specific to a given QSP.

3.3 Extensibility

   Additional generic-mandatory or generic-optional may need to be
   defined in the future.  This can be done by modification of this
   document.  Additional QSP-specific parameters are defined in separate
   Informational documents specific to a given QSP.

4. QSPEC Format Overview

   QSPEC = <QSPEC Control Information> <QoS Description>

   As described above, the QSPEC object contains the actual resource
   description (QoS description) as well as QSPEC control information.
   Both QoS description and QSPEC control information may contain
   read-write and read-only objects.

   Read-write objects can be changed by any QNE, including by QoS NSIS
   functions along the signaling path, whereas read-only objects are
   fixed by the initiating QNE and/or responding QNEs. An example of a
   read-write object is the QoS Available, which is updated by
   intermediate QNEs. An example of a read-only object is QoS Desired
   as sent by the QNI.


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


4.1. QSP Specific Control Information

   QSP specific control information is used for QSPEC-specific control
   information and for specific signaling functions not defined in QoS-
   NSLP. It enables building a new signaling policy within a QoS-NSLP
   signaling framework, see for example [RMD-QSP].

   Generic-Optional Parameter: <Hop Count>

   This read-write hop count field limits the maximum number of QoS-NSLP
   hops. <Hop Count> must not be confused with the scope of the QoS NSLP
   message carrying the QSPEC.  This scope would be coded in the Common
   Control Information.

   Generic-Optional Parameter: <Excess Treatment>

   This read-write 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 adjusted as needed by QNEs.

4.2 QoS Description

   The QoS Description is broken down into the following objects:

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

   Of these objects, QoS Desired and Minimum QoS are read-only, whereas
   QoS Available and QoS Reserved are read-write. If it needs to be
   ensured that QoS Desired and Minimum QoS are indeed not changed along
   the path, it is possible to apply selective protection of these
   objects only. The verification is based on cryptographic procedures.

   On the QSPEC template level, the only restriction on object usage is
   that <Minimum QoS> should always travel together with <QoS Available>
   and/or <QoS Desired>. Otherwise there is no restriction on how many
   of these objects a QSPEC may carry, nor what type of object is
   carried in what type of QoS NSLP message.  For example, in a
   receiver-initiated reservation scenario, the initiating QNE may send
   a QUERY carrying a <QoS Available> object to probe the available
   resources on the path. The same QUERY may carry a <QoS Desired>
   object.  The responding QNE can re-use the latter objects in the
   RESERVE message.  The QoS NSLP and particularly the QSPs prescribe
   how the objects in QSPECs are interpreted and used, and therefore
   restrict this freedom.

   The union of all the objects identified in this Section can provide
   all functionality of the objects specified in RSVP IntServ.  QoS
   Desired may in fact just be a description of traffic to be sent, but
   it may also include more parameters (e.g. delay) or signal for more
   resources than those derived from an exact traffic description (e.g.
   a token bucket with a higher peak rate).  Furthermore all objects can
   carry the same parameter types.  Hence, a QNI could send a RESERVE
   with QoS Desired contained a particular Average bandwidth, and at the
   same time include a QoS Available Object for querying availability of

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   this same parameter.  If QoS Desired cannot be reserved, the QNR can
   use the information Collected in QoS Available along the path to
   signal back to the QNI a more promising value of QoS Desired.  The
   details of such Message exchanges are defined in [QoS-Sig].

4.2.1 <QoS Desired>

   <QoS Desired> = <R> <Token Bucket> <QoS Class> <Priority>

   Generic-Mandatory Parameters: <R>

   Generic-Optional Parameters: <Token Bucket> <QoS Class> <Priority>

   These parameters describe the resources the QNI desires to reserve
   and hence this is a read-only object. QoS Desired may be an accurate
   description of the traffic the QNI is going to inject into the
   network.  It may however also ask for more (or less) resources.

   <R> = link bandwidth flow is entitled to [RFC 2212]

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

   <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)
   [DIFFSERV, DCLASS], or DiffServ-enabled MPLS traffic engineering
   (DSTE) class type [DSTE].

   <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 was 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.  These are read-only parameters.

4.2.2 <QoS Available>

   <QoS Available> = <NON QSP Hop> <QSP Hops> <Available Bandwidth> <Min
   Latency> <M> <Ctot> <Dtot> <Csum> <Dsum> <Priority>

   Generic-Mandatory Parameters: <NON QSP Hop> <QSP Hops>
                                 <Available Bandwidth>


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   Generic-Optional Parameters: <Min Latency> <Ctot> <Dtot> <Csum>
                                <Dsum>

   These parameters describe the resources currently available on the
   path and hence the object is read-write. They are defined in
   [RFC 2210, 2212, 2215].

   <NON QSP Hop> is a flag bit telling the QNR (or QNI in a RESPONSE
   message) whether or not a completely reservation-capable path exists
   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
   provide QoS control services at all.  If this bit is set, the values
   of all other parameters in the <QoS Available> are unreliable.

   <QSP Hops> indicates the number of hops in the NSLP aware network
   which support a given QSP.  The QNE MUST support and characterize the

   service in conformance with the relevant QSP specification, and if it

   does not it must correctly set the <NON QSP Hop> flag parameter.  The
   composition rule for this parameter is to increment the counter by
   one at each QSP-aware hop.  This quantity, when composed from the QNI

   to QNR informs the QNR (or QNI in a RESPONSE message) of the number
   of QSP-aware QNEs traversed along the path.

   The <Available Bandwidth> parameter provides information 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 <Min 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 <Min 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

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   gives the application knowledge of both the minimum and maximum
   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.

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

   Each QNE must inspect this object. 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.

4.2.3 <QoS Reserved>

   <QoS Reserved> = <R> <S> <Token Bucket> <QoS Class> <Priority>

   These parameters describe the QoS reserved by the QNEs down the
   path. <R>, <Token Bucket>, <QoS Class> and <Priority> are defined
   above.

   Generic-Optional Parameter: <S> = slack term: difference between
   desired delay and delay obtained by using reservation level R (used
   to reduce resource reservation for flow) [RFC 2212].  This is a
   read-write parameter.

4.2.4 <Minimum QoS>

   <Minimum QoS> = <R> <Token Bucket> <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 an read-only object. The desired QoS is included with a <QoS
   Desired> and/or a <QoS Available> object seeded to the desired QoS
   value. The minimum acceptable QoS value is coded in the <Minimum QoS>

   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 failed and can be aborted. When
   this method is employed the QNR SHOULD signal back to the QNI the
   value <QoS Available> attained in the end, because the reservation

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   may need to be adapted accordingly.

5. QSPEC Functional Specification

   This Section defines the encodings of the QSPEC parameters and
   control information defined in Section 4.

5.1 <Hop Count> Parameter

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |   Hop Count   |
   +-+-+-+-+-+-+-+-+

   Hop Count: 8 bits
       Indicates the maximum number of NSLP hops between the QNI and
       QNR.  Values of the composed parameter will range from 1 to 255,
       limited by the bound on IP hop count.

5.2 <Excess Treatment> Parameter

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

   Excess Treatment: 8 bits
       Indicates how the QNE should process out-of-profile traffic.
       Allowed values are as follows:
       0: drop
       1: shape
       2: remark
       The excess treatment parameter is initially set by the QNI and
       adjusted as needed by QNEs.

5.3 <NON QSP Hop> & <QSP Hops> Parameters [RFC 2210, 2215]

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  NON QSP Hop  |    QSP Hops   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NON QSP Hop: 8 bits
       This field is set to 1 if a non QSP-aware QNE is encountered on
       the path from the QNI to the QNR.

   QSP Hops: 8 bits
       Indicates the number of QSP hops between the QNI and QNR.  Values

       of the composed parameter will range from 1 to 255, limited by
       the bound on IP hop count.


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


5.4 <R> & <S> Parameters [RFC 2212]

   The rate R 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>.  The rate term R can be represented
   using single-precision IEEE floating point.  Slack term S MUST be
   hnonnegative and is measured in microseconds.

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

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

5.5 <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 (M).

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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 [M]  (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.

5.6 <QoS Class> Parameters

5.6.1 <PHB Class> Parameter [DIFFSERV-CLASS]

Encoding of the DiffServ per-hop-behavior (PHB) class if as follows:


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


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

   PHB Class: 8 bits
       Indicates the PHB class. Values currently allowed are 0, 1, 2,
       3, ..., 20.

Encoding of the PHB Class parameter is taken from [DIFFSERV-CLASS]:

    ------------------------------------------------------------------
   |   Service     |PHB Class|    DSCP     |       Application        |
   |  Class Name   | (Name)  |    Value    |        Examples          |
   |===============+=========+=============+==========================|
   |Administrative |0 (CS7)  |   111000    | Heartbeats               |
   |---------------+---------+-------------+--------------------------|
   |Network Control|1 (CS6)  |   110000    | Network routing          |
   |---------------+---------+-------------+--------------------------|
   |Telephony      |2 (EF)   |   101110    | IP Telephony bearer      |
   |---------------+---------+-------------+--------------------------|
   |Signaling      |3 (CS5)  |   101000    | IP Telephony signaling   |
   |---------------+---------+-------------+--------------------------|
   |Multimedia     |4 (AF41) |   100010    | H.323/V2 video           |
   |Conferencing   |5 (AF42) |   100100    | conferencing (elastic)   |
   |               |6 (AF43) |   100110    |                          |
   |---------------+---------+-------------+--------------------------|
   |Real-time      |7 (CS4)  |   100000    | Video conferencing and   |
   |Interactive    |         |             | Interactive gaming       |
   |---------------+---------+-------------+--------------------------|
   |Multimedia     |8 (AF31) |   011010    | Streaming video and      |
   |Streaming      |9 (AF32) |   011100    | audio on demand          |
   |               |10 (AF33)|   011110    |                          |
   |---------------+---------+-------------+--------------------------|
   |Broadcast Video|11 (CS3) |   011000    |Broadcast TV & live events|
   |---------------+---------+-------------+--------------------------|
   |Low Latency    |12 (AF21)|   010010    |Client/server transactions|
   |Data           |13 (AF22)|   010100    |Web-based ordering        |
   |               |14 (AF23)|   010110    |                          |
   |---------------+---------+-------------+--------------------------|
   |OAM            |15 (CS2) |   010000    | Non-critical OAM&P       |
   |---------------+---------+-------------+--------------------------|
   |High Throughput|16 (AF11)|   001010    | Store and forward        |
   |Data           |17 (AF12)|   001100    | applications             |
   |               |18 (AF13)|   001110    |                          |
   |---------------+---------+-------------+--------------------------|
   |Standard       |19 (DF,  |   000000    | Undifferentiated         |
   |               |    CS0) |             | applications             |
   |---------------+---------+-------------+--------------------------|
   |Low Priority   |20 (CS1) |   001000    | Any flow that has no BW  |
   |Data           |         |             | assurance                |
    ------------------------------------------------------------------


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


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

   Y.1541 QoS classes are defined as follows:

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

   Y.1541 QoS Class: 8 bits
       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.

   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.


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


5.6.3 <DSTE Class Type> Parameter [DSTE]

   DSTE class type is defined as follows:

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

   DSTE Class Type: 8 bits
       Indicates the DSTE class type. Values currently allowed are 0, 1,

       2, 3, 4, 5, 6, 7.

5.7 Priority Parameters

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

    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: 16 bits (unsigned)
      The priority of the new flow compared with the defending priority
      of previously admitted flows.  Higher values represent higher
      priority.

   Defending Priority: 16 bits (unsigned)

5.7.2 <Reservation Priority> Parameter [SIP-PRIORITY]

    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


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   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

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

5.8 <QoS Available> Parameters

5.8.1 <Available Bandwidth> Parameter [RFC 2215]

    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 b/w estimate  (32-bit IEEE floating point number)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Values of this parameter are measured in bytes per second.  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

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   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.

5.8.2 <Min Latency> Parameter [RFC 2210, 2215]

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Minimum path latency (32-bit integer)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The composition rule for the <Min 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. The distinguished value (2**32)-1 is taken to mean
   indeterminate latency. A QNE which cannot accurately predict the
   latency 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 latency 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.

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

    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) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


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

7.  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 (QSP ID) is
   a 32 bit value carried in a QSPEC object.  The allocation policy for
   new QSP IDs is TBD.

   This document also defines 24 objects for the QSPEC Template, as
   Detailed in Section 5.  Values are to be assigned for them from the
   GIMPS Object Type registry.

8.  Acknowledgements

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

9. Intellectual Property Considerations

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


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   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.

10.  Normative References

   [DIFFSERV] S. Blake et. al., "An Architecture for Differentiated
   Services", RFC 2475, December 1998.
   [KEY] S. Bradner, "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997
   [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service
   Signaling," work in progress.
   [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.
   [RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP) --
   Version 1 Functional Specification," RFC 2205, September 1997.
   [RSVP-INTSERV] J. Wroclawski, "The Use of RSVP with IETF Integrated
   Services", RFC 2210, September 1997.

11.  Informative References

   [DCLASS] Bernet Y., Format of the RSVP DCLASS Object, RFC 2996,
   November 2000
   [DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines
   for DiffServ Service Classes," work in progress.
   [DSTE] F. Le Faucheur et. al., Requirements for Support of
   Differentiated Services-aware MPLS Traffic Engineering, RFC 3564,
   July 2003
   [INTSERV] B. Braden et. al., "Integrated Services in the Internet
   Architecture: an Overview," RFC 1633, June 1994.
   [INTSERV-QSP] C. Kappler, "A QoS Model for Signaling IntServ
   Controlled-Load Service with NSIS," work in progress.
   [NSIS-REQ] M. Brunner et. al., "Requirements for QoS Signaling
   Protocols", work in progress.
   [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling
   Protocol - Capability Set 3" Sep. 2003
   [RMD-QSP] A. Bader, L. Westberg, G. Karagiannis, C. Kappler and T.
   Phelan, " RMD-QSP: 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,
   "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-QSP] J. Ash, et. al., "NSIS Network Service Layer Protocol
   QoS Signaling Proof-of-Concept," work in progress.

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


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

   Georgios Karagiannis
   University of Twente
   P.O. BOX 217
   7500 AE Enschede
   The Netherlands
   EMail: g.karagiannis@ewi.utwente.nl

   Andrew McDonald
   Siemens/Roke Manor Research
   Roke Manor Research Ltd.
   Romsey, Hants SO51 0ZN
   UK
   EMail: andrew.mcdonald@roke.co.uk

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   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: Example QSPECs

   Note the mere definition of QSPECs is not sufficient for determining
   how to signal for DiffServ and IntServ respectively. Rather, the
   full QSP needs to be defined.

A.1 QSPEC for Admission Control for DiffServ

   QSPEC for Diffserv QSP in general may be provided in future versions
   of this draft.  A QSPEC for a DiffServ QSP is included in [RMD-QSP].

A.2 QSPEC for IntServ Controlled Load Service

   The QoS Model 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 [RSVP-INTSERV] and [RFC2215].

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

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

   <QoS Desired> = <Token Bucket>
   <QoS Available> = <non QSP hop> <QSP hops> <Available Bandwidth>
                     <Min Latency> <M>
   <QoS Reserved> = <Token Bucket>

   An IntServ over Diffserv QSPEC is


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   <QoS Desired> = <Token Bucket>
   <QoS Class> = <PHB Class>
   <QoS Available> = <non QSP hop> <QSP hops> <Available Bandwidth>
                     <Min Latency> <M>
   <QoS Reserved> = <Token Bucket>

   Or a simple QSPEC for Diffserv requesting bandwidths for different
   PHBs is

   <QoS Desired> = <R>
   <QoS class> = <PHB Class>

A.3 QSPEC for IntServ Guaranteed Services

   The QoS Model 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 guarantied services is the following:

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

   <QoS Desired> = <Token Bucket>

   This object contains token bucket parameters defined in [RFC 2210].
   (equivalent to TSpec defined in RSVP).

   <QoS Available> = <non QSP hop> <QSP hops> <Available Bw>
   <Min Latency> <MTU> <Ctot> <Dtot> <Csum> <Dsum>

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

   <QoS Reserved> = <Token Bucket> <R> <S>
   Requested Rate and Slack Term defined in [RFC 2212], equivalent to
   RSpec of RSVP.

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

Appendix B: Example of NSLP QSPEC Operation

   This Appendix illustrates the operation and use of the QSPEC within
   the NSLP.  The example configuration looks like this:


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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


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

   In this configuration, a laptop computer and a handheld wireless
   device are the end points for some application that has QoS
   requirements.  Assume that the two end points are stationary during
   the application session.  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
   DQOS support.  That network is connected to a Diffserv core network
   that uses RMD.  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,
   and the QNEs in between all implement NSLP/QSPEC.  There are two ways
   to signal the flow:

   Option A. The Laptop-QNI discovers which QSPs are supported on the
   data path by sending a QUERY message along the data path.  The
   RESPONSE message indicates the preferred QSP supported in the domains

   along the path.  The Laptop-QNI then knows that the RMD-QSP and
   XG-QSP are in the path and stacks the appropriate generic parameters
   needed by the RMD-QSPEC and XG-QSPEC in the RESERVE message.  It can
   also stack the QSP-specific parameters need by the XG-QSP in a second
   QSPEC to be used only within the XG-QSP domain.

   Option B. The QNI creates a reservation request and includes the
   initiator QSPEC with the generic parameters.  Each QNE extracts the
   generic parameters it needs to implement the QSP within the domain.
   For example, in the RMD domain the <R> parameter is extracted, or
   alternatively it is translated based on <Token Bucket> parameters.
   On the other hand, at the XG network ingress, a 'Local QoS Model'
   and Local-QSPEC corresponding to the XG-QSP are generated according
   to the procedures described in Section 4.5 of [QoS-SIG].  That is,
   the XG-QNI must map between the two resource descriptions and
   construct the appropriate second 'local' QSPEC object to be pushed on
   top.  This top QSPEC becomes the current QSPEC used within the XG-QSP
   domain, that is, the translated QSPEC becomes the first QSPEC, and
   the original initiator QSPEC is second.  This saves the XG-QNEs the
   trouble of re-translating the initiator QSPEC.  At the egress edge of
   the XG-QSP domain, the translated QSPEC is popped, and the initiator
   QSPEC returns to the number 1 position.  (Note that stand-along QNEs

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   simply forward the initiator QSPEC, and the translated QSPEC (if any)
   is only used within the QNE.  Eventually the RESERVE request arrives
   at the QNR.

Appendix C: QoS Models, QoS Signaling Policies and QSPECs

   This Appendix gives a description of QoS Models, QSPs 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 QoS Models. A QoS Model is a particular QoS provisioning method
   or QoS architecture such a IntServ Controlled Load, Guaranteed
   Service. DiffServ, or RMD for DiffServ.

   The definition of the QoS Model is independent from the definition
   of QoS NSLP. Existing QoS Models do not specify how to use QoS NSLP
   to signal for them. Therefore, we need to define the QoS Signaling
   Policy (QSP), specific to each QoS Model, which describes the QoS
   Model specific signaling functions. QoS Signaling Policy are defined
   for "Resource Management in DiffServ" in [RMD-QSP] and for IntServ
   Controlled Load in [INTSERV-QSP].

   A QSP should include the following information:

   - Role of QNEs in this QoS Model:
   E.g. location, frequency, statefulness...
   - QSPEC Definition:
   A QSP should specify the QSPEC, including generic and optional
   parameters. Furthermore it needs to explain how generic parameters
   not used in this QSP are mapped onto parameters defined therein.
   - Message Format
   Objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY
   - State Management
   It describes how QSPEC info is treated and interpreted in the
   Resource Management Function and QSP 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 QoS Model.

Appendix D: 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.

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

Internet Draft          QoS-NSLP QSPEC Template           December 2004


   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 debate at this point lead us
   to a slightly different mapping of necessary functionality to
   objects, which should result in more flexible signaling models.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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.

   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.

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.

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


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/