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