[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
                                                                Danny Goderis, Alcatel
                  Internet Draft                           Sven Van Den Bosch, Alcatel
                  Document: draft-tequila-sls-02.txt             Yves T'joens, Alcatel
                   Expires: August - 2002                       Olivier Poupel, Alcatel
                                                            Christian Jacquenet, France
                                                                            Telecom R&D
                                                                  George Memenios, NTUA
                                                                    George Pavlou, UniS
                                                      Richard Egan, Thales Research Ltd
                                                                     David Griffin, UCL
                                                          Panos Georgatsos, AlgoSystems
                                                             Leonidas Georgiadis, Univ.
                                                                           Thessaloniki
                                                                   Pim Van Heuven, IMEC
                                                                          February 2002
                 
                 
                           Service Level Specification Semantics and Parameters
                                        <draft-tequila-sls-02.txt>
                 
                 
                 Status of this Memo
                 
                  This document is an Internet-Draft and is in full conformance
                  with all provisions of Section 10 of RFC2026.
                 
                 
                  Internet-Drafts are working documents of the Internet Engineering
                  Task Force (IETF), its areas, and its working groups.  Note that
                  other groups may also distribute working documents as Internet-
                  Drafts.
                 
                  Internet-Drafts are draft documents valid for a maximum of six
                  months and may be updated, replaced, or obsoleted by other documents
                  at any time.  It is inappropriate to use Internet-Drafts as
                  reference material or to cite them other than as "work in progress."
                 
                  The list of current Internet-Drafts can be accessed at
                       http://www.ietf.org/ietf/1id-abstracts.txt
                  The list of Internet-Draft Shadow Directories can be accessed at
                       http://www.ietf.org/shadow.html.
                 
                 
                 Abstract
                 
                  This document  identifies the basic information to be handled by
                  Service Level Specifications (SLS, [RFC 2475], [DS-TERMS]) when
                  considering the deployment of value-added IP service offerings over
                  the Internet. IP service offerings can be provided together with a
                  given quality of service (QoS), whose definition can be conveyed in
                  an SLS, from a technical standpoint. Since these IP services are
                  likely to be provided over the whole Internet, their corresponding
                  QoS will be based upon a set of technical parameters that both
                  customers and network providers will have to agree upon. From this
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 1]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  perspective, this draft aims at listing (and promoting a standard
                  formalism for) a set of basic parameters which will actually compose
                  the elementary contents of an SLS.
                 
                  Such a specification effort tries to address the following concerns:
                 
                       - Provide a standard set of information to be negotiated
                         between a customer and a network provider or between network
                         providers;
                 
                       - Provide the corresponding semantics of such information, so
                         that it might be appropriately modeled and processed by the
                         above-mentioned parties (in an automated fashion).
                 
                 
                 
                 Table of Contents
                 
                  Status of this Memo................................................1
                  Abstract...........................................................1
                  Table of Contents..................................................2
                  0  Conventions used in this document..............................3
                  1  Introduction...................................................3
                  1.1  Changes w.r.t. the previous version..........................3
                  1.2  Motivation...................................................3
                  1.3  Objectives...................................................4
                  2  Basic assumption and terminology...............................5
                  3  SLS content & template.........................................5
                  3.1  SLS Identification...........................................5
                  3.2  Scope........................................................6
                  3.3  Flow Identification..........................................7
                  3.4  Traffic Envelop and Traffic Conformance......................9
                  3.5  Excess Treatment............................................11
                  3.6  Performance Guarantees......................................11
                  3.7  Service schedule............................................15
                  3.8  Reliability.................................................16
                  3.9  Monitoring..................................................16
                  3.10  Others.....................................................17
                  4  Service Level Specifications and Per Domain Behaviours........17
                  4.1  DiffServ Terminology........................................18
                  4.1.1 About Service Level Specifications.........................18
                  4.1.2 About Per Domain Behaviors.................................18
                  4.1.3 About SLS and PDB relationships............................18
                  4.2  SLS and PDB similarities and differences....................19
                  4.2.1 A subset of common parameters..............................19
                  4.2.2 External interfaces versus intra-domain QoS building blocks 19
                  4.3  From PHB to value-added IP services: a layered DiffServ view 20
                  5  Service Level Specification examples..........................21
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 2]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  5.1  Virtual Leased Line.........................................21
                  5.2  Bandwidth Pipe for data-services............................22
                  5.3  Minimum rate guarantee with allowed excess..................22
                  5.4  Qualitative Olympic services................................23
                  5.5  The Funnel service..........................................23
                  5.6  Best effort traffic.........................................24
                  6  SLS negotiation requirements..................................24
                  7  Security Considerations.......................................24
                  8  Acknowledgment................................................25
                  References........................................................25
                  Author's Addresses................................................26
                  Full Copyright Statement..........................................28
                 
                 
                 
                 0  Conventions used in this document
                 
                  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                  "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
                  this document are to be interpreted as described in RFC 2119.
                 
                 
                 
                 1  Introduction
                 
                 1.1 Changes w.r.t. the previous version
                 
                  This is the fourth version of an Internet Draft on the issue of
                  Service Level Specifications (SLSs). This version contains some
                  editorial changes, some additions of parameters for identification
                  and monitoring, new service scheduling parameters and an update of
                  the section 4 entitled "Service Level Specifications and Per Domain
                  Behaviors". This  section discusses the similarities and differences
                  between SLSs and PDBs. Also some minor editing changes and reference
                  updates have been incorporated in this version.
                 
                 
                 1.2 Motivation
                 
                  This document is presented to the IETF community to gauge the
                  interest for advancing the work on the specification of an SLS
                  definition, its semantics and its potential negotiation protocol(s).
                  The deployment of QoS-based value-added IP services over the global
                  Internet is one of the most exciting challenges that the network
                  providers try to currently address, especially when considering the
                  deployment of such service over administrative domains. From this
                  standpoint, it seems useful to consider the specification of an SLS
                  template these network providers would agree upon, so as e.g. to
                  facilitate the enforcement of an inter-domain QoS policy.
                 
                 
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 3]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 1.3 Objectives
                 
                  This document presents an outline for the definition of the Service
                  Level Specification parameters and the semantics that go behind this
                  representation for a transport service.
                 
                  The need to have such an agreed set of Service Level Specification
                  parameters and semantics is manifold.
                 
                  First, it is necessary to be able to allow for a highly developed
                  level of automation and dynamic negotiation of Service Level
                  Specifications between customers and network providers. Automation
                  and dynamics are indeed helpful in providing customers (as well as
                  providers) the technical means for the dynamic provisioning of
                  quality of service configuration information.
                 
                  Second, the design and the deployment of QoS-aware and capable
                  Network and Element Management system in a multi-vendor environment
                  requires a standardized set of semantics for Service Level
                  Specifications being negotiated at different locations, such as:
                 
                       - within an administrative domain (for intra-domain SLS
                         negotiation purposes);
                 
                       - between the customer and the network provider, where the
                         customer might be e.g. a company, an application service
                         provider (e.g. a voice over IP provider), another network
                         provider, etc.
                 
                       - between administrative domains (for inter-domain negotiation
                         purposes).
                 
                  While the representation and semantics behind a Service Level
                  Specification need to be standardized, this document does not assume
                  that the syntax, nor the SLS negotiation protocol need to be
                  uniquely defined. The SLS negotiation protocol and associated
                  requirements is out of scope of this document.
                 
                  The document is structured as follows.
                 
                  Section 2 lists the basic assumptions underlying this work and some
                  terminology.
                 
                  Section 3 describes the parameters of the Service Level
                  Specification (template) for a transport service. This draft only
                  describes the semantics of the SLS-parameters, omitting all
                  implementation details as for instance the parameter data types (at
                  this moment).
                 
                  Section 4 provides some examples of relevant SLS specifications,
                  with the aim to show the usage of the templates. The SLS formalism
                  defined in section 3 allows making a distinction between qualitative
                  and quantitative SLSs:
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 4]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                       - SLSs depicting qualitative services should yield the
                         specification of relative QoS indicators, such as a "low" IP
                         packet loss. From this standpoint, best effort traffic is
                         expected to be qualified by an SLS of that range of
                         qualitative services.
                 
                       - SLSs depicting quantitative services should yield the
                         accurate measurement of QoS indicators, such as e.g., transit
                         delay.
                 
                  Sections 5 and 6 finally describe some SLS (protocol) negotiation
                  requirements and security considerations respectively.
                 
                  The material presented in this draft derives from work within the
                  IST-TEQUILA project [TEQUILA].
                 
                 
                 
                 2  Basic assumption and terminology
                 
                  The basic assumption of this draft is that IP services will be
                  deployed over a public IP infrastructure, which will be (partly if
                  not completely) composed of diffserv-aware network elements ([RFC-
                  2475], [DS-MODEL]). These network elements are able to implement Per
                  Hop Behaviors (PHBs), including the Assured Forwarding PHB ([RFC-
                  2597]), and the Expedited Forwarding PHB ([RFC-2598].
                 
                  In this document, the owner of the transport network equipment, i.e.
                  the IP network, is called network provider. The network provider
                  offers IP transport services to its customers. The IP transport
                  services are technically described by SLSs. The customers of the
                  network provider may be corporates, application service providers
                  (themselves offering e.g. voice or video to residential users) or
                  other network providers.
                 
                  The terminology used in this draft is in agreement with the DiffServ
                  Working Group terminology introduced in [RFC-2475], section 1.2
                  "terminology" and further specified in [DS-TERMS]).
                 
                 
                 
                 3  SLS content & template
                 
                  The following describes the attributes of the Service Level
                  Specification.
                 
                 
                 3.1 SLS Identification
                 
                  The SLS Identification is a field used by the service provider and
                  the customer to identify the SLS and the service the SLS is related
                  to.
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 5]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                 
                  SLS Identification = (SLS Id, Service Id)
                 
                       - SLS Id: This is the parameter identifying the SLS
                 
                       - Service Id: This the parameter identifying the service the
                         SLS is related to.
                 
                  The SLS Identification is mainly dedicated to the classification of
                  multiple SLSs that can composed a service.
                 
                 
                 3.2 Scope
                 
                  The scope of an SLS associated to a given service offering indicates
                  where the Quality of Service (QoS) policy for that specific service
                  offering is to be enforced. Therefore the scope uniquely identifies
                  the geographical/topological region over which the QoS is to be
                  enforced by indicating the boundaries of that region.
                 
                  An SLS is associated with uni-directional traffic flows. Note
                  however that this does not exclude the provisioning of bidirectional
                  technical agreements, by combining one or more SLSs.
                 
                  The associated scope of the SLS MUST be expressed by a couple of
                  ingress and egress interfaces. Ingress/egress denote respectively
                  the entry/exit points of the IP packets relative to the region
                  (network).
                 
                  Scope = (ingress, egress) with ingress/egress defined as
                 
                       - Ingress: interface identifier | set of interface identifiers
                         | any
                 
                       - Egress : interface identifier | set of interface identifiers
                         | any
                 
                  Remarks:
                 
                       - "|" denotes an exclusive OR.
                 
                       - "any" is logically equivalent with unspecified.
                 
                  The following combinations of (ingress, egress) interfaces are
                  allowed:
                 
                       - (1,1) -  one-to-one communication
                 
                       - (1,N) - one-to-many communication (N>1)
                 
                       - (1,any) - one-to-any communication
                 
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 6]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                       - (N,1) - many-to-one communication (N>1)
                 
                       - (any,1) - any-to-one communication
                 
                  The above taxonomy excludes the many-to-many communication (M,N).
                  Either ingress OR egress MUST be specified to exactly ONE interface
                  identifier (with a non-exclusive OR). Many-to-many communication
                  (M,N) can be decomposed into M times one-to-many communication
                  (1,N).
                 
                  This taxonomy SHOULD avoid all ambiguity about the IP flow (defined
                  as a set of IP datagrams sharing at least one common characteristic,
                  like e.g. the same [source address; destination address] pair), and
                  its corresponding identification. (see section 3.2 and 3.3). If the
                  ingress is a single interface identifier, then the traffic envelop
                  and flow id concerns the incoming IP packet stream at the unique
                  ingress point. If (only) the egress is a single interface, i.e.
                  (N|any,1), then the traffic envelop and flow id concerns the
                  outgoing (aggregate) traffic on the egress link. More details about
                  the latter can be found in the example given in section 4.5.
                 
                  In the remaining part of this document SLSs with an associated scope
                  (topology) of (1,1) ; (1,N) ; (N,1) will be called respectively
                  Pipe, Hose and Funnel SLSs.
                 
                  Disclaimer:
                 
                  An ingress (or egress) interface identifier should uniquely
                  determine the boundary link as defined in [RFC-2475] on which
                  packets arrive/depart at the border of a DS domain. This link
                  identifier MAY be an IP address, but it may also be any other
                  mutually agreed upon identifier which uniquely identifies a boundary
                  link. For example a layer-two identifier in case of Ethernet or
                  unnumbered PPP-based access  links in (Point-to-Point Protocol,
                  [RFC-1661]).
                 
                 
                 3.3 Flow Identification
                 
                  The flow identification (Flow Id) of an SLS associated to a given
                  service offering indicates for which IP packets the QoS policy for
                  that specific service offering is to be enforced.
                 
                  A Flow Id identifies a stream of IP datagrams sharing at least one
                  common characteristic. An SLS contains one (and only one) Flow Id,
                  which MAY formally be specified by providing one or more of the
                  following attributes:
                 
                  Flow Id = (Differentiated Services information, source information,
                  destination information, application information)
                 
                       - Differentiated Services information = DSCP value | set of
                         DSCP values | any
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 7]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                       The Differentiated Services Code Point (DSCP) IP header field
                         is defined in [RFC-2474].
                 
                       - Source information = source address | set of  source
                         addresses | source prefixe | set of source prefixes | any
                 
                       - Destination information = destination address | set of
                         destination addresses | destination prefixe | set of
                         destination prefixes | any
                 
                       - Application information = protocol number | protocol number
                         and source port, destination port | any
                 
                  Note: "any" is again logically equivalent with unspecified.
                 
                  Thus, the Flow Id may be expressed by information attributes related
                  to the source/destination nodes, the application or the DS field in
                  the IP header. The Flow Id provides the necessary information for
                  classifying the packets at a DS boundary node.
                 
                  This datagram classification can either reflect a Behaviour
                  Aggregate (BA) or Multi-Field (MF)classification.
                 
                  In case of MF-classification all attributes MAY be specified,
                  including the DSCP field. MF classification may depict as well
                  micro-flows as aggregate macro-flows, based on e.g. source network
                  prefix [DS-MODEL]. Also the "set-of" semantics allows for the
                  specification of aggregate flows. If a Flow Id is e.g. specified by
                  a set of two IP source addresses, then any packet with either of the
                  two concerned source addresses in its header belongs to the IP
                  packet stream identified by Flow Id.
                 
                  In case of BA-classification [RFC-2475], the DSCP attribute MUST be
                  specified and the other attributes MUST NOT be specified. If a set
                  of DSCP-values is specified, then any packet having a DSCP belonging
                  to this set is part of the Flow Id packet stream. As an example
                  consider an Ordered Aggregate (OA) IP packet stream of a particular
                  Assured Forwarding Class AFx (AF1,AF2,AF3,AF4 - see [RFC 2597]).
                  This stream could be specified within one Flow Id using three DSCP-
                  values, indicating the three drop precedences levels.
                 
                  It should however be noticed that the DSCP-value(s) specified in the
                  SLS has (have) as such nothing to do with the DSCP-marking of
                  packets inside the DiffServ network. The latter, i.e. the "interior"
                  DSCP is used for differentiating packets according to Per Hop
                  Behaviours (PHBs). The former, i.e. the "ingress" DSCP value
                  (specified in the SLS), is just another way of identifying a packet
                  stream, eventually in combination with other IP header fields. At
                  the ingress DiffServ node (incoming) packets are classified based on
                  the "ingress" DSCP value (amongst others), after which they may be
                  re-marked by the "interior" DSCP-value.
                 
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 8]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  Finally note also that the IP routing scheme MAY put restrictions on
                  combining scope and flow identification within an SLS.
                 
                  In general, if (only) Flow ID is specified by source and destination
                  IP address (IP-src, IP-dest), and the scope is unspecified, then
                  there is no a-priori assumption about the actual ingress/egress
                  points that this traffic will cross. Indeed, it is the
                  responsibility of the network provider to define the most
                  appropriate route for this traffic, by enforcing the corresponding
                  traffic engineering and routing policies. Thus, the (ingress,
                  egress) information (which in this case is NOT part of the SLS
                  template instance) is then derived from the Flow Id and the routing
                  policy of the network provider.
                 
                  On the other hand, if both Flow Id AND scope are specfied in the
                  SLS, resp. by the pairs (IP-src, IP-dest) and (IP-ingr, IP-egr)
                  pairs then it is clear that the IP packets MUST follow the route
                  (IP-src,...,IP-ingr,...,IP-egr,...,IP-dest). Thus the restriction is
                  that the scope (IP-ingr, IP-egr) is part of the route from IP-scr to
                  IP-dest.
                 
                  Also remark that the exclusion of the many-to-many communication
                  scope model puts similar constraints on the source/destination
                  fields of the Flow Identification.
                 
                 
                 3.4 Traffic Envelop and Traffic Conformance
                 
                  The traffic envelop describes the traffic (conformance)
                  characteristics of the IP packet stream identified by the Flow Id.
                  The traffic envelop is a set of Traffic Conformance Parameters,
                  describing how the packet stream should look like to get the
                  guarantees indicated by the performance parameters (defined in
                  section 3.5)
                 
                  The Traffic Conformance Parameters are the basic input for the
                  Traffic Conformance Algorithm. Traffic Conformance Testing is the
                  combination of the Traffic Conformance Parameters and the Traffic
                  Conformance Algorithm. This will usually be done at a DS-boundary
                  node.
                 
                  The algorithm and the conformance test can be binary-based or multi-
                  level based.
                 
                  Binary Traffic Conformance Testing is a set of actions which
                  uniquely identifies the "in-profile" and "out-of profile" (or
                  excess) packets of an IP stream (identified by Flow-Id). In this
                  case the Traffic Conformance Parameters describe the reference
                  values the traffic (identified by the Flow ID.) will have to comply
                  with, thus yielding the notions of "in" and "out" of profile
                  traffics. The Traffic Conformance Algorithm is the mechanism
                  enabling unambiguously to identify all "in" or "out" of profile
                  packets based on these Conformance parameters.
                 
                  TEQUILA Consortium   Expires August - 2002                [Page 9]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                  In case of multi-level (n) Traffic Conformance Testing a packet will
                  be tagged (by the algorithm) as belonging to a particular level
                  (1...n). Packets tagged as level n are called "excess" packets.
                 
                  The SLS MUST indicate the concerned level (n) of the conformance
                  testing algorithm:
                 
                       - Multi-level conformance testing n (integer)
                 
                  The following gives a (non-exhaustive) list of potential conformance
                  parameters.
                 
                       - Peak rate p (bits per second)
                 
                       - Token bucket rate r (bits per second)
                 
                       - Bucket depth b (bytes)
                 
                       - Maximum Transfer Unit (MTU) M (bytes)
                 
                       - Minimum packet size (bytes)
                 
                  Binary-based Traffic Conformance Testing examples:
                 
                       - Conformance parameters = token bucket parameters (b,r);
                         conformance algorithm = token bucket algorithm.
                 
                       - Conformance parameters = token bucket parameters and peak
                         rate (b,r,p) with p larger than r; conformance algorithm =
                         the combined token bucket (b,r) and (b,p). This is the
                         conformance test for Integrated Services Controlled Load and
                         Guaranteed Service IP flows in the IntSer QoS architecture
                         [RFC-2211, RFC-2212]. The scheme permits bursty traffic to be
                         sent, limited to a burst of b bytes, with a (long-term)
                         average rate of r and a peak rate of no more than p.
                 
                       - Conformance parameters = MTU; conformance algorithm = all
                         packets allowed with size smaller than MTU; packets larger
                         than MTU are fragmented or dropped.
                 
                  Three-level based Traffic Conformance Testing example
                 
                       - The Two-rate Three-colour marker is based on two token
                         buckets with rates r1 and r2 (r2 being greater than r1),
                         containing respectively green and yellow tokens. The simplest
                         operational mode is the "colour-blank" mode. A packet is
                         tagged "green" if there are green and yellow tokens
                         available, yellow if only yellow tokens are available and
                         otherwise it is tagged red.
                 
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 10]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 3.5 Excess Treatment
                 
                  This section describes how the network provider will process excess
                  traffic, i.e. out-of-profile traffic (in case of binary conformance
                  testing) or n-level traffic (in case of n-level conformance
                  testing). The process takes place after Traffic Conformance Testing,
                  described previously.
                 
                  Excess traffic may be dropped, shaped and/or remarked. The SLS MUST
                  specify the appropriate action by the following attribute.
                 
                       - Excess Treatment
                 
                  If Excess Treatment is not indicated, then excess traffic is
                  dropped. Depending on the appropriate action, more parameters MAY be
                  required The following is an indication in case of binary
                  conformance testing. Multi-level conformance testing (like the
                  definition of a hierarchical drop preference model) MAY also be
                  enforced, but this concern has been left for further study.
                 
                       - If excess traffic is dropped, then all packets marked as
                         "out-of-profile" by the Traffic Conformance Algorithm are
                         dropped. No extra parameters are needed.
                 
                       - If excess traffic is shaped, then all packets marked as "out-
                         of-profile" by the Traffic Conformance Algorithm are delayed
                         until they are "in-profile". The shaping rate is the
                         policing/token bucket rate r. The extra parameter is the
                         buffer size of the shaper.
                 
                       - If excess traffic is marked or remarked, then all packets
                         marked as "out-of-profile" by the the Traffic Conformance
                         Algorithm are (re-) marked with a particular DSCP-value
                         (yellow or red). The extra parameter is the DSCP.
                 
                 
                 3.6 Performance Guarantees
                 
                  The performance parameters describe the service guarantees the
                  network offers to the customer for the packet stream described by
                  the Flow Id and within the limits of the geographical/topological
                  extent given by the scope.
                 
                  There are four performance parameters:
                 
                       - one-way transit delay, optional quantile
                 
                       - packet delay variation or jitter, optional quantile
                 
                       - packet loss
                 
                       - throughput
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 11]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  Delay, jitter and packet loss guarantees are for the in-profile
                  traffic in case of binary conformance testing. For multi-level (n)
                  conformance testing, delay, jitter and loss guarantees MAY be
                  specified for each conformance level-i, except the last one (n). For
                  example if n = 3, one can have a delay guarantee for the
                  "conformance level-1" packets and a different delay guarantee for
                  the "conformance level-2" packets. No guarantees are given for
                  excess ("conformance level-n") traffic.
                 
                  The throughput is an overall guarantee for the IP packet stream,
                  independent of a particular level (see below).
                 
                  The following definitions always consider the (measurable)
                  performance parameters related to the packet stream specified by the
                  Flow Id. For simplicity the definitions below are given for binary
                  conformance testing (n=2), but generalisation is straightforward.
                 
                  The delay and jitter indicate respectively the maximum packet
                  transfer delay and packet transfer delay variation from ingress to
                  egress.
                 
                  Delay and jitter may either be specified as worst case
                  (deterministic) bounds or as quantiles. Indeed, the worst case
                  delay/jitter bounds will be very rare events and customers may find
                  measurements of e.g. 99.5th percentile a more relevant empirical
                  gauge of delay/jitter.
                 
                  Suppose e.g. that the SLS specifies the triple (delay = 10ms,
                  quantile = 10E-3). Then the probability that the transfer delay of a
                  packet (between ingress-egress) is larger than 10ms, is less than
                  10E-3.
                 
                  The above syntax for delay/jitter can be generalised by specifying
                  in the SLS an array of e.g. N (delay/jitter, quantile)-couples. The
                  more couples, the better the delay probability tail distribution can
                  be approximated. Such a specification together with the eventual
                  need of such a generalisation is for further study.
                 
                  The packet loss probability is ratio of the lost (in-profile)
                  packets between ingress and egress and the offered (in-profile)
                  packets at ingress.
                 
                                lost packets between (& including) ingress and egress
                  packet loss = ------------------------------------------------------
                                      offered (injected) packets at ingress
                 
                  The throughput is the rate measured at egress counting all packets
                  identified by Flow Id. Notice that all packets, independently of
                  their conformance level (in/out-of-profile) contribute. Indeed, if
                  the customer (only) wants a throughput guarantee, then he/she does
                  not care whether in- or out-profile packets are dropped, but is only
                  interested in the overall throughput of its packet stream.
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 12]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  Note on the relation with the Traffic Conformance Parameters
                  (section 3.3) in case of a binary-based conformance testing
                  algorithm:
                 
                       - The Traffic Conformance Algorithm (and parameters) MUST be
                         specified when guaranteeing delay/jitter or packet loss, i.e.
                         if one of these performance parameters is quantified in the
                         SLS. Conformance testing is required because the delay/jitter
                         and loss guarantees are only for the stream of in-profile
                         packets.
                 
                       - When only guaranteeing a throughput, or if non-of the other
                         performance parameters is quantified, the traffic conformance
                         algorithm MAY be specified. It is not required to specify the
                         Conformance Algorithm, because the (eventual) throughput
                         guarantee does not require the strict distinction between
                         in/out-of-profile traffic. However, the network operator will
                         probably protect his network by implementing a Traffic
                         Conditioner at Ingress and specifying the token policing rate
                         (r) (almost) equal to the throughput guarantee R, r~R.  He
                         may or may not tag/mark excess traffic, according to his own
                         - internal - policy rules. See also example 4.2.
                 
                  Note on the relation between throughput R, packet loss p and excess
                  treatment in case of a binary-based conformance testing algorithm:
                 
                       - First consider the case where excess traffic is dropped (or
                         shaped to in-profile) based on the token bucket (b,r) traffic
                         conformance algorithm. As only in-profile packets are allowed
                         at ingress, the following equality holds:
                 
                               throughput R = (1-p) * token rate r
                 
                       Thus the throughput guarantee can be derived from the loss
                       probability and token rate and is therefore not an independent
                       parameter.
                 
                       - If excess traffic is allowed (and marked accordingly), then
                         "throughput" is an independent parameter because it also
                         takes into account the out-of-profile packets (measured at
                         egress). One has obviously the inequality:
                 
                               throughput R >= (1-p) * token rate r
                 
                 
                  Quantitative performance guarantees
                 
                  A performance parameter is said to be quantified if its value is
                  specified to a numeric (quantitative) value.
                 
                  The service guarantee offered by the SLS is said to be quantitative
                  IF at least one of the 4 performance parameters is quantified.
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 13]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                  Qualitative performance guarantees
                 
                  If non of the SLS performance parameters are quantified, then the
                  performance parameters "delay" and "packet loss" MAY be "qualified".
                 
                  Possible qualitative values (for delay and/or loss): high, medium,
                  low.
                 
                  Relative delay guarantees:
                 
                       - gold service : value = low
                 
                       - silver service : value = medium
                 
                       - bronze service : value = high or not indicated
                 
                  Relative loss guarantees
                 
                       - green service : value = low
                 
                       - yellow service : value = medium
                 
                       - red service : value = high or not indicated
                 
                  The quantification of relative difference between <high/medium/low>
                  is a matter of provider's policy (e.g. high = 2 x  medium ; medium =
                  2 x low).
                 
                  The above taxonomy yields the following combinations of qualitative
                  services (Table 1).
                 
                   |------------------------------------------------------|
                   |\ delay |             |               |               |
                   | \------|     low     |    medium     |     high      |
                   |  loss  |             |               |               |
                   |------------------------------------------------------|
                   | low    | gold green  | silver green  | bronze green  |
                   | medium | gold yellow | silver yellow | bronze yellow |
                   | high   | gold red    | silver red    | bronze red    |
                   |------------------------------------------------------|
                                       Table 1: Combinations table
                 
                  The service guarantee offered by the SLS is said to be qualitative
                  if it is NOT quantitative and either delay or loss (non-exclusive)
                  are qualified to "medium" or "low", i.e. excluding bronze/red from
                  the above.
                 
                  The service guarantee offered by the SLS is said to be best-effort
                  if it is NOT quantified nor qualified.
                 
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 14]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 3.7 Service schedule
                 
                  The service schedule indicates the start and the end of the service,
                  i.e. when the service is available.
                 
                  The Service schedule MAY be specified with the following parameters:
                 
                  Service schedule = (Start date, End date, MonthMask, DayMask,
                  TimeMask)
                 
                       - Start date: Date and hour from which the service becomes
                         available.
                 
                       - End date: Date and hour from which the service becomes
                         unavailable.
                 
                  Start date and End date MUST be specified and End date MUST be
                  greater than End date.
                 
                  Remark: service schedule "from now on" [now, infinity] can be
                  captured by putting the above to their full range.
                 
                       - MonthMask: Month of the year range | set of Month of the year
                         range
                 
                       - DayMask: Day of the month range | set of Day of the month
                         range
                 
                       - TimeMask: Time of the day range | set of Time of the day
                         range
                 
                 
                  An SLS is active between the Start date and the End date. MonthMask,
                  DayMask and TimeMask MAY be specified to refine the periods of
                  activation of the SLS.
                 
                  MonthMask, DayMask and TimeMask respectively identify the months of
                  the year, the days of the month and the time of the day in which the
                  SLS is valid.
                 
                  For example, to define an SLS from the 01/01/02 at 0:00AM to
                  12/31/05 at 11:59PM, in January, March, and from June to November,
                  only the second half of these months, from 2:00AM to 7:00AM and from
                  8:00PM to 11:00PM, the Service schedule is specified as follow:
                 
                       - Start date: (01012002, 00:00:00AM)
                 
                       - End Date: (12312005, 11:59:59PM)
                 
                       - MonthMask: (01, 03, [06 11])
                 
                       - DayMask: ([15 31]
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 15]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                       - TimeMask: ([02:00:00AM 07:00:00AM], [08:00:00PM 11:00:00PM])
                 
                 
                 
                 3.8 Reliability
                 
                  Reliability indicates the maximum allowed mean downtime per year
                  (MDT) and the maximum allowed time to repair (TTR) in case of
                  service breakdown (e.g. in case of cable cut).
                 
                  The Mean Down Time might be expressed in minutes per year and the
                  Maximum Time To Repair might be expressed in seconds.
                 
                 
                 3.9 Monitoring
                 
                  The monitoring indicates the QoS parameters that have to be
                  monitored and reported. They will be applied on the set of
                  interfaces defined in the Scope block of the SLS Template.
                 
                  The monitoring part is composed of the following parameters:
                 
                       - Delay Measurement Period: Describes the period for measuring
                         the delay.
                 
                       - Delay Reporting: Indicates when the delay measurement reports
                         have to be sent to the customer.
                 
                       - Delay Notification Threshold: Indicates a delay threshold
                         that triggers a notification to the customer if the threshold
                         is reached.
                 
                       - Jitter Measurement Period: Describes the period for measuring
                         the jitter.
                 
                       - Jitter Reporting: Indicates when the jitter measurement
                         reports have to be sent to the customer.
                 
                       - Jitter Notification Threshold: Indicates a jitter threshold
                         that triggers a notification to the customer if the threshold
                         is reached.
                 
                       - Packet Loss Measurement Period: Describes the period for
                         measuring the packet loss.
                 
                       - Packet Loss Reporting: Indicates when the packet loss
                         measurement reports have to be sent to the customer.
                 
                       - Packet Loss Notification Threshold: Indicates a packet loss
                         threshold that triggers a notification to the customer if the
                         threshold is reached.
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 16]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                       - Throughput Measurement Period: Describes the period for
                         measuring the throughput.
                 
                       - Throughput Reporting: Indicates when the packet loss
                         measurement reports have to be sent to the customer.
                 
                       - Throughput Notification Threshold: Indicates a throughput
                         threshold that triggers a notification to the customer if the
                         threshold is reached.
                 
                       - Maximum outage time: Indicates the duration of outage that is
                         allowed for any interfaces described in the Scope. If the
                         value overtakes the threshold, the provider sends a
                         notification describing this event to the customer.
                 
                       - Maximum bandwidth: Indicates the maximum bandwidth that can
                         be used on any interface described in the Scope. If the value
                         overtakes the threshold, the provider sends a notification
                         describing this event to the customer. Maximum Bandwidth
                         utilization reflects the maximum bandwidth usage that is set
                         on each interfaces. It indicates a percentage of the capacity
                         bandwidth of the interface (if speed SNMP variable).
                 
                       - Total number of outage: Indicates for each interface
                         described in the Scope the maximum number of outage
                         authorized. If the value overtakes the threshold, the
                         provider sends a notification describing this event to the
                         customer
                 
                       - Reporting Document Type: Describes which kind of documents
                         have to be sent to the customer (word, excel, HTML, etc.).
                 
                       - Reporting Destination Address: Indicates where the provider
                         has to send the reports (email, postal, fax, etc.).
                 
                 
                 3.10  Others
                 
                  Other parameters such as route, security, scheduled maintenance,
                  etc... remain for further study.
                 
                 
                 
                 4  Service Level Specifications and Per Domain Behaviours
                 
                  Recently the IETF DiffServ working group has documented in an
                  informational RFC [RFC 3086] the concept of DiffServ Per Domain
                  Behaviours (PDBs). Although this [RFC 3086] clearly specifies the
                  difference between PDBs and SLSs, it is worthwile to further
                  elaborate communalities and differences between PDBs and SLSs.
                 
                  We first recall the DiffServ working group terminology.
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 17]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                 4.1 DiffServ Terminology
                 
                 4.1.1 About Service Level Specifications
                 
                  According to the IETF DiffServ working group, a Service Level
                  Agreement (SLA) is "the documented result of a negotiation between a
                  customer and a provider of an IP service that specifies the levels
                  of availability, serviceability, performance, operation or other
                  attributes of the transport service" [DS-TERMS].
                 
                  The SLA contains technical and non-technical terms and conditions.
                  The technical specification of the IP connectivity service is given
                  in Service Level Specifications (SLSs). An SLS "is a set of
                  technical parameters and their values, which together define the
                  service, offered to a traffic stream by a DiffServ domain". SLSs
                  describe the traffic characteristics of IP flows and the QoS
                  guarantees offered by the network to these flows.
                 
                 4.1.2 About Per Domain Behaviors
                 
                  In [RFC 3086] a "Per Domain Behavior is the expected treatment that
                  an identifiable or target group of packets will receive from "edge-
                  to-edge" of a DS domain. A particular PHB (or, if applicable, list
                  of PHBs) and traffic conditioning requirements are associated with
                  each PDB".
                 
                  "A PDB is characterized by specific metrics that quantify the
                  treatment a set of packets with a particular DSCP (or set of DSCPs)
                  will receive as it crosses a DS domain"
                 
                 4.1.3 About SLS and PDB relationships
                 
                  [RFC 3086] clearly states that "there is a clear distinction between
                  the definition of a Per-Domain Behavior in a DS domain and a service
                  that might be specified in a Service Level Agreement. The PDB
                  definition is a technical building block...in configuring DS
                  domains, but the PDB (or PDBs) used by a provider is not expected to
                  be visible to customers any more than the specific PHBs employed in
                  the provider's network would be."
                 
                  However, "the measurable parameters of a PDB should be suitable for
                  use in Service Level Specifications at the network edge."
                 
                  Vice versa, SLSs are "expected to include specific values or bounds
                  for PDB parametersd."
                 
                  Therefore SLSs and PDBs are different concepts but there is clearly
                  a relationship between both. We now further elaborate on this
                  relationship.
                 
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 18]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 4.2 SLS and PDB similarities and differences.
                 
                 4.2.1 A subset of common parameters
                 
                  Both an SLS and a PDB try to capture the technical "terms and
                  conditions" for describing the behavior of an (aggregate) packet
                  stream crossing a (DiffServ) domain. Roughly speaking, if the
                  incoming packet stream behaves appropriately, then the network will
                  treat the packet stream as can be expected (from the SLS or the
                  PDB).
                 
                  Within the context of this draft, the incoming packet stream is
                  identified by a "Flow Identifier", which may be mapped accordingly
                  on PDB classifiers and packet filters. "Behaving appropriately"
                  means that the packet stream should be conformant with the Traffic
                  Envelop (section 3.3). As in a PDB, excess packets are subject to a
                  Traffic Conditioner which may mark, drop or shape these packets.
                 
                  The resulting packet stream, called the foo traffic aggregate in
                  [RFC 3086] is conditioned such that it may expect reasonable
                  treatment in the DS domain. In the context of this draft, the foo
                  traffic aggregate is the "in-profile" stream and should get the QoS
                  performance guarantees as defined in section 3.5.
                 
                  Clearly [RFC 3086] states correctly that (some) paparameters of SLSs
                  should be mapped on PDB characteristics and that (some) PDB
                  parameters should be suitable for SLSs. Obviously the definition of
                  specific PDBs and those of SLS template(s) should be correlated.
                 
                 4.2.2 External interfaces versus intra-domain QoS building blocks
                 
                  Although SLSs and PDBs may have a common parameter subset, the
                  concepts themselves are substantially different.
                 
                  In summary, an SLS and PDB differ along the following lines:
                 
                       - An SLS is an external interface between two legal entities,
                         i.e. a customer and a provider. A PDB is a technical intra-
                         domain QoS building block.
                 
                       - An SLS should be (QoS) technology independent while a PDB is
                         clearly a DiffServ concept. For example, as mentioned in [RFC
                         3086], it should be possible to offer "premium IP services"
                         over a Best-Effort network by  over-provisioning the network
                         resources. Thus delay-sensitive services must not necessarily
                         be mapped on a PDB like a "Virtual Wire", but as in the
                         example above, the service may simply use a best-effort
                         "PDB". There is no one to one mapping; the mapping will be
                         determined by the provider policy. (Analogously the mapping
                         of PDB to PHB is not one-to-one neither).
                 
                       - An SLS is itself a (service) building bilding block for
                         constructing (complex) IP transport services. For example, a
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 19]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                         bi-directional Virtual Leased Line has two SLSs. Multi-edge
                         VPNs may be very complex and require multiple SLSs. In
                         general, an {SLS}-set is needed for describing the technical
                         (QoS & traffic-related) characteristics of an IP transport
                         service.
                 
                       - Finally, an SLS and a PDB also have some distinct parameters.
                         For example, the scope and the service schedule of an SLS
                         specify respectively where (the geographical region) and when
                         this typical service is applicable. It is unlikely that a
                         PDB, as a generic service independent building block, will
                         specify such parameters.
                 
                 
                 4.3 From PHB to value-added IP services: a layered DiffServ view
                 
                  We end this PDB-SLS discussion by a high-level view on a possible
                  layered ("object") model for describing and enabling value-added IP
                  services over DiffServ networks.
                 
                   |--------------------------------------------|
                   | IP Transport Services - SLA                |
                   |       - non-technical terms & conditions   |
                   |       - technical parameters {SLS}-set     |
                   |--------------------------------------------|
                   | Service Level Specifications - SLS         |
                   |       - IP service traffic characteristics |
                   |       - offered network QoS guarantees     |
                   |--------------------------------------------|
                   | Per Domain Behaviors - PDB                 |
                   |       - network QoS capabilities           |
                   |       - DiffServ edge-to-edge aggregates   |
                   |--------------------------------------------|
                   | Per Hop Behaviors - PHB                    |
                   | Traffic Conditioning Block - TCB           |
                   |       - generic router QoS capabilities    |
                   |       - DiffServ edge & core routers       |
                   |--------------------------------------------|
                   | Schedulers (e.g. WFQ, WTP)                 |
                   | Algorithmic Droppers (e.g. RED)            |
                   | Markers (e.g. SRTCM, TRTCM)                |
                   |       - implementation                     |
                   |       - vendor & product specific          |
                   |--------------------------------------------|
                 
                    Figure 1: A layered service-object model for DiffServ
                 
                  Each of the underlying "layers" or "objects" exposes its (QoS)
                  capabilities to the upper layer. Conversely, an upper-layer object
                  makes use of the lower-layer capabilities and therefore should be
                  mapped onto the lower layer objects.
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 20]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  According to [RFC 3086] the specification of a PDB type should
                  e.g.include the (lower-layer) PHB or PHB-group on which the PDB is
                  build.
                 
                  On the othe hand, the mapping of SLSs to PDBs (and therefore PHBs)
                  is a rather unexplored area. For example, it is clear that an SLS is
                  service and customer specific; and is part of the service management
                  system of the provider. A PDB is customer agnostic and could be a
                  prefered object for (longer-term) traffic engineering and resource
                  management.
                 
                  Clearly the mapping from SLS to PDB involves an aggregation policy
                  of the provider, i.e. mapping of customer aware objects to non-
                  custome aware entities. This is a non-straightforward problem. It
                  may be very much determined by the provider policy, but some general
                  "service mapping" and "customer aggregation" guidelines should be
                  very useful.
                 
                  This is for further study.
                 
                 
                 
                 5  Service Level Specification examples.
                 
                  Within this section several instantiations of SLSs are presented to
                  illustrate the potential use of the SLS template defined above.
                 
                 
                 5.1 Virtual Leased Line
                 
                  The following specifies the SLS for a (uni-directional) VLL with
                  quantified throughput guarantee of 1 Mbps, a delay guarantee of 20
                  ms for a 10E-3 quantile and zero packet loss.
                 
                       - Scope: one-to-one communication (Ingress, Egress) specified
                 
                       - Flow identification: (source,destination) IP-addresses,
                         DSCP=EF.
                 
                       - Traffic Conditioning: token bucket (b,r), r = 1 Mbps
                 
                       - Excess Treatment = dropping. Thus only in-profile packets are
                         allowed.
                 
                       - Delay guarantee = (d = 20 ms, t = 5 minutes, q = 10E-3)
                 
                       - Loss guarantee p = 0 (imlying a throughput guarantee R = r)
                 
                       - Service Schedule: may be indicated
                 
                       - Reliability: may be indicated
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 21]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  Notice that in this example, the throughput guarantee is a derived
                  parameter from the packet loss p=0, the the conditioning token
                  bucket parameter r=1 Mbps and the excess treatment=dropping.
                 
                 
                 5.2 Bandwidth Pipe for data-services
                 
                  The following SLS specifies a bandwidth pipe with a strict
                  throughput guarantee, but with only a loose requirements for packet
                  loss, i.e. "low". Thus, the SLS only mentions the scope (pipe), the
                  Flow Id and a throughput guarantee. Remark that there are now
                  traffic conformance parameters (and consequently no excess treatment
                  indication).
                 
                       - Scope: one-to-one communication (Ingress, Egress) specified
                 
                       - Flow identification: (source,destination) IP-addresses
                 
                       - Throughput guarantee R = 1 Mbps
                 
                       - Service Schedule: may be indicated
                 
                       - Reliability: may be indicated
                 
                  Although there is no (explicit) traffic conditioning agreement
                  between the customer and the network operator (i.e. such parameters
                  are not mentioned in the SLS), the operator is likely to protect his
                  network by implementing a traffic conditioner token bucket (b,r). If
                  the operator can guarantee a zero packet loss for the bandwidth
                  pipe, then the token rate equals the throughput guarantee. However,
                  the SLS can also be met by the operator without such a stringent
                  loss requirement, say p = 10E-5. In this case the token rate is
                  derived from the throughput guarantee and the loss probability:
                 
                       token rate r = R / (1-p)
                 
                  The in-profile packet stream (according to the conditioner (b,r))
                  has a throughput guarantee of R = r * (1-p) = 1 Mbps.
                 
                  Further, it is up to the operator's policy whether or not excess
                  traffic (again according to the operator's conditioner (b,r), which
                  is not mentioned in the SLS agreement) is allowed or not in his
                  network.
                 
                 
                 5.3 Minimum rate guarantee with allowed excess
                 
                  The following SLS could be applied for bulk FTP traffic that
                  requires a minimum throughput, but would take everything it can get
                  (TCP). Also adaptive applications, like video streaming, that
                  however require a minimum throughput for the service.
                 
                       - Scope: one-to-one (Pipe)
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 22]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                       - Flow identification: e.g. DSCP-value indicating a possible
                         AF-PBH.
                 
                       - Traffic Conformance Parameters: (b,r) MUST be indicated
                 
                       - Excess Treatment: Remarking MUST be indicated (excess is
                         given a higher drop precedence)
                 
                       - Performance guarantees: guaranteed throughput R = r.
                 
                 
                 5.4 Qualitative Olympic services
                 
                  The following SLS is meant for the Olympic Service. It could be used
                  for differentiating applications such as web-browsing and e-mail
                  traffic.
                 
                  SLS 1 (on-line web-browsing)
                       - Scope: one-to-one (pipe) or one-to-many (hose)
                 
                       - Flow identification: MAY be indicated
                 
                       - Traffic Conformance Parameters: token parameters (b,r) The
                         token bucket rate r indicates an (average) maximum Committed
                         Information Rate (CIR) for which "better-than-best-effort"
                         treatment will be applied.
                 
                       - Excess Treatment: remarking.
                 
                       - Performance Parameter: Delay and Packet loss are indicated as
                         "low": gold/green class
                 
                  SLS2 : (background e-mail traffic)
                 
                       This is identical to SLS1 but targeting the silver/green class.
                 
                 
                 5.5 The Funnel service
                 
                  The service offered by the funnel model is primarily a protection
                  service: the customer wants to set a maximum on the amount of
                  traffic (characterized by a DSCP) entering his network. It could
                  e.g. be used for business customers to restrict the amount of web
                  browsing traffic entering their network.
                 
                                 /---------------\
                                 |Network   _____|______ B
                                 |    _____/     |
                      A__________|___.___________|______ C
                        /_____   |    _____      |
                        \a(out)  |         \_____|_______D
                                 \---------------/
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 23]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                 
                              Figure 2: Funnel model
                 
                  In [Figure 2], the customer A requires that the traffic entering his
                  network from B,C and D does not exceed the rate a_out.
                 
                       - Scope: Funnel (N|all,1).
                 
                       - Flow identification: DSCP MUST be indicated. The filter (see
                         below) is applied to all traffic characterized by the DSCP -
                         value.
                 
                       - Traffic Conformance Parameters: (b, r) MUST be indicated. The
                         token bucket parameters indicate the maximum allowed
                         throughput (r = a_out) towards the customer network on the
                         specified egress interface. This maximum or filter is applied
                         to all packets marked with the DSCP-value indicated above.
                 
                       - Excess treatment: dropping (this is actually the service
                         offered by the network).
                 
                       - Performance Parameter: not specified.
                 
                 
                 5.6 Best effort traffic
                 
                       - Scope : all models
                 
                       - Flow identification : none
                 
                       - Traffic Conformance Parameters: if not indicated, then the
                         full link capacity is allowed
                 
                       - Excess Treatment: not specified
                 
                       - Performance Parameters: none
                 
                       - Service Schedule: may be indicated.
                 
                       - Reliability: may be indicated.
                 
                 
                 
                 6  SLS negotiation requirements
                 
                  The SLS negotiation protocol is for further study.
                 
                 
                 
                 7  Security Considerations
                 
                  The information which will yield the instantiation of an SLS
                  template to address the specific requirements of a customer in terms
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 24]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  of the quality associated to the service it has subscribed to may
                  require the activation of security features so that:
                 
                       - Identification and authentication of the requesting entity
                         needs to be performed;
                 
                       - Identification and authentication of the peering entities
                         which will participate in the SLS negotiation process needs
                         to be performed;
                 
                       - Preservation of the confidentiality of the information to be
                         conveyed during the SLS negotiation and instantiation
                         procedures between the peering entities is a MUST.
                 
                 
                 8  Acknowledgment
                 
                  Part of this work has been funded under the European Commission 5th
                  framework IST program.
                 
                  The authors would like to acknowledge all their colleagues in the
                  TEQUILA project for their input and reflection on this work.
                 
                  The authors also would like to acknowledge Werner Almesberger,
                  Marcus Brunner, Stefaan De Cnodder, Stefano Salsano, Alberto
                  Kamienski and Abdul Malick for their useful comments and suggestions
                  on the mailing list sls@ist-tequila.org and during private
                  conversation.
                 
                 
                 References
                 
                  [TEQUILA]   IST-Tequila project http://www.ist-tequila.org/
                 
                  [RFC 1661]  "The Point-to-Point Protocol (PPP)", W. Simpson,
                              http://www.ietf.org/rfc/rfc1661.txt?number=1661
                 
                  [RFC 2205]  "Resource ReSerVation Protocol (RSVP)- Version 1
                              Functional Specification", R. Braden et al.
                              http://www.ietf.org/rfc/rfc2205.txt?number=2205
                 
                  [RFC-2211]  "Specification of the Controlled-Load Network Element
                              Service", J. Wroclawski, RFC 2211, September 1997.
                 
                  [RFC-2212]  "Specification of Guaranteed Quality of Service", S.
                              Shenker, C. Partridge, R. Guerin, RFC 2212, September
                              1997.
                 
                  [RFC 2474]  "Definition of the Differentiated Services Field (DS
                              Field) in the IPv4 and IPv6 Headers", K.Nichols, S.
                              Blake, F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt
                 
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 25]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  [RFC 2475]  "An Architecture for Differentiated Services", S. Blake,
                              D. Black, M.Carlson,E.Davies,Z.Wang,W.Weiss,
                              www.ietf.org/rfc/rfc2475.txt
                 
                  [RFC 2597]  "Assured Forwarding PHB Group", F. Baker, J. Heinanen,
                              W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt
                 
                  [RFC 2598]  "An Expedited Forwarding PHB", V.Jacobson, K.Nichols,
                              K.Poduri, www.ietf.org/rfc/rfc2598.txt
                 
                  [RFC 2638]  "A Two-bit Differentiated Services Architecture for the
                              Internet", K. Nichols, V. Jacobson, L. Zhang, July 1999.
                              www.ietf.org/rfc/rfc2638.txt
                 
                  [RFC 2698]  "A Two Rate Three Color Marker." J. Heinanen, R. Guerin.
                              September 1999. www.ietf.org/rfc/rfc2698.txt
                 
                  [RFC 3086]  "Definition of Differentiated Services Per Domain
                              Behaviors and Rules for their specification". K.
                              Nichols, B. Carpenter April 2001
                              http://www.ietf.org/rfc/rfc3086.txt
                 
                  [DS-MODEL]  "A Conceptual Model for Diffserv Routers", Y. Bernet et
                              al., draft-ietf-diffserv-model-06.txt, Work in Progress,
                              February 2001
                 
                  [DS-TERMS]  "New Terminology and Clarifications for Diffserv", D.
                              Grossman, draft-ietf-diffserv-new-terms-08.txt, work in
                              progress, January 2002
                 
                 
                 
                 Author's Addresses
                 
                  Danny Goderis
                  Alcatel Corporate Research Center
                  Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
                  Phone : 32-3-240-7853
                  Fax   : 32-3-240-9932
                  E-mail: Danny.Goderis@Alcatel.be
                 
                  Yves T'Joens
                  Alcatel Corporate Research Center
                  Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
                  Phone : 32-3-240-7890
                  Fax   : 32-3-240-9932
                  E-mail: Yves.TJoens@Alcatel.be
                 
                  Sven Van den Bosch
                  Alcatel Corporate Research Center
                  Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
                  Phone : 32-3-240-8103
                  Fax   : 32-3-240-9932
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 26]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  E-mail: sven.van_den_bosch@alcatel.be
                 
                  Olivier Poupel
                  Alcatel Research & Innovation
                  Route de Nozay, F-91461 Marcoussis, France
                  Phone : 33-1-69-63-47-07
                  Fax   : 33-1-69-63-44-50
                  E-mail: Olivier.Poupel@alcatel.fr
                 
                  Christian Jacquenet
                  France Telecom Research and Development
                  FT R&D /DMI
                  42, rue des Coutures
                  BP6243
                  14066 CAEN CEDEX 04
                  France
                  Phone : +33 2 31 75 94 28
                  Fax   : +33 2 31 73 56 26
                  E-mail: christian.jacquenet@francetelecom.fr
                 
                  George Memenios
                  Research Associate, Telecommunications Laboratory NTUA
                  Heroon Polytechniou 9
                  157 73 Zografou, Athens, Greece
                  Phone : +30 1 772 1494
                  Fax   : +30 1 772 2534
                  E-mail: gmemen@telecom.ntua.gr
                 
                  George Pavlou
                  Centre for Communication Systems Research (CCSR)
                  Univ. of Surrey, Guildford, Surrey GU2 7XH, UK
                  Phone : +44 (0)1483 259480
                  Fax   : +44 (0)1483 876011
                  E-mail: G.Pavlou@eim.surrey.ac.uk
                 
                  Richard Egan
                  Thales Research Ltd
                  Worton Drive
                  Worton Grange Industrial Estate
                  Reading, Berkshire RG2 OSB
                  Phone : +44 118 986 8601
                  Fax   : +44 118 923 8399
                  E-mail : richard.egan@uk.thalesgroup.com
                 
                  David Griffin
                  Department of Electronic and Electrical Engineering
                  University College London
                  Torrington Place, London WC1E 7JE, UK
                  Phone : +44 (0)20 7679 3557
                  Fax   : +44 (0)20 7388 9325
                  E-mail: D.Griffin@ee.ucl.ac.uk
                 
                  Panos Georgatsos
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 27]


                  Internet Draft    Service Level Specification        February 2002
                                      Semantics and Parameters
                 
                  Algosystems S.A.
                  4, Sardeon str., 172 34 Athens, Greece
                  Phone : 30-1-93-10-281
                  Fax :   30-1-93-52-873
                  E-mail: pgeorgat@algo.com.gr
                 
                  Leonidas Georgiadis
                  Aristotel Univ. of Thessaloniki, Faculty of Engineering
                  School of Electrical and Computer Engineering, Telecommunications
                  Dept.
                  PO Box 435, Thessaloniki, 54006, Greece
                  Phone : 30-31-996385
                  Fax   : 30-31-996312
                  E-mail: leonid@eng.auth.gr
                 
                 
                 
                 Full Copyright Statement
                 
                  Copyright (C) The Internet Society (2001).  All Rights Reserved.
                 
                  This document and translations of it may be copied and furnished to
                  others, and derivative works that comment on or otherwise explain it
                  or assist in its implementation may be prepared, copied, published
                  and distributed, in whole or in part, without restriction of any
                  kind, provided that the above copyright notice and this paragraph
                  are included on all such copies and derivative works.  However, this
                  document itself may not be modified in any way, such as by removing
                  the copyright notice or references to the Internet Society or other
                  Internet organizations, except as needed for the purpose of
                  developing Internet standards in which case the procedures for
                  copyrights defined in the Internet Standards process must be
                  followed, or as required to translate it into languages other than
                  English.
                 
                  The limited permissions granted above are perpetual and will not be
                  revoked by the Internet Society or its successors or assigns.
                 
                  This document and the information contained herein is provided on an
                  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
                  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
                  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
                  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
                  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
                 
                  TEQUILA Consortium   Expires August - 2002               [Page 28]