Internet DRAFT - draft-ash-nsis-nslp-qspec


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

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

   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  The list of Internet-
   Draft Shadow Directories can be accessed at

Copyright Notice

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

Ash et al.               Expires - January 2005                [Page 1]
Internet Draft           QoS-NSLP QSpec Template              July 2004


   This draft describes a QSpec template for the QoS NSIS Signaling 
   Layer Protocol (QoS NSLP) for signaling QoS reservations in the 
   Internet. A QSpec is transported in QoS-NSLP messages and is opaque 
   to QoS NSLP. It contains the QoS Signaling Model (QSM) Control 
   Information and QoS Description parameters. Control Information is, 
   for example, the scope of a particular QSpec. QoS Description 
   parameters are primary input and output parameters of the Resource 
   Management Function.  They include descriptions of the QoS desired 
   and the QoS reserved. QoS Description parameters can also be used 
   for collecting information about resource availability along the 
   path and for signaling a range of acceptable QoS. The QSpec template 
   defines generic parameters that are common to many QSMs. 
   Particularly they are derived from the IntServ and DiffServ QoS 
   Models. They should be used by all QSMs if applicable and must be 
   understood by all QNEs. By identifying the generic parameters we aim 
   to ensure interoperability between different QSMs.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .3
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3. Processing of QSpec . . . . . . . . . . . . . . . . . . . . . . 5
   4. QSpec Template . . . . . . . . . . . . . . . . . . . . . . . . .6
   4.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . .6
   4.2 QSpec Format Overview . . . . . . . . . . . . . . . . . . . . .8
   4.2.1 QSM Specific Control Information . . . . . . . . . . . . . . 8
   4.2.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 10 QoS Desired . . . . . . . . . . . . . . . . . . . . . . . 11 QoS Available . . . . . . . . . . . . . . . . . . . . . . 12 QoS Reserved . . . . . . . . . . . . . . . . . . . . . . .12 Minimum QoS . . . . . . . . . . . . . . . . . . . . . . . 12
   5. Security Considerations . . . . . . . . . . . . . . . . . . . .13
   6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . .13
   7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   8. Intellectual Property Considerations . . . . . . . . . . . . . 14
   9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .16
   Appendix A Example Qspecs . . . . . . . . . . . . . . . . . . . . 17
   A.1 QSpec for Admission Control for DiffServ . . . . . . . . . . .17
   A.2 QSpec for IntServ Controlled Load Service . . . . . . . . . . 18
   A.3 QSpec for IntServ Guaranteed Load Service . . . . . . . . . . 18
   Appendix B QoS Models, QoS Signaling Models and QSpecs . . . . . .19
   Disclaimer of Validity and Copyright Statement . . . . . . . . . .20

Ash et al.              Expires - January 2005                 [Page 2]
Internet Draft          QoS-NSLP QSpec Template               July 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 

   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 usage of QoS NSLP to signal for a specific 
   QoS Model is called 'QoS Signaling Model'. Examples of different 
   QSMs for NSIS are specified in [TRQ-QoS-SIG, INTSERV-QoS-SIG, RMD-
   QoS-SIG]. For more information on QoS Models and QSMs see the 

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

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

   The QoS Description can have sub-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 a sub-object denoting minimum QoS. Usage 
   of these sub-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.

Ash et al.              Expires - January 2005                 [Page 3]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   This draft provides a template for QSpec, which is needed in order 
   to help defining individual QSMs and in order to promote 
   interoperability between QSMs.
   The processing of QSpec is described in more detail in Section 2.  
   The proposed QSpec template is given in Section 3, including an 
   applicability statement. Appendix A proposes preliminary QSpecs for 
   the IntServ Controlled Load and Guaranteed Service QoS Models. 
   Appendix B explains in more detail the relation between QoS Models, 
   QSMs and QSpecs. It also explains the current understanding of the 
   content of a QSM.

2. Terminology

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

   Generic Parameter: Parameter that MUST be understood by any QNE, and 
   SHOULD be used if applicable

   Immutable Parameter: Parameter that is set by initiating or 
   responding QNE and is not changed during the processing of QSpec 
   along the path

   Minimum QoS: Minimum QoS is a functionality that MAY be supported by 
   any QSM: 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. 

   Mutable Parameter: Parameter that can be changed during the 
   processing of QSpec by any QNE along the path

   Optional Parameter: Parameter that SHOULD be used by QSMs if 

   QoS Description: Container of the QSpec sub-objects, which describes 
   QoS. These parameters are input or output parameters of Resource 
   Management Function

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

   QoS Desired: The description of the desired QoS and/or the traffic 
   for which the sender request reservation. 

