One document matched: draft-ietf-nsis-qspec-01.txt
Differences from draft-ietf-nsis-qspec-00.txt
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. | PAFTECH AB 2003-2026 | 2026-04-22 11:45:40 |