One document matched: draft-kappler-nsis-qosmodel-controlledload-01.txt
Differences from draft-kappler-nsis-qosmodel-controlledload-00.txt
Next Steps in Signaling C. Kappler
Internet-Draft Siemens AG
Expires: November 13, 2005 May 12, 2005
A QoS Model for Signaling IntServ Controlled-Load Service with NSIS
draft-kappler-nsis-qosmodel-controlledload-01
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 BCP 79.
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.
This Internet-Draft will expire on November 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a QoS Model to signal IntServ controlled load
service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS
Model specific information is carried in an opaque object, the QSPEC.
This document hence specifies the QSPEC for controlled load service,
how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP
messages must be used to achieve IntServ controlled load service.
Kappler Expires November 13, 2005 [Page 1]
Internet-Draft Controlled-Load QOSM May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling with QoS NSLP . . . . . . . . . . . . . . . . . . . 3
2.1 QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 QSPEC . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 QoS Model . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IntServ Controlled Load Service . . . . . . . . . . . . . . . 5
4. QoS Model for IntServ Controlled Load Service . . . . . . . . 6
4.1 Role of QNEs . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 QSPEC . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1 Controlled Load Service Requirements . . . . . . . . . 7
4.2.2 QOSM ID . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.3 QSPEC Control Information . . . . . . . . . . . . . . 8
4.2.4 QoS Description . . . . . . . . . . . . . . . . . . . 8
4.3 Usage of QoS-NSLP Messages . . . . . . . . . . . . . . . . 9
5. Processing Rules in QNEs . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Kappler Expires November 13, 2005 [Page 2]
Internet-Draft Controlled-Load QOSM May 2005
1. Introduction
The QoS NSIS Signaling Layer Protocol, QoS-NSLP [2] 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 in a separate object, the QSPEC [3]. A method for
achieving QoS for a traffic flow using QoS NSLP signaling is called
QoS model. It is expected that a number of QoS models will be
developed for QoS-NSLP. Examples are [4], [5] and this draft.
The purpose of this document is to describe a QoS model for
controlled-load service of IntServ [6]. [7] specifies how to signal
for controlled-load service with RSVP [8] . 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
[9], achieving QoS in appropriately engineered DiffServ networks with
admission control [10], or sending traffic via MPLS Label Switched
Paths (LSPs) with reserved bandwidths and admission control [11][12].
The document is structured as follows: It gives a brief overview of
QoS-NSLP and the QSPEC, and the content and features of a QoS model
as described in [2] and [3]. It then gives a brief overview of the
controlled-load service of IntServ. Subsequently, the actual QoS
model for IntServ controlled-load service is described.
2. Signaling with QoS NSLP
2.1 QoS NSLP
QoS NSLP [2] is an NSIS signaling layer protocol for signaling QoS
reservations in the Internet. Together with GIMPS [13][14] , 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.
Kappler Expires November 13, 2005 [Page 3]
Internet-Draft Controlled-Load QOSM May 2005
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.
2.2 QSPEC
QoS NSLP carries QoS Model specific information encapsulated in an
opaque object, the QSPEC [3]. The QSPEC thus fulfills a similar
purpose as TSpec, RSpec and AdSpec in RSVP [8]. The QSPEC is not
processed by the QoS NSLP Processing unit on a QNE, but passed as-is
to the Resource Management Function (RMD) on the same node, where it
is interpreted.
The QSPEC is structured internally into QSPEC Control Information,
and QoS Description.
o QSPEC Control Information contains parameters that govern the
processing of the resource request in the RMF, e.g. information on
excess treatment.
o QoS Description describes the actual resources required and/or
offered. It is composed of QSPEC objects, namely QoS Desired, QoS
Available, QoS Reserved and Minimum QoS. A particular QoS
Description typically only contains a subset of these objects.
o
* QoS Desired contains parameters describing the QoS desired by a
QNI.
* QoS Available contains parameters describing the available
resources. This QSPEC object is used to collect information
along a path.
* QoS Reserved describes the actual QoS reserved
* Minimum QoS can be included by a QNI together with QoS Desired
to signal a range of QoS (between QoS Desired and Minimum QoS)
is acceptable.
Kappler Expires November 13, 2005 [Page 4]
Internet-Draft Controlled-Load QOSM May 2005
The QSPEC template [3] defines a number of mandatory and optional
QSPEC parameters. Mandatory parameters must be interpreted by each
QNE, whereas optional parameters can also be ignored. This ensures
some degree of interoperability between QoS Models while at the same
time providing extensibility and flexibility. In a given QoS Model,
new optional parameters may be defined.
The QSPEC usually carries a QoS Model identifier, which identifies
what QoS Model is being signaled about. The QoS Model defines what
parameters must be included in a given QSPEC. However, the QNI may
also include additional parameters, in order to give additional
information to QNEs that are not supporting this specific QoS Model,
or to collect path information that is interesting to the QNI or
other QNEs.
2.3 QoS Model
A QoS-enabled domain supports a particular QoS model (QOSM), which is
a method to achieve QoS for a traffic flow with QoS NSLP signaling,
such as IntServ controlled load or DiffServ [15]. QoS NSLP is
independent of the QOSM, just as RSVP [8] is independent of IntServ.
A QOSM hence incorporates QoS provisioning methods and a QoS
architecture. It however also defines how to use QoS NSLP. It
defines the behavior of the resource management function (RMF),
including inputs and outputs, and how QSPEC information on traffic
description, resources required, resources available, and control
information required by the RMF is interpreted. A QOSM also
specifies the QSPEC parameters that describe the QoS and how
resources will be managed by the RMF.
3. IntServ Controlled Load Service
As specified in [6], 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 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
Kappler Expires November 13, 2005 [Page 5]
Internet-Draft Controlled-Load QOSM May 2005
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. When signalign with QoS NSLP, the QSPEC
object carrying desired resources is called <QoS Desired>. 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 [10]. 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 [16] 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
[12] or MPLS LSPs [11]. The per-flow traffic descriptor is in this
case used for admission control into the tunnel /LSP.
4. QoS Model for IntServ Controlled Load Service
According to [3], a QOSM SHOULD include the following information:
o Role of QNEs in this QOSM: E.g. location, frequency, statefulness
etc.
o QSPEC Definition: A QOSM SHOULD specify the QSPEC, including QSPEC
parameters. Furthermore it needs to explain how mandatory QSPEC
parameters not used in this QOSM are mapped onto parameters
defined therein.
o Message sequencing and QSPEC object population, i.e. usage of QoS-
NSLP messages to signal the QOSM. Message Format and QSPEC
objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY
o State Management It describes how QSPEC info is treated and
interpreted in the RMF and QOSM specific processing. E.g.
admission control, scheduling, policy control, QoS parameter
accumulation (e.g. delay).
Subsequent sections treat these points one-by-one.
Kappler Expires November 13, 2005 [Page 6]
Internet-Draft Controlled-Load QOSM May 2005
4.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. 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.
4.2 QSPEC
4.2.1 Controlled Load Service Requirements
The controlled-load service uses a token bucket specification with a
bucket rate r and a bucket depth b. The token bucket also includes
peak rate (p), a minimum policed unit (m) and a maximum packet size
(M) to describe a data flow's required resources. 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 [7].
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.
When using RSVP to signal for controlled-load services, the PATH
message collects information on MTU which is used by the receiver to
adapt the reservation parameters in the RESV message. While this is
one possible way for signaling controlled load services, this is not
prescribed by the controlled load service itself.
4.2.2 QOSM ID
Later versions of this document will define a QOSM ID.
Kappler Expires November 13, 2005 [Page 7]
Internet-Draft Controlled-Load QOSM May 2005
4.2.3 QSPEC Control Information
No QSPEC Control Information is necessary. Information on Excess
Treatment (drop or reshape) may be included. Note the original
controlled load service specification leaves it up to network
elements (i.e. QNEs) how to treat non-comforming traffic. It is
unclear to what extent this treatment can be prescribed.
In RSVP, when non-IntServ hops are discovered on the path, a flag is
raised. Additionally, the number of IntServ hops is counted. This
way a sender or receiver can determine whether end-to-end QoS could
be achieved.
The QSPEC template defines similar parameters, particularly <non-
QOSM-hops> and <QOSM hops>. They flag/count the number of QNEs on
the data path (not) supporting the QOSM identified in the QSPEC.
Together with a counter/flag in QoS NSLP which identifying hops not
supporting QoS NSLP they provide sufficient information. The benefit
however in this case is still unclear: All QSPEC parameters
necessary for controlled load service are mandatory parameters. This
means even if a QNE does not support the controlled load service
QOSM, it is still able to make sense of the parameters and reserve
QoS accordingly.
4.2.4 QoS Description
The controlled load QOSM uses only mandatory parameters defined in
[3].
<QoS Desired> = <token bucket>(<QoS Class>)
<QoS Available> = (<bandwidth><path latency>)<MTU>
<Minimum QoS> = <token bucket>>(<QoS Class>)
<QoS Reserved> = <token bucket> OR <MTU>
Of these, only <QoS Desired> and <QoS Reserved> will be used by all
implementations. Including <QoS Class> allows to also cover
scenarios in which the flow passes a DiffServ cloud. This is also
foreseen when signaling for controlled load with RSVP [16].
<QoS Available> is necessary for receiver-initiated reservations, and
MAY be used in sender-initiated reservations. It is used for
gathering path characteristics such as <MTU>. This information can
be used by QNI or QNR to update the reservation, particularly to re-
issue a failed reservation. For controlled load service,
additionally gathering information on bandwidth and path latency is
Kappler Expires November 13, 2005 [Page 8]
Internet-Draft Controlled-Load QOSM May 2005
desirable (TBD why; this is how it is done in RSVP). Note <path
latency> is an optional parameter, i.e. some QNEs may not understand
it. However, such QNEs are required to raise a corresponding flag.
In this case the value collected in <path latency> is a lower bound
to the actual value.
<Minimum QoS> is optional. It always travels together with <QoS
Desired>. It signifies that the QNI can accept a downgrade of
resources for particular parameters in the reservation, down to the
value of the respective parameter in <Minimum QoS>. For parameters
not appearing in <Minimum QoS>, it cannot accept a downgrade. For
controlled load service this means if <token bucket> is included, a
downgrade of all token bucket parameters within the designated range
is acceptable. If <MTU> is included only, only the maximum packet
size issued by the QNI is negotiable (remember the token bucket also
includes a maximum packet size parameter)
In all QSPEC objects additional parameters MAY be included, as
described in [3].
Future versions of this draft will include a description of how other
mandatory QSPEC parameters which are not used in the controlled load
QOSM are treated by by QNEs implementing the controlled load QOSM
4.3 Usage of QoS-NSLP Messages
QoS-NSLP allows a variety of message sequences for reserving
resources. Particularly, sender-initiated, receiver-initiated and
bi-directional messages are possible. E.g., in sender-initiated
reservations, a RESERVE is issues by the QNI. If the reservation is
successful, the QNR replies with a RESPONSE. If the reservation
fails, the QNE at which it failed sends a RESPONSE.
For a given message sequence, the QSPEC template defines what QSPEC
objects travel in which of these messages, and how they are
translated from message-to-message. For each of the message sequence
defined in QoS NSLP, a variety of QSPEC object usages is possible.
o in sender-initiated reservations, the RESERVE may carry just <QoS
Desired> to indicate the exact QoS it wants, and the corresponding
RESPONSE carries solely <QoS Reserved>. This implies either the
exact resources described in <QoS Desired> are reserved, or the
reservation fails.
o in another sender-initiated reservation, a more fancy QNI would
include, in addition to <QoS Desired>, a <QoS Available> QSPEC
object, or even a <Minimum QoS>. <QoS Available> allows collecting
path properties, e.g. MTU and currently available bandwidth, and
Kappler Expires November 13, 2005 [Page 9]
Internet-Draft Controlled-Load QOSM May 2005
<Minimum QoS> signals that (and how much) less resources than <QoS
Desired> are acceptable. The RESPONSE message carries <QoS
Reserved>, and additionally copies the <QoS Available> QSPEC
Object from RESERVE, this way informing the QNI e.g. about the
MTU. This information may be of particular interest if a
reservation failed. Note however, that the QNE failing the
reservation sends the RESPONSE, such that this way no complete e2e
information on e.g. MTU can be collected. Note also that QNIs
usually are flexible about MTU and can just add a <Minimum QoS>
with a <MTU = 0> parameter set. Generally, it needs to be
discussed what is the most efficient way of providing feedback to
the QNI for sender-initiated reservations.
Note that the initial message and the QSPEC objects therein fully
determines the sequencing of subsequent messages, and also determines
what QSPEC objects will be carried in them.
The controlled load service can be signaled with any of the message
exchanges and QSPEC object combinations defined in [2] and [3].
Note, in contrast, in RSVP only one type of message exchange is
defined (receiver-initiated reservations, and the equivalent of
<Minimum QoS> = <MTU = 0>.). However, this is a characteristic of
RSVP rather than of the controlled load service.
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 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 signaled in <QoS
Desired>, resp. in <.Minimum QoS> if available, is bigger than
the MTU of the segment of the path managed by this QNE.
Kappler Expires November 13, 2005 [Page 10]
Internet-Draft Controlled-Load QOSM May 2005
Resource requests for new flows are accepted if capacity is
available. Reservation modifications are accepted if the new
<.token bucket> is strictly smaller than the old one (for rules
for ordering token buckets see [6]). 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)
unless <.Excess Treatment> was included saying non-conformant
packets must be dropped.
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.
6. Security Considerations
This Internet Draft raises no new security issues.
7. Conclusions
This document describes a QoS Model to signal IntServ controlled load
service with QoS NSLP. Up to now, it was only described how to
signal for IntServ controlled load service with RSVP [6]. Since no
independent document exists that describes IntServ controlled load by
its own, i.e. without RSVP, it is sometimes difficult to determined
what features described in [6] are specific to IntServ controlled
load, and which features are specific to RSVP:
Kappler Expires November 13, 2005 [Page 11]
Internet-Draft Controlled-Load QOSM May 2005
o Is it indeed vital for QNIs signaling for controlled load service
to be informed about the number of hops not implementing this
QOSM? Since the controlled load QOSM exclusivly relies on
mandatory parameters it can be expected that all QNEs can make
sense of the reservation, independent of whether they explicitly
implement controlled load service or not. Of more interest
appears the number of non-QoS-NSLP hops (which is collected in the
main message body of QoS NSLP rather than in the QSPEC).
o Why is it necessary to collect delay and bandwidth information
along the data path? The result of the collection does not seem
to influence the reservation process.
o The QoS NSLP QOSM for controlled load service allows a variety of
message exchanges all eventually resulting in a reservation, e.g.
sender-initiated, receiver-initiated and bidirectional signaling.
The controlled load service when signaled with RSVP was bound to
sender-initiated reservations.
o When signaling with RSVP, it is not possible to define a range of
acceptable QoS. Also this seems to be a charcteristic of RSVP
rather than a feature of the controlled load service.
An issue of general interest discovered here concerns feedback of
information in sender-initiated scenarios (In receiver-initiated
scenarios it does not occurr because path information is collected
before the RESERVE is issued). A QNI may include in <QoS Available>
several parameters, e.g. MTU, it would like to measure along the
data path. If the reservation fails, e.g. because the maximum packet
size was to large, the QNE failing the reservation returns a
RESPONSE, including the <QoS Available> QSPEC object with accumulated
information up to this point. The QNI can learn from this why the
reservation failed (because the MTU is less than the maximum packet
size in this example) at this particular QNE. However it cannot be
sure a subsequent downgraded RESERVE will be more successful. This
is because there may be even more difficult conditions (e.g. even
smaller MTU) down the path. That is, in sender-initiated scenarios
it is not straightforward to receive feedback from a failed
reservation that allows to make a good guess at what size of
reservation would be more successful. Of course it would be possible
for the QNI to issue a QUERY first to find out about a suitable value
for, e.g. maximum packet size. However this adds another round-trip
time to the reservation, thereby obsoleting one of the main benefits
of sender-initiated reservations compared to receiver-initiated ones.
In this draft, the feedback problem is solved by including a <Minimum
QoS> QSPEC object in sender-initated reservations. This gives some
flexibility as it implicitly says the QNI would also accept a
Kappler Expires November 13, 2005 [Page 12]
Internet-Draft Controlled-Load QOSM May 2005
downgraded reservation, up to the value specified. When the maximum
packet size in < Minimum QoS is set to a very small value
reservations are not going to fail because of a MTU problem. Note
however as currently specified in [3], the <Minimum QoS> QSPEC object
is not necessarily supported by all QNEs.
8. References
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[2] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-
of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
progress), February 2005.
[3] Ash, J., "QoS-NSLP QSpec Template", draft-ietf-nsis-qspec-03
(work in progress), February 2005.
[4] Bader, A., "RMD-QOSM - The Resource Management in Diffserv QoS
model", draft-ietf-nsis-rmd-01 (work in progress),
February 2005.
[5] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using
Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in
progress), May 2005.
[6] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[8] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[9] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[10] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation over
Diffserv Networks", RFC 2998, November 2000.
[11] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[12] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Kappler Expires November 13, 2005 [Page 13]
Internet-Draft Controlled-Load QOSM May 2005
Operation Over IP Tunnels", RFC 2746, January 2000.
[13] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
for Signaling", draft-ietf-nsis-ntlp-05 (work in progress),
February 2005.
[14] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-07 (work in progress), December 2004.
[15] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[16] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
Author's Address
Cornelia Kappler
Siemens AG
Siemensdamm 62
13627 Berlin
Germany
Email: cornelia.kappler@siemens.com
Appendix A. Acknowledgements
The author would like to thank Andrew McDonald for fruitful
discussions.
Kappler Expires November 13, 2005 [Page 14]
Internet-Draft Controlled-Load QOSM May 2005
Intellectual Property Statement
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.
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kappler Expires November 13, 2005 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 05:30:29 |