Ash et al.              Expires - January 2005                 [Page 4]
Internet Draft          QoS-NSLP QSpec Template               July 2004

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

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

   QoS Signaling Model (QSM): A signaling model describing how to use 
   QoS NSLP to signal for a specific QoS Model 

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

   QSM-specific NSLP Processing: Functions in a QNE that process QSM 
   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, e.g. scope of 
   QSpec or token bucket.

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

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

3. Processing of QSpec

   The model of QoS-NSLP message processing is illustrated in Figure 1. 
   A QoS-NSLP message is interpreted in the common NSLP processing of a 
   QNE as described in [QOS-SIG]. The QSpec, however, is opaque to QoS-
   NSLP, which means that it is not processed in the common NSLP 
   processing but handed over to the QSM-specific NSLP processing and 
   then to the Resource Management Function (RMF). The QSM control 
   information is interpreted and perhaps modified by the QSM-specific 
   NSLP processing, and the QoS description is interpreted and may be 
   modified by the   resource management function. Both, QSM-specific 
   NSLP processing and the RMF, may advise the common NSLP processing 
   on how to proceed with the signaling, e.g. to tear down a preempted 
   reservation. From an implementation point of view, the   common NSLP 
   processing is the same in each NSIS capable router, whereas QSM-
   specific NSLP processing and the RMF are QSM specific.  Note that 
   the QSM-specific NSLP processing box is an addition to the QoS-NSLP 
   processing model of [QoS-SIG] suggested in this document. 

Ash et al.              Expires - January 2005                 [Page 5]
Internet Draft          QoS-NSLP QSpec Template               July 2004

                                   |     Local     |
                                   |Applications or|
                                   |Management (e.g|
                                   |for aggregates)|
         +-------------+     +------------+----------+   +---------+
         |Common NSLP  |     |QSM-specific| Resource |   | Policy  |
         | Processing  +<<>>>|    NSLP    |Mgmt. Fct.|<<>| Control |
         |             |     | Processing |          |   |         |
         +-------------+     +------------+----------+   +---------+
              .  ^   |                   * ^
              |  V   .                *    ^
            +----------+            *      ^
            |   GIMPS  |         *         ^
            |Processing|       *           V
            +----------+       *           V
              |      |         *           V
              .      .         *           V
              |      |         *     .............................
              .      .         *     .   Traffic Control         .
              |      |         *     .                +---------+.
              .      .         *     .                |Admission|.
              |      |         *     .                | Control |.
    +----------+    +------------+   .                +---------+.
   -|  Input   |    | Outgoing   |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
    |  Packet  |    | Interface  |   .+----------+    +---------+  
  =>|Processing|====| Selection  |===.|  Packet  |====| Packet  |.=>         
    |          |    |(Forwarding)|   .|Classifier|     Scheduler|.
    +----------+    +------------+   .+----------+    +---------+.

              Figure 1. Model of QoS-NSLP Processing in a QNE

4. QSpec Template

4.1. Applicability

   The QSpec template defines a format for the QSpec, as well as a 
   number of generic and optional QSpec parameters. Generic parameters 
   provide a common language for QSM developers to build their QSpecs 
   and are likely to be re-used in several QSMs.  

Ash et al.              Expires - January 2005                 [Page 6]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   This eases comparing different QSpecs and different QSMs - and 
   possibly simplifies mapping of one into another.  Thus developers 
   should avoid defining parameters similar to the generic, 
   standardized ones. All parameters used in DiffServ and IntServ QSMs 
   are generic parameters.

   A specific QSM may, however, only use a subset or perhaps none of 
   the generic QSpec parameters.  For instance, it may only allow the 
   token bucket to be specified.  Furthermore, a QSM may define 
   additional parameters.  

   All QNEs must be able to understand the generic parameters. It is 
   important to note this does not imply they must also implement all 
   generic parameters (e.g. token bucket). However they must be able to 
   provide a meaningful mapping to locally used parameters.

   Hence, to summarize, generic parameters SHOULD be used by QSMs if 
   applicable.  Generic parameters MUST be understood by any QNE. QNEs 
   do not need to implement generic parameters. They MUST however be 
   able to provide a meaningful mapping from generic parameters onto 
   local parameters. If they translate generic parameters into local 
   ones they must raise an appropriate flag (tbd).

   Optional parameters SHOULD be used by QSMs if applicable, and 
   defining optional parameters facilitates interworking.  However, 
   QNEs outside the domain employing a particular QSM cannot be 
   expected to understand the optional parameters.

   A QSpec is specific to a QSM and is identified by a QSM ID carried 
   in QoS NSLP. However, as explained above, the generic parameters 
   contained in a QSpec are understood by any QNE, even if the 
   corresponding QSM is not known. Therefore a QNE SHOULD interpret the 
   generic parameters contained in a QSpec, even if it does not 
   understand the QSM. QoS NSLP provides appropriate error codes to 
   attach to the QSpec which indicate such a translation took place. 
   Hence, generic parameters ease global intelligibility of QoS NSLP 

   It needs to be investigated whether a minimal set of generic QSpec 
   parameters MUST even be implemented in any QNE: this may be 
   important for true interoperability of QSMs. The set of QSpec 
   parameters that MUST be supported could be a subset of the generic 
   ones defined here.

   This version of the QSpec Template Draft only defines generic 
   parameters. Examples for optional parameters will be provided in the 

Ash et al.              Expires - January 2005                 [Page 7]
Internet Draft          QoS-NSLP QSpec Template               July 2004

4.2. QSpec Format Overview

   QSpec = <QSM Control Information> <QoS Description>

   As described above, the QSpec object contains the actual resource 
   description (QoS description) as well as QSM control information.  
   Both QoS description and QSM control information may contain mutable 
   and immutable parameters.

   Mutable parameters can be changed by any QNE, including by QoS NSIS 
   functions along the signaling path, whereas immutable parameters are 
   fixed by the initiating QNE and/or responding QNEs. An example of a 
   mutable parameter is the path's MTU, an example of an immutable 
   parameter is a token bucket describing the traffic to be sent.

4.2.1. QSM Specific Control Information

   QSM 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 model within a QoS-NSLP 
   signaling framework, see for example [RMD-QoS-SIG] and [RMD-QSM].

   Generic parameters:

   - <Hop Count>

   mutable hop count field, limiting the scope of QSpec to a 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.

   - <Service Schedule> = <start time>, <end time> | <relative time 
   duration from RESPONSE>

   immutable parameter, indicating the desired start time and end time 
   of the service, i.e. when is the service available. The values for 
   <end time> and <relative time duration from RESPONSE> respectively 
   can be infinity, in which case the reservation can be ended by the 
   usual tearing RESERVE. The Service Schedule parameter has two-fold 

   a. Reservation of resources for the immediate future when the full 
   flow ID (e.g. port number) is still being negotiated. In this time 
   <start time> is set to zero. 

Ash et al.              Expires - January 2005                 [Page 8]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   b. Scheduling of reservations ahead of time to make sure resources 
   will be available. An example is reservation of resources for a 
   video-conference. Also in this case the full flow ID may not be 
   known at the time of reservation. 

   Hence, in both cases the QNI sends an incomplete RESERVE prompting 
   the Resource Management Function to set aside resources without 
   actually configuring the router(s). Router configuration is 
   triggered by a RESERVE containing the full flow ID. Appropriate 
   security measures need to be taken to prevent Denial of Service 
   abuse of this functionality (tbd). 

   It needs to be considered whether Service Schedule should be an 
   optional parameter because supporting it involves some overhead: the 
   RMF needs functionality to set aside resources in advance and 
   configure the router(s) later. Furthermore, for large advance 
   reservations, it may be necessary to "phase out" ongoing 
   reservations much earlier than the actual reservation in order to 
   make sure resources will be available. 

   Note that even reservations that are "scheduled" need to be 
   refreshed just as ongoing reservations. Refresh periods are specific 
   to a particular state in a particular QNE [QoS-SIG]. Hence it is 
   conceivable that QNEs decide locally to make the refresh period for 
   scheduled reservations considerably longer than that for ongoing 

   - Flag indicating unsuccessful reservation in stateless/reduced 
   state QNEs

   Since in case of stateless/reduced state QoS-NSLP operation interior 
   nodes do not store per flow information edge nodes should be 
   notified about unsuccessful reservation, see further specification 
   in [RMD-QSM].  

   - Flag indicating severe congestion in stateless/reduced state QNEs

   Similarly to unsuccessful reservation, in case of sever congestion 
   this flag may be set in refresh messages. Note that severe 
   congestion notification can be done also by data remarking, see more 
   details in [RMD-QSM].  

   Note that stateless/reduced state operation mode is used in some 
   DiffServ based QoS signaling models, see for example [RMD-QSM]. 
   These control fields are needed because interior routers do not 
   store per flow QoS-NSLP states and they are used for notifying edge.

Ash et al.              Expires - January 2005                 [Page 9]
Internet Draft          QoS-NSLP QSpec Template               July 2004

4.2.2 QoS Description

   The QoS Description objects are broken down into the following 

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

   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 sub-objects a QSpec may carry, nor what type of 
   sub-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> sub-
   object to probe the available resources on the path. The same QUERY 
   may carry a <QoS Desired> sub-object. The responding QNE can re-use 
   the latter objects in the RESERVE message.  The QoS NSLP and 
   particularly the QSMs prescribe how the sub-objects in QSpecs are 
   interpreted and used, and therefore restrict this freedom.

   The union of all the sub-objects identified in this Section 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 debate at this point let us to a slightly 
   different mapping of necessary functionality to sub-objects, which 
   should result in more flexible signaling models.

   Particularly, we settled for defining a "QoS Desired" rather than a 
   "Traffic Specification". QoS Desired may in fact just be a
   description of traffic to be sent, but it may also include more

Ash et al.              Expires - January 2005                [Page 10]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   parameters (e.g. delay) or signal for resources than those derived 
   from an exact traffic description (e.g. a token bucket with a higher 
   peak rate). Furthermore we consider to allow all sub-objects 
   carrying the same parameter types (to be detailed in future versions 
   of this draft). Hence, a QNI could send a RESERVE with QoS Desired 
   containing a particular average bandwidth, and at the same time 
   include a QoS Available sub-object for querying availability of 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 need to be fixed elsewhere. <QoS Desired>

   <QoS Desired> = <R> <token bucket> <QoS class> <Priority>

   These parameters describe the traffic the QNI is going to inject 
   into the reservation and hence it is immutable.

   <R> = reserved rate desired

   <token bucket> = <r> <b> <p> <m> <M>
   as defined in [RFC 2210]

   <QoS-class> = <PHB> <Y.1541 QoS class> <DS-TE 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], or DiffServ-enabled
   traffic engineering (DS-TE) class type [DS-TE].

   <Priority> = <Emergency>

   Reservation priority is an essential way to differentiate flows for 
   emergency services, ETS, E911, etc., and assign them a higher 
   priority than normal priority flows. Appropriate security measures 
   need to be taken to prevent abuse of this parameter.  These are 
   immutable parameters.

   There has been some debate whether such priority parameters should 
   be generic to all NSLPs, generic to QoS-NSLP, or generic to QSMs, 
   that is, where they should be defined.  It is beyond the scope of 
   this document whether the priorities defined here are also useful in 
   other NSLPs.  However, we believe in the context of QoS-NSLP that 
   priority is best placed in the QSM and QSpec. The reason is that the 

Ash et al.              Expires - January 2005                [Page 11]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   resource management function seems to function more efficiently if 
   priority state is held there rather than in common QoS-NSLP
   processing of messages (see Figure 1).  Only the resource management 
   function knows that resources are not sufficient and that it may be 
   necessary to preempt a reservation.  If preemption state was 
   associated with QoS-NSLP state rather than with resource management 
   state, the resource management function would need to negotiate with 
   the common QoS-NSLP processing until the two work out what 
   reservation to preempt.

   Note that although we locate priority parameters with the QSM, the 
   fact that we make them generic parameters could be seen as a 
   recommendation to implement them in all QNEs (see discussion above).

   Note that QoS Desired may carry parameters like desired delay or 
   loss parameters, however these are optional parameters and not 
   specified in this document. <QoS Available>

   <QoS Available> = <non IS hop> <IS hops> <Available Bw> <Min 
   latency> <M> <Ctot> <Dtot> <Csum> <Dsum>

   These parameters describe the resources currently available on the 
   path and are defined in [RFC 2210, 2212, 2215].  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. <QoS Reserved>

   <QoS Reserved> = <token bucket> <QoS-class> <Priority> <R> <S> 

   These parameters describe the QoS reserved by the QNEs down the 
   path. <token bucket> <QoS-class> <Priority> are defined in Sec. above. <R> <S> are defined in [RFC 2212]. These are mutable 
   parameters. <Minimum QoS>

   <Minimum QoS> = <token bucket> <QoS-class> <Priority>

Ash et al.              Expires - January 2005                [Page 12]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   <Minimum QoS> doesn't 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. The desired QoS is included with a <QoS Desired> and/or a 
   <QoS Available> subobject seeded to the desired QoS value. The 
   minimum acceptable QoS value is coded in the <Minimum QoS> 
   subobject. 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 it is important that the QNR signals back to 
   the QNI the value <QoS Available> attained in the end, because the 
   reservation may need to be adapted accordingly. 

5. Security Considerations

   The Service Schedule and Priority parameters raise possibilities for 
   Denial of Service Attacks. How to deal with this will be handled in 
   future versions of this draft.

6.  Open Issues

   a. A detailed discussion of QSM development guidelines needs to be 

   b. A more detailed specification of the generic parameters needs to 
   be given.

   c. The relationship of common NSLP processing, QSM-specific NSLP 
   processing and resource management function, as well as how their 
   tasks differ needs, to be described more clearly.  For example, how 
   do QSM-specific NSLP processing and the RMF influence message 
   processing in common NSLP processing?

   d. Should/can we request that QNEs MUST implement a subset of 
   generic parameters?

   e. May a node compose a QSpec containing more parameters than 
   defined in the QSM it is signaling for, e.g. for later use by other 

   f. The following optional parameters have been proposed to support 
   other QSMs, and need to be discussed for inclusion in the next 
   revisions of the draft:

Ash et al.              Expires - January 2005                [Page 13]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   i) adding the individual parameters:
   <Transfer Delay>, <Delay Variation>, <Packet Loss Ratio>, and 
   <Packet Error Ratio> to all of the QoS Description categories:
   <QoS Desired> <QoS Available> <QoS Reserved> <Minimum QoS>

   ii) Generalize the priority parameter as follows:

   <Priority> = <Reservation Priority> <Setup Priority> <Holding 

   Where <Setup Priority> and <Holding Priority> are as specified in 
   RFC 3209.

   g. Do we need an explicit Traffic Specification, or is a <QoS 
   Desired> that may not exactly describe the issued traffic 

   h. Should Service Schedule be an optional parameter because of the 
   overhead it may introduce? 

7.  Acknowledgements

   The authors would like to thank Robert Hancock and Sven van den 
   Bosch for their helpful suggestions.

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

Ash et al.              Expires - January 2005                [Page 14]
Internet Draft          QoS-NSLP QSpec Template               July 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-

9.  References

   [DIFFSERV] S. Blake et. al., "An Architecture for Differentiated 
   Services", RFC 2475, December 1998.
   [DS-TE] F. Le Faucheur et. al., Requirements for Support of 
   Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, 
   July 2003
   [KEY] S. Bradner, "Key words for use in RFCs to Indicate Requirement 
   Levels", BCP 14, RFC 2119, March 1997
   [INTSERV] B. Braden et. al., "Integrated Services in the Internet 
   Architecture: an Overview," RFC 1633, June 1994.
   [INTSERV-QoS-SIG] 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.
   [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. 
   [RMD-QoS-SIG] A. Bader et. al., "RMD (Resource Management in 
   Diffserv) QoS-NSLP model", work in progress.
   [RMD-QSM] A. Bader, L. Westberg, G. Karagiannis, C. Kappler and T. 
   Phelan, "Resource Management for DiffServ QoS Signaling Model" 
   <draft-ietf-nsis-rmd-diffserv-00>, work in progress.
   [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.
   [TRQ-QoS-SIG] J. Ash et. al., "NSIS Network Service Layer Protocol 
   QoS Signaling Proof-of-Concept," work in progress.
   [QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service 
   Signaling," work in progress.
   [Y.1541] ITU-T Recommendation Y.1541, "Network Performance 
   Objectives for IP-Based Services," May 2002.
   [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling 
   Protocol - Capability Set 3" Sep. 2003

Ash et al.              Expires - January 2005                [Page 15]
Internet Draft          QoS-NSLP QSpec Template               July 2004

10.  Authors' Addresses

   Jerry Ash
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578
   Fax:   +1-(732)-368-8659

   Attila Bader
   Traffic Lab
   Ericsson Research
   Ericsson Hungary Ltd.
   Laborc u. 1 H-1037
   Budapest Hungary

   Chuck Dvorak
   Room 2A37
   180 Park Avenue, Building 2
   Florham Park, NJ 07932
   Phone: + 1 973-236-6700
   Fax:+1 973-236-7453

   Yacine El Mghazli
   Route de Nozay
   91460 Marcoussis cedex
   Phone: +33 1 69 63 41 87

   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin 13627

   Georgios Karagiannis
   University of Twente

Ash et al.              Expires - January 2005             [Page 16]
Internet Draft          QoS-NSLP QSpec Template            July 2004

   P.O. BOX 217
   7500 AE Enschede
   The Netherlands

   Andrew McDonald
   Siemens/Roke Manor Research
   Roke Manor Research Ltd.
   Romsey, Hants SO51 0ZN

   Al Morton
   Room D3-3C06
   200 S. Laurel Avenue
   Middletown, NJ 07748
   Phone: + 1 732 420-1571
   Fax: +.1 732 368-1192

   Percy Tarapore
   Room D1-3D33
   200 S. Laurel Avenue
   Middletown, NJ 07748
   Phone: + 1 732 420-4172

   Lars Westberg
   Ericsson Research
   Torshamnsgatan 23
   SE-164 80 Stockholm, Sweden

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 QSM needs to be defined.

A.1 QSpec for Admission Control for DiffServ 

   QSpec for Diffserv QSM in general may be provided in future versions 
   of this draft. A QSpec for a DiffServ QSM, RMD is partically 
   included in [RMD-QSM]. 

Ash et al.              Expires - January 2005                [Page 17]
Internet Draft          QoS-NSLP QSpec Template               July 2004

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 subobjects 
   <QoS Desired> and <QoS Available>, as well as <QoS Reserved>. Which 
   sub-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 QSM. Parameters in the QSpec are as 

   <QoS Desired> = <token bucket> 
   <QoS Available> = <non IS hop> <IS hops> <Available Bw> <Min 
   latency> <M> 
   <QoS Reserved> = <token bucket> 

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 sub-object contains token bucket parameters defined in [RFC 
   2210]. Equivalent to TSpec defined in RSVP. 

   <QoS Available> = <non IS hop> <IS hops> <Available Bw> <Min 
   latency> <MTU> <Ctot> <Dtot> <Csum> <Dsum>

   These parameters are defined in [RFC 2212] and [RFC 2215]. This sub-
   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 

Ash et al.              Expires - January 2005                [Page 18]
Internet Draft          QoS-NSLP QSpec Template               July 2004

   from parameters contained in <QoS Available>, and may be updated on 
   the return paths.

Appendix B: QoS Models, QoS Signaling Models and QSpecs

   This section gives a description of QoS models, QSMs 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 
   Models (QSMs), specific to each QoS Model, which describes the QoS 
   Model specific signaling functions. QoS Signaling Model are defined 
   for "Resource Management in DiffServ" in [RMD-QSM] and for IntServ 
   Controlled Load in [INTSERV-QoS-SIG].

   A QSM should include the following information: 

   - Role of QNEs in this QoS Model: 
   E.g. location, frequency, statefulness...

   - QSpec Definition: 
   A QSM should specify the QSpec, including generic and optional 
   parameters. Furthermore it needs to explain how generic parameters 
   not used in this QSM 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 QSM 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.

Ash et al.              Expires - January 2005                [Page 19]
Internet Draft          QoS-NSLP QSpec Template               July 2004

Disclaimer of Validity

   This document and the information contained herein are provided on 

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.

Ash et al.              Expires - January 2005                [Page 20]