NSIS Working Group
Internet Draft Sven Van den Bosch (Editor)
Alcatel
Georgios Karagiannis
Univ. of Twente/Ericsson
Andrew McDonald
Siemens/Roke Manor Research
Document: draft-ietf-nsis-qos-nslp-00.txt
Expires: March 2004 September 2003
NSLP for Quality-of-Service signaling
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 draft describes an NSIS Signaling Layer Protocol (NSLP) for
signaling QoS reservations in the Internet. It is in accordance with
the framework and requirements developed in NSIS.
Together with the NTLP, it provides functionality similar to RSVP and
extends it. The QoS-NSLP is independent of the underlying QoS
specification or architecture and provides support for different
reservation models. It is simplified by the elimination of support
for multicast flows.
Van den Bosch et al. Expires - March 2004 [Page 1]
NSLP for Quality-of-Service signaling September 2003
This version of the draft focuses on the basic protocol structure. It
identifies the different message types and describes the basic
operation of the protocol to create, refresh, modify and teardown a
reservation or to obtain information on the characteristics of the
associated data path.
Conventions used in this document
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 [1].
Table of Contents
1. Introduction...................................................3
1.1 Scope and background.......................................3
1.2 Model of operation.........................................3
1.3 Terminology................................................6
2. Protocol design principles.....................................7
2.1 Basic protocol structure...................................7
2.2 QoS model..................................................8
2.3 Authentication and authorization...........................9
2.4 Control Information........................................9
2.5 Nested protocol operation.................................10
2.6 Protocol extensibility....................................11
2.7 Implementation flexibility for scalability................11
3. Basic message types...........................................12
3.1 RESERVE...................................................12
3.2 QUERY.....................................................14
3.3 RESPONSE..................................................14
3.4 NOTIFY....................................................15
4. Basic outline of operation....................................15
4.1 Making a reservation......................................15
4.2 Refreshing a reservation..................................17
4.3 Sending a response........................................18
4.4 Performing a query........................................19
4.5 Tearing down a reservation................................19
5. IANA section..................................................20
6. Requirements for the NSIS Transport Layer Protocol (NTLP).....20
6.1 Support for stateless operation...........................20
6.2 Support for Source Identification Information (SII).......21
6.3 Last node detection.......................................21
6.4 Re-routing detection......................................22
6.5 Performance requirements..................................22
7. Open issues...................................................22
7.1 Refinements of this version...............................22
7.2 Content for next (-01) version............................23
7.3 Content for future (-0x) versions.........................23
Van den Bosch et al. Expires - March 2004 [Page 2]
NSLP for Quality-of-Service signaling September 2003
8. Security Considerations.......................................26
9. Change History................................................26
10. Appendix A: A strawman QSpec template........................26
References.......................................................27
Acknowledgments..................................................29
Contributors.....................................................29
Contact information..............................................29
Full Copyright Statement.........................................29
1. Introduction
1.1 Scope and background
This document defines a Quality of Service (QoS) NSIS Signaling Layer
Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This
protocol establishes and maintains state at nodes along the path of a
data flow for the purpose of providing some forwarding resources for
that flow. It is intended to satisfy the QoS-related requirements of
[2]. This QoS-NSLP is part of a larger suite of signaling protocols,
whose structure is outlined in [3]; this defines a common NSIS
Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many
aspects of signaling message delivery.
The design of QoS-NSLP is conceptually similar to RSVP [4], and uses
soft-state peer-to-peer refresh messages as the primary state
management mechanism. Although there is no backwards compatibility at
the level of protocol messages, interworking with RSVP at a signaling
application gateway would be possible in some circumstances. QoS-NSLP
extends the set of reservation mechanisms to meet the requirements of
[2], in particular support of sender or receiver-initiated
reservations, as well as a type of bi-directional reservation and
support of reservations between arbitrary nodes, e.g. edge-to-edge,
end-to-access, etc. On the other hand, there is no support for IP
multicast.
QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular
QoS provisioning method or QoS architecture; this is similar to (but
stronger than) the decoupling between RSVP and the IntServ
architecture [5]. It should be able to carry information for various
QoS models; the specification of Integrated Services for use with
RSVP given in [6] could form the basis of one QoS model.
1.2 Model of operation
Van den Bosch et al. Expires - March 2004 [Page 3]
NSLP for Quality-of-Service signaling September 2003
This section presents a logical model for the operation of the QoS-
NSLP and associated provisioning mechanisms within a single node. It
is adapted from the discussion in section 1 of [4]. The model is
shown in Figure 1.
+---------------+
| Local |
|Applications or|
|Management (e.g|
|for aggregates)|
+---------------+
^
^
V
V
+----------+ +----------+ +---------+
| QoS-NSLP | | Resource | | Policy |
|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
+----------+ +----------+ +---------+
. ^ | * ^
| V . * ^
+----------+ * ^
| NTLP | * ^
|Processing| * V
+----------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
| | * .............................
. . * . Traffic Control .
| | * . +---------+.
. . * . |Admission|.
| | * . | Control |.
+----------+ +------------+ . +---------+.
<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.==>
| | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+.
.............................
<.-.-> = signaling flow
=====> = data flow (sender -->receiver)
<<<>>> = control and configuration operations
****** = routing table manipulation
Figure 1: QoS-NSLP in a Node
Van den Bosch et al. Expires - March 2004 [Page 4]
NSLP for Quality-of-Service signaling September 2003
From the perspective of a single node, the request for QoS may result
from a local application request, or from processing an incoming QoS-
NSLP message.
- The 'local application case' includes not only user
applications (e.g. multimedia applications) but also network
management (e.g. initiating a tunnel to handle an aggregate,
or interworking with some other reservation protocol - such as
RSVP). In this sense, the model does not distinguish between
hosts and routers.
- The 'incoming message' case requires NSIS messages to be
captured during input packet processing and handled by the
NTLP. Only messages related to QoS are passed to the QoS-NSLP.
The NTLP may also generate triggers to the QoS-NSLP (e.g.
indications that a route change has occurred).
The QoS request is handled by a local 'resource management' function,
which coordinates the activities required to grant and configure the
resource.
- The grant processing involves two local decision modules,
'policy control' and 'admission control'. Policy control
determines whether the user has administrative permission to
make the reservation. Admission control determines whether the
node has sufficient available resources to supply the
requested QoS.
- If both checks succeed, parameters are set in the packet
classifier and in the link layer interface (e.g., in the
packet scheduler) to obtain the desired QoS. Error
notifications are passed back to the request originator. The
resource management function may also manipulate the
forwarding tables at this stage, to select (or at least pin) a
route; this must be done before interface-dependent actions
are carried out (including forwarding outgoing messages over
any new route), and is in any case invisible to the operation
of the protocol.
Policy control is expected to make use of a AAA service external to
the node itself. Some discussion can be found in [7] and [8]. More
generally, the processing of policy and resource management functions
may be outsourced to an external node leaving only 'stubs' co-located
with the NSLP; this is not visible to the protocol operation,
although it may have some influence on the detailed design of
protocol messages to allow the stub to be minimally complex.
Van den Bosch et al. Expires - March 2004 [Page 5]
NSLP for Quality-of-Service signaling September 2003
The group of user plane functions, which implement QoS for a flow
(admission control, packet classification, and scheduling) is
sometimes known as 'traffic control'.
Admission control, packet scheduling, and any part of policy control
beyond simple authentication have to be implemented using specific
definitions for types and levels of QoS; we refer to this as a QoS
model. Our assumption is that the QoS-NSLP is independent of the QoS
model, that is, QoS parameters (e.g. IntServ service elements) are
interpreted only by the resource management and associated functions,
and are opaque to the QoS-NSLP itself. QoS Models are discussed
further in section 2.2.
The final stage of processing for a resource request is to indicate
to the QoS-NSLP protocol processing that the required resources have
been configured. The QoS-NSLP may generate an acknowledgement message
in one direction, and may propagate the resource request forwards in
the other. Message routing is (by default) carried out by the NTLP
module. Note that while Figure 1 shows a unidirectional data flow,
the signaling messages can pass in both directions through the node,
depending on the particular message and orientation of the
reservation.
1.3 Terminology
The terminology defined in [3] applies to this draft. In addition,
the following terms are used:
- edge QNE - a QNE that is located at the boundary of an
administrative domain, e.g., Diffserv.
- egress QNE - an edge QNE that handles the traffic as it leaves
the domain.
- ingress QNE - an edge QNE that handles the traffic as it
enters the domain.
- interior QNE - a QNE that is part of an administrative domain,
e.g., Diffserv, and is not an edge QNE.
- QNE - an NSIS Entity (NE), which supports the QoS-NSLP.
- QNI - the first node in the sequence of QNEs that issues a
reservation request.
- QNR - the last node in the sequence of QNEs that receives a
reservation request.
Van den Bosch et al. Expires - March 2004 [Page 6]
NSLP for Quality-of-Service signaling September 2003
- QoS-NSLP stateful operation - mode of operation where per-flow
reservation states are created, maintained and used.
- QoS-NSLP reduced-state operation - mode of operation where
reservation states with a coarser granularity (e.g. per-class)
are created, maintained and used.
- QoS-NSLP stateless operation - mode of operation where
reservation state is not needed and not created.
- reduced state QNE - a QNE that supports the QoS NSLP reduced
state operation.
- Source or message source - QoS NSLP messages are sent peer-to-
peer. This means that a QNE considers its adjacent stateful
upstream or downstream peer to be the source of a QoS NSLP
message. I.e. the source of a QoS NSLP message is not
necessarily the QNI.
- Stateful QNE - a QNE that supports the QoS NSLP stateful
operation.
- Stateless QNE - a QNE that supports the QoS NSLP stateless
operation.
2. Protocol design principles
2.1 Basic protocol structure
Messages are normally passed from the NSLP to the NTLP via an API,
which also specifies the signaling application (as QoS-NSLP), the
flow/session identifier, and an indication of the intended direction
- towards data sender or receiver. On reception, the NTLP provides
the same information to the QoS-NSLP.
The protocol specifies four message types (RESERVE, QUERY, RESPONSE
and NOTIFY) and two objects (QSpec and Policy object).
- Each protocol message includes header information that
identifies the message type and determines which objects it
may carry.
- A protocol message also contains Control Information (CI);
this is a group of objects that qualify and/or restrict the
action that a QNE may perform on the QoS message. Control
Van den Bosch et al. Expires - March 2004 [Page 7]
NSLP for Quality-of-Service signaling September 2003
Information is always associated to a QSpec, i.e. CI and QSpec
always come in pairs. This is important when we have locally
valid objects e.g. for reduced state operation, because both a
CI and a QSpec will be added.
- QSpec object: The QoS parameters defined by the QoS model are
carried in a QSpec object. It describes the QoS that is being
reserved.
- Policy object: The Policy object authenticates and authorizes
the requester of the QoS reservation.
This memo intends to define message types and control information for
the QoS-NSLP (generic to all QoS models). It also introduces the QoS
model (section 2.2) and Policy object (section 2.3). However, a
detailed description of these objects will need to be provided in
separate documents.
2.2 QoS model
A QoS model is a defined mechanism for achieving QoS as a whole. The
specification of a QoS model includes a description of its QoS
parameter information, as well as how that information should be
treated or interpreted in the network. In that sense, the QoS model
goes beyond the QoS-NSLP protocol level in that it could also
describe underlying assumptions, conditions and/or specific
provisioning mechanisms appropriate for it.
A QoS model provides a specific set of parameters to be carried in
the QSpec, or restricts the values these parameters can take.
Integrated Services [5], Differentiated Services[9] and RMD [11] are
all examples of QoS models. There is no restriction on the number of
QoS models. QoS models may be local, meaning that they are private to
one network, implementation or vendor specific or global, meaning
that they must be implementable by different networks and vendors.
The QSpec contains a set of parameters and values describing the
requested resources. It is opaque to the QoS-NSLP and similar in
purpose to the TSpec, RSpec and AdSpec specified in [4,6]. At each
QNE, its content is interpreted by the resource management function
for the purposes of policy control and traffic control (including
admission control and configuration of the packet classifier and
scheduler).
Different QoS models may share a common set of QoS parameters.
Standardizing a QSpec template would allow for a consistent
specification of common QoS parameters in different QoS models. It
Van den Bosch et al. Expires - March 2004 [Page 8]
NSLP for Quality-of-Service signaling September 2003
would simplify the introduction of new QoS models as well as greatly
increasing interoperability. Other examples of QoS description for
which a template was standardized are e.g. the MEF Ethernet Service
definition [10]. The QSpec template is envisaged to be useful for
specifying a wide range of QoS descriptions. It would, for instance,
need to support both qualitative and quantitative QoS specifications
in order to provide for terminals that are not willing or capable to
quantitatively describe the traffic behavior they require. A strawman
QSpec template is described in Appendix A. In addition to
standardizing a QSpec template, individual QoS models could be
standardized, but we would expect them to have local significance
only.
2.3 Authentication and authorization
Future versions of this document will contain a discussion on the
Policy object, based on [7,8].
2.4 Control Information
Any QoS-NSLP message may contain a set of objects for conveying
information about how these messages should be handled. This set of
objects is collectively known as Control Information (CI).
Control Information can have a local scope (Local Control Information
or LCI) or global scope.
The ability of a QNE to explicitly request a RESPONSE to its messages
(section 2.4.1) and the ability to limit the scope of a message are
both examples of Control Information (section 2.4.2). Future versions
of the draft may include more examples of Control
Information objects.
2.4.1 ResponseRequest
Some QNEs may require explicit responses to messages they send. A
QUERY message (section 3.2), for instance, will always cause a
RESPONSE message (section 3.3) to be sent. The QNE that generates a
RESERVE message (section 3.1) may explicitly request that it triggers
a RESPONSE.
If a RESPONSE message is required or desired, the QNE inserts a
ResponseRequest object in the message. The exact format of this
object will be determined in a future version of this specification.
Van den Bosch et al. Expires - March 2004 [Page 9]
NSLP for Quality-of-Service signaling September 2003
In order to be able to match a response back to the corresponding
request , the ResponseRequest object contains Response Identification
Information (RII). The RII is inserted by the QNE that requests the
response and is copied into the corresponding RESPONSE message. QNEs
that receive a RESPONSE containing their own RII should not forward
the message further.
The ResponseRequest object also contains a flag to indicate whether
it is requesting a response from the next node (a 'local' response),
or a response from the QNR. More general ways of specifying scoping
information will be investigated in future versions of this document.
Note that if an intermediate QNE desires a RESPONSE as well, it
should not change the RII or add another ResponseRequest since the
RESPONSE will pass through it anyway.
2.4.2 Message and object scoping
QoS-NSLP supports locally defined QoS model specifications by means
of local QSpecs and local Control Information. Messages containing
such local information need to be scoped, i.e. it should be possible
to restrict the forwarding of such a message to the domain in which
it is applicable. It may also be needed to scope individual objects
in the message.
One example of message scoping uses the RII to limit the forwarding
of a RESPONSE to the QNE that requested it. Another example might be
controlling the scope of a tearing RESERVE.
The two scopes of "single QoS-NSLP hop" and "whole path" appear to be
useful concepts. In case no scoping information is specified, the
default case of "whole path" must be assumed. It is still to be
determined what the best way(s) of specifying more flexible scoping
information, such as per-domain are.
2.5 Nested protocol operation
For various reasons an operator may want to use a different type of
QoS specification (i.e. a different QoS model) within its network.
This may be done, for example, in order for QNEs to be able to store
less reservation state. In order to allow some local selection of
which QoS Model to use without destroying all end-to-end aspects of
the signaling, QoS-NSLP allows a nesting of QoS Models by 'stacking'
more than one pair of Control Information / QSpec object within a
message.
Van den Bosch et al. Expires - March 2004 [Page 10]
NSLP for Quality-of-Service signaling September 2003
The details of this operation will be covered in future versions of
this draft. This nested operation would allow localized QSpec objects
and control information to be used along parts of the path. It also
has dependencies on the scoping facilities provided by the protocol.
2.6 Protocol extensibility
QoS-NSLP is designed in modular way making it possible to support
different QoS models and other future extensions of the protocol.
Extensions can be provided by specifying new QoS models and their
usage or defining new QoS-NSLP objects (similar to the current QSpec
and Policy object) and their usage.
In QoS-NSLP the basic operation mechanism of the protocol is clearly
separated from the control and traffic information being transported.
This logical separation makes it possible to develop a variety of new
QoS models within one protocol frame. Each of the QoS-NSLP message
types can carry, for each supported QoS Model, QoS descriptions by
using object templates. This memo discusses a template for the QoS
specification (QSpec). A future version will also cover the Policy
object.
A new QoS model is specified by defining the internal content of the
template objects and by defining how QoS provisioning is done in
different nodes. Another important aspect of defining a new QoS model
is the specification of the associated CI used in these templates,
which allow particular setting in different nodes.
A QoS model may have internal structure into different components,
some of which may have application limited to particular nodes while
being opaque to others.
2.7 Implementation flexibility for scalability
The QoS-NSLP protocol supports QoS architectures in which some QNEs
may not be able or willing to store per-session state. A stateless
operation is conceivable, in which QNEs interior to a domain store
neither NSLP nor NTLP state. They rather e.g. just send and receive
messages to provide information on currently available resources, and
react upon overload detection. Also reduced-state operation is
conceivable, in which QNEs do not store full per session (per-flow or
per-aggregate) state in both NSLP and NTLP, but rather, e.g. one per-
class state in NSLP and no state in NTLP. Examples of how QoS can be
achieved with stateless and reduced-state operation are described in
RMD [11].
Van den Bosch et al. Expires - March 2004 [Page 11]
NSLP for Quality-of-Service signaling September 2003
Stateless and reduced state operation is only applicable under
certain circumstances. Stateless or reduced state QNEs are not able
to perform message bundling, message fragmentation and reassembly (at
the NSLP) or congestion control. They are not able to establish and
maintain security associations with their neighbors, which means they
can only be applied in a trusted environment. For these reasons, a
typical application of stateless or reduced state QNEs is for
signaling within a single domain where the edges of the domain are
stateful QNEs.
Stateless and reduced state QoS-NSLP operation makes the most sense
when (some nodes of) the underlying NTLP is (are) able to operate in
a stateless way as well. Such nodes should not worry about keeping
reverse path state, message fragmentation and reassembly (at the
NTLP), congestion control or security associations. A stateless or
reduced state QNE will be able to inform the underlying NTLP of this
situation. We rely on the NTLP design to allow for a mode of
operation that can take advantage of this information (section 6.1).
3. Basic message types
The QoS-NSLP contains four message types: RESERVE, QUERY, RESPONSE
and NOTIFY.
These messages have different conceptual properties; the
fundamental properties of the message determine how it should be
analyzed from the perspective of re-ordering, loss, end-to-end
reliability and so on. It is important for applications to know
whether NSLP messages can be repeated, discarded or merged and so on
(e.g. for edge mobility support, rerouting, etc). Indeed, the
ordering of messages that don't manipulate state at QNEs matters
little, whereas the way that messages that manipulate state are
interleaved matters very much. Therefore NSLP is designed such that
the message type identifies whether a message is manipulating state
(in which case it is idempotent) or not (it is impotent).
3.1 RESERVE
The RESERVE message is used to manipulate QoS reservation state in
QNEs. A RESERVE message may create, refresh, modify or remove such
state.
The RESERVE message opaquely transports a QSpec object, describing
the desired service level and a Policy object, authorizing the
requestor of the service. It also carries the lifetime of the
reservation (most likely in the Control Information part). Each node
Van den Bosch et al. Expires - March 2004 [Page 12]
NSLP for Quality-of-Service signaling September 2003
may insert a local QSpec object and or local Control Information
(LCI) provided it has a way of scoping this information (e.g. at the
boundary of a domain).
In some cases, a QNE needs to be able to distinguish between newly
created, modified state or refreshed state based on the RESERVE
message alone (not in combination with state information obtained
from previous messages). Therefore, one or more additional flags that
provide this differentiation may be needed. Future versions of this
draft will describe how such flag(s) will be provided and used.
In order to clearly distinguish between a RESERVE message that sets
the reserved resources to zero and a RESERVE message that tears down
QoS-NSLP state completely, a tear bit should be foreseen. Note that
the potential initiation of (reverse path) state removal at the NTLP
is a separate issue. This will be signaled over the API between NTLP
and QoS-NSLP.
RESERVE messages are sent peer-to-peer. This means that a QNE
considers its adjacent upstream or downstream peer to be the source
of the RESERVE message. Note that two nodes that are adjacent at the
QoS-NSLP layer may in fact be separated by several NTLP hops. A QoS-
NSLP node may want to be able to detect changes in its QoS-NSLP
peers, or send a message to an explicitly identified node, e.g. for
tearing down a reservation on an old path. This functionality can be
provided by keeping track of a Source Identification Information
(SII) object that is similar in nature to the RSVP_HOP object
described in [4]. We assume such an SII (section 6.2) to be available
as a service from the NTLP.
The RESERVE message is idempotent; the resultant effect is the same
whether a message is received once or many times. In addition, the
ordering of RESERVE messages matters - an old RESERVE message does
not replace a newer one. Both of these features are required for
protocol robustness - messages may be re-ordered on route (e.g.
because of mobility, or at intermediate NTLP nodes) or spuriously
retransmitted.
In order to tackle these issues, the RESERVE message contains a
Reservation Sequence Number (RSN). A RSN is an identifier that
indicates the order in which state modifying actions are performed by
a QNE. The RSN has local significance only, i.e. between QNEs.
Attempting to make an identifier that was unique in the context of a
session identifier but the same along the complete path would be very
hard. Since RESERVEs can be sent by any node on the path that
maintains reservation state (e.g. for path repair) we would have the
difficult task of attempting to keep the identifier synchronized
along the whole path. The ordering only matters between a pair of
Van den Bosch et al. Expires - March 2004 [Page 13]
NSLP for Quality-of-Service signaling September 2003
nodes maintaining reservation state, i.e. stateful QNEs. This means
that we can instead make the Reservation Sequence Number unique just
between a pair of neighboring stateful QNEs. Note that an alternative
might be for the NTLP to guarantee in-order delivery between the NSLP
peers.
The sender of a RESERVE message may want to receive some confirmation
from a downstream node. For this purpose the RESERVE message may
contain a ResponseRequest object (section 2.4.1).
3.2 QUERY
A QUERY message is used to request information about the data path
without making a reservation. This functionality can be used to
'probe' the network for path characteristics or for support of
certain QoS models. The information obtained from a QUERY may be used
in the admission control process of a QNE (e.g. in case of
measurement-based admission control). Note that a QUERY does not
change existing reservation state, nor does it cause state to be
installed in nodes other than the one that generated the QUERY.
A QUERY message contains a ResponseRequest object containing Response
Identification Information (RII) that allows matching back RESPONSE
to the QUERY request. It is transported unchanged along the data path
and may be used to scope the RESPONSE to a QUERY message (section
3.3).
The QUERY message can gather information along the data path in a
number of objects. Some of these objects may be part of the QoS
model. Others may be generic to the QoS-NSLP protocol.
A QUERY message may be scoped. If scoping information is present,
this means that the QUERY is not supposed to go down the entire path
to the QNR but rather that is has a maximum number of QNE hops it can
travel. Else, the default case (whole path) is assumed. It is
currently an open issue what the best way of message scoping is
(section 7.1)
3.3 RESPONSE
The REPONSE message is used to provide information about the result
of a previous QoS-NSLP message, e.g. confirmation, error or
information resulting from a query. The RESPONSE message is impotent,
it does not cause any state to be installed or modified.
Van den Bosch et al. Expires - March 2004 [Page 14]
NSLP for Quality-of-Service signaling September 2003
A QNE may want to receive a RESPONSE message to inform it that the
reservation has been successfully installed. The RESERVE message may
contain a ResponseRequest object for this purpose. Such a
ResponseRequest object can be used to request an explicit
confirmation of the state manipulation signaled in the RESERVE
message.
The forwarding of the RESPONSE message along the path does not
necessarily imply the existence of NTLP reverse-path state at every
node. For example, the NTLP may have a mechanism to pass a message
directly from the egress to the ingress of a region of QNEs that do
not store per-flow reverse-path state.
If a QNE or the QNR is unable to provide the requested information or
if the response is negative, the RESPONSE message may be used to
carry an error message.
A QUERY always causes a RESPONSE to be sent. Therefore, a QUERY
message will always contain a ResponseRequest object. A RESERVE may
cause a RESPONSE to be sent if this is explicitly requested or when
an error occurs.
3.4 NOTIFY
NOTIFY messages are used to convey information to a QNE. NOTIFY
messages are impotent (they do not cause a change in state directly).
NOTIFY messages differ from RESPONSEs in that they need not refer to
any particular state or previously received message. They are sent
asynchronously. The NOTIFY message itself does not trigger or mandate
any action in the receiving QNE.
The information conveyed by a NOTIFY message is typically related to
error conditions. One example would be notification to an upstream
peer about state being torn down.
4. Basic outline of operation
4.1 Making a reservation
To make a new reservation, the QNI builds a RESERVE message
containing a QSpec specifying the resources required and a Policy
object containing user identification and authorization information.
It initializes a Reservation Sequence Number (RSN) counter for the
flow and provides the initial value in the RESERVE message. This
Van den Bosch et al. Expires - March 2004 [Page 15]
NSLP for Quality-of-Service signaling September 2003
message is passed to the NTLP, which delivers it to the next QNE. A
ResponseRequest object may be introduced if a confirmation of
successful reservation is desired.
At the next QNE the RESERVE message is examined. Policy control and
admission control decisions are made. The node performs appropriate
actions based on the content of any QSpec object in the message. The
QoS NSLP generates a new RESERVE message based on the one it
received. This is passed to the NTLP, which forwards it to the next
QNE.
The same processing is performed at further QNEs on the path, up to
the QNR.
At the QNR, having determined that it is the last QNE (section 6.3)
on the path, the attempt to send a further RESERVE message is
aborted. The NR may rely on information obtained from the NTLP to
determine that it is the last node (section 6.3).
A QNE may want to store per-flow state for a number of reasons. It
may be that per-flow reservations are required to provide better
granularity of reserved resources. Some additional functions can also
be provided by the NSLP by storing NSLP state.
If the QNE wishes to be able to detect changes in the neighboring QNE
(i.e. that a future RESERVE message did not come from the same node
as the one that sent this RESERVE), then it records the identity of
that node (e.g. SII). The SII on the outgoing message is defined by
the NTLP.
If the QNE also wants to detect re-ordered or duplicated RESERVE
messages then it must also store the Reservation Sequence Number.
When an NSLP node that maintains per-flow reservation state (and may
generate refreshes) generates a RESERVE message to forward on to the
next peer it must replace the Reservation Sequence Number in the
message it received with one of its own. If the NSLP does not
maintain any per-flow reservation state (and thus cannot generate new
RESERVE messages (refreshes, tears, etc) on its own) then it can use
the RSN from the RESERVE message it received, rather than maintaining
its own sequence numbers. By managing the sequence numbers in this
manner, the source of the RESERVE does not need to determine how the
next NSLP node will process the message.
Layering approaches (as outlined in section 2.5) can be used by an
ingress QNE to translate end-to-end NSLP messages into a form which
is particularly suited to the local network, where it is expected
that interior nodes will benefit from this. For example, where only
per-class state or no state is stored by nodes (as for stateless or
Van den Bosch et al. Expires - March 2004 [Page 16]
NSLP for Quality-of-Service signaling September 2003
reduced-state operation in section 2.7). At the egress of the region,
this local QSpec can be removed.
4.2 Refreshing a reservation
Since the NSIS protocol suite normally takes a soft-state approach to
managing reservation state in QNEs, the state created by a RESERVE
message must be periodically refreshed. Reservation state is deleted
if no new RESERVE messages arrive before the expiration of the
reservation lifetime. The Reservation lifetime is indicated in the
RESERVE message when the reservation is made. Maintaining the
reservation beyond this lifetime can be done by sending a RESERVE
message with the same QSpec and Policy objects as the original
message that created the reservation and by indicating that it is
refreshing existing state. Note that a refreshing RESERVE should not
increment the Reservation Sequence Number.
At the expiration of a "refresh timeout" period, each QNE
independently examines its state and sends a refreshing RESERVE
message to the next QNE peer where it is absorbed. This peer-to-peer
refreshing (as opposed to the QNI initiating a refresh which travels
all the way to the QNR) allows QNEs to choose refresh intervals as
appropriate for their environment. For example, it is conceivable
that refreshing intervals in the backbone, where reservations are
relatively stable, are much larger than in an access network. The
"refresh timeout" is calculated within the QNE and is not part of the
protocol; however, it must be chosen to be compatible with the
reservation lifetime, and an assessment of the reliability of message
delivery.
The details of timer management and timer changes (slew handling and
so on) are left for future versions of this document.
If a RESPONSE has been received to acknowledge that reservation state
has been installed, then an abbreviated form of refreshing RESERVE
message ('summary refresh') can be sent which references the
reservation using the Reservation Sequence Number, rather than
including the full reservation specification. Note that this
functionality requires an explicit acknowledgment of state
installation to ensure that the RSN reference will be understood. It
is up to a QNE that receives a ResponseRequest to decide whether it
wants to accept summary refreshes and provide this explicit
acknowledgment. For example, reduced state QNEs that cannot support
summary refreshes would not send this acknowledgement.
It is currently an open point which parts of the RESERVE message are
reused by the summary refresh. A summary refresh containing only the
Van den Bosch et al. Expires - March 2004 [Page 17]
NSLP for Quality-of-Service signaling September 2003
RSN seems to be the minimal case of a broad spectrum of varying
amounts of data that we send in an update. Future versions of this
document will attempt to identify some objects as 'needing refresh'.
4.3 Sending a response
A QNE sending a RESERVE message may also request a RESPONSE message
to be sent back to it. To do this it includes a ResponseRequest
object with a RII object in it.
When a node processes a received RESERVE message it should examine it
to see if it contains a local ResponseRequest object. If it does,
then a RESPONSE message is generated, and the contents of this object
are copied into it. The local ResponseRequest object is removed from
the RESERVE message being sent out.
At the QNR, the processing of local ResponseRequest objects is
carried out normally (this may happen before this QNE has determined
that it is the QNR). If the RESERVE message received by the QNR
contained a ResponseRequest object, then a RESPONSE message is
created with the contents of the ResponseRequest object copied into
it.
On receiving a RESPONSE message a QNE should check the contents of
the ResponseRequest object echoed back to see if it contains an
identifier supplied by it (the RII). If it does, then it should
inspect the contents of the message and send it no further. This
should always be the case for local ResponseRequest objects. If one
of these is received with an incorrect identifier, then the RESPONSE
must be discarded.
For other QNR responses, the QNE may inspect the message and then
must pass it back to the NTLP to be sent on.
When a RESPONSE message reaches the edge of a stateless domain, the
egress QNE will map/interchange the control information used by the
"end to end" and "local" scope QoS model types. The generated LCI
information will be encapsulated into the RESPONSE message. By using
the stored SII of the ingress QNE the RESPONSE message will be sent
to the particular ingress QNE node.
Stateless and reduced state interior QNEs are not using the RESPONSE
message.
When the RESPONSE message is received by the ingress QNE node, the
LCI information is used by the "local" scope QoS model. Afterwards,
Van den Bosch et al. Expires - March 2004 [Page 18]
NSLP for Quality-of-Service signaling September 2003
the LCI information is removed from the RESPONSE message, which is
sent towards the QNI.
4.4 Performing a query
In order to perform a query along a path, a QNE constructs a QUERY
message. The message must contain a ResponseRequest object in the
same manner as described above to allow it to match any received
RESPONSE messages back to the original QUERY. The QUERY message may
contain general QoS NSLP query elements, as well as objects specific
to a given QoS model. The message is then passed to the NTLP to be
passed along the path.
A QNE (including the QNR) receiving a QUERY message should inspect it
and manipulate the general query objects and QoS model specific query
objects as required. It then passes it to the NTLP for further
forwarding unless it knows it is the QNR.
At the QNR, a RESPONSE message is generated. Into this is copied the
ResponseRequest object, and other general and QoS model specific
information from the QUERY message. It is then passed to the NTLP to
be forwarded peer-to-peer back along the path.
Each QNE receiving the RESPONSE message should inspect the
ResponseRequest object to see if it contains an RII supplied by it.
If it does not then it simply passes the message back to the NTLP
unless it is a local RESPONSE. If it does, it uses the RII to match
the RESPONSE back to the original QUERY, and performs any appropriate
action based on the result of the query.
4.5 Tearing down a reservation
Although the use of soft state means that it is not necessary to
explicitly tear down an old reservation, it is RECOMMENDED that QNIs
send a teardown request as soon as a reservation is no longer needed.
A teardown deletes reservation state and travels towards the QNR from
its point of initiation. A teardown message may be initiated either
by an application in a QNI or by a QNE along the route as the result
of a state timeout or service preemption. Once initiated, a teardown
message must be forwarded QNE peer - to - QNE peer without delay.
A QNE can remove a reservation by building a RESERVE message with the
'tear' indicator set to inform the next-hop QNE to remove the
reservation state that it may hold. The tearing RESERVE is passed to
the NTLP to be forwarded along the NEs up to the next-hop QNE. It is
currently an open issue whether the tearing RESERVE will
Van den Bosch et al. Expires - March 2004 [Page 19]
NSLP for Quality-of-Service signaling September 2003
automatically tear down state in each NE. The next-hop QNE either
tears down the corresponding reservation and passes on the tearing
RESERVE, or, if it already has torn down the reservation, discards
the message.
In addition, the QNE should construct a NOTIFY message and attempt to
send it back to the QNE that requested the reservation originally.
The NOTIFY message will inform the other QNE that a reservation has
been removed. On receipt of such a NOTIFY message a QNE should
determine an appropriate course of action. This may include removing
its own reservation state, and passing the NOTIFY message back
further along the path.
The attempt to send a NOTIFY message may be abandoned if the NTLP is
not able to route the message along the reverse-path (e.g. because it
has not stored the necessary state). In case of a stateless or
reduced state domain, the ingress QNE of the domain will be notified
by the egress QNE, which has kept track of its SII. The ingress QNE
can then send the NOTIFY message further upstream. It can also
initiate a scoped tearing RESERVE message towards the egress QNE.
5. IANA section
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the QoS-
NSLP, in accordance with BCP 26 [12].
Future versions of this draft will identify name spaces in QoS-NSLP
that require registration and contain recommendations for
registration policies.
6. Requirements for the NSIS Transport Layer Protocol (NTLP)
For the moment this section will merely describe what we assume
and/or request to be available from the NTLP. This section will later
be updated to describe the eventual interface when NTLP work gets
finalized.
6.1 Support for stateless operation
Stateless or reduced state QoS-NSLP operation makes the most sense
when (some nodes of) the underlying NTLP is (are) able to operate in
a stateless way as well. Such nodes should not worry about keeping
reverse state, message fragmentation and reassembly (at the NTLP),
congestion control or security associations. A stateless or reduced
Van den Bosch et al. Expires - March 2004 [Page 20]
NSLP for Quality-of-Service signaling September 2003
state QNE will be able to inform the underlying NTLP of this
situation. We rely on the NTLP design to allow for a mode of
operation that can take advantage of this information.
6.2 Support for Source Identification Information (SII)
There are several circumstances where it is necessary for a QNE to
identify the adjacent QNE peer, which is the source of a signaling
application message; for example, it may be to apply the policy that
"state can only be modified by messages from the node that created
it".
We rely on the NTLP to provide this functionality. By default, all
outgoing QoS-NSLP messages are tagged like this at the NTLP layer,
and this is propagated to the next QNE, where it can be used as an
opaque identifier for the state associated with the message; we call
this the Source Identification Information (SII). The SII is
logically similar to the RSVP_HOP object of [4]; however, any IP (and
possibly higher level) addressing information is not interpreted in
the QoS-NSLP. Indeed, the intermediate NTLP nodes could enforce
topology hiding by masking the content of the SII (provided this is
done in a stable way).
Keeping track of the SII of a certain reservation also provides a
means for the QoS-NSLP to detect route changes. When a QNE receives a
RESERVE referring to existing state but with a different SII, it
knows that its upstream peer has changed. It can then use the old SII
to send initiate a teardown along the old section of the path. This
functionality would require the NTLP to be able to route based on the
SII. We would like this functionality to be available as a service
from the NTLP.
6.3 Last node detection
There are situations in which a QNE needs to determine whether it is
the last QNE on the data path (QNR), e.g. to construct and send a
RESPONSE message.
A number of conditions may result in a QNE determining that it is the
QNR:
- the QNE may be the flow destination
- the QNE have some other prior knowledge that it should act as
the QNR
Van den Bosch et al. Expires - March 2004 [Page 21]
NSLP for Quality-of-Service signaling September 2003
- the QNE may be the last NSIS-capable node on the path
- the QNE may be the last NSIS-capable node on the path
supporting the QoS NSLP
Of these four conditions, the last two can only be detected by the
NTLP. We rely on the NTLP to inform the QoS-NSLP about these cases by
providing a trigger to the QoS-NSLP when it determines that it is the
last NE on the path, which supports the QoS-NSLP. It requires the
NTLP to have an error message indicating that no more NSLPs of a
particular type are available on the path.
6.4 Re-routing detection
This trigger is provided when the NTLP detects that the route taken
by a flow (which the QoS-NSLP has issued signaling messages for) has
changed.
6.5 Performance requirements
The QoS-NSLP will generate messages with a range of performance
requirements for the NTLP. These requirements may result from a
prioritization at the QoS-NSLP (section 7.3.4) or from the
responsiveness expected by certain applications supported by the QoS-
NSLP.
The NTLP design should be able to ensure that performance for one
class of messages was not degraded by aggregation with other classes
of messages. The different classes of performance requirements will
be listed in future versions of this document.
7. Open issues
7.1 Refinements of this version
Some topics raised in this document would benefit from more detailed
discussion. These include:
- description of the operation under re-routing conditions
- description of the modification operation
- description of the operation under error conditions
- detailed discussion of message timer
- detailed discussion of control information, more particularly
message scoping
- detailed discussion on the impact of a tearing RESERVE on state
Van den Bosch et al. Expires - March 2004 [Page 22]
NSLP for Quality-of-Service signaling September 2003
teardown at the NTLP
7.2 Content for next (-01) version
In addition to refining the discussion of topics currently described
in this document, we intend the next version of this document to
discuss the following issues.
7.2.1 Sender/Receiver-initiated operation
A sender-initiated reservation is made when the QNI for that flow is
located upstream of the QNR with respect to the data path of the flow
that is being signaled for. A receiver-initiated reservation is then
made when the QNI is located downstream of the QNR with respect to
the data path of the flow that is being signaled for. Note however,
that the actual QoS-NSLP entities that initiate these signaling
procedures can be anywhere along the data path, not just at the
endpoints.
There are signaling scenarios in which the receiver-initiated
approach is more advantageous, while in others the sender-initiated
approach is required. QoS-NSLP stateless operation, for example, is
only possible when the sender-initiated approach is applied.
The next version of this draft will describe the use of sender-
initiated and receiver-initiated reservations in the protocol. Note
that the solution of this issue will also impact the way bi-
directional reservations are supported (see Section 7.3.3).
7.2.2 Message formats
This version of the draft describes the functionality provided by the
QoS-NSLP messages. Encoding this functionality into a message format
is left for the next version.
7.2.3 Message flows
This version of the draft briefly describes basic protocol operation.
Future versions of this draft will include message flow diagrams for
informative purposes (potentially in an appendix).
7.3 Content for future (-0x) versions
Van den Bosch et al. Expires - March 2004 [Page 23]
NSLP for Quality-of-Service signaling September 2003
7.3.1 Aggregation
Future versions of this document will describe the use of aggregation
to reduce the signaling overhead (message bundling) and the routing
state (similar to [13]).
7.3.2 Tunnel management
Future versions of this document will describe the use of QoS-NSLP
over tunnels and the associated tunnel management.
7.3.3 Bi-directional/proxy operation
A future version of this draft will discuss the use of bi-directional
reservations, i.e. combining the reservations for a pair of coupled
flows going in opposite directions. The main difficulty here is that
the two flows, although between the same end points, may traverse
different paths across the Internet.
Two proposals for tackling this are:
- generate both a sender initiated and a receiver-initiated
reservation at the QNI (section 7.2.1), and allow them to be bundled
together by the NTLP (the bundle can be split if the paths diverge).
- generate a sender-initiated reservation that includes a request for
the QNR to generate a sender-initiated reservation for the flow in
the other direction.
Both methods make some assumption about the flow routing. The first
method requires that both flows pass through the same QNI. The second
assumes that the QNR for one direction is on the path of the flow in
the other direction.
A future version will also include discussion on the operation of
QoS-NSLP with (path-coupled) proxies.
7.3.4 Priority and preemption
The QoS-NSLP will generate messages with different priority.
Prioritization at the level of the QoS-NSLP includes reservation
priority and message priority.
Reservation priority enables some reservations to be setup even if
resources would normally not be available (e.g. for emergency
services). This requires a priority indication in the message. Note
Van den Bosch et al. Expires - March 2004 [Page 24]
NSLP for Quality-of-Service signaling September 2003
that such an indication may be restricted to the QoS model scope,
although every QoS model is expected to need this functionality.
Whether resources are freed by means of pre-emption (the act of
tearing down an existing reservation to free resource for a new one)
or whether high-priority resources should be pre-provisioned is an
implementation issue for the Resource Management Function.
Message priority allows QoS-NSLP messages to be processed and
forwarded in a different order than in which they arrived. This may
be needed to ensure responsiveness to reservation requests or
modifications (e.g. a reservation caused by a mobility event of an
in-service session may need to be handled faster than a query or a
new reservation request). This kind of prioritization should then be
supported in the QoS-NSLP message set and may pose requirements on
the NTLP (section 6.5).
Future versions of this document will describe the support and use of
prioritization for the QoS-NSLP.
7.3.5 Network Address Translation (NAT)
Since the QoS-NSLP is used for requesting resources for data flows,
the messages inevitably involve IP addresses and, possibly, port
numbers. However, the addresses/ports of the data flow can be
modified by Network Address Translators (NATs) along the path. It is
hoped that some (or all) of this problem can be pushed down into the
NTLP, so that only generic NSIS-awareness is required at the NAT,
rather than requiring specific support for QoS-NSLP (as described in
section 5.3 of [3]). Future versions of this document may contain
additional discussion on this issue.
7.3.6 Security components
7.3.7 Mobility
A future version of this draft will provide details on mobility
support in QoS-NSLP, following the requirements in [2], [14]. A
number of issues are associated with mobility support, such as
localizing the new reservation to the new segment of the path,
removing reservation state along the old segment of the path,
recognizing a RESERVE message for an already established reservation
although the IP address of the mobile node changed, possible
concealment of QoS-NSLP messages due to IP-in-IP tunneling utilized
in mobile IP, etc. Some of these issues can be solved by employing a
session ID that is independent of the IP address, in addition to the
Van den Bosch et al. Expires - March 2004 [Page 25]
NSLP for Quality-of-Service signaling September 2003
flow ID (this has security implications, see [15]), and by supporting
the SII and reservation sequence numbers. Some mobility support will
be provided by NTLP, such as detection of route changes. More details
are discussed in [16].
8. Security Considerations
The security of the NSLP is provided by a combination of security
functions at the NTLP and NSLP. Subsequent versions of this draft
will need to contain a specification of the NSLP security features,
and how these interact with those at the NTLP.
Some consideration of the problems can be found in [17][15][8]
9. Change History
10. Appendix A: A strawman QSpec template
This appendix describes a strawman QSpec template. The QSpec template
could include objects and fields for conveying the following
information:
- QSpec ID: This would allow IANA reservation of well known
QSpec parameter combinations
- Traffic Envelope and traffic conformance (similar to RSVP's
TSpec)
- Excess treatment: what happens to non-conforming traffic of a
certain reservation (may be dropped but could be remarked as
well)
- Offered guarantees: this may be delay, jitter, loss or
throughput, both qualitatively (low delay) and quantitatively
(delay < 100ms, optionally even with quantiles
Note that the specification may support ranges of acceptable
values
- Service schedule: for when is the service requested: this
would allow a RESERVE/COMMIT functionality
- Reliability: what percentage of the time do you expect to get
the offered guarantee (this will allow e.g. a local resource
management function to map the traffic to an APS protected
link)
Van den Bosch et al. Expires - March 2004 [Page 26]
NSLP for Quality-of-Service signaling September 2003
- Monitoring requirements: what information do you require about
the reservation. This is related to the AdSpec functionality
and may contain parameters or sub object to be used in QUERY.
Note that Flow identification information is also needed but that
this is not assumed to be part of the QSpec template but rather
available over the API between NTLP and QoS-NSLP.
It is not the intention that all QoS models support all fields and
sub objects defined here. The definition of a QoS model entails a
selection of one or more of these fields and/or sub objects. For
instance, one QoS model could only allow QSpec ID and DSCP to be
specified.
References
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2 M. Brunner, Ed., "Requirements for QoS signaling protocols."
draft-ietf-nsis-req-09.txt, August 2003.
3 R. Hancock, Ed., "Next Steps in Signaling: Framework", draft-ietf-
nsis-fw-03.txt (work in progress), June 2003.
4 Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
5 Braden, B., Clark, D. and S. Shenker, "Integrated Services in the
Internet Architecture: an Overview", RFC 1633, June 1994.
6 Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
7 Tschofenig, H., "NSIS Authentication, Authorization and Accounting
Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress),
March 2003.
8 Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne,
"QoS NSLP Authorization Issues", draft-tschofenig-nsis-qos-authz-
issues-00 (work in progress), June 2003.
Van den Bosch et al. Expires - March 2004 [Page 27]
NSLP for Quality-of-Service signaling September 2003
9 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
Architecture for Differentiated Services", RFC 2475, December
1998.
10 Metro Ethernet Forum, "Ethernet Services Model," letter ballot
document, August 2003.
11 Westberg, L., "Resource Management in Diffserv (RMD) Framework",
draft-westberg-rmd-framework-04 (work in progress), September
2003.
12 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
13 Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
14 H. Chaskar, "Requirements of a QoS solution for Mobile IP," RFC
3583, Sept. 2003.
15 H. Tschofenig, H. Schulzrinne, et al., "Security implications of
the session identifier" Internet Draft, June 2003.
16 X. Fu, H. Schulzrinne, H. Tschofenig "Mobility Support in NSIS",
Internet Draft, June 2003.
17 H. Tschofenig and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-02.txt (work in progress), June 2003.
Van den Bosch et al. Expires - March 2004 [Page 28]
Acknowledgments
This section will contain acknowledgments.
Contributors
This draft combines work from three individual drafts. The following
authors from these drafts also contributed to this document: Robert
Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia
Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and
Maarten Buechli (Dante) and Eric Waegeman (Alcatel).
Contact information
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
email: karagian@cs.utwente.nl
Andrew McDonald
Roke Manor Research
Old Salisbury Lane
Romsey
Hampshire
SO51 0ZN
United Kingdom
email: andrew.mcdonald@roke.co.uk
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen
Belgium
email: sven.van_den_bosch@alcatel.be
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
Van den Bosch et al. Expires - March 2004 [Page 29]
NSLP for Quality-of-Service signaling September 2003
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 assigns. 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.
Van den Bosch et al. Expires - March 2004 [Page 30]