Stefano Salsano, CoRiTeL
Fabio Ricciato, CoRiTeL
Martin Winter, Siemens AG
Gerald Eichler, T-Nova
Anne Thomas, Dresden Univ. of Techn.
Falk Fuenfstueck Dresden Univ. of Techn.
Thomas Ziegler, Salzburg Research
Christof Brandauer, Salzburg Research
Internet Draft: draft-salsano-aquila-sls-00.txt
November, 2000
Expiration: May, 2001
Definition and usage of SLSs in the AQUILA consortium
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 (2000). All Rights Reserved.
Abstract
This document describes the usage of Service Level Specifications in
framework of the IST-AQUILA consortium. It represents a positive
feedback to the draft "Service Level Specification Semantics and
Parameters" [TEQUILA-SLS].
The AQUILA consortium agrees on the need to have a standard formalized
representation of SLS between the customer and the network. This
representation should be very general and capable to express all the
AQUILA consortium Expires May 2001 1
Definition and usage of SLSs in the AQUILA consortium Nov-00
possible service offerings based on the Diffserv model. The AQUILA
consortium also identified the need for a mechanism to simplify the
generic description of the SLS. This led to the definition of
"predefined SLS types".
The described SLS approach is under realization in a demonstrator
("AQUILA first trial"), which can provide valuable feedback.
Table of Contents
Abstract........................................................1
Glossary........................................................2
1. Introduction ................................................16
2. Rationale for having predefined SLS types ...................16
3. Semantic content of SLSs ....................................16
4. Predefined SLS types ........................................16
5. References ..................................................16
6. Author Information and Acknowledgements .....................16
Glossary
a2p any-to-point
ACA Admission Control Agent
AQUILA Adaptive Resource Control for QoS Using an IP-based Layered
Architecture
BSP Bucket Size for PR (bytes)
BSS Bucket Size for SR (bytes).
DSCP Differentiated Services Codepoint
EAR Expected Average Rate
EAT End-user Application Toolkit
M Maximum Allowed Packet Size
m Minimum Policed Unit
p2a point-to-any
p2m point-to-many
p2p point-to-point
PCBR Premium Constant Bit Rate
PMM Premium MultiMedia
PMC Premium Mission Critical)
PR Peak Rate (bit/s).
PVBR Premium Variable Bit Rate
RCA Resource Control Agent
SLS Service Level Specification
SR Sustainable Rate (bit/s)
AQUILA consortium Expires May 2001 2
Definition and usage of SLSs in the AQUILA consortium Nov-00
1. Introduction
The AQUILA [AQUILA] consortium aims at defining and implementing a
layered architecture [D1201] for the support of QoS in IP networks. In
the AQUILA architecture (see Figure 1) a reservation request is sent by
the so called "End-user Application Toolkit" (EAT) to the "Admission
Control Agent" (ACA). The reservation request specifies the required
resources and QoS level and provides the information needed to identify
the flow(s) to which the reservation applies. Resources are managed by
the "Resource Control Agent" (RCA).
In the AQUILA approach, the semantic content of the reservation request
is identified in chapter 2 of [D1301], and then it is used to define the
actual communication protocol, which is based on CORBA. One goal of this
document is to compare the approach followed by AQUILA with [TEQUILA-
SLS]. Therefore the notation used in this document is harmonized as much
as possible with notation in [TEQUILA-SLS].
The AQUILA consortium is in the process of implementing its proposed
architecture in a demonstrator. This can give an interesting feedback on
the SLS concepts that are discussed here. This document includes
comments on what features are implemented in the demonstrator, which
will be referred to as "AQUILA first trial".
There is a set of commonalties between the AQUILA and TEQUILA
approaches. The main difference is that the AQUILA consortium has
introduced the concept of predefined SLS types that are based on the
generic SLS definition. These predefined SLS types can be used to
simplify the interaction between the customer and the network. From the
point of view of the applications, a predefined SLS type supports a
range of applications that have similar communication behavior and
therefore similar QoS requirements, such as for delay, packet loss, etc.
From operator's point of view it simplifies the network management and
allows efficient flow aggregation.
Section 2 describes the rationale for having predefined SLS types,
section 3 specifies the semantic content of the generic AQUILA SLS,
section 4 provides examples of predefined SLS types, showing the SLS
types that will be provided in the AQUILA first trial.
AQUILA consortium Expires May 2001 3
Definition and usage of SLSs in the AQUILA consortium Nov-00
+-------+ +-------+
| |---------| EAT | +-------+
| | +-------+ -----| RCA |
| | | / +-------+
| | +-------+ /
| Host | | ACA |/
| | +-------+ Resource Control layer
| | - - - | - - - - - - - - - - - - - - -
| | | Transport layer
| | +-------+ +-------+
| |---------| Edge |---------| Core |--
| | |Router | |Router |
+-------+ +-------+ +-------+
Figure 1: Simplified view of AQUILA architecture
2. Rationale for having predefined SLS types
The Service Level Specification is the technical way to express what the
operator of a Diffserv network can provide to a customer. Defining a
generic SLS means trying to capture all the possible service offerings
that can be provided over a Diffserv network. A quite complex set of
parameters will be contained in the generic SLS.
An instance of the generic SLS, containing concrete values for the
parameters represents an "external" service that is provided to a
customer by the Diffserv network operator.
The Diffserv network operator will use the SLS parameters to map the
user requirements into internal mechanisms (e.g. Diffserv QoS classes).
The mapping process between the generic SLS and the concrete QoS
mechanisms can be very complex if the user can freely select and combine
the parameters. Inefficiencies can also be added. Incidentally, it is
commonly believed that only a few QoS classes will be handled in core
Diffserv networks.
To solve these problems a drastic approach is indeed to standardize the
external services offered to the customer, possibly having a one-to-one
mapping with the internal mechanisms in the Diffserv network. The idea
of having "Globally Well known Services" is for example used in [QB-BB].
The approach proposed in this draft is more generic. The idea is to have
a powerful generic SLS description template and to define external
services as "predefined SLS type", in terms of the generic SLS template.
A "predefined SLS type" fixes values (or range of values) for a subset
of the parameters in the generic SLS. It may also fix some relationships
or dependencies between some parameters. If this mechanism is used, the
SLS that is invoked by the customer will carry an indication of the
"predefined SLS type" and it will contain the actual values for the
parameters that are not fixed.
It is important to note that the proposed mechanism is not mandatory,
but it only adds a capability to the SLS negotiation mechanism. It is
AQUILA consortium Expires May 2001 4
Definition and usage of SLSs in the AQUILA consortium Nov-00
always possible to have unrestricted (or "custom") SLSs between the
customer and the network. It is up to the network operator to choose the
preferred way of offering services to the customer: by means of the
generic SLS template, by using predefined SLS types, or both.
As a predefined SLS type is always defined in terms of the generic SLS
description template, it represents a "compression" of the latter to
optionally ease the mapping process inside the network and the
negotiation between the customer and the network.
Another technical reason to have predefined SLS can be found looking at
the requirements of IP applications. For example three important groups
of Internet applications that could benefit from Quality of Service are:
- Interactive multimedia applications where multimedia data are
exchanged and showed immediately (e.g. Multimedia Conferences, Voice
over IP).
- Streaming multimedia applications where multimedia data are
downloaded by the client and buffered (e.g. Audio/Video on Demand,
Internet TV).
- Mission critical applications where discrete, real-time data are
reliably exchanged (e.g. Business to Business, Online Banking, Online
Games).
Applications corresponding to one of these groups have relatively
similar QoS behavior and requirements: interactive multimedia
applications mainly depend on throughput (bandwidth), delay, and jitter;
streaming multimedia applications mainly depend on throughput; mission
critical applications mainly depend on delay and packet loss whereas
their bandwidth need is relatively low.
This repartition of widely spread applications into similar QoS behavior
and requirement groups is the basic rationale behind providing
predefined SLS types. The aim of the design/creation/ realization of a
predefined SLS type consists in adjusting its features in order to
support one group of applications having similar QoS behavior and
requirements.
3. Semantic content of SLSs
The semantic content of the AQUILA SLS is composed of the following
attributes:
- SLS type
- Scope
- Flow identification
- Traffic description and conformance testing
- Performance guarantees
- Service schedule
3.1 SLS type
The SLS type distinguishes between a CUSTOM SLS and a PREDEFINED SLS
type. Within an instance of a CUSTOM SLS all the parameters can be
AQUILA consortium Expires May 2001 5
Definition and usage of SLSs in the AQUILA consortium Nov-00
freely specified and combined. When a PREDEFINED SLS type is used, only
a subset of the parameters must be specified in the SLS instance and
some restrictions apply on the range of parameter values and on the
allowed combination of parameters.
The list of predefined SLS types defined in the AQUILA project is:
PCBR - Premium CBR;
PVBR - Premium VBR;
PMM - Premium MultiMedia;
PMC - Premium Mission Critical.
A more detailed definition of these SLS types is given in section 4.
Note: the CUSTOM SLS is not implemented in the AQUILA first trial.
3.2 Scope
The Scope attribute indicates the typology of the ongoing reservation
with reference to the end-points of the traffic flow. The following
Scopes are defined:
p2p - point-to-point;
p2a - point-to-any;
p2m - point-to-many;
a2p - any-to-point;
m2p _ many-to-point.
Point to point scope means that the ingress and egress interfaces of the
traffic flow are specified; p2a means that an ingress interface is
specified, while the flow can exit the network from any egress
interface; p2m means that there is a given ingress interface and a set
of possible egress interfaces for the flow (note that only unicast flows
are considered, so p2m does not mean multicast); a2p means that the
egress point is given and the traffic can enter from any ingress
interface; m2p means that there is a given egress interface and a set of
possible ingress interfaces.
Note: only p2p and p2a scopes are implemented in the AQUILA first trial.
3.3 Flow identification
Flow identification focuses on the association between packets and SLSs.
The term flow refers to a stream of IP packets that are somehow related.
3.3.1 Discussion on flow identification
The IP header and higher level 4 headers include fields that can be
analyzed for appropriate QoS handling decisions, e.g. SLS association.
There are four basic types of flow identification that can be combined:
Address based, Protocol based, Port Number based, DSCP based flow
identification.
Address based flow identification:
AQUILA consortium Expires May 2001 6
Definition and usage of SLSs in the AQUILA consortium Nov-00
Address based flow identification allows to identify packets from a
certain source and/or to a certain destination using the address fields
in the IP header. Care must be taken when address translation is
performed. Beside single addresses also addresses of a sub-network will
be supported.
Protocol based flow identification:
The Layer 4 protocol is indicated within the IP header protocol field.
Flows can be classified on the basis or their Layer 4 protocol.
Port Number based flow identification:
The TCP and UDP header contain source and destination port numbers which
typically specify the required service. Instead of single port numbers
port number ranges are sometimes required.
DS-Byte based flow identification:
The Diffserv Code Point (DSCP) is contained in the DS-Byte of the IP
header (the former "Type of Service" Byte). In case of DSCP based
identification, the Diffserv node uses the DSCP of incoming packets for
classification. This means that the packets have been appropriately
marked in the upstream nodes (for example using "host marking" if the
upstream node is an end-user).
3.3.2 Specification of flow identification
A flow is identified by matching the fields in the packet headers with
the flow ID attributes given in the SLS. An EXTENDED FlowID and a BASIC
FlowID are proposed.
The Basic FlowID attribute has 6 components:
Source IP address
Destination IP address
Protocol ID
Source Port Number / Number Range
Destination Port Number / Number Range
DS-byte
A packet should match all the 6 components in the BASIC FlowID to be
associated to the SLS. Each component can be replaced by a wildcard,
this means that all the packets match that component. The Source and
Destination IP address can have "partial" wildcards to select a range of
addresses. For the source and destination ports, a single port number of
a range of contiguous ports can be specified.
If more complex classifying rules are needed, the EXTENDED FlowID is
used. The EXTENDED FlowID is the logical OR of a set of Basic FlowID.
Note: in the AQUILA first trial only the Basic FlowID is implemented.
3.4 Traffic description and conformance testing
AQUILA consortium Expires May 2001 7
Definition and usage of SLSs in the AQUILA consortium Nov-00
The Traffic description and conformance testing attributes aim to
provide an effective description of the traffic relevant to the
reservation. This description is needed by the policing and admission
control functions in the Diffserv network. As for the policing, the
traffic description should enable simple policing algorithms at the
network side, to easily check whether a specific traffic realization is
in-profile or out-of-profile. As for the admission control, the traffic
description should capture the fundamental characteristics of the
traffic, in order to allow the network to perform an effective admission
decision.
There are a lot of different traffic description models ("Traffic
descriptor algorithms"). The SLS must specify which Traffic descriptor
algorithm is used and provide the relevant parameters. The following
Traffic descriptor algorithms have been defined so far:
- Single-Rate (intended for deterministic CBR sources).
- Dual-Token-Bucket (for bursty sources with limited peak rate).
- Single-Token-Bucket (for adaptive sources, e.g. TCP).
The set of parameters for each Traffic descriptor algorithms is provided
in Table 1.
Table 1: Traffic Description Parameters
----------------------------------------------------------------
Traffic descriptor algorithm | Parameters
------------------------------|---------------------------------
Single-Rate | PR, m, M, BSP, EAR
Dual-Token-Bucket | SR, BSS, PR, m, M, BSP, EAR
Single-Token-Bucket | SR, BSS, m, M
----------------------------------------------------------------
The parameters are explained hereafter:
- PR : Peak Rate (bit/s).
- BSP : Bucket Size for PR (bytes).
In conjunction with PR the BSP forms a single token bucket meter. The
role of BSP is to allow for a little tolerance in the definition/
policing of the peak rate, similarly to CDVT (Cell Delay Variation
Tolerance) in ATM, in order to accommodate for the jitter introduced by
the elements of the access network. Typically its value is assumed
implicitly by the network. Expected typical values are around 4-5 times
M.
- SR : Sustainable Rate (bit/s).
- BSS : Bucket Size for SR (bytes).
In conjunction with SR the BSS forms a single token bucket meter. The
role of BSS is to allow for some burstiness in the source traffic flow.
- M : Maximum Allowed Packet Size.
- m : Minimum Policed Unit.
- EAR : Expected Average Rate.
AQUILA consortium Expires May 2001 8
Definition and usage of SLSs in the AQUILA consortium Nov-00
If used it could allow for a better resource allocation. It is well
known that the sustainable rate is in general larger than the average
rate, and for some traffic sources the difference may be distance is
considerable. The customer could be stimulated by means of a tariff
policy to provide information about its expected average rate. The
network could then check a posteriori if the advertised average rate has
been met within some tolerance. Anyway the EAR is not subject to be
policed by the ED.
Both the Single rate and the Single Token Bucket represent a single
token bucket policer. The difference is that the Single rate is meant to
police the peak rate, therefore the Burst size is typically few times
the maximum packet size.
With the Dual Token Bucket both the peak rate and the sustained rate are
policed.
Note: EAR is not implemented in the AQUILA first trial
Note: with respect to the TEQUILA approach, this section has been called
"Traffic description and conformance testing" instead of "Traffic
conformance testing". The idea is that these attributes also aim to
describe the traffic in order to perform proper admission control
algorithms.
3.5 Performance guarantees
The performance guarantee attributes describe the QoS requirements of
the customer and the commitment of the network to fulfill these
requirements. Both quantitative and qualitative attributes are foreseen.
The quantitative values can be maximum values, mean values or
percentiles. The qualitative attributes can be used to express relative
guarantees between different classes.
Table 2: Performance guarantee attributes
---------------------------------------------------------------
Attribute | Measurement unit
----------------------------------|----------------------------
Quantitative maximum Delay | (ms)
Quantitative maximum Jitter | (ms)
Quantitative maximum Loss Ratio |
|
Quantitative Delay percentile | (percentile; ms)
Quantitative Jitter percentile | (percentile; ms)
|
Quantitative mean Delay | (ms)
Quantitative mean Jitter | (ms)
|
Qualitative Delay | (medium/low/very low)
Qualitative Jitter | (medium/low/very low)
Qualitative Loss Ratio | (medium/low/very low)
---------------------------------------------------------------
AQUILA consortium Expires May 2001 9
Definition and usage of SLSs in the AQUILA consortium Nov-00
The delay is meant as the one way delay, the jitter is defined as the
variation of one way delay (max delay _ min delay) of a flow.
The details of the measurement procedure to evaluate statistic
parameters like percentiles or mean values should be defined. This is
for further study.
Note: in the AQUILA first trial only qualitative attributes have been
considered
3.6 Service schedule
The service schedule attributes are needed to provide the information
related to the start and the duration of the service.
The basic type of reservation is "semi-permanent", which is configured
statically and lasts continuously until de-configured.
There can be "immediate" dynamic reservations (just like in the
telephone network: the reservation starts immediately and remains valid
until the user explicitly releases it). More complex scenarios could
foresee advanced reservations with start-time and end-time or periodic
reservations (daily, weekly...).
Table 3 shows a set of possible Service Schedule attributes with their
parameters.
Table 3: Service schedule attributes
--------------------------------------------------------------------
Service schedule | Parameters
----------------------|---------------------------------------------
Immediate |
Advance reservation | Start time, start date, End Time, End date
Periodic | For further study
Semi-permanent |
--------------------------------------------------------------------
Semi-permanent and immediate reservations have a similar meaning (from
now until released), the need to differentiate between the two is for
further study.
Note: in the AQUILA first trial only "immediate" reservation are
considered.
4. Predefined SLS types
In this section the four predefined SLS types supported by the AQUILA
consortium in the first trial are described. Note that this draft does
not intend to recommend the usage of the described set of SLS types as
such. The description represents a concrete application of the concept
of predefined SLS. The provided values of the parameters often represent
a first guess in the search of useful services, subject to tuning after
the trial experience.
AQUILA consortium Expires May 2001 10
Definition and usage of SLSs in the AQUILA consortium Nov-00
The important goal is to show that a part of the parameters of the
generic SLS is fixed in the definition of the SLS type, while the
remaining set is open and will be specified by the customer in the SLS
instance. Therefore the notation (FIXED) and (OPEN) will be used to
highlight this concept. An "X" stands for not applicable.
4.1 Premium CBR
Characteristics
The Premium CBR predefined SLS is intended for applications with
stringent requirements concerning delay, delay variation, and loss
probability. Applications are not assumed to implement any form of
congestion control. This predefined SLS is well suited for constant bit
rate applications independently of their bandwidth requirements as well
as applications that generate low bandwidth VBR flows. The Premium CBR
service can be used by applications whose maximum packet size is small.
Sample applications
Voice applications, VLL-like and Circuit Emulation-like service.
Specification of Premium CBR
- Scope
p2p (FIXED)
- Flow identification:
to be filled by the customer in the instance SLS (OPEN)
- Traffic description and conformance testing:
Traffic descriptor algorithm: Single-Rate.
----------------------------------------------------------------
Parameter | Minimum admitted| Maximum admitted| Default | Note
----------|-----------------|-----------------|---------|-------
PR | 0 Kb/s | 200 Kb/s | - | (OPEN)
BSP | X | X | 512 B | (FIXED)
m | 40 B | 256 B | 40 B | (OPEN)
M | X | X | 256 B | (FIXED)
-----------------------------------------------------------------
- Performance guarantees
Qualitative Delay (low) (FIXED)
Qualitative Loss Ratio (very low) (FIXED)
- Service schedule
Immediate (FIXED)
Note: Excess traffic for Premium CBR is dropped. At the moment there is
no formal way in the AQUILA SLS to express this behavior. It is for
further study the extension of AQUILA SLS including a concept like
"Excess Treatment" in [TEQUILA-SLS].
AQUILA consortium Expires May 2001 11
Definition and usage of SLSs in the AQUILA consortium Nov-00
4.2 Premium VBR
Characteristics
The Premium VBR predefined SLS is intended for applications with medium
to high bandwidth requirements. The requirements concerning delay and
delay variation are the same as for the Premium CBR service. While
applications are assumed to generate traffic at a variable bit rate no
assumptions concerning congestion control mechanisms are made. A
restriction on the maximum packet size is enforced.
Sample applications
Video and teleconferencing.
Specification of Premium VBR
- Scope
p2p (FIXED)
- Flow identification:
to be filled by the customer in the instance SLS (OPEN)
- Traffic description and conformance testing:
Traffic descriptor algorithm: Dual-Token-Bucket.
----------------------------------------------------------------
Parameter | Minimum admitted| Maximum admitted| Default | Note
----------|-----------------|-----------------|---------|-------
PR | 0 Kb/s | 1 Mb/s | - | (OPEN)
BSP | X | X | 1024 B | (FIXED)
SR | 0 Kb/s | PR | PR | (OPEN)
BSS | M | 30 M | 10 M | (OPEN)
m | 40 B | M | 40 B | (OPEN)
M | X | X | 512 B | (FIXED)
-----------------------------------------------------------------
- Performance guarantees
Qualitative Delay (low) (FIXED)
Qualitative Loss Ratio (low) (FIXED)
- Service schedule
Immediate (FIXED)
Note: Excess traffic for Premium VBR is dropped. At the moment there is
no formal way in the AQUILA SLS to express this behavior. It is for
further study the extension of AQUILA SLS including a concept like
"Excess Treatment" in [TEQUILA-SLS].
4.3 Premium MultiMedia
Characteristics
The Premium MultiMedia predefined SLS is intended for high bandwidth
applications that require the delivery of some minimum bandwidth at a
high probability. Unlike the services mentioned before, the Premium
AQUILA consortium Expires May 2001 12
Definition and usage of SLSs in the AQUILA consortium Nov-00
MultiMedia service may provide additional bandwidth to the applications.
All applications are assumed to implement some kind of congestion
control mechanism whose aggressiveness is somewhat similar to the one of
TCP. There are no restrictions concerning the packet size.
Sample applications
Streaming multimedia, Premium FTP
Specification of Premium MultiMedia
- Scope
p2p (FIXED)
- Flow identification:
to be filled by the customer in the instance SLS (OPEN)
- Traffic description and conformance testing:
Traffic descriptor algorithm: Single-Token-Bucket.
----------------------------------------------------------------
Parameter | Minimum admitted| Maximum admitted| Default | Note
----------|-----------------|-----------------|---------|-------
SR | 0 Kb/s | 250 Kb/s | 100 Kb/s| (OPEN)
BSS | M | 30 M | 10 M | (OPEN)
m | 40 B | M | 40 B | (OPEN)
M | X | X | 1500 B | (FIXED)
-----------------------------------------------------------------
- Performance guarantees
Qualitative Loss Ratio (medium/low) (FIXED)
- Service schedule
Immediate (FIXED)
Note: Excess traffic for Premium MultiMedia is forwarded with no QoS
guarantee. At the moment there is no formal way in the AQUILA SLS to
express this behavior. It is for further study the extension of AQUILA
SLS including a concept like "Excess Treatment" in [TEQUILA-SLS].
4.4 Premium Mission Critical
Characteristics
The Premium Mission Critical predefined SLS is intended for applications
that generate non-greedy flows with a rather short lifetime. The
applications are assumed to implement some kind of congestion control
mechanism whose aggressiveness is somewhat similar to the one of TCP.
Sample applications
Transaction oriented applications
- Scope
p2a (FIXED)
AQUILA consortium Expires May 2001 13
Definition and usage of SLSs in the AQUILA consortium Nov-00
- Flow identification:
to be filled by the customer in the instance SLS (OPEN)
- Traffic description and conformance testing:
Traffic descriptor algorithm: Double-Token-Bucket.
----------------------------------------------------------------
Parameter | Minimum admitted| Maximum admitted| Default | Note
----------|-----------------|-----------------|---------|-------
PR | 0 Kb/s | 50 Kb/s | - | (OPEN)
BSP | X | X | 2048 B | (FIXED)
SR | 0 Kb/s | 5 Kb/s | | (OPEN)
BSS | M | 10 M | 10 M | (OPEN)
m | 40 B | M | 40 B | (OPEN)
M | X | X | 1024 B | (FIXED)
-----------------------------------------------------------------
- Performance guarantees
Qualitative Loss Ratio (very low) (FIXED)
- Service schedule
Immediate (FIXED)
Note: Excess traffic for Premium MultiMedia is forwarded with no QoS
guarantee. At the moment there is no formal way in the AQUILA SLS to
express this behavior. It is for further study the extension of AQUILA
SLS including a concept like "Excess Treatment" in [TEQUILA-SLS].
5. References
[AQUILA] "Adaptive Resource Control for QoS Using an IP-based Layered
Architecture" IST project 1999-10077
http://www-st.inf.tu-dresden.de/aquila/
[D1201] "System architecture and specification for the first trial",
IST-1999-10077-WP1.2-SAG-1201-PU/b0, Public deliverable of the
[AQUILA] project
[D1301] "Specification of the traffic handling for the first trial",
IST-1999-10077-WP1.3-COR-1301-PU/b0, Public deliverable of the
[AQUILA] project
[QB-BB] "QBone Bandwidth Broker Architecture" _ Work in Progress _
http://qbone.internet2.edu/bb/bboutline2.html
[TEQUILA-SLS] "Service Level Specification Semantics and Parameters", D.
Goderis et al. _ draft-tequila-sls-00.txt
6. Author Information and Acknowledgements
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 AQUILA
project for their important contribution to this work.
AQUILA consortium Expires May 2001 14
Definition and usage of SLSs in the AQUILA consortium Nov-00
Stefano Salsano
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
Via di Tor Vergata, 135
00133 Roma - ITALY
e-mail: salsano@coritel.it
Fabio Ricciato
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
Via di Tor Vergata, 135
00133 Roma - ITALY
e-mail: ricciato@coritel.it
Martin Winter
Siemens AG, ICN WN CC EK A19
81359 Munich - Germany
e-mail: martin.winter@icn.siemens.de
Gerald Eichler
T-Nova Deutsche Telekom Innovationsgesellschaft mbH
Am Kavalleriesand 3
64295 Darmstadt _ GERMANY
e-mail: Gerald.Eichler@telekom.de
Falk Fuenfstueck
Dresden University of Technology
Institute for Software- and Multimedia-Technology
D-01062 Dresden
e-mail: Falk.Fuenfstueck@inf.tu-dresden.de
Anne Thomas
Dresden University of Technology
Institute for Software- and Multimedia-Technology
D-01062 Dresden
e-mail: Anne.Thomas@inf.tu-dresden.de
Thomas Ziegler
Salzburg Research Forschungsgesellschaft m.b.H.
Jakob HaringerstraBe 5
5020 Salzburg - AUSTRIA
email: Thomas.Ziegler@salzburgresearch.at
Christof Brandauer
Salzburg Research Forschungsgesellschaft m.b.H.
Jakob HaringerstraBe 5
5020 Salzburg - AUSTRIA
email: Christof.Brandauer@salzburgresearch.at
AQUILA consortium Expires May 2001 15