[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-01.txt>                             Attila Bader
Expiration Date: April 2005                                    Ericsson
                                                       Cornelia Kappler
                                                             Siemens AG


                                                           October 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/ietf/1id-abstracts.txt.  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.              Expires - April 2005                   [Page 1]

Internet Draft           QoS-NSLP QSpec Template           October 2004


Table of Contents


   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .2
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . .4
   3.1 Processing of QSpec. . . . . . . . . . . . . . . . . . . . . . 4
   3.2 Generic Parameters. . . . . . . . . . . . . . . . . . . . . . .5
   3.3 Extensibility. . . . . . . . . . . . . . . . . . . . . . . . . 5
   4. QSpec Format Overview. . . . . . . . . . . . . . . . . . . . . .6
   4.1 QSP Specific Control Information. . . . . . . . . . . . . . . .6
   4.2 QoS Description. . . . . . . . . . . . . . . . . . . . . . . . 7
   4.2.1 QoS Desired. . . . . . . . . . . . . . . . . . . . . . . . . 8
   4.2.2 QoS Available. . . . . . . . . . . . . . . . . . . . . . . . 8
   4.2.3 QoS Reserved. . . . . . . . . . . . . . . . . . . . . . . . .9
   4.2.4 Minimum QoS. . . . . . . . . . . . . . . . . . . . . . . . . 9
   5. Security Considerations. . . . . . . . . . . . . . . . . . . . .9
   6. Open Issues. . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .10
   8. Intellectual Property Considerations. . . . . . . . . . . . . .10
   9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .11
   10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 11
   Appendix A Example Qspecs. . . . . . . . . . . . . . . . . . . . .13
   A.1 QSpec for Admission Control for DiffServ. . . . . . . . . . . 13
   A.2 QSpec for IntServ Controlled Load Service. . . . . . . . . . .13
   A.3 QSpec for IntServ Guaranteed Services. . . . . . . . . . . . .14
   Appendix B QoS Models, QoS Signaling Policies and QSpecs. . . . . 14
   Appendix C Mapping of QoS Desired, QoS Available, and QoS Reserved
   of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ. . . . . . .15
   Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . .16
   Disclaimer of Validity and Copyright Statement. . . . . . . . . . 16


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 [TRQ-QoS-SIG, INTSERV-QoS-SIG, RMD-
   QoS-SIG]. 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.


Ash et al.              Expires - April 2005                   [Page 2]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   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.  The applicability of the QSpec
   is discussed in Section 3. The QSpec template is given in Section 4.
   Section 5 gives security considerations. Appendix A proposes QSpecs
   for the IntServ Controlled Load and Guaranteed Service QoS Models.
   Appendix B explains in more detail the relation between QoS Models,
   QSPs and QSpecs. It also explains the current understanding of the
   content of a QSP. Appendix C explains how the objects defined for the
   QSpec map onto the corresponding TSpec, AdSpec and RSpec of RSVP.


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


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


   Read-write 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 QSPs if
   applicable


Ash et al.              Expires - April 2005                   [Page 3]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   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.


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


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


Ash et al.              Expires - April 2005                   [Page 4]

Internet Draft           QoS-NSLP QSpec Template           October 2004


3.2 Generic Parameters


   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 QSP developers to build their QSpecs
   and are likely to be re-used in several QSPs.  This eases comparing
   different QSpecs and different QSPs - and possibly simplifies
   mapping of one into another.  Thus developers should avoid defining
   proprietary parameters equivalent to the generic, standardized ones.
   All parameters used in DiffServ and IntServ QSPs are generic
   parameters.


   A specific QSP 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 QSP may define
   additional parameters. In any event, generic parameters SHOULD be
   used by QSPs if applicable.


   The Resource Management Function (RMF) in all QNEs must be able to
   understand the generic parameters. This means a Resource Management
   Function is not restricted in how the traffic conditioning of a
   particular generic parameter is implemented. It MUST however be able
   to provide a meaningful implementation of generic parameters.
   Additionally, when QoS properties of a path are collected, a RMF
   must be able to give a meaningful answer.  For example, when a
   RESERVE message carries a QSpec with a token bucket, the RMF must
   be able to update the token bucket parameters according to what
   it is able to provide, even if it does not implement a token
   bucket.


   A QSpec is specific to a QSP and is identified by a QSP 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 QSP is not known. Therefore a QNE SHOULD interpret the
   generic parameters contained in a QSpec, even if it does not
   understand the QSP. I.e. an unknown QSP should not lead to abortion
   of the signaling message, or to not passing the QSpec to the RMF.
   QoS NSLP provides the error code ôUnknown QSPö to indicate only
   generic parameters were interpreted.   Hence, generic parameters
   ease global intelligibility of QoS NSLP messages.


3.3 Extensibility


   A specific QSP may need more parameters than the generic ones. The
   QSpec Template allows additional types of parameters, namely
   optional parameters.


   Optional parameters are parameters that are likely to occur in many
   QSPs, which however are necessary neither for the DiffServ nor the
   IntServ QoS Model (because parameters needed for these QoS Models are
   by definition generic parameters). Future versions of this draft will
   define a number of optional parameters, e.g. for measuring delay.


Ash et al.              Expires - April 2005                   [Page 5]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   Optional parameters SHOULD be used by QSPs if applicable to
   facilitate interworking. However, QNEs outside the domain employing a
   particular QSP cannot be expected to understand the optional
   parameters.


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 an read-only object is QoS Desired
   as sent by theQNI.


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-QoS-SIG] and [RMD-QSP].


   Generic parameters:


   - <Hop Count>


   read-write 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>


   Read-only 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
   use:


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


Ash et al.              Expires - April 2005                   [Page 6]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   b. Scheduling of reservations ahead of time to make sure resources
   will be available, i.e. a Reserve / Commit functionality. An example
   is reservation of resources for a video-conference. Also in this case
   the full flow ID, e.g. port numbers, 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.


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


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.


Ash et al.              Expires - April 2005                   [Page 7]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   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 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 fixed in [QoS-Sig].


4.2.1 <QoS Desired>


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


   These parameters describe the resources the QNI desires to reserve
   and hence this is an 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.


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


   <R> = the share of the linkÆs bandwidth the flow is entitled to (see
   RFC 2212)


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


   <QoS-class> = <PHB-DCLASS> <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, DCLASS], 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
   read-only parameters.


4.2.2 <QoS Available>


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


Ash et al.              Expires - April 2005                   [Page 8]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   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].  <QSP hops> and <non QSP hops> are the
   number of QSP aware and non QSP aware nodes along the path. 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> <token bucket> <QoS-class> <Priority> <S>


   These parameters describe the QoS reserved by the QNEs down the
   path. <R>, <token bucket>, <QoS-class> and <Priority> are defined
   above. <S> is defined in [RFC 2212]. This is a read-write object.


4.2.4 <Minimum QoS>


   <Minimum QoS> = <R> <token bucket> <QoS-class> <Priority>, <R>,
   <token bucket>, <QoS-class> and <Priority> are defined above


   <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.
   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 may need to be adapted accordingly.


5. Security Considerations


   The Service Schedule parameter raises possibilities for Denial of
   Service Attacks because an attacker could signal a QNE to set aside
   resources without ever completing the reservation. This is prevented
   by charging incomplete / pending reservations.


   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


Ash et al.              Expires - April 2005                   [Page 9]

Internet Draft           QoS-NSLP QSpec Template           October 2004


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


6.  Open Issues


   a. Clarify the relationship of Common NSLP Processing, QSP-specific
   NSLP Processing and the Resource Management Function.


   b. Specify optional parameters proposed to support other QSPs.


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


   d. Are proprietary QSpec parameters required?


   e. Is a flag needed to indicate when a QNE cannot process a given
   generic parameter?


   f. Should PHB explicitly signaled in PHB-DCLASS?


   g. The bit-level format for the QoS objects and QoS parameters needs
      to be defined


7.  Acknowledgements


   The authors would like to thank Robert Hancock, Sven van den
   Bosch, and Hannes Tschofenig 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
   at http://www.ietf.org/ipr.


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


Ash et al.              Expires - April 2005                  [Page 10]

Internet Draft           QoS-NSLP QSpec Template           October 2004


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.
   1997.
   [RMD-QoS-SIG] A. Bader et. al., "RMD (Resource Management in
   Diffserv) QoS-NSLP model", work in progress.
   [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)"
   <draft-ietf-nsis-rmd-diffserv-qsm-01>, 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
   [DCLASS] Bernet Y., Format of the RSVP DCLASS Object, RFC 2996,
   November 2000


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


Ash et al.              Expires - April 2005                  [Page 11]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   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


   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


Ash et al.              Expires - April 2005                  [Page 12]

Internet Draft           QoS-NSLP QSpec Template           October 2004


   Percy Tarapore
   AT&T
   Room D1-3D33
   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, RMD is partically
   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 IS hop> <IS hops> <Available Bw> <Min
   latency> <M>
   <QoS Reserved> = <token bucket>


   An IntServ over Diffserv QSpec is


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


Ash et al.              Expires - April 2005                  [Page 13]

Internet Draft           QoS-NSLP QSpec Template           October 2004


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


   <QoS Desired> = <R>
   <QoS class> = <DCLASS>



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 IS hop> <IS 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: QoS Models, QoS Signaling Policies and QSpecs


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


Ash et al.              Expires - April 2005                  [Page 14]

Internet Draft           QoS-NSLP QSpec Template           October 2004


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


   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 C: Mapping of QoS Desired, QoS Available and QoS Reserved of
NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ


   The union of QoS Desired, QoS Available and QoS Reserved can provide
   all functionality of the objects specified in RSVP IntServ, however
   it is difficult to provide an exact mapping.


   In RSVP, the Sender TSpec specifies the traffic an application is
   going to send (e.g. token bucket). The AdSpec can collect path
   characteristics (e.g. delay). Both are issued by the sender. The
   receiver sends the FlowSpec which includes a Receiver TSpec
   describing the resources reserved using the same parameters as the
   Sender TSpec, as well as a RSpec which provides additional IntServ
   QoS Model specific parameters, e.g. Rate and Slack.


   The RSVP TSpec/AdSpec/RSpec seem quite tailored to
   receiver-initiated signaling employed by RSVP, and the IntServ
   QoS Model. E.g. to the knowledge of the authors it is not possible
   for the sender to specify a desired maximum delay except
   implicitly and mutably by seeding the AdSpec accordingly. Likewise,
   the RSpec is only meaningfully sent in the receiver-issued RSVP
   RESERVE message. For this reason our debate at this point lead us
   to a slightly different mapping of necessary functionality to
   objects, which should result in more flexible signaling models.


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


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.


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.


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