NSIS Working Group
Internet Draft Cornelia Kappler
Document: draft-kappler-nsis-qosmodel- Siemens AG
controlledload-00.txt
Expires: August 2004 February 2004
A QoS Model for Signaling IntServ Controlled-Load Service with NSIS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
Abstract
This document presents a validation of QoS-NSLP by adapting an
existing QoS model, controlled-load service from IntServ, for
signaling with QoS-NSLP. It describes how to signal for controlled-
load service with QoS-NSLP, and clarifies the features necessary for
a QoS model description.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Table of Contents
1. Introduction...................................................2
2. QoS NSLP Overview..............................................3
3. What is a QoS Model............................................3
Kappler Expires - August 2004 [Page 1]
QoS Model for IntServ Controlled-Load Service February 2004
4. IntServ Controlled Load Service Overview.......................4
5. NSIS QoS Model for IntServ Controlled Load Service.............5
5.1 Role of QNEs...............................................6
5.2 Control Information........................................6
5.3 Content of QSpec, Including Resource Description...........6
5.4 Objects to be Carried in QUERY and RESPONSE................7
5.5 Processing Rules in QNEs...................................7
5.6 Usage of QoS-NSLP Messages.................................9
6. Feedback to QoS-NSLP and Open Issues..........................10
Security Considerations..........................................11
References.......................................................11
Acknowledgment...................................................13
Author's Address.................................................13
1. Introduction
The QoS NSIS Signaling Layer Protocol, QoS-NSLP [qos-nslp] defines
how to signal for QoS reservations in the Internet. The protocol is
not bound to a specific mechanism for achieving QoS, such as IntServ
or DiffServ. Rather, the actual QoS information is carried opaquely
in the protocol. A mechanism for achieving QoS is called QoS model in
[qos-nslp]. It is expected that a number of QoS models will be
developed for QoS-NSLP.
The purpose of this document is to validate QoS-NSLP by adapting an
existing QoS model for signaling with QoS-NSLP, and analyze what
exactly a QoS model needs to be doing. The QoS model described here
is based on the controlled-load service of IntServ [RFC2211].
[RFC2210] specifies how to signal for controlled-load service with
RSVP. This document describes how to signal for the same service with
QoS-NSLP.
The controlled-load service is rather minimal both in terms of
information that is signaled - basically bandwidth in the form of a
token bucket û and in terms of prescribed realization of the service
in the network. It is therefore suited for a wide range of
realizations, such as reserving resources per-flow per-network node
[RFC1633], achieving QoS in appropriately engineered DiffServ
networks with admission control [RFC2998], or sending traffic via
MPLS Label Switched Paths (LSPs) with reserved bandwidths and
admission control [RFC3031][RFC2746].
In this document (unless explicitly referring to [qos-nslp]), the
term ôQoS modelö is defined in more detail than in [qos-nslp] as ôa
mechanism for achieving QoS, and a description of how to use QoS-NSLP
for signaling itö. In this sense, the ômechanismö for controlled-load
service is already defined in [RFC2211]. This document contains the
Kappler Expires - August 2004 [Page 2]
QoS Model for IntServ Controlled-Load Service February 2004
description of how to use QoS-NSLP for signaling it, and can hence be
considered the analogue of [RFC2210].
The document is structured as follows: It gives a brief overview of
QoS-NSLP, and the content and features of a QoS model as foreseen in
[qos-nslp]. It then gives a brief overview of the controlled-load
service of IntServ. Subsequently, the actual QoS model for
controlled-load service is described. It turns out a QoS model needs
more details in order to be useful for QoS-NSLP than outlined in
[qos-nslp]. The additions and open issues are summarized in the last
section.
2. QoS NSLP Overview
QoS NSLP [qos-nslp] is an NSIS signaling layer protocol for signaling
QoS reservations in the Internet. Together with NTLP [ntlp] [nsis-
fw], it provides functionality similar to RSVP and extends it, e.g.
by supporting both sender-initiated and receiver-initiated
reservations. QoS-NSLP however does not support multicast. QoS NSLP
establishes and maintains reservation state in QoS-NSLP aware nodes,
called QNEs, along the path of a data flow. The number or frequency
of QNEs is not prescribed. The node initiating a reservation request
is called QNI, the node terminating the request is called QNR. QNI
and QNR are also QNEs, and are not necessarily the actual sender and
receiver of the data flow they are signaling for as they may also be
proxying for them.
QoS-NSLP defines four message types, RESERVE, QUERY, RESPONSE and
NOTIFY. The message type identifies whether a message manipulates
state (e.g. RESERVE) or not (e.g. QUERY, RESPONSE). The RESERVE
message is used to create, refresh, modify or remove reservation
state in QNEs. The QUERY message is used to request information about
the data path without making a reservation. This functionality can be
used to æprobeÆ the path for certain characteristics. The RESPONSE
message is used to provide information about the results of a
previous RESERVE or QUERY message, e.g. confirmation of a successful
reservation, error, or for transferring results of a QUERY back
towards the querying node. The NOTIFY message is not important in the
context of this memo.
3. What is a QoS Model
QoS NSLP is a QoS signaling protocol that is independent of the so-
called QoS model, just as RSVP [RFC2205] is independent of IntServ
[RFC1633]. According to [qos-nslp], a QoS model is a defined
mechanism for achieving QoS. The specification of a QoS model
includes a description of its QoS parameter information, as well as
Kappler Expires - August 2004 [Page 3]
QoS Model for IntServ Controlled-Load Service February 2004
how that information should be treated or interpreted in the network.
A QoS model could also describe underlying assumptions, conditions
and/or specific provisioning mechanisms. It is expected that a number
of QoS models will be developed for QoS-NSLP. IntServ and DiffServ
[RFC2475] are given as examples that could provide the basis of NSIS
QoS models.
In a QoS-NSLP RESERVE message, a description of the actual resources
that are requested is carried in an Object, the QSpec. The QSpec is
opaque to QoS-NSLP and similar in purpose to the TSpec, RSpec and
AdSpec specified in [RFC2205],[RFC2210]. Thereby the TSpec is a
description of the data flow generated by the sender for which
resources are to be reserved, containing e.g. peek bandwidth and
token bucket parameters, RSpec contains additional parameters
necessary to invoke a service, and AdSpec carries information
generated in or modified by the network, e.g. maximum currently
available bandwidth, which is used for making reservation decisions.
The QSpec is specific to the QoS model. The QoS model provides the
parameters to be carried in the QSpec, and restricts their values. In
[qos-nslp], also a strawman QSpec template is provided. The RESERVE
message may additionally contain QoS model specific control
information used by the QoS modelÆs processing. Control information
may qualify or restrict the action a QNE may perform on the QoS
message. At each QNE, QSpec and corresponding control information are
interpreted by the resident resource management function for the
purposes of policy control and traffic control, including admission
control and configuration of the packet classifier and scheduler.
The QoS model may also define specific objects to be carried in the
QUERY message, in order to gather resource specific information on
the data path without making a reservation. It is assumed in this
memo that also the RESPONSE message may carry QoS model specific
objects in order to distribute the queried information to interested
nodes [This is not said in [qos-nslp] but seems to be understood].
As described in the Introduction, this document explicitly includes
in the term ôQoS modelö the description of how to use QoS-NSLP to
signal for the envisaged QoS mechanism.
4. IntServ Controlled Load Service Overview
As specified in [RFC2211], the controlled-load service defined for
IntServ supports applications which are highly sensitive to overload
conditions, e.g. real-time applications. The controlled-load service
provides to an application approximately the end-to-end service of an
unloaded best-effort network. ôUnloadedö thereby is used in the sense
Kappler Expires - August 2004 [Page 4]
QoS Model for IntServ Controlled-Load Service February 2004
of ônot heavily loaded or congestedö rather than in the sense of ôno
other network traffic whatsoeverö.
The definition of controlled-load service is intentionally imprecise.
It implies a very high percentage of transmitted packets will be
successfully delivered to the end nodes. Furthermore, the transit
delay experienced by a very high percentage of the delivered packets
will not greatly exceed the minimum transmit delay experienced by any
successfully delivered packet. In other words, a short disruption of
the service is viewed as statistical effect which may occur in normal
operation. Events of longer duration are indicative of failure to
allocate sufficient resources to the controlled-load flow.
In order to ensure that the conditions on controlled-load service are
met, clients requesting the service provide network elements on the
data path with an estimation of the data traffic they are going to
generate. When signaling with RSVP, the object carrying this
estimation is called TSpec. In return, the service ensures that in
each network element on the data path, resources adequate to process
traffic falling within this descriptive envelope will be available to
the client. This must be accomplished by admission control.
The controlled-load service is implemented per-flow in each network
element on the data-path. Thereby, a network element may be an
individual node such as a router. However, a network element can also
be a subnet, e.g. a DiffServ cloud within a larger IntServ network
[RFC2998]. In this case, the per-flow traffic description (e.g.
carried in the RSVP TSpec) together with the DiffServ Code Point
(carried e.g. in the DCLASS object [RFC2996] of RSVP) is used for
admission control into the DiffServ cloud. The DiffServ cloud must
ensure it provides controlled-load service. It is also possible to
operate controlled-load service over logical links such as IP tunnels
[RFC2746] or MPLS LSPs [RFC3031]. The per-flow traffic descriptor is
in this case used for admission control into the tunnel /LSP.
5. NSIS QoS Model for IntServ Controlled Load Service
As described above, according to [qos-nslp], a QoS model needs to
define
- a description of resources to be reserved, carried in the QSpec,
- control information associated with the QSpec,
- objects to be carried in QUERY and RESPONSE,
- processing rules for packet treatment in network elements, e.g.
regarding admission control, packet scheduling and policy control.
However, during this validation exercise, it became apparent that
additional information seems necessary for fully specifying a QoS
model. This document therefore also provides information on
Kappler Expires - August 2004 [Page 5]
QoS Model for IntServ Controlled-Load Service February 2004
- The role of QNEs:
how do QNEs map onto controlled-load service network elements,
- Usage of QoS-NSLP messages in the QoS model:
what QoS-NSLP messages to use for signaling controlled-load service.
- information carried in the QSpec beyond a description of resources
to be reserved, such as QoS model identification, and AdSpec like
information such as local availability of QoS model.
5.1 Role of QNEs
Controlled-load service network elements can be individual routers or
subnets. I.e. it is not necessary for each network node on the data
path to interpret the signaling for the service. Rather, dedicated
nodes may interpret signaling information and take on responsibility
that the subnet they represent delivers adequate service. In fact,
this setting maps nicely onto QoS-NSLP û and the NSIS protocol suite
in general. In NSIS, QNEs are just required to be located on the data
path. However there are no prescriptions regarding their number or
frequency. This is in contrast to RSVP, where each router on the data
path is expected to be RSVP-capable. Hence, in the controlled-load
QoS model, there must be (at least) one QNE acting on behalf of every
network element. E.g. all ingress routers to a DiffServ cloud could
be QNEs, performing admission control (Note for this usage it would
be necessary to also carry the DiffServ Code Point in the QoS_NSLP
message, analogously to the DCLASS Object in RSVP [RFC2996]. A more
detailed discussion will be provided in future versions of this
document). If there is more than one QNE per network element, they
must be coordinated among themselves to ensure the network element
delivers controlled-load service.
5.2 Control Information
No specific control information is necessary.
5.3 Content of QSpec, Including Resource Description
The controlled-load service uses a token bucket specification plus a
peak rate (p), a minimum policed unit (m) and a maximum packet size
(M) to describe a data flow's required resources. The token bucket
specification includes a bucket rate r and a bucket depth b. The
minimum policed unit m is an integer measured in bytes. All IP data
grams of size less than m are counted against the token bucket as
being of size m. For more details, including value ranges of the
parameters see [RFC2210]. It seems feasible to reuse the
TOKEN_BUCKET_TSPEC defined for IntServ in [RFC2215] in the QSpec. The
XDR description of this set of parameters is reproduced here:
struct {
float r;
Kappler Expires - August 2004 [Page 6]
QoS Model for IntServ Controlled-Load Service February 2004
float b;
float p;
unsigned m;
unsigned M;
} TOKEN_BUCKET_TSPEC;
The controlled-load service has no required characterization
parameters the QNI needs to be informed about, i.e. current
measurement and monitoring information need not be exported by QNEs,
although individual implementations may do so if they wish. In RSVP
one would say the service-specific data fragment in the AdSpec
carries no prescribed information except whether the service is
implemented in each network element. If an implementation wishes to
export information, appropriate fields in the QSpec would need to be
defined. The information can be fed-back to the QNI by means of a
RESPONSE message.
It may be useful for the controlled-load service QSpec to contain
AdSpec-like fields that are updated by each QNE, such as minimum MTU
and maximum currently available bandwidth. In fact such fields are
already foreseen in the strawman proposal QSpec template in [qos-
nslp]. For usage of these parameters see Sec 5.6.
Additionally, the QSpec should contain a QoS model (or QSpec) ID,
also foreseen in the strawman QSpec template.
Later versions of this document will give the precise Object format.
5.4 Objects to be Carried in QUERY and RESPONSE
For sender-initiated reservations, the QUERY message is not used
(except see discussion in Sec. 5.6). The RESPONSE needs to carry
generic ôreservation successfulö and ôQoS Object not understoodö
information which should be defined in another document ([qos-nslp]
and/or a QoS Model template). Additionally, the RESPONSE needs to
carry more precise information why a reservation failed, such as ôMTU
too large, permissible MTU size isà), see also Sec. 5.6. The
corresponding object will be defined in a later version of this
document.
5.5 Processing Rules in QNEs
- Admission Control
For controlled-load service, QNEs are required to perform admission
control. All resources important to the operation of the network
element must be considered when admitting a request. Common examples
of such resources include link bandwidth, router or switch port
Kappler Expires - August 2004 [Page 7]
QoS Model for IntServ Controlled-Load Service February 2004
buffer space, and computational capacity of the packet forwarding
engine. It is not prescribed how a QNE determines adequate resources
are available. It is however required that they make bandwidth
greater than the token rate available to the flow in certain
situations in order to account for fluctuations. E.g. statistical
methods may be used to determine how much bandwidth is necessary.
There are no target values for other parameters, e.g. delay or loss,
other than providing a service closely equivalent to that provided to
best-effort traffic under lightly loaded conditions.
QNEs must reject a service request (by returning an admission control
error) if the maximum packet size M is bigger than the MTU of the
segment of the path managed by this QNE.
Resource requests for new flows are accepted if capacity is
available. Reservation modifications are accepted if the new
TOKEN_BUCKET_TSPEC is strictly smaller than the old one (for rules
for ordering TOKEN_BUCKET_TSPECs see [RFC2211]). Otherwise they are
treated like new reservations from an admission control perspective.
- Packet Scheduling
No specific scheduling mechanism is prescribed, as long as admitted
flows receive appropriate service.
- Policy Control
The controlled-load service is provided to a flow on the basis that
the flow's traffic conforms to the traffic parameters signaled at
flow setup time. Packets arriving when no tokens are available, or
arriving with a rate greater than the peek rate, are considered non-
conformant. QNEs are allowed to somewhat delay packets for making
them conformant (i.e. to reshape the flow).
Links are not permitted to fragment packets which receive the
controlled-load service. Packets larger than the MTU of the link must
be treated as non-conformant.
Nonconformant packets should be forwarded on a best-effort basis, as
long as the contracted QoS of other flows is not compromised, and as
long as best-effort traffic is not impacted unfairly. The mechanism
for implementing this policy is not prescribed. E.g. it would be
possible to degrade the service delivered to the entire flow which
originated the nonconformant packets, or to just degrade or even drop
nonconformant packets (such as packets larger than the MTU). Note
each QNE MUST independently ensure other flows are not impacted by
non-conforming packets.
Kappler Expires - August 2004 [Page 8]
QoS Model for IntServ Controlled-Load Service February 2004
5.6 Usage of QoS-NSLP Messages
QoS-NSLP allows for both sender-initiated and receiver-initiated
reservations. So far however, only message flows for receiver-
initiated reservations are defined in [qos-nslp]. Therefore this
document at this point also only describes sender-initiated
reservations for controlled-load service.
In order to reserve controlled-load service, the sender initiates a
RESERVE message containing a QSpec with the traffic description
detailed in Sec. 5.3. If the request is admitted, a corresponding
RESPONSE may be returned, as described in [qos-nslp].
The case of failing admission is more interesting. Admission may fail
either because the MTU advertised in the traffic description is too
large for at least one link, or because at least one QNE doesnÆt have
the resources available to accommodate the advertised traffic. It
would be helpful for the initiator of the RESERVE message, the QNI,
to know what MTU or what resources would be feasible in order to be
able to make another reservation attempt if so desired.
In RSVP, the actual reservation is always made by the receiver. The
initiator however triggers the reservation action by sending a PATH
message containing the traffic description in the TSpec, and an
AdSpec object, updated at each network element, which collects
information on path properties, such as MTU and currently available
bandwidth. The receiver can use the information in the AdSpec to make
an appropriate reservation request.
With a sender-initiated reservation as discussed here, collecting
information from network elements for use in the reservation is not
as straightforward. For signaling controlled-load service with QoS-
NSLP the following possibilities exist:
* The QNI obtains information on the appropriate MTU not via QoS-NSLP
but differently (out-of-band). This way failing admission because of
oversized MTU is avoided. Admission may however still fail for lack
of resources.
* The QNI issues a QUERY and awaits the RESPONSE before sending the
actual RESERVE. While serving the purpose, this procedure adds
another round-trip time and thus defeats the point (or at least one
point) of sender-initiated reservations.
* The QNE failing admission returns a RESPONSE to the QNI, giving the
reason and a suitable value for MTU / bandwidth ([qos-nslp] does not
specify yet which QNE informs the QNI a reservation failed: e.g. the
QNE at which the reservation failed, or the QNR). For another
reservation attempt at this QNE, success would be guaranteed (in case
Kappler Expires - August 2004 [Page 9]
QoS Model for IntServ Controlled-Load Service February 2004
of failing because of MTU) or at least be more likely (in case of
failing because of lack of resources). However, a QNE further down
the path towards the receiver may still deny admission.
* The QNI adds an AdSpec-like Object (or appropriate fields in the
QSpec) in the RESERVE, containing a proposal for MTU and for
bandwidth. The QNE failing admission sets a ôdeniedö bit in the
RESERVE (not defined yet) or QSpec / AdSpec, and updates the AdSpec-
like object (henceforth called AdSpec for simplicityÆs sake) with
permissible values. Then it continues to forward the RESERVE towards
the QNR. Each QNE on the path continues to update the AdSpec if local
MTU and bandwidth are even smaller than the values currently
contained in the AdSpec. The QNR returns the AdSpec with a RESPONSE
message saying ôfailureö to the QNI. This method allows for efficient
adaptation of failed reservations, but adds overhead regarding
bandwidth and processing. In case of a failed first attempt, it adds
half a roundtrip time latency compared to receiver-initiated
reservation.
6. Feedback to QoS-NSLP and Open Issues
When elaborating the present QoS model, a number of requirements and
suggestions for clarification came up that should be considered for
QoS-NSLP, the strawmanÆs proposal for a QSpec template, and QoS
models in general:
- A feedback mechanism should be provided to inform QNIs when the
desired QoS model is not known to a QNE that is supposed to interpret
it. In RSVP a ôbreak bitö is set in the AdSpec. Such a break bit
however is delivered to the QNR (in the case of QoS-NSLP). An
alternative is for the QNE to issue an error RESPONSE message back to
the QNI.
- Information that is generated in or modified by the network
(AdSpec-like information) may travel both in RESERVE and QUERY. When
it is traveling in the RESERVE, is it an additional object,
independent of the QSpec? This may make sense if it then can be
reused as-is as object in QUERY. Also, just as in RSVP, the
information carried in a RESERVE would be logically separated in a
mutable and an immutable part. Mutable information in the RESERVE
implies (not yet mentioned explicitly in [qos-nslp]) QNEs may
manipulate information contained in RESERVE Objects.
- [qos-nslp] provides a staw manÆs proposal for a QSpec template. It
is suggested to extend this template to a QoS model template, similar
to the network element service specification template for IntServ in
[RFC2216].
Kappler Expires - August 2004 [Page 10]
QoS Model for IntServ Controlled-Load Service February 2004
- Regarding content of the QSpec template in [qos-nslp], the QoS
model presented here needs the fields for QoS Model (QSpec) ID,
Traffic Envelope and traffic conformance and, possibly, Monitoring
Requirements (namely minimum MTU and maximum currently available
bandwidth). The other fields foreseen in the template are not
necessary for this QoS Model. One could however picture a slight
extension of the QoS model in which Excess Treatment (what happens to
non-conforming traffic) and Service Schedule (giving a time for which
the service is requested) are also used. This QoS model does not
require additional fields not yet listed in the QSpec template. It
may however be useful if the template allows for ôfree fieldsö in
which e.g. implementation specific information can be exported by
QNEs (see Sec. 5.3).
- Would it make sense to define standard objects for QUERY and
RESPONSE as well?
And, already detailed above:
- A QoS model should include a description of both the mechanism to
provide QoS and the usage of QoS-NSLP to signal for this mechanism
(cf. Sec. 1). Particularly, a QoS model should include, beyond what
is already listed in [qos-nslp], a description of (cf. Sec. 5)
* the role of QNEs
* usage of QoS-NSLP messages in the QoS model
* a full specification of the QSpec including, but not limited to, a
resource description
- Should QoS-NSLP or the QoS model define what QNE returns an error
RESPONSE upon failed reservations(cf. Sec. 5.6)?
- What is the most efficient way of providing feedback to the QNI for
sender-initiated reservations (cf. Sec. 5.6)? Does the feedback
mechanisms need to be described or could an implementation pick the
one it finds the most useful?
Later versions of this document will contain the precise QSpec Object
and RESPONSE object formats, and a description of how to do receiver-
initiated reservations.
Security Considerations
This Internet Draft raises no security issues.
References
Kappler Expires - August 2004 [Page 11]
QoS Model for IntServ Controlled-Load Service February 2004
[nsis-fw] Hancock, R. and et al., "Next Steps in Signaling:
Framework", draft-ietf-nsis-fw-05 (work in progress), October 2003.
[ntlp] Schulzrinne, H. and Hancock, R., "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-00 (work in
progress), Oct. 2003.
[RFC1633] Braden, B., Clark, D. and Shenker, S., ôIntegrated Services
in the Internet Architecture: An Overviewö, RFC 1633, June 1994.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, Sep 1997.
[RFC2210] Wroclawski, J., ôThe Use of RSVP with IETF Integrated
Servicesö, RFC 2210, September 1997.
[RFC2211] Wroclawski, J., ôSpecification of the Controlled-Load
Network Element Serviceö, RFC 2211, September 1997.
[RFC2215] Shenker, S. and Wroclawski, J., ôGeneral Characterization
Parameters for Integrated Service Network Elementsö, RFC 2215,
September 1997.
[RFC2216] Shenker, S. and Wroclawski, J., ôNetwork Element Service
Specification Templateö, RFC 2216, September 1997.
[RFC2475] Blake, S., Carlson, M., Davies, D., Wang, Z. and W. Weiss,
"An Architecture for Differentiated Services", RFC 2475, December
1998.
[RFC2746] Terzis, A., Wroclawski, J. and L. Zhang, "RSVP Operation
Over IP Tunnels", RFC 2746, January 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B. and J. Wroclawski, "A Framework for
Integrated Services Operation over Diffserv Networks", RFC 2998,
November 2000.
[RFC3031] Rosen, E., Viswanathan, A., Callon, R., ôMultiprotocol
Label Switching Architectureö, RFC 3031, January 2001.
[qos-nslp] Van den Bosch, S., Karagiannis, G. And McDonald, A., "NSLP
for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-01 (work
in progress), October 2003.
Kappler Expires - August 2004 [Page 12]
QoS Model for IntServ Controlled-Load Service February 2004
Acknowledgment
The author would like to thank Andrew McDonald for providing helpful
feedback.
Author's Address
Cornelia Kappler
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Email: cornelia.kappler@siemens.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Kappler Expires - August 2004 [Page 13]
