Submitted to the OAM Area / SLSU Yves T'Joens, Alcatel INTERNET DRAFT Danny Goderis, Alcatel Raju Rajan,AT&T Labs Research Stefano Salsano, Coritel Christian Jacquenet, France Telecom R&D George Memenios, NTUA George Pavlou, UniS Richard Egan, Racal Research Ltd David Griffin, UCL Pim Vanheuven, IMEC Panos Georgatsos, AlgoSystems Leonidas Georgiadis, Univ. Thessaloniki October 2000 Expires April 2000 Service Level Specification and Usage Framework 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document provides a framework for Service Level Specification and Usage. It provides the terminology used within this context and Manyfolks Expires April, 2001 [Page 1] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 gives an architectural description of how and where Service Levels can be negotiated. It further provides a introductory section on known efforts in research and industry on building a service framework on the grounds of a diffserv enabled network. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Service Management 3.1 Service Model 3.2 Service Negotiation Process 3.3 Service Negotiation Interface 3.3.1 Intra-domain 3.3.2 Inter-domain 4.0 Architecture and Relationship to other IETF work 5.0 Overview of ongoing efforts 5.1 Diffserv WG efforts 5.2 Bandwidth Brokers 5.3 Service Negotiation Interface Efforts Acknowledgements References Full Copyright Statement Authors Addresses 1.0 Introduction This document presents a framework for Service Level Specification and Usage. Today, instantiation of service levels between customers and providers is a rather static and labour intensive task. It is to be understood that standardization of the basic process may allow for a highly developed level of automation and dynamic negotiation of Service Level Specifications between customers and providers. This automation may prove helpful in providing customers (as well as providers) the technical means for the dynamic provisioning of quality of service. The automation in itself is e.g. necessary to allow roaming (dial-in) users and mobile users to have access and negotiate a transport Service Level, independent of their point of attachment to the network. Further, the design and the deployment of a service negotiation infrastructure in a multi-vendor / multi-provider environment requires a standardized set of semantics for Service Level Specifications being negotiated at different locations: - between the customer and the service provider (namely between the Customer Premises Equipment (CPE) and its point of attachment Manyfolks Expires April, 2001 [Page 2] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 to the IP network managed by the service provider); - within an administrative domain (for intra-domain transport service negotiation purposes); - between administrative domains (for inter-domain transport service negotiation purposes). The document is structured as follows. Chapter 2 provides an terminology and definition set used in the description of the framework. Chapter 3 extends on the aspects involved in Service management. Chapter 4 positions this work in the context of ongoing standardization efforts at the level of the IETF. Chapter 5 provides an overview of related activities that can either directly or indirectly contribute to a standardized architecture for service negotiation across the Internet. [ed. note : I have brought together input from different sources for this first version, and some wordsmithing and alignment in terminology is still required. At some points I have left some editorial notes to guide comments/contributions] 2.0 Terminology [ed. note : we need to flesh out some of the terminology to avoid conflicts with other workgroups/efforts] A transport domain is a set of one or more autonomous systems that together provide transport services beyond best effort to customer networks. A transport domain consists of a set of routers that are connected by internal interfaces, and that offer transport services to customer networks at its external interfaces. The ingress interface is the external interface where datagrams enter the transport subdomain. The egress interface is the external interface where datagrams leave the transport subdomain. The Service offering entity is further referred to as the Provider. An IP flow is a set of correlated IP datagrams that share at least one common characteristic, like the same protocol identifier, the Manyfolks Expires April, 2001 [Page 3] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 same DSCP (DiffServ Code Point, [RFC-2474]) value, etc. A Service Level Specification (template) is a protocol independent representation of a set of technical parameters and their associated semantics that describe the transport service a flow is to receive over the transport domain, between ingress and egress interfaces. A Service Level Object is a protocol dependent instantiation of a Service Level Specification, that is to say, it contains the parameters and their values that describe the transport service a specified flow is to receive over the transport domain. A Service Level Agreement (SLA) is a contractual document which a subscriber and a service provider have agreed upon. A subscriber (or a Customer) is a legal representative who has the (legal) ability to subscribe to a service offering. A user is an entity (a human being or a process, from a general perspective) who has been named by a subscriber and appropriately identified by a service provider, so that he might benefit from a service according to his associated rights and duties. A Transport Service consists of a set of Service Level Objects, that should be taken atomically when negotiating a service that pertains to multiple flows at once. (e.g., a bidirectional service). A Transport Service is part of the Service Level Agreement. A Transport Service is further denoted as the Service. 3.0 Service Management Service Management concerns the definition and negotiation of Services between the customer/user and the provider. Section 3.1 describes the definition of a Service, while section 3.2 elaborates on the negotiation of Services between the Customer/User and the Provider. Finally section 3.3 elaborates the reference points in the Internet where service negotiation may apply. 3.1 The Service Model A Service Level Specification (SLS) template is a protocol independent representation of a set of technical parameters and their associated semantics that describe the transport service a flow is to receive over the transport domain, between ingress and egress interfaces. The description of these parameters is the subject of draft-tequila-sls-00.txt [SLS], and the reader is referred to [TEQUILA] for further information. Note that this work is presently Manyfolks Expires April, 2001 [Page 4] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 limited to unidirectional flows. A Service Level Object (SLO) is a protocol dependent instantiation of a Service Level Specification, that is to say, it contains the parameters and their values that describe the transport service a specified flow is to receive over the transport domain. This framework does not assume the use of any particular protocol for the negotiation (subscription or invocation). A Transport Service consists of a set of Service Level Objects, that should be taken atomically when negotiating a service that pertains to multiple flows at once. (e.g., a bidirectional service.) 3.2 Service Negotiation Process This framework assumes the Service negotiation process to be composed of a Service Subscription, and a Service Invocation phase. Service Subscription can be loosely defined as the process of negotiating the right to invoke one or more Transport Services at a later time, Service Subscription is a process between a Subscriber and a Provider. Service Invocation refers to the process of actually requesting an amount of resources as described in a (different) Transport Service, Service Invocation is a process between a User and a Provider. Note that the allocation of resources to the user does not have to be immediate, but can be subject to a service schedule as parameter of a Transport Service/ Service Level Object. Note that the administrative entity performing Service Subscription (i.e., the Subscriber) does not have to be the same administrative entity as the one performing Service Invocation (i.e., the User). E.g., a video service provider (or more general, an application service provider), can assume the role of Subscriber to the provider of the transport domain, on behalf of the end-user of the video services. The actual invocation of the transport service could then be triggered by the end-user application. The parameters involved in Service Subscription do not necessarily have to be the same as these used in Service Invocation. More generically, the parameters involved in Service Invocation can be said to be in-range or out-of-range of the set of parameters that pertain to the Service subscription process. The acceptance of Service Invocations that are out-of-range is a policy left to the providers. Note that the Service subscription process may be augmented with a Manyfolks Expires April, 2001 [Page 5] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 set of parameters that describe the likelyhood of accepting a Service invocation at a later time (e.g., invocation blocking probability). This invocation blocking probability may be derived from the set of Subscribed services that allready apply to the external (user) interface, or to the overall set of services that have been subscribed over the full transport domain. Although both subscription and invocation are here described as separate processes, invocation may be allowed in combination with subscription, that would make the service negotiation one atomic action. Note that the negotiation of services accross the transport domain, may require a recursive level of service (pre-)negotiation between the sub-transport domains that make up the overall transport domain. This is often denoted as the provider - provider negotiation process. The services negotiation between customer A and provider B, may yield an additional (not necessarily) symmetric Service negotiation between Provider B and Customer C, so that protection of denial of service attacks may appropriately be enforced, for example. 3.3 Service Negotiation Interface A standardized approach to Service Negotiation is required, according to the following transport domain taxonomy effort. Indeed, the transport domain can be composed of a single domain (i.e. a set of IP routers being managed by a globally unique and administrative entity, as per [RFC-1771]), or of a set of administrative domains. 3.3.1 Intra-domain Service negotiation may be provided over intra-domain interfaces, a typical example being application servers requesting particular transport services on behalf of its end-users. E.g., a VPN manager, H.323 GK, Media Gateway Controllers or other. This is particularly so when the transport provider and the application service provider are the same administrative entity. 3.3.2 Inter-domain Service negotiation can cross an administrative boundary, such as the customer - Transport Service Provider interface, or between Transport Service Providers. The request for interdomain Customer Services (these for which one or more of the interfaces referred to in the scope of a Service Level Object are not in the same (sub-)transport domain) may involve a recursive set of Transport Service contracts between a concatenation of transport providers on the route between Manyfolks Expires April, 2001 [Page 6] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 ingress and egress interfaces. Another example would be where the transport provider and the application service provider would be two distinct administrative entities, e.g., a IP Telephone Service Provider that wants to connect a number of media gateways over the transport provider's network, and would like some automated level of trunk dimensioning/installation. 4.0 Architecture and relationship to other IETF work +---------------------------------+ | Policy Management | +---------------------------------+ +--------------+ +--------------+ +-------------+ | Service | | Service | | | | Subscription |========| Subscription | | | +--------------+ +--------------+ | Traffic | | Engineering | +--------------+ +--------------+ | | | Service | | Service | | | | Invocation |========| Invocation | | | +--------------+ +--------------+ +-------------+ | | | +--------------+ +------------------------+ | data plane | | Traffic Traffic | | forwarding |-------------| Conditioning mgt | +--------------+ +------------------------+ +--------------------------------+ | monitoring/measurement | +--------------------------------+ Customer Provider Figure 1. architectural framework Figure 1 gives a high level functional architecture for the provisioning of services accross IP networks. The figure depicts the communication that may exist between a Customer/User and a Provider. The negotiating peer processes are depicted as the Service Subscription and the Service Invocation blocks in figure 1. The communication between these processes is the main subject of this document. Although not explicit part of the scope of this document, figure 1 further depicts a number of supporting functions that are required to Manyfolks Expires April, 2001 [Page 7] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 honour the services negotiated by both peers. They are provided here to offer the reader an overview of how the work referred to in this document relates to other ongoing activity within the IETF. The role of traffic engineering is to configure the network so as to allow the network to provide the services negotiated by the customers. Traffic engineering may largely be described as the process of network planning and dimensioning, path selection, (implicit or explicit) path establishment, and path resource reservation. A framework for traffic engineering in the internet is provided in [TE]. The latter however does not yet cover the subject of QoS enhanced traffic engineering for diffserv networks. Note that the routing process (both intra- and interdomain are to be seen as part of the traffic engineering function). The role of traffic conditioning is to execute a set of actions to conform traffic to a certain traffic contract as negotiated between the customer and the provider. It typically involves shaping, remarking or dropping of datagrams at the ingress or egress to/from a transport domain. Traffic management involves scheduling and buffer management so as to service datagrams according to the service level negotiated between the User and the Provider. Traffic conditioning is often seen as a function at the edge of the transport domain, while traffic management would be required at each individual hop in the transport domain. Both traffic conditioning and traffic management are covered by the diffserv wg [DIFFSERV]. Note that a specific interface for configuring both traffic conditioning and traffic management parameters is under specification by the rap wg [RAP], this work is also known as COPS (Common Open Policy Service [RFC-2748]) provisioning for diffserv networks [PIBDS], similarly, use can be made of SNMP [MIBDS]. The negotiation of services may be subject to policy control by the provider. A framework for policy control is currently under investigation by the policy framework group. The reader is referred to [POLICY] for an overview of the latter. Note that quite a number of parameters that are today described as part of the SLS template, can also be retrieved in the protocol independent representation model for diffserv network operation discussed in the Policy Framework group. More specifically, these parameters that relate to the configuration of traffic management and conditioning parameters at the edge of the transport domain. As such it may be expected that the protocol independent definition of a SLS can be seen as an extension to this work. Manyfolks Expires April, 2001 [Page 8] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 Negotiation of services invokes the dual concept of service monitoring, in the end, an agreed framework should exist to qualify that the Service instantiation is appropriately enforced, according to the parameters as agreed within the individual Service Level Objects. Currently, the IP Performance Measurements working group of the IETF defines a set of parameters that quantitatively describe the properties of streams over IP networks. The reader is referred to [IPPM] for further information concerning measurements. Note that a very particular way of invoking services would be through the use of RSVP (Resource Reservation Protocol, [RFC2205]) in an integrated services environment [INTSERV]. In this case, the use of the RSVP signalling protocol may yield the appropriate resource allocation in the transport domain, according to the enforcement of the corresponding Service instantiation. The interworking between intserv and diffserv domains, is presently covered in [ISSL]. 5.0 Overview of ongoing efforts 5.1 Diffserv WG efforts The purpose of this section is to present an overview of ongoing activities which are either directly related to SLSs or which could impact the SLS definition. The specification of SLSs is out of the scope of the Diffserv WG. The definition of PDBs (Per Domain Behaviour) [DSBA] could however have an impact on the SLS definition. According to [DSBA], the PDB describes the behaviour experienced by packets of a particular traffic aggregate as they cross a Diffserv domain. A PDB will be associated with a set of rules that are enforced during the entry of packets in Diffserv domain and with measurable attributes to describe what will happen to packets in crossing the domain. Similarly an SLS will describe the arrival of customer packets to the network and how the network will handle them. It is important to keep in mind that in general the PDB definitions and their attributes are not expected to be directly visible to customers at the SLS level. Another activity of the Diffserv working group is the definition of an informal management model for Diffserv Routers [DSMOD] and of the corresponding formal MIB definition [MIBDS]. The router capabilities (classification, policing, metering...) are described defining a set of parameters and algorithms. The relationship of these definitions with the corresponding definitions at SLS level should be taken into account. 5.2 Bandwidth Brokers Manyfolks Expires April, 2001 [Page 9] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 The Bandwidth Broker concept was first introduced in [2BIT]. There are several projects dealing with Bandwidth Broker architectures, see for example [CAN], [ITTC]. The communication between a Client and a Bandwidth Broker, or among two Bandwidth Brokers is always based on a form of SLS. In the context of the Qbone Internet2 project, the Bandwidth Broker Working Group is defining the architecture of a Bandwidth Broker and a protocol for inter-domain communication between Bandwidth Brokers. The current status of the definition of the Architecture and of the "Simple Interdomain Bandwidth Broker Signalling" (SIBBS) is described in [QB-BB]. This document provides a definition of the SLS as being "not a reservation, but rather a commitment to allow reservations (or a potential for reservations)", and leaves the formal description of this type of SLS out of the scope of current work. The definition of SLS in [QB-BB] can be mapped in the "subscription SLS" discussed in this document. In [QB- BB], the actual reservation is carried by SIBBS protocol in the "Resource Allocation Request" (RAR) messages. RAR messages contains "...the space-time coordinates of the service, the kind of service (and possibly parameters of the service) and possibly the characteristics of the input...". The content of the RAR messages can be compared to the "invocation SLS" discussed in this document. It is worth noting that the "kind of service" parameter in the RAR means a reference to a "Globally Well-known Service" (GWS) and that currently the only service under consideration is the "QBone Premium Service" (QPS). AT&T's Policy Arena is a policy based management approach to scalable management networks, aimed at automating the creation and administration of end-to-end QoS services. An important component of the Policy Arena approach is to allow customers to create, modify and manage QoS pipes or hoses across the provider's backbone, and receive customized reports on the performance of the active service instances. Towards this end, Policy Arena comprises of independent policy servers in the customer and provider networks which negotiate the attributes of service instantiation, take responsibility for parsing and checking parameters for correctness and consistency; distribute policies to various network devices and monitor their enforcement. To perform these roles, the policy layer includes a set of functions that provide monitoring, configuration and control of both the attributes of services and the policies governing them. The policy layer captures users' requirements, device independent configuration, aggregates device-state information, co-ordinates event notifications across various sub-systems, and in some cases "closes the loop" between monitoring and control. 5.3 Service Negotiation Interface efforts As far as the SLS negotiation mechanisms and protocols are concerned Manyfolks Expires April, 2001 [Page 10] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 a set of possible candidates is: PPP, RSVP, SIBBS, COPS, HTTP, XML based negotiation, CORBA. References to past or ongoing activities on some of these approaches is given hereafter: [PPPSLA] describe the negotiation of SLA using PPP; the SIBBS interdomain protocol is described in [QB-BB]; an intradomain solution using COPS has been proposed in [COPSODRA]; the MIAMI project [Reference??] used an XML based negotiation, the AQUILA project [AQUILA] is using CORBA for communicating reservation requests from the customer to an admission control agent in the network. [ed. note : other efforts will be taken into account, when references and basic text are provided] 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 TEQUILA project for their input and reflection on this work. References [2BIT] "A Two-bit Differentiated Services Architecture for the Internet." K. Nichols, V. Jacobson, L. Zhang, July 1999, RFC 2638, Informational (see also ftp://ftp.ee.lbl.gov/parpers/dsarch.pdf) [AQUILA] AQUILA project IST-1999-10077 http://www-st.inf.tu- dresden.de/aquila/ - "System architecture and specification for first trial" Public deliverable [DIFFSERV]"Differentiated Services Working Group", http://www.ietf.org/html.charters/diffserv-charter.html [DSBA] K. Nicols, B. Carpenter, "Definition of Differentiated Services Behavior Aggregates and Rules for their Specification" [DSMOD] Y. Bernet, S. Blake, D. Grossman, A. Smith "An Informal Management Model for Diffserv Routers" - draft-ietf-diffserv-model- 04.txt [DS-TERMS] "New terminology for diffserv", D. Grossman, draft-ietf- diffserv-new-terms-02.txt, work in progress [CAN] "CANARIE ANA Bandwidth Broker" http://www.gait.bcit.bc.ca/Projects/bandwidth_broker/index.html Manyfolks Expires April, 2001 [Page 11] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 [COPSODRA] S. Salsano "COPS Usage for Outsourcing Diffserv Resource Allocation", - draft-salsano-issll-cops-odra-00.txt [INTSERV]"Integrated Services Working Group", http://www.ietf.org/html.charters/intserv-charter.html [IPPM] "IP Performance Metrics", http://www.ietf.org/html.charters/ippm-charter.html [ISSLL]"Integrated Services over Specific Link Layers", http://www.ietf.org/html.charters/issll-charter.html [ITTC] "Implementation of a Bandwidth Broker System for Resource Management in Differentiated Services" - http://www.ittc.ukans.edu/~kdrao/845/index.html [MIBDS] F. Baker, K. Chan, A. Smith "Management Information Base for the Differentiated Services Architecture" - draft-ietf-diffserv-mib- 04.txt [POLICY] "Policy Framework Working Group", http://www.ietf.org/html.charters/policy-charter.html [PPPSLA] J. De Clercq, P. De Schrijver, C. Zaccone, Y. T'Joens, "PPP Diffserv SLA Negotiation" [QB-BB] "QBone Bandwidth Broker Architecture" Work in Progress http://qbone.internet2.edu/bb/bboutline2.html [QBONE] "Qbone Architecture (v1.0), Ben Teitelbaum (1999), http://www.internet2.edu/qos/wg/papers/qbArch/ [RAP] "Resource Allocation Protocol Working Group", http://www.ietf.org/html.charters/rap-charter.html [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 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 [RFC 2475] "An Architecture for Differentiated Services", S. Blake, Manyfolks Expires April, 2001 [Page 12] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 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 [SLS] Goderis et al., "Service Level Specification Semantics, Parameters and negotiation requirements.", draft-tequila-sls-00.txt, October 2000, Work in Progress [TE] "Internet Traffic Engineering Working Group", http://www.ietf.org/html.charters/tewg-charter.html [TEQUILA] "Functional Architecture Definition and Top Level Design of the TEQUILA system", Goderis et al., public deliverable, September 2000, http://www.ist-tequila.org Full copyright statement Copyright (C) The Internet Society (1999). 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 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. Manyfolks Expires April, 2001 [Page 13] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 Authors Addresses Yves T'Joens Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240- Fax : 32-3-240-9932 E-mail: Yves.TJoens@Alcatel.be Danny Goderis Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240- Fax : 32-3-240-9932 E-mail: Danny.Goderis@Alcatel.be Raju Rajan AT&T Labs Research 180 Park Ave., Florham Park, NJ 07932 rajan@research.att.com Stefano Salsano Coritel [address lacking, stefano ?] Christian Jacquenet France Telecom Research and Development FT R&D /DMI 42, rue des Coutures BP6243 14066 CAEN CEDEX 04 France Tel : +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 Manyfolks Expires April, 2001 [Page 14] Internet Draft draft-manyfolks-sls-framework-00.txt October, 2000 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 Racal Research Ltd Worton Drive Worton Grange Industrial Estate Reading, Berkshire RG2 OSB tel: +44 118 986 8601 fax: +44 118 923 8399 e-mail : richard.egan@rrl.co.uk 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 Email: D.Griffin@ee.ucl.ac.uk Panos Georgatsos 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 Manyfolks Expires April, 2001 [Page 15]