Network Working Group Jerry Ash
Internet Draft AT&T
<draft-ash-nsis-nslp-qspec-00.txt> Attila Bader
Expiration Date: December 2004 Ericsson
Cornelia Kappler
Siemens AG
May 2004
QoS-NSLP QSpec Template
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.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Ash et al. Expires December 2004 [Page 1]
Internet Draft QoS-NSLP QSpec Template
Abstract
This draft describes a QSpec template for the QoS NSIS Signaling
Layer Protocol (QoS NSLP) for signaling QoS reservations in the
Internet. A QSpec is transported in QoS-NSLP messages and is opaque
to QoS NSLP. It contains the QoS Signaling Model (QSM) control
information and QoS description parameters. Control information is,
for example, a flag that a particular QSM was not understood by one
QoS NSLP entity. QoS description parameters are primary input and
output parameters of the Resource Management Function. They include
immutable descriptions of the traffic for which resources are to be
reserved and of the desired QoS. QoS description parameters can also
be used for collecting information about resource availability along
the path. The QSpec template defines generic parameters that are
common to many QSMs. They should be used by all QSMs if applicable.
By identifying the generic parameters we aim to ensure
interoperability between different QSMs.
Table of Contents
1 Introduction ................................................. 3
2 Processing of QSpec .......................................... 4
3 QSpec Template ............................................... 5
3.1 Applicability .............................................. 5
3.2 QSpec Format Overview ...................................... 6
3.3 QSM ID ..................................................... 7
3.4 QSM Specific Control Information ........................... 7
3.5 QoS Description Parameter Types ............................ 8
3.5.1 Traffic Descriptors ...................................... 9
3.5.2 QoS Class ................................................ 10
3.5.3 QoS Characterization ..................................... 11
3.5.4 Excess Treatment ......................................... 11
3.5.5 Priority and Reliability ................................. 11
3.5.6 Monitoring Requirements .................................. 12
4 Security Considerations ...................................... 12
5 Open Issues and Outlook ...................................... 13
6 Acknowledgements ............................................. 13
7 References ................................................... 14
8 Authors' Addresses ........................................... 15
9 Full Copyright Statement ..................................... 16
Ash et al. Expires December 2004 [Page 2]
Internet Draft QoS-NSLP QSpec Template
1. Introduction
The QoS NSLP establishes and maintains state at nodes along the path
of a data flow for the purpose of providing forwarding resources
(QoS) for that flow [QOS-SIG]. The design of QoS NSLP is conceptually
similar to RSVP [RSVP], and meets the requirements of [NSIS-REQ].
QoS NSLP does not mandate any specific 'QoS Signaling Model' (QSM),
i.e. it does not mandate a particular QoS provisioning method or QoS
architecture. It should be able to support, for example, IntServ and
signaling for DiffServ admission control, and satisfy the need of
more complex control planes such as defined in [Q.2630, Y.1541].
Examples of different QSMs for NSIS are specified in [TRQ-QoS-SIG,
INTSERV-QoS-SIG, RMD-QoS-SIG]. Note that what we call QSM here is
called QoS Model in [QoS-SIG]. We call it QSM to emphasize this work
is not about inventing new QoS provisioning methods or QoS
architectures. Rather it is about enabling the signaling of existing
QoS provisioning methods / architectures with QoS NSLP. Future
versions of this ID and [QoS-SIG] will be consolidated.
QSM-specific information is carried in the so-called QSpec object,
which travels in QoS-NSLP messages. The QSpec is opaque to QoS NSLP,
and can have subobjects corresponding to the TSpec, RSpec and AdSpec
objects specified in RSVP. This is, the QSpec may contain a traffic
characterization (TSpec) and a description of desired QoS (RSpec). It
can also collect information about available resources (AdSpec). As
opposed to RSVP, however, usage of these subobjects is not bound to
particular message types to allow for flexibility. E.g., an object
collecting information about desired QoS may travel in any QoS NSLP
message, for example a QUERY message or a RESERVE message.
The QSpec object contains two types of information: QSM control
information and a QoS description. The QoS description contains the
aforementioned subobjects for description of traffic, description of
desired QoS, and for collecting information about resources and
offered QoS. The QSM control information contains information not
related to the actual resource management but rather to message
processing. Examples of QSM control information are scope of the
QSpec or a flag indicating the QSM was not understood by one QoS NSIS
entity (QNE). QSM control information must not be confused with the
common control information, which is a set of objects traveling in
QoS NSLP messages. Whereas QSM control information is specific to the
QSpec, common control information is specific to the QoS NSLP
message.
Ash et al. Expires December 2004 [Page 3]
Internet Draft QoS-NSLP QSpec Template
A QSM describes QSpec usage in QoS NSLP messages, it defines a set of
QoS description and QSM control information parameters for QSpec, and
it may restrict the values these parameters can take. This draft
provides a template for QSpec, which is needed in order to help
defining individual QSMs and in order to promote interoperability
between QSMs.
In particular, the following parameter types are proposed for QSpec:
1) QSpec ID
2) QSM Control Information
3) QoS Description
a) Traffic Descriptors
b) QoS Class
c) QoS Characterization
d) Excess Treatment
e) Priority and Reliability
f) Service Schedule
g) Monitoring Requirements
The processing of QSpec is described in more detail in Section 2, it
is based on the arguments given in [INTSERV-QOS-SIG]. The proposed
QSpec template is given in Section 3, including an applicability
statement.
2. Processing of QSpec
The model of QoS-NSLP message processing is illustrated in Figure 1.
A QoS-NSLP message is interpreted in the common NSLP processing of a
QNE as described in [QOS-SIG]. The QSpec, however, is opaque to QoS-
NSLP, which means that it is not processed in the common NSLP
processing but handed over to the resource management function and
QSM-specific NSLP processing. The QSM control information is
interpreted and perhaps modified by the QSM-specific NSLP processing,
and the QoS description is interpreted and may be modified by the
resource management function. Both, QSM-specific NSLP processing and
the resource management function, may advise the common NSLP
processing on how to proceed with the signaling, e.g. to tear down a
preempted reservation. From an implementation point of view, the
common NSLP processing is the same in each NSIS capable router,
whereas QSM-specific NSLP processing and the resource management
function are QSM specific. Note that the QSM-specific NSLP
processing box is an addition to the QoS-NSLP processing model of
[QoS-SIG] suggested in this document. Details of how QSM-specific
Ash et al. Expires December 2004 [Page 4]
Internet Draft QoS-NSLP QSpec Template
NSLP processing, common NSLP processing and the resource management
function collaborate need to be worked out.
+---------------+
| Local |
|Applications or|
|Management (e.g|
|for aggregates)|
+---------------+
^
+------------------+ ^
| QSM-specific | V
| NSLP Processing | +----------+ +---------+
| | | Resource | | Policy |
+------------------+<<<<<<>>>>>>>|Mgmt. Fct.|<<<>>>| Control |
| Common NSLP | | | | |
| Processing | +----------+ +---------+
| | * ^
+------------------+ * ^
. ^ | * ^
| V . * ^
+----------+ * ^
| NTLP | * ^
|Processing| * V
+----------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
Figure 1. Updated Model of QoS-NSLP Processing in a QNE
3. QSpec Template
3.1. Applicability
The QSpec template defines a format for the QSpec, as well as a
number of generic and optional QSpec parameters. Generic parameters
provide a common language for QSM developers to build their QSpecs
and are likely to be re-used in several QSMs. This eases comparing
different QSpecs and different QSMs - and possibly simplifies mapping
of one into another. Thus developers should avoid defining
Ash et al. Expires December 2004 [Page 5]
Internet Draft QoS-NSLP QSpec Template
parameters similar to the generic, standardized ones.
A specific QSM may, however, only use a subset or perhaps none of the
generic QSpec parameters. For instance, it may only allow the QSpec
ID and token bucket to be specified. Furthermore, a QSM may define
additional parameters. It is also important to note that QNEs need
not support all the generic QSpec parameters.
Generic parameters SHOULD be used by QSMs if applicable. Generic
parameters SHOULD be understood by any QNE.
Optional parameters SHOULD be used by QSMs if applicable, and
defining optional parameters facilitates interworking. However, QNEs
outside the domain employing a particular QSM cannot be expected to
understand the optional parameters.
It needs to be investigated whether a minimal set of generic QSpec
parameters MUST (rather than SHOULD) be supported in any QNE: this
may be important for interoperability of QSMs. For example, QoS NSIS
functions at the edge of a domain may have to interpret arriving
QSpecs and translate them into QSpecs specific to the local QSM. Such
translation is not necessarily a local, bi-lateral function between
adjacent domains since QSpecs can be stacked and hence tunnel through
domains. The set of QSpec parameters that MUST be supported could be
a subset of the generic ones defined here.
3.2. QSpec Format Overview
QSpec = <QSM ID> <QSM Control Information> <QoS Description>
As described above, the QSpec object contains the actual resource
description (QoS description) as well as QSM control information.
Both QoS description and QSM control information may contain mutable
and immutable parameters.
Mutable parameters can be changed by any QNE, including by QoS NSIS
functions along the signaling path, whereas immutable parameters are
fixed by the initiating QNE and/or responding QNEs. An example of a
mutable parameter is bandwidth available along a path, an example of
an immutable parameter is bandwidth desired.
<QSM Control Information> = <mutable QSM Control Information>
<immutable QSM Control Information>
Ash et al. Expires December 2004 [Page 6]
Internet Draft QoS-NSLP QSpec Template
<QoS Description> = <mutable QoS Description> <immutable QoS
Description>
Mutable or immutable QoS Description parameters can appear as sub-
objects as follows:
<mutable QoS Description> = <Resource Availability>
<immutable QoS Description> = <Traffic Characterization>, <QoS
Desired>
On the QSpec template level, there is no restriction on how many of
these sub-objects a QSpec may carry, nor what type of sub-object is
carried in what type of QoS NSLP message. For example, in a
receiver-initated reservation scenario, the initiating QNE may send a
QUERY carrying a <Resources Availability> object to probe the
available resources on the path, and simultaneously carrying <QoS
Desired> and <Traffic Characterization> objects. The responding QNE
can re-use the latter objects in the RESERVE message. The QoS NSLP
and particularly the QSMs prescribe how the sub-objects in QSpecs are
interpreted and used, and therefore restrict this freedom.
3.3. QSM ID
The QSM ID allows IANA reservation of QSpec parameter combinations.
Generic Parameter: IANA <QSM ID>
3.4. QSM Specific Control Information
QSM specific control information contains QSM specific control fields
and flags. This information is used for QSpec-specific control
information and for specific signaling functions not defined in QoS-
NSLP. It enables building a new signaling model within a QoS-NSLP
signaling frame, see for example [RMD-QoS-SIG].
Generic parameters:
- <TTL>
mutable time-to-live field, limiting the scope of QSpec to a maximum
number of QoS-NSLP hops. TTL must not be confused with the scope of
the QoS NSLP message carrying the QSpec. This scope would be coded
Ash et al. Expires December 2004 [Page 7]
Internet Draft QoS-NSLP QSpec Template
in the common control information, as described above.
- <QSM Unknown>
mutable flag, indicating the QSM was not understood at least one QNE
- <Denied Flag>
mutable parameter, indicating unsuccessful reservation in a QNE
- <Service Schedule> = <start time>, <end time>, <relative time
duration from RESPONSE>
immutable parameter, indicating the desired start time and end time
of the service, i.e. when is the service available. This parameter
is related to the COMMIT flag suggested in [QOS-NSLP].
Further optional parameter examples are:
- Message Type, further specifying the QoS-NSLP message type
- Flag indicating bi-directional reservation
- Flag indicating severe congestion
- Load Sharing, a field indicating load sharing and percent of load
that is reserved for the actual flow. (It needs to be investigated
whether this field, defined in [RMD-QOS-SIG] is equivalent to the
NO_RESOURCE_SHARING flag in [QOS-SIG].)
3.5. QoS Description Parameter Types
An overview of QoS description parameter types was already given in
Section 1. Some QoS description parameter types are by their nature
immutable (e.g. priority), some are mutable (e.g. excess treatment),
and some can be both mutable or immutable, e.g. bandwidth.
Correspondingly, these latter parameters can appear e.g. in <Traffic
Characterization> as well as in <Resource Availability> as needed by
the QSM. The following table attempts a (preliminary) mapping of QoS
description parameter type on sub-object type.
Ash et al. Expires December 2004 [Page 8]
Internet Draft QoS-NSLP QSpec Template
<Resource <Traffic <QoS
Availability> Characterization> Desired>
Traffic
Descriptors x x x
QoS Class x x
QoS Charact. x x
Excess Treatment x
Prio. and Reliability x
Service Schedule x
Monitoring Requirements x
3.5.1. Traffic Descriptors
These parameters may describe traffic characteristics or
desired/available QoS. The complexity of the parameter set depends
on the QSM being used. They can be just bandwidth, or, more
generally indicate an equivalent resource value describing the
resources used by the stream that fulfills a probabilistic QoS
criterion. They can indicate a traffic envelope that is an upper
bound of the expected traffic. Or they may also contain other packet
level descriptors that are needed for call admission control used at
the boundary of a domain. Traffic descriptors are used for resource
management and traffic conformance testing. Traffic conformance
testing can be based on, for example, a token-bucket algorithm as
specified in [RFC2210].
Traffic descriptor parameters can be mutable or immutable: They can,
for example, immutably appear in <Traffic Characterization> or
<Desired QoS>. They can also be mutable in <Resource Availability>
traveling, for example, in a QUERY message that collects resource
information along a path. In the coding of a traffic descriptor, a
bit is included that says whether a specific instance is mutable or
immutable (or perhaps it is sufficient to locate in a specific
mutable/immutable sub-object)
Traffic descriptors are primary input/output parameters of a resource
reservation function and are most probably part of any QSM.
Generic mutable/immutable traffic descriptor parameters:
a. <Bandwidth or Number of Resource Units>
This is the simplest traffic descriptor. It can be an equivalent
bandwidth (or resource unit) value, for example, determined at the
boundary of a QoS domain derived from more complex descriptors.
Whether the bandwidth is to be interpreted as average or peak
Ash et al. Expires December 2004 [Page 9]
Internet Draft QoS-NSLP QSpec Template
bandwidth is defined in the QSM. (Open issue: this freedom may limit
interoperability.)
b. <Token Bucket> = <Token Bucket Rate (r), Token Bucket Size (b),
Peak Data Rate (p), Minimum Policed Unit (m), Maximum Packet Size
(M)>
The token bucket is, for example, used by the Guaranteed Load or
Controlled Load service defined in [RFC2210], which is in common use.
Optional Parameters:
For some traffic types a simple token bucket is not an appropriate
descriptor and other parameters are needed, for example, for
admission control or to calculate an equivalent resource value at the
boundary of a resource domain [LEAKY-BUCKET].
a. <Token bucket + Other Source Descriptor>
For example, in order to take into account the voice activity in
resource management for real-time voice traffic (e.g. VoIP, AMR coded
voice), voice activity has to be signaled in addition to token bucket
parameters. Note that ITU [Q.2630], which is used for the UTRAN
transport network control plane, also applies such a descriptor for
the variable bit rate stringent capability class.
b. <More Complex Descriptors>
For example, multiple token buckets may be required, such as in ITU
[Q.2630], which defines a tolerant capability class described by a
two token-bucket model defining traffic behavior in two different
time scales. See also [Y.1541].
3.5.2. QoS Class
An application may like to reserve resources for packets with a
particular QoS class, e.g. the DiffServ code point (DSCP) per-hop
behavior [DIFFSERV], Y.1541 QoS class [Y.1541], or DiffServ-enabled
traffic engineering (DS-TE) class type [DS-TE].
Generic immutable QoS Class Parameters, for example, in
<Traffic Characterization>: <QoS-class> = <DSCP> | <Y.1541 QoS class>
| <DS-TE class type>
Ash et al. Expires December 2004 [Page 10]
Internet Draft QoS-NSLP QSpec Template
3.5.3. QoS Characterization
These parameters can, for example, describe the QoS characteristics
required by the initiating QNE. In this case they appear mutably in
<Resource Availability>. They may also be used by the QoS NSIS
functions to describe what guarantees they are able to offer. In this
case they appear immutably in <QoS Desired>.
Generic mutable or immutable QoS Parameters
<QoS Characterization> = <Transfer Delay>, <Delay Variation>, <Packet
Loss>, <Bit Error Rate>
3.5.4. Excess Treatment
This mutable parameter describes how the network provider will
process excess traffic, that is, out-of-profile traffic (in case of
binary conformance testing) or n-level traffic (in case of n-level
conformance testing). The process takes place after traffic
conformance testing, described previously. Excess traffic may be
dropped, shaped and/or remarked. The excess treatment parameter is
initially set by the initiating QNE, and adjusted as needed by QoS
NSIS functions:
Generic mutable Excess Treatment parameter: <Excess Treatment>
3.5.5. Priority and Reliability
[RFC 3209] specifies setup and holding priority, which are in common
use. [RFC 3181] specifies preemption and defending priority, which in
the opinion of the authors of this document map to the former set of
priorities. Reservation priority is an essential way to differentiate
flows for emergency services, ETS, E911, etc., and assign them a
higher priority than normal or best-effort priority flows (e.g.,
High, Normal, Best Effort). Restoration priority specifies the
urgency with which a service requires successful restoration under
failure conditions (e.g., High, Normal, Best Effort).
Generic immutable Priority and Reliability Parameters (immutable):
a. <Setup Priority>
b. <Holding Priority>
Ash et al. Expires December 2004 [Page 11]
Internet Draft QoS-NSLP QSpec Template
c. <Reservation Priority>
d. <Restoration Priority>.
There has been some debate whether such priority parameters should be
generic to all NSLPs, generic to QoS-NSLP, or generic to QSMs, that
is, where they should be defined. It is beyond the scope of this
document whether the priorities defined here are also useful in other
NSLPs. However, we believe in the context of QoS-NSLP that priority
is best placed in the QSM and QSpec. The reason is that the resource
management function seems to function more efficiently if priority
state is held there rather than in common QoS-NSLP processing of
messages (see Figure 1). Only the resource management function knows
that resources are not sufficient and that it may be necessary to
preempt a reservation. If preemption state was associated with QoS-
NSLP state rather than with resource management state, the resource
management function would need to negotiate with the common QoS-NSLP
processing until the two work out what reservation to preempt.
Note that although we locate priority parameters with the QSM, the
fact that we make them generic parameters could be seen as a
recommendation to implement them in all QNEs (see discussion above).
3.5.6. Monitoring Requirements
Immutable information required about an ongoing reservation.
Generic Parameters:
4. Security Considerations
A QoS-NSLP message may also carry one or more policy objects that
authenticate and authorize the sender of a QSpec. Hence the policy
object may be specific to a QSpec and be bound to it. Moreover, the
QoS-NSLP policy object would usually be bound to immutable
parameters, unless it, too, is changed along the signaling path. In a
future version of this draft, the binding of the policy object and
QSpec and the resulting authorization issues need to be investigated.
Ash et al. Expires December 2004 [Page 12]
Internet Draft QoS-NSLP QSpec Template
5. Open Issues and Outlook
a. A detailed discussion of QSM development guidelines needs to be
provided.
b. A more detailed specification of the generic parameters needs to
be given.
c. The relationship of common NSLP processing, QSM-specific NSLP
processing and resource management function, as well as how their
tasks differ needs, to be described more clearly. For example, is
the QSpec passed to the QSM-specific NSLP processing first and then
to the resource management function? How do QSM-specific NSLP
processing and the resource management function influence message
processing in common NSLP processing?
d. Should/can we request that QNEs MUST support a subset of generic
parameters?
e. Is it QSM or QoS Model?
f. Where is an unknown QSM handled? In the common NSLP processing
(e.g. by issuing an error notification) or by the QSM-specific NSLP
processing (e.g. by setting the corresponding flag in the QSM control
information)? Note that the generic parameters contained in an
unknown QSM may still be understood by the QSM-specific processing
and the Resource Mangagement Function. Hence it may make sense to
process even unknown QSMs.
g. How is resource sharing handled, respectively, in the common NSLP
processing, QSM-specific NSLP processing and resource management
function?
h. Need to streamline the <Service Schedule> QSM control information
defined here and the COMMIT flag suggested in [QOS-NSLP].
6. Acknowledgements
The authors would like to thank Robert Hancock and Sven van den Bosch
for their helpful suggestions.
Ash et al. Expires December 2004 [Page 13]
Internet Draft QoS-NSLP QSpec Template
7. References
[DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DS-TE] Le Faucheur, F., et. al., Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering,
RFC 3564, July 2003
[KEY] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[E.361] ITU-T Recommendation, "QoS Routing Support for
Interworking of QoS Service Classes Across Routing
Technologies," May 2003.
[INTSERV] Braden, B., et. al., "Integrated Services in the
Internet Architecture: an Overview," RFC 1633, June 1994.
[INTSERV-QoS-SIG] Kappler, C., "A QoS Model for Signaling IntServ
Controlled-Load Service with NSIS," work in progress.
[LEAKY-BUCKET] Butto, M., et. al., "Effectiveness of the Leaky Bucket
Policing Mechanism in ATM Networks," IEEE Journal of
Selected Areas in Communications, Vol. 9. No. 3. April
1991; Yang, X. "Designing Traffic Profiles for Bursty
Internet Traffic," IEEE Global Internet, Taipei, Taiwan,
November 2002; Sairamesh, J., Shroff, N., "Limitations
and Pitfalls of Leaky Bucket," Proceedings of IEEE ICCCN
94, San Francisco, CA, September 1994.
[NSIS-REQ] Brunner, M., et. al., "Requirements for QoS Signaling
Protocols", work in progress.
[NSIS-FRAMEWORK] Hancock, R., et. al., "Next Steps in Signaling:
Framework", work in progress.
[RMD-QoS-SIG] A. Bader, et. al., "RMD (Resource Management in Diffserv)
QoS-NSLP model", work in progress
[RSVP] Braden, B., et. al., "Resource ReSerVation Protocol
(RSVP) -- Version 1 Functional Specification," RFC 2205,
September 1997.
[RSVP-INTSERV] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001.
[TRQ-QoS-SIG] Ash, J., et. al., "NSIS Network Service Layer Protocol QoS
Signaling Proof-of-Concept," work in progress.
[QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service
Signaling," work in progress.
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance
Objectives for IP-Based Services," May 2002.
[Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling
Protocol - Capability Set 3" Sep. 2003
Ash et al. Expires December 2004 [Page 14]
Internet Draft QoS-NSLP QSpec Template
8. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Fax: +1-(732)-368-8659
Email: gash@att.com
Attila Bader
Traffic Lab
Ericsson Research
Ericsson Hungary Ltd.
Laborc u. 1 H-1037
Budapest Hungary
EMail: Attila.Bader@ericsson.com
Chuck Dvorak
AT&T
Room 2A37
180 Park Avenue, Building 2
Florham Park, NJ 07932
Phone: + 1 973-236-6700
Fax:+1 973-236-7453
E-mail: cdvorak@att.com
Yacine El Mghazli
Alcatel
Route de Nozay
91460 Marcoussis cedex
FRANCE
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
Cornelia Kappler
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Email: cornelia.kappler@siemens.com
Ash et al. Expires December 2004 [Page 15]
Internet Draft QoS-NSLP QSpec Template
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
Andrew McDonald
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
EMail: andrew.mcdonald@roke.co.uk
Al Morton
AT&T
Room D3-3C06
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-1571
Fax: +.1 732 368-1192
E-mail: acmorton@att.com
Percy Tarapore
AT&T
Room D1-3D33
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-4172
E-mail: tarapore@.att.com
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@ericsson.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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
Ash et al. Expires December 2004 [Page 16]
Internet Draft QoS-NSLP QSpec Template
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.
Ash et al. Expires December 2004 [Page 17]