Danny Goderis, Alcatel
Internet Draft Sven Van Den Bosch, Alcatel
Document: draft-tequila-sls-02.txt Yves T'joens, Alcatel
Expires: August - 2002 Olivier Poupel, Alcatel
Christian Jacquenet, France
Telecom R&D
George Memenios, NTUA
George Pavlou, UniS
Richard Egan, Thales Research Ltd
David Griffin, UCL
Panos Georgatsos, AlgoSystems
Leonidas Georgiadis, Univ.
Thessaloniki
Pim Van Heuven, IMEC
February 2002
Service Level Specification Semantics and Parameters
<draft-tequila-sls-02.txt>
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 document identifies the basic information to be handled by
Service Level Specifications (SLS, [RFC 2475], [DS-TERMS]) when
considering the deployment of value-added IP service offerings over
the Internet. IP service offerings can be provided together with a
given quality of service (QoS), whose definition can be conveyed in
an SLS, from a technical standpoint. Since these IP services are
likely to be provided over the whole Internet, their corresponding
QoS will be based upon a set of technical parameters that both
customers and network providers will have to agree upon. From this
TEQUILA Consortium Expires August - 2002 [Page 1]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
perspective, this draft aims at listing (and promoting a standard
formalism for) a set of basic parameters which will actually compose
the elementary contents of an SLS.
Such a specification effort tries to address the following concerns:
- Provide a standard set of information to be negotiated
between a customer and a network provider or between network
providers;
- Provide the corresponding semantics of such information, so
that it might be appropriately modeled and processed by the
above-mentioned parties (in an automated fashion).
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
0 Conventions used in this document..............................3
1 Introduction...................................................3
1.1 Changes w.r.t. the previous version..........................3
1.2 Motivation...................................................3
1.3 Objectives...................................................4
2 Basic assumption and terminology...............................5
3 SLS content & template.........................................5
3.1 SLS Identification...........................................5
3.2 Scope........................................................6
3.3 Flow Identification..........................................7
3.4 Traffic Envelop and Traffic Conformance......................9
3.5 Excess Treatment............................................11
3.6 Performance Guarantees......................................11
3.7 Service schedule............................................15
3.8 Reliability.................................................16
3.9 Monitoring..................................................16
3.10 Others.....................................................17
4 Service Level Specifications and Per Domain Behaviours........17
4.1 DiffServ Terminology........................................18
4.1.1 About Service Level Specifications.........................18
4.1.2 About Per Domain Behaviors.................................18
4.1.3 About SLS and PDB relationships............................18
4.2 SLS and PDB similarities and differences....................19
4.2.1 A subset of common parameters..............................19
4.2.2 External interfaces versus intra-domain QoS building blocks 19
4.3 From PHB to value-added IP services: a layered DiffServ view 20
5 Service Level Specification examples..........................21
TEQUILA Consortium Expires August - 2002 [Page 2]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
5.1 Virtual Leased Line.........................................21
5.2 Bandwidth Pipe for data-services............................22
5.3 Minimum rate guarantee with allowed excess..................22
5.4 Qualitative Olympic services................................23
5.5 The Funnel service..........................................23
5.6 Best effort traffic.........................................24
6 SLS negotiation requirements..................................24
7 Security Considerations.......................................24
8 Acknowledgment................................................25
References........................................................25
Author's Addresses................................................26
Full Copyright Statement..........................................28
0 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 Introduction
1.1 Changes w.r.t. the previous version
This is the fourth version of an Internet Draft on the issue of
Service Level Specifications (SLSs). This version contains some
editorial changes, some additions of parameters for identification
and monitoring, new service scheduling parameters and an update of
the section 4 entitled "Service Level Specifications and Per Domain
Behaviors". This section discusses the similarities and differences
between SLSs and PDBs. Also some minor editing changes and reference
updates have been incorporated in this version.
1.2 Motivation
This document is presented to the IETF community to gauge the
interest for advancing the work on the specification of an SLS
definition, its semantics and its potential negotiation protocol(s).
The deployment of QoS-based value-added IP services over the global
Internet is one of the most exciting challenges that the network
providers try to currently address, especially when considering the
deployment of such service over administrative domains. From this
standpoint, it seems useful to consider the specification of an SLS
template these network providers would agree upon, so as e.g. to
facilitate the enforcement of an inter-domain QoS policy.
TEQUILA Consortium Expires August - 2002 [Page 3]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
1.3 Objectives
This document presents an outline for the definition of the Service
Level Specification parameters and the semantics that go behind this
representation for a transport service.
The need to have such an agreed set of Service Level Specification
parameters and semantics is manifold.
First, it is necessary to be able to allow for a highly developed
level of automation and dynamic negotiation of Service Level
Specifications between customers and network providers. Automation
and dynamics are indeed helpful in providing customers (as well as
providers) the technical means for the dynamic provisioning of
quality of service configuration information.
Second, the design and the deployment of QoS-aware and capable
Network and Element Management system in a multi-vendor environment
requires a standardized set of semantics for Service Level
Specifications being negotiated at different locations, such as:
- within an administrative domain (for intra-domain SLS
negotiation purposes);
- between the customer and the network provider, where the
customer might be e.g. a company, an application service
provider (e.g. a voice over IP provider), another network
provider, etc.
- between administrative domains (for inter-domain negotiation
purposes).
While the representation and semantics behind a Service Level
Specification need to be standardized, this document does not assume
that the syntax, nor the SLS negotiation protocol need to be
uniquely defined. The SLS negotiation protocol and associated
requirements is out of scope of this document.
The document is structured as follows.
Section 2 lists the basic assumptions underlying this work and some
terminology.
Section 3 describes the parameters of the Service Level
Specification (template) for a transport service. This draft only
describes the semantics of the SLS-parameters, omitting all
implementation details as for instance the parameter data types (at
this moment).
Section 4 provides some examples of relevant SLS specifications,
with the aim to show the usage of the templates. The SLS formalism
defined in section 3 allows making a distinction between qualitative
and quantitative SLSs:
TEQUILA Consortium Expires August - 2002 [Page 4]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
- SLSs depicting qualitative services should yield the
specification of relative QoS indicators, such as a "low" IP
packet loss. From this standpoint, best effort traffic is
expected to be qualified by an SLS of that range of
qualitative services.
- SLSs depicting quantitative services should yield the
accurate measurement of QoS indicators, such as e.g., transit
delay.
Sections 5 and 6 finally describe some SLS (protocol) negotiation
requirements and security considerations respectively.
The material presented in this draft derives from work within the
IST-TEQUILA project [TEQUILA].
2 Basic assumption and terminology
The basic assumption of this draft is that IP services will be
deployed over a public IP infrastructure, which will be (partly if
not completely) composed of diffserv-aware network elements ([RFC-
2475], [DS-MODEL]). These network elements are able to implement Per
Hop Behaviors (PHBs), including the Assured Forwarding PHB ([RFC-
2597]), and the Expedited Forwarding PHB ([RFC-2598].
In this document, the owner of the transport network equipment, i.e.
the IP network, is called network provider. The network provider
offers IP transport services to its customers. The IP transport
services are technically described by SLSs. The customers of the
network provider may be corporates, application service providers
(themselves offering e.g. voice or video to residential users) or
other network providers.
The terminology used in this draft is in agreement with the DiffServ
Working Group terminology introduced in [RFC-2475], section 1.2
"terminology" and further specified in [DS-TERMS]).
3 SLS content & template
The following describes the attributes of the Service Level
Specification.
3.1 SLS Identification
The SLS Identification is a field used by the service provider and
the customer to identify the SLS and the service the SLS is related
to.
TEQUILA Consortium Expires August - 2002 [Page 5]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
SLS Identification = (SLS Id, Service Id)
- SLS Id: This is the parameter identifying the SLS
- Service Id: This the parameter identifying the service the
SLS is related to.
The SLS Identification is mainly dedicated to the classification of
multiple SLSs that can composed a service.
3.2 Scope
The scope of an SLS associated to a given service offering indicates
where the Quality of Service (QoS) policy for that specific service
offering is to be enforced. Therefore the scope uniquely identifies
the geographical/topological region over which the QoS is to be
enforced by indicating the boundaries of that region.
An SLS is associated with uni-directional traffic flows. Note
however that this does not exclude the provisioning of bidirectional
technical agreements, by combining one or more SLSs.
The associated scope of the SLS MUST be expressed by a couple of
ingress and egress interfaces. Ingress/egress denote respectively
the entry/exit points of the IP packets relative to the region
(network).
Scope = (ingress, egress) with ingress/egress defined as
- Ingress: interface identifier | set of interface identifiers
| any
- Egress : interface identifier | set of interface identifiers
| any
Remarks:
- "|" denotes an exclusive OR.
- "any" is logically equivalent with unspecified.
The following combinations of (ingress, egress) interfaces are
allowed:
- (1,1) - one-to-one communication
- (1,N) - one-to-many communication (N>1)
- (1,any) - one-to-any communication
TEQUILA Consortium Expires August - 2002 [Page 6]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
- (N,1) - many-to-one communication (N>1)
- (any,1) - any-to-one communication
The above taxonomy excludes the many-to-many communication (M,N).
Either ingress OR egress MUST be specified to exactly ONE interface
identifier (with a non-exclusive OR). Many-to-many communication
(M,N) can be decomposed into M times one-to-many communication
(1,N).
This taxonomy SHOULD avoid all ambiguity about the IP flow (defined
as a set of IP datagrams sharing at least one common characteristic,
like e.g. the same [source address; destination address] pair), and
its corresponding identification. (see section 3.2 and 3.3). If the
ingress is a single interface identifier, then the traffic envelop
and flow id concerns the incoming IP packet stream at the unique
ingress point. If (only) the egress is a single interface, i.e.
(N|any,1), then the traffic envelop and flow id concerns the
outgoing (aggregate) traffic on the egress link. More details about
the latter can be found in the example given in section 4.5.
In the remaining part of this document SLSs with an associated scope
(topology) of (1,1) ; (1,N) ; (N,1) will be called respectively
Pipe, Hose and Funnel SLSs.
Disclaimer:
An ingress (or egress) interface identifier should uniquely
determine the boundary link as defined in [RFC-2475] on which
packets arrive/depart at the border of a DS domain. This link
identifier MAY be an IP address, but it may also be any other
mutually agreed upon identifier which uniquely identifies a boundary
link. For example a layer-two identifier in case of Ethernet or
unnumbered PPP-based access links in (Point-to-Point Protocol,
[RFC-1661]).
3.3 Flow Identification
The flow identification (Flow Id) of an SLS associated to a given
service offering indicates for which IP packets the QoS policy for
that specific service offering is to be enforced.
A Flow Id identifies a stream of IP datagrams sharing at least one
common characteristic. An SLS contains one (and only one) Flow Id,
which MAY formally be specified by providing one or more of the
following attributes:
Flow Id = (Differentiated Services information, source information,
destination information, application information)
- Differentiated Services information = DSCP value | set of
DSCP values | any
TEQUILA Consortium Expires August - 2002 [Page 7]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
The Differentiated Services Code Point (DSCP) IP header field
is defined in [RFC-2474].
- Source information = source address | set of source
addresses | source prefixe | set of source prefixes | any
- Destination information = destination address | set of
destination addresses | destination prefixe | set of
destination prefixes | any
- Application information = protocol number | protocol number
and source port, destination port | any
Note: "any" is again logically equivalent with unspecified.
Thus, the Flow Id may be expressed by information attributes related
to the source/destination nodes, the application or the DS field in
the IP header. The Flow Id provides the necessary information for
classifying the packets at a DS boundary node.
This datagram classification can either reflect a Behaviour
Aggregate (BA) or Multi-Field (MF)classification.
In case of MF-classification all attributes MAY be specified,
including the DSCP field. MF classification may depict as well
micro-flows as aggregate macro-flows, based on e.g. source network
prefix [DS-MODEL]. Also the "set-of" semantics allows for the
specification of aggregate flows. If a Flow Id is e.g. specified by
a set of two IP source addresses, then any packet with either of the
two concerned source addresses in its header belongs to the IP
packet stream identified by Flow Id.
In case of BA-classification [RFC-2475], the DSCP attribute MUST be
specified and the other attributes MUST NOT be specified. If a set
of DSCP-values is specified, then any packet having a DSCP belonging
to this set is part of the Flow Id packet stream. As an example
consider an Ordered Aggregate (OA) IP packet stream of a particular
Assured Forwarding Class AFx (AF1,AF2,AF3,AF4 - see [RFC 2597]).
This stream could be specified within one Flow Id using three DSCP-
values, indicating the three drop precedences levels.
It should however be noticed that the DSCP-value(s) specified in the
SLS has (have) as such nothing to do with the DSCP-marking of
packets inside the DiffServ network. The latter, i.e. the "interior"
DSCP is used for differentiating packets according to Per Hop
Behaviours (PHBs). The former, i.e. the "ingress" DSCP value
(specified in the SLS), is just another way of identifying a packet
stream, eventually in combination with other IP header fields. At
the ingress DiffServ node (incoming) packets are classified based on
the "ingress" DSCP value (amongst others), after which they may be
re-marked by the "interior" DSCP-value.
TEQUILA Consortium Expires August - 2002 [Page 8]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
Finally note also that the IP routing scheme MAY put restrictions on
combining scope and flow identification within an SLS.
In general, if (only) Flow ID is specified by source and destination
IP address (IP-src, IP-dest), and the scope is unspecified, then
there is no a-priori assumption about the actual ingress/egress
points that this traffic will cross. Indeed, it is the
responsibility of the network provider to define the most
appropriate route for this traffic, by enforcing the corresponding
traffic engineering and routing policies. Thus, the (ingress,
egress) information (which in this case is NOT part of the SLS
template instance) is then derived from the Flow Id and the routing
policy of the network provider.
On the other hand, if both Flow Id AND scope are specfied in the
SLS, resp. by the pairs (IP-src, IP-dest) and (IP-ingr, IP-egr)
pairs then it is clear that the IP packets MUST follow the route
(IP-src,...,IP-ingr,...,IP-egr,...,IP-dest). Thus the restriction is
that the scope (IP-ingr, IP-egr) is part of the route from IP-scr to
IP-dest.
Also remark that the exclusion of the many-to-many communication
scope model puts similar constraints on the source/destination
fields of the Flow Identification.
3.4 Traffic Envelop and Traffic Conformance
The traffic envelop describes the traffic (conformance)
characteristics of the IP packet stream identified by the Flow Id.
The traffic envelop is a set of Traffic Conformance Parameters,
describing how the packet stream should look like to get the
guarantees indicated by the performance parameters (defined in
section 3.5)
The Traffic Conformance Parameters are the basic input for the
Traffic Conformance Algorithm. Traffic Conformance Testing is the
combination of the Traffic Conformance Parameters and the Traffic
Conformance Algorithm. This will usually be done at a DS-boundary
node.
The algorithm and the conformance test can be binary-based or multi-
level based.
Binary Traffic Conformance Testing is a set of actions which
uniquely identifies the "in-profile" and "out-of profile" (or
excess) packets of an IP stream (identified by Flow-Id). In this
case the Traffic Conformance Parameters describe the reference
values the traffic (identified by the Flow ID.) will have to comply
with, thus yielding the notions of "in" and "out" of profile
traffics. The Traffic Conformance Algorithm is the mechanism
enabling unambiguously to identify all "in" or "out" of profile
packets based on these Conformance parameters.
TEQUILA Consortium Expires August - 2002 [Page 9]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
In case of multi-level (n) Traffic Conformance Testing a packet will
be tagged (by the algorithm) as belonging to a particular level
(1...n). Packets tagged as level n are called "excess" packets.
The SLS MUST indicate the concerned level (n) of the conformance
testing algorithm:
- Multi-level conformance testing n (integer)
The following gives a (non-exhaustive) list of potential conformance
parameters.
- Peak rate p (bits per second)
- Token bucket rate r (bits per second)
- Bucket depth b (bytes)
- Maximum Transfer Unit (MTU) M (bytes)
- Minimum packet size (bytes)
Binary-based Traffic Conformance Testing examples:
- Conformance parameters = token bucket parameters (b,r);
conformance algorithm = token bucket algorithm.
- Conformance parameters = token bucket parameters and peak
rate (b,r,p) with p larger than r; conformance algorithm =
the combined token bucket (b,r) and (b,p). This is the
conformance test for Integrated Services Controlled Load and
Guaranteed Service IP flows in the IntSer QoS architecture
[RFC-2211, RFC-2212]. The scheme permits bursty traffic to be
sent, limited to a burst of b bytes, with a (long-term)
average rate of r and a peak rate of no more than p.
- Conformance parameters = MTU; conformance algorithm = all
packets allowed with size smaller than MTU; packets larger
than MTU are fragmented or dropped.
Three-level based Traffic Conformance Testing example
- The Two-rate Three-colour marker is based on two token
buckets with rates r1 and r2 (r2 being greater than r1),
containing respectively green and yellow tokens. The simplest
operational mode is the "colour-blank" mode. A packet is
tagged "green" if there are green and yellow tokens
available, yellow if only yellow tokens are available and
otherwise it is tagged red.
TEQUILA Consortium Expires August - 2002 [Page 10]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
3.5 Excess Treatment
This section describes how the network provider will process excess
traffic, i.e. 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 SLS MUST
specify the appropriate action by the following attribute.
- Excess Treatment
If Excess Treatment is not indicated, then excess traffic is
dropped. Depending on the appropriate action, more parameters MAY be
required The following is an indication in case of binary
conformance testing. Multi-level conformance testing (like the
definition of a hierarchical drop preference model) MAY also be
enforced, but this concern has been left for further study.
- If excess traffic is dropped, then all packets marked as
"out-of-profile" by the Traffic Conformance Algorithm are
dropped. No extra parameters are needed.
- If excess traffic is shaped, then all packets marked as "out-
of-profile" by the Traffic Conformance Algorithm are delayed
until they are "in-profile". The shaping rate is the
policing/token bucket rate r. The extra parameter is the
buffer size of the shaper.
- If excess traffic is marked or remarked, then all packets
marked as "out-of-profile" by the the Traffic Conformance
Algorithm are (re-) marked with a particular DSCP-value
(yellow or red). The extra parameter is the DSCP.
3.6 Performance Guarantees
The performance parameters describe the service guarantees the
network offers to the customer for the packet stream described by
the Flow Id and within the limits of the geographical/topological
extent given by the scope.
There are four performance parameters:
- one-way transit delay, optional quantile
- packet delay variation or jitter, optional quantile
- packet loss
- throughput
TEQUILA Consortium Expires August - 2002 [Page 11]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
Delay, jitter and packet loss guarantees are for the in-profile
traffic in case of binary conformance testing. For multi-level (n)
conformance testing, delay, jitter and loss guarantees MAY be
specified for each conformance level-i, except the last one (n). For
example if n = 3, one can have a delay guarantee for the
"conformance level-1" packets and a different delay guarantee for
the "conformance level-2" packets. No guarantees are given for
excess ("conformance level-n") traffic.
The throughput is an overall guarantee for the IP packet stream,
independent of a particular level (see below).
The following definitions always consider the (measurable)
performance parameters related to the packet stream specified by the
Flow Id. For simplicity the definitions below are given for binary
conformance testing (n=2), but generalisation is straightforward.
The delay and jitter indicate respectively the maximum packet
transfer delay and packet transfer delay variation from ingress to
egress.
Delay and jitter may either be specified as worst case
(deterministic) bounds or as quantiles. Indeed, the worst case
delay/jitter bounds will be very rare events and customers may find
measurements of e.g. 99.5th percentile a more relevant empirical
gauge of delay/jitter.
Suppose e.g. that the SLS specifies the triple (delay = 10ms,
quantile = 10E-3). Then the probability that the transfer delay of a
packet (between ingress-egress) is larger than 10ms, is less than
10E-3.
The above syntax for delay/jitter can be generalised by specifying
in the SLS an array of e.g. N (delay/jitter, quantile)-couples. The
more couples, the better the delay probability tail distribution can
be approximated. Such a specification together with the eventual
need of such a generalisation is for further study.
The packet loss probability is ratio of the lost (in-profile)
packets between ingress and egress and the offered (in-profile)
packets at ingress.
lost packets between (& including) ingress and egress
packet loss = ------------------------------------------------------
offered (injected) packets at ingress
The throughput is the rate measured at egress counting all packets
identified by Flow Id. Notice that all packets, independently of
their conformance level (in/out-of-profile) contribute. Indeed, if
the customer (only) wants a throughput guarantee, then he/she does
not care whether in- or out-profile packets are dropped, but is only
interested in the overall throughput of its packet stream.
TEQUILA Consortium Expires August - 2002 [Page 12]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
Note on the relation with the Traffic Conformance Parameters
(section 3.3) in case of a binary-based conformance testing
algorithm:
- The Traffic Conformance Algorithm (and parameters) MUST be
specified when guaranteeing delay/jitter or packet loss, i.e.
if one of these performance parameters is quantified in the
SLS. Conformance testing is required because the delay/jitter
and loss guarantees are only for the stream of in-profile
packets.
- When only guaranteeing a throughput, or if non-of the other
performance parameters is quantified, the traffic conformance
algorithm MAY be specified. It is not required to specify the
Conformance Algorithm, because the (eventual) throughput
guarantee does not require the strict distinction between
in/out-of-profile traffic. However, the network operator will
probably protect his network by implementing a Traffic
Conditioner at Ingress and specifying the token policing rate
(r) (almost) equal to the throughput guarantee R, r~R. He
may or may not tag/mark excess traffic, according to his own
- internal - policy rules. See also example 4.2.
Note on the relation between throughput R, packet loss p and excess
treatment in case of a binary-based conformance testing algorithm:
- First consider the case where excess traffic is dropped (or
shaped to in-profile) based on the token bucket (b,r) traffic
conformance algorithm. As only in-profile packets are allowed
at ingress, the following equality holds:
throughput R = (1-p) * token rate r
Thus the throughput guarantee can be derived from the loss
probability and token rate and is therefore not an independent
parameter.
- If excess traffic is allowed (and marked accordingly), then
"throughput" is an independent parameter because it also
takes into account the out-of-profile packets (measured at
egress). One has obviously the inequality:
throughput R >= (1-p) * token rate r
Quantitative performance guarantees
A performance parameter is said to be quantified if its value is
specified to a numeric (quantitative) value.
The service guarantee offered by the SLS is said to be quantitative
IF at least one of the 4 performance parameters is quantified.
TEQUILA Consortium Expires August - 2002 [Page 13]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
Qualitative performance guarantees
If non of the SLS performance parameters are quantified, then the
performance parameters "delay" and "packet loss" MAY be "qualified".
Possible qualitative values (for delay and/or loss): high, medium,
low.
Relative delay guarantees:
- gold service : value = low
- silver service : value = medium
- bronze service : value = high or not indicated
Relative loss guarantees
- green service : value = low
- yellow service : value = medium
- red service : value = high or not indicated
The quantification of relative difference between <high/medium/low>
is a matter of provider's policy (e.g. high = 2 x medium ; medium =
2 x low).
The above taxonomy yields the following combinations of qualitative
services (Table 1).
|------------------------------------------------------|
|\ delay | | | |
| \------| low | medium | high |
| loss | | | |
|------------------------------------------------------|
| low | gold green | silver green | bronze green |
| medium | gold yellow | silver yellow | bronze yellow |
| high | gold red | silver red | bronze red |
|------------------------------------------------------|
Table 1: Combinations table
The service guarantee offered by the SLS is said to be qualitative
if it is NOT quantitative and either delay or loss (non-exclusive)
are qualified to "medium" or "low", i.e. excluding bronze/red from
the above.
The service guarantee offered by the SLS is said to be best-effort
if it is NOT quantified nor qualified.
TEQUILA Consortium Expires August - 2002 [Page 14]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
3.7 Service schedule
The service schedule indicates the start and the end of the service,
i.e. when the service is available.
The Service schedule MAY be specified with the following parameters:
Service schedule = (Start date, End date, MonthMask, DayMask,
TimeMask)
- Start date: Date and hour from which the service becomes
available.
- End date: Date and hour from which the service becomes
unavailable.
Start date and End date MUST be specified and End date MUST be
greater than End date.
Remark: service schedule "from now on" [now, infinity] can be
captured by putting the above to their full range.
- MonthMask: Month of the year range | set of Month of the year
range
- DayMask: Day of the month range | set of Day of the month
range
- TimeMask: Time of the day range | set of Time of the day
range
An SLS is active between the Start date and the End date. MonthMask,
DayMask and TimeMask MAY be specified to refine the periods of
activation of the SLS.
MonthMask, DayMask and TimeMask respectively identify the months of
the year, the days of the month and the time of the day in which the
SLS is valid.
For example, to define an SLS from the 01/01/02 at 0:00AM to
12/31/05 at 11:59PM, in January, March, and from June to November,
only the second half of these months, from 2:00AM to 7:00AM and from
8:00PM to 11:00PM, the Service schedule is specified as follow:
- Start date: (01012002, 00:00:00AM)
- End Date: (12312005, 11:59:59PM)
- MonthMask: (01, 03, [06 11])
- DayMask: ([15 31]
TEQUILA Consortium Expires August - 2002 [Page 15]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
- TimeMask: ([02:00:00AM 07:00:00AM], [08:00:00PM 11:00:00PM])
3.8 Reliability
Reliability indicates the maximum allowed mean downtime per year
(MDT) and the maximum allowed time to repair (TTR) in case of
service breakdown (e.g. in case of cable cut).
The Mean Down Time might be expressed in minutes per year and the
Maximum Time To Repair might be expressed in seconds.
3.9 Monitoring
The monitoring indicates the QoS parameters that have to be
monitored and reported. They will be applied on the set of
interfaces defined in the Scope block of the SLS Template.
The monitoring part is composed of the following parameters:
- Delay Measurement Period: Describes the period for measuring
the delay.
- Delay Reporting: Indicates when the delay measurement reports
have to be sent to the customer.
- Delay Notification Threshold: Indicates a delay threshold
that triggers a notification to the customer if the threshold
is reached.
- Jitter Measurement Period: Describes the period for measuring
the jitter.
- Jitter Reporting: Indicates when the jitter measurement
reports have to be sent to the customer.
- Jitter Notification Threshold: Indicates a jitter threshold
that triggers a notification to the customer if the threshold
is reached.
- Packet Loss Measurement Period: Describes the period for
measuring the packet loss.
- Packet Loss Reporting: Indicates when the packet loss
measurement reports have to be sent to the customer.
- Packet Loss Notification Threshold: Indicates a packet loss
threshold that triggers a notification to the customer if the
threshold is reached.
TEQUILA Consortium Expires August - 2002 [Page 16]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
- Throughput Measurement Period: Describes the period for
measuring the throughput.
- Throughput Reporting: Indicates when the packet loss
measurement reports have to be sent to the customer.
- Throughput Notification Threshold: Indicates a throughput
threshold that triggers a notification to the customer if the
threshold is reached.
- Maximum outage time: Indicates the duration of outage that is
allowed for any interfaces described in the Scope. If the
value overtakes the threshold, the provider sends a
notification describing this event to the customer.
- Maximum bandwidth: Indicates the maximum bandwidth that can
be used on any interface described in the Scope. If the value
overtakes the threshold, the provider sends a notification
describing this event to the customer. Maximum Bandwidth
utilization reflects the maximum bandwidth usage that is set
on each interfaces. It indicates a percentage of the capacity
bandwidth of the interface (if speed SNMP variable).
- Total number of outage: Indicates for each interface
described in the Scope the maximum number of outage
authorized. If the value overtakes the threshold, the
provider sends a notification describing this event to the
customer
- Reporting Document Type: Describes which kind of documents
have to be sent to the customer (word, excel, HTML, etc.).
- Reporting Destination Address: Indicates where the provider
has to send the reports (email, postal, fax, etc.).
3.10 Others
Other parameters such as route, security, scheduled maintenance,
etc... remain for further study.
4 Service Level Specifications and Per Domain Behaviours
Recently the IETF DiffServ working group has documented in an
informational RFC [RFC 3086] the concept of DiffServ Per Domain
Behaviours (PDBs). Although this [RFC 3086] clearly specifies the
difference between PDBs and SLSs, it is worthwile to further
elaborate communalities and differences between PDBs and SLSs.
We first recall the DiffServ working group terminology.
TEQUILA Consortium Expires August - 2002 [Page 17]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
4.1 DiffServ Terminology
4.1.1 About Service Level Specifications
According to the IETF DiffServ working group, a Service Level
Agreement (SLA) is "the documented result of a negotiation between a
customer and a provider of an IP service that specifies the levels
of availability, serviceability, performance, operation or other
attributes of the transport service" [DS-TERMS].
The SLA contains technical and non-technical terms and conditions.
The technical specification of the IP connectivity service is given
in Service Level Specifications (SLSs). An SLS "is a set of
technical parameters and their values, which together define the
service, offered to a traffic stream by a DiffServ domain". SLSs
describe the traffic characteristics of IP flows and the QoS
guarantees offered by the network to these flows.
4.1.2 About Per Domain Behaviors
In [RFC 3086] a "Per Domain Behavior is the expected treatment that
an identifiable or target group of packets will receive from "edge-
to-edge" of a DS domain. A particular PHB (or, if applicable, list
of PHBs) and traffic conditioning requirements are associated with
each PDB".
"A PDB is characterized by specific metrics that quantify the
treatment a set of packets with a particular DSCP (or set of DSCPs)
will receive as it crosses a DS domain"
4.1.3 About SLS and PDB relationships
[RFC 3086] clearly states that "there is a clear distinction between
the definition of a Per-Domain Behavior in a DS domain and a service
that might be specified in a Service Level Agreement. The PDB
definition is a technical building block...in configuring DS
domains, but the PDB (or PDBs) used by a provider is not expected to
be visible to customers any more than the specific PHBs employed in
the provider's network would be."
However, "the measurable parameters of a PDB should be suitable for
use in Service Level Specifications at the network edge."
Vice versa, SLSs are "expected to include specific values or bounds
for PDB parametersd."
Therefore SLSs and PDBs are different concepts but there is clearly
a relationship between both. We now further elaborate on this
relationship.
TEQUILA Consortium Expires August - 2002 [Page 18]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
4.2 SLS and PDB similarities and differences.
4.2.1 A subset of common parameters
Both an SLS and a PDB try to capture the technical "terms and
conditions" for describing the behavior of an (aggregate) packet
stream crossing a (DiffServ) domain. Roughly speaking, if the
incoming packet stream behaves appropriately, then the network will
treat the packet stream as can be expected (from the SLS or the
PDB).
Within the context of this draft, the incoming packet stream is
identified by a "Flow Identifier", which may be mapped accordingly
on PDB classifiers and packet filters. "Behaving appropriately"
means that the packet stream should be conformant with the Traffic
Envelop (section 3.3). As in a PDB, excess packets are subject to a
Traffic Conditioner which may mark, drop or shape these packets.
The resulting packet stream, called the foo traffic aggregate in
[RFC 3086] is conditioned such that it may expect reasonable
treatment in the DS domain. In the context of this draft, the foo
traffic aggregate is the "in-profile" stream and should get the QoS
performance guarantees as defined in section 3.5.
Clearly [RFC 3086] states correctly that (some) paparameters of SLSs
should be mapped on PDB characteristics and that (some) PDB
parameters should be suitable for SLSs. Obviously the definition of
specific PDBs and those of SLS template(s) should be correlated.
4.2.2 External interfaces versus intra-domain QoS building blocks
Although SLSs and PDBs may have a common parameter subset, the
concepts themselves are substantially different.
In summary, an SLS and PDB differ along the following lines:
- An SLS is an external interface between two legal entities,
i.e. a customer and a provider. A PDB is a technical intra-
domain QoS building block.
- An SLS should be (QoS) technology independent while a PDB is
clearly a DiffServ concept. For example, as mentioned in [RFC
3086], it should be possible to offer "premium IP services"
over a Best-Effort network by over-provisioning the network
resources. Thus delay-sensitive services must not necessarily
be mapped on a PDB like a "Virtual Wire", but as in the
example above, the service may simply use a best-effort
"PDB". There is no one to one mapping; the mapping will be
determined by the provider policy. (Analogously the mapping
of PDB to PHB is not one-to-one neither).
- An SLS is itself a (service) building bilding block for
constructing (complex) IP transport services. For example, a
TEQUILA Consortium Expires August - 2002 [Page 19]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
bi-directional Virtual Leased Line has two SLSs. Multi-edge
VPNs may be very complex and require multiple SLSs. In
general, an {SLS}-set is needed for describing the technical
(QoS & traffic-related) characteristics of an IP transport
service.
- Finally, an SLS and a PDB also have some distinct parameters.
For example, the scope and the service schedule of an SLS
specify respectively where (the geographical region) and when
this typical service is applicable. It is unlikely that a
PDB, as a generic service independent building block, will
specify such parameters.
4.3 From PHB to value-added IP services: a layered DiffServ view
We end this PDB-SLS discussion by a high-level view on a possible
layered ("object") model for describing and enabling value-added IP
services over DiffServ networks.
|--------------------------------------------|
| IP Transport Services - SLA |
| - non-technical terms & conditions |
| - technical parameters {SLS}-set |
|--------------------------------------------|
| Service Level Specifications - SLS |
| - IP service traffic characteristics |
| - offered network QoS guarantees |
|--------------------------------------------|
| Per Domain Behaviors - PDB |
| - network QoS capabilities |
| - DiffServ edge-to-edge aggregates |
|--------------------------------------------|
| Per Hop Behaviors - PHB |
| Traffic Conditioning Block - TCB |
| - generic router QoS capabilities |
| - DiffServ edge & core routers |
|--------------------------------------------|
| Schedulers (e.g. WFQ, WTP) |
| Algorithmic Droppers (e.g. RED) |
| Markers (e.g. SRTCM, TRTCM) |
| - implementation |
| - vendor & product specific |
|--------------------------------------------|
Figure 1: A layered service-object model for DiffServ
Each of the underlying "layers" or "objects" exposes its (QoS)
capabilities to the upper layer. Conversely, an upper-layer object
makes use of the lower-layer capabilities and therefore should be
mapped onto the lower layer objects.
TEQUILA Consortium Expires August - 2002 [Page 20]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
According to [RFC 3086] the specification of a PDB type should
e.g.include the (lower-layer) PHB or PHB-group on which the PDB is
build.
On the othe hand, the mapping of SLSs to PDBs (and therefore PHBs)
is a rather unexplored area. For example, it is clear that an SLS is
service and customer specific; and is part of the service management
system of the provider. A PDB is customer agnostic and could be a
prefered object for (longer-term) traffic engineering and resource
management.
Clearly the mapping from SLS to PDB involves an aggregation policy
of the provider, i.e. mapping of customer aware objects to non-
custome aware entities. This is a non-straightforward problem. It
may be very much determined by the provider policy, but some general
"service mapping" and "customer aggregation" guidelines should be
very useful.
This is for further study.
5 Service Level Specification examples.
Within this section several instantiations of SLSs are presented to
illustrate the potential use of the SLS template defined above.
5.1 Virtual Leased Line
The following specifies the SLS for a (uni-directional) VLL with
quantified throughput guarantee of 1 Mbps, a delay guarantee of 20
ms for a 10E-3 quantile and zero packet loss.
- Scope: one-to-one communication (Ingress, Egress) specified
- Flow identification: (source,destination) IP-addresses,
DSCP=EF.
- Traffic Conditioning: token bucket (b,r), r = 1 Mbps
- Excess Treatment = dropping. Thus only in-profile packets are
allowed.
- Delay guarantee = (d = 20 ms, t = 5 minutes, q = 10E-3)
- Loss guarantee p = 0 (imlying a throughput guarantee R = r)
- Service Schedule: may be indicated
- Reliability: may be indicated
TEQUILA Consortium Expires August - 2002 [Page 21]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
Notice that in this example, the throughput guarantee is a derived
parameter from the packet loss p=0, the the conditioning token
bucket parameter r=1 Mbps and the excess treatment=dropping.
5.2 Bandwidth Pipe for data-services
The following SLS specifies a bandwidth pipe with a strict
throughput guarantee, but with only a loose requirements for packet
loss, i.e. "low". Thus, the SLS only mentions the scope (pipe), the
Flow Id and a throughput guarantee. Remark that there are now
traffic conformance parameters (and consequently no excess treatment
indication).
- Scope: one-to-one communication (Ingress, Egress) specified
- Flow identification: (source,destination) IP-addresses
- Throughput guarantee R = 1 Mbps
- Service Schedule: may be indicated
- Reliability: may be indicated
Although there is no (explicit) traffic conditioning agreement
between the customer and the network operator (i.e. such parameters
are not mentioned in the SLS), the operator is likely to protect his
network by implementing a traffic conditioner token bucket (b,r). If
the operator can guarantee a zero packet loss for the bandwidth
pipe, then the token rate equals the throughput guarantee. However,
the SLS can also be met by the operator without such a stringent
loss requirement, say p = 10E-5. In this case the token rate is
derived from the throughput guarantee and the loss probability:
token rate r = R / (1-p)
The in-profile packet stream (according to the conditioner (b,r))
has a throughput guarantee of R = r * (1-p) = 1 Mbps.
Further, it is up to the operator's policy whether or not excess
traffic (again according to the operator's conditioner (b,r), which
is not mentioned in the SLS agreement) is allowed or not in his
network.
5.3 Minimum rate guarantee with allowed excess
The following SLS could be applied for bulk FTP traffic that
requires a minimum throughput, but would take everything it can get
(TCP). Also adaptive applications, like video streaming, that
however require a minimum throughput for the service.
- Scope: one-to-one (Pipe)
TEQUILA Consortium Expires August - 2002 [Page 22]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
- Flow identification: e.g. DSCP-value indicating a possible
AF-PBH.
- Traffic Conformance Parameters: (b,r) MUST be indicated
- Excess Treatment: Remarking MUST be indicated (excess is
given a higher drop precedence)
- Performance guarantees: guaranteed throughput R = r.
5.4 Qualitative Olympic services
The following SLS is meant for the Olympic Service. It could be used
for differentiating applications such as web-browsing and e-mail
traffic.
SLS 1 (on-line web-browsing)
- Scope: one-to-one (pipe) or one-to-many (hose)
- Flow identification: MAY be indicated
- Traffic Conformance Parameters: token parameters (b,r) The
token bucket rate r indicates an (average) maximum Committed
Information Rate (CIR) for which "better-than-best-effort"
treatment will be applied.
- Excess Treatment: remarking.
- Performance Parameter: Delay and Packet loss are indicated as
"low": gold/green class
SLS2 : (background e-mail traffic)
This is identical to SLS1 but targeting the silver/green class.
5.5 The Funnel service
The service offered by the funnel model is primarily a protection
service: the customer wants to set a maximum on the amount of
traffic (characterized by a DSCP) entering his network. It could
e.g. be used for business customers to restrict the amount of web
browsing traffic entering their network.
/---------------\
|Network _____|______ B
| _____/ |
A__________|___.___________|______ C
/_____ | _____ |
\a(out) | \_____|_______D
\---------------/
TEQUILA Consortium Expires August - 2002 [Page 23]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
Figure 2: Funnel model
In [Figure 2], the customer A requires that the traffic entering his
network from B,C and D does not exceed the rate a_out.
- Scope: Funnel (N|all,1).
- Flow identification: DSCP MUST be indicated. The filter (see
below) is applied to all traffic characterized by the DSCP -
value.
- Traffic Conformance Parameters: (b, r) MUST be indicated. The
token bucket parameters indicate the maximum allowed
throughput (r = a_out) towards the customer network on the
specified egress interface. This maximum or filter is applied
to all packets marked with the DSCP-value indicated above.
- Excess treatment: dropping (this is actually the service
offered by the network).
- Performance Parameter: not specified.
5.6 Best effort traffic
- Scope : all models
- Flow identification : none
- Traffic Conformance Parameters: if not indicated, then the
full link capacity is allowed
- Excess Treatment: not specified
- Performance Parameters: none
- Service Schedule: may be indicated.
- Reliability: may be indicated.
6 SLS negotiation requirements
The SLS negotiation protocol is for further study.
7 Security Considerations
The information which will yield the instantiation of an SLS
template to address the specific requirements of a customer in terms
TEQUILA Consortium Expires August - 2002 [Page 24]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
of the quality associated to the service it has subscribed to may
require the activation of security features so that:
- Identification and authentication of the requesting entity
needs to be performed;
- Identification and authentication of the peering entities
which will participate in the SLS negotiation process needs
to be performed;
- Preservation of the confidentiality of the information to be
conveyed during the SLS negotiation and instantiation
procedures between the peering entities is a MUST.
8 Acknowledgment
Part of this work has been funded under the European Commission 5th
framework IST program.
The authors would like to acknowledge all their colleagues in the
TEQUILA project for their input and reflection on this work.
The authors also would like to acknowledge Werner Almesberger,
Marcus Brunner, Stefaan De Cnodder, Stefano Salsano, Alberto
Kamienski and Abdul Malick for their useful comments and suggestions
on the mailing list sls@ist-tequila.org and during private
conversation.
References
[TEQUILA] IST-Tequila project http://www.ist-tequila.org/
[RFC 1661] "The Point-to-Point Protocol (PPP)", W. Simpson,
http://www.ietf.org/rfc/rfc1661.txt?number=1661
[RFC 2205] "Resource ReSerVation Protocol (RSVP)- Version 1
Functional Specification", R. Braden et al.
http://www.ietf.org/rfc/rfc2205.txt?number=2205
[RFC-2211] "Specification of the Controlled-Load Network Element
Service", J. Wroclawski, RFC 2211, September 1997.
[RFC-2212] "Specification of Guaranteed Quality of Service", S.
Shenker, C. Partridge, R. Guerin, RFC 2212, September
1997.
[RFC 2474] "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", K.Nichols, S.
Blake, F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt
TEQUILA Consortium Expires August - 2002 [Page 25]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
[RFC 2475] "An Architecture for Differentiated Services", S. Blake,
D. Black, M.Carlson,E.Davies,Z.Wang,W.Weiss,
www.ietf.org/rfc/rfc2475.txt
[RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen,
W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt
[RFC 2598] "An Expedited Forwarding PHB", V.Jacobson, K.Nichols,
K.Poduri, www.ietf.org/rfc/rfc2598.txt
[RFC 2638] "A Two-bit Differentiated Services Architecture for the
Internet", K. Nichols, V. Jacobson, L. Zhang, July 1999.
www.ietf.org/rfc/rfc2638.txt
[RFC 2698] "A Two Rate Three Color Marker." J. Heinanen, R. Guerin.
September 1999. www.ietf.org/rfc/rfc2698.txt
[RFC 3086] "Definition of Differentiated Services Per Domain
Behaviors and Rules for their specification". K.
Nichols, B. Carpenter April 2001
http://www.ietf.org/rfc/rfc3086.txt
[DS-MODEL] "A Conceptual Model for Diffserv Routers", Y. Bernet et
al., draft-ietf-diffserv-model-06.txt, Work in Progress,
February 2001
[DS-TERMS] "New Terminology and Clarifications for Diffserv", D.
Grossman, draft-ietf-diffserv-new-terms-08.txt, work in
progress, January 2002
Author's Addresses
Danny Goderis
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-7853
Fax : 32-3-240-9932
E-mail: Danny.Goderis@Alcatel.be
Yves T'Joens
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-7890
Fax : 32-3-240-9932
E-mail: Yves.TJoens@Alcatel.be
Sven Van den Bosch
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
Phone : 32-3-240-8103
Fax : 32-3-240-9932
TEQUILA Consortium Expires August - 2002 [Page 26]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
E-mail: sven.van_den_bosch@alcatel.be
Olivier Poupel
Alcatel Research & Innovation
Route de Nozay, F-91461 Marcoussis, France
Phone : 33-1-69-63-47-07
Fax : 33-1-69-63-44-50
E-mail: Olivier.Poupel@alcatel.fr
Christian Jacquenet
France Telecom Research and Development
FT R&D /DMI
42, rue des Coutures
BP6243
14066 CAEN CEDEX 04
France
Phone : +33 2 31 75 94 28
Fax : +33 2 31 73 56 26
E-mail: christian.jacquenet@francetelecom.fr
George Memenios
Research Associate, Telecommunications Laboratory NTUA
Heroon Polytechniou 9
157 73 Zografou, Athens, Greece
Phone : +30 1 772 1494
Fax : +30 1 772 2534
E-mail: gmemen@telecom.ntua.gr
George Pavlou
Centre for Communication Systems Research (CCSR)
Univ. of Surrey, Guildford, Surrey GU2 7XH, UK
Phone : +44 (0)1483 259480
Fax : +44 (0)1483 876011
E-mail: G.Pavlou@eim.surrey.ac.uk
Richard Egan
Thales Research Ltd
Worton Drive
Worton Grange Industrial Estate
Reading, Berkshire RG2 OSB
Phone : +44 118 986 8601
Fax : +44 118 923 8399
E-mail : richard.egan@uk.thalesgroup.com
David Griffin
Department of Electronic and Electrical Engineering
University College London
Torrington Place, London WC1E 7JE, UK
Phone : +44 (0)20 7679 3557
Fax : +44 (0)20 7388 9325
E-mail: D.Griffin@ee.ucl.ac.uk
Panos Georgatsos
TEQUILA Consortium Expires August - 2002 [Page 27]
Internet Draft Service Level Specification February 2002
Semantics and Parameters
Algosystems S.A.
4, Sardeon str., 172 34 Athens, Greece
Phone : 30-1-93-10-281
Fax : 30-1-93-52-873
E-mail: pgeorgat@algo.com.gr
Leonidas Georgiadis
Aristotel Univ. of Thessaloniki, Faculty of Engineering
School of Electrical and Computer Engineering, Telecommunications
Dept.
PO Box 435, Thessaloniki, 54006, Greece
Phone : 30-31-996385
Fax : 30-31-996312
E-mail: leonid@eng.auth.gr
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or 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.
TEQUILA Consortium Expires August - 2002 [Page 28]