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

Versions: 00 01 02 03                                                   
                                                  Danny Goderis, Alcatel
                                                   Yves T'joens, Alcatel
                                 Christian Jacquenet, France Telecom R&D
                                                   George Memenios, NTUA
                                                     George Pavlou, UniS
                                        Richard Egan, Racal Research Ltd
                                                      David Griffin, UCL
                                           Panos Georgatsos, AlgoSystems
                                 Leonidas Georgiadis, Univ. Thessaloniki
                                                    Pim Van Heuven, IMEC

INTERNET DRAFT <draft-tequila-sls-00.txt>
                                                          November, 2000
                                                      Expires March 2001


Service Level Specification Semantics and Parameters.

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 included in
   Service Level Specifications (SLS, [RFC 2475], [DS-TERMS]) when
   considering the deployment of value-added IP service offerings over
   the Internet. Such IP service offerings can be provided together with
   a given quality of service (QoS), which is expected to be defined in
   such SLS, from a technical perspective. Since these IP services are



TEQUILA consortium         Expires March 2001                   [Page 1]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   likely to be provided over the whole Internet, their corresponding
   QoS will be based upon a set of technical parameters that both
   customers and services providers will have to agree upon. From this
   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 service provider or amongst services providers within
   the context of processing an SLS;

   - 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

   1.   Introduction
   1.1  Motivation
   1.2  Objective
   2.   Basic assumptions and terminology
   3.   SLS content & template
   3.1. Scope
   3.2. Flow Description
   3.3. Traffic Envelop and Traffic Conformance
   3.4. Excess Treatment
   3.5. Performance Guarantees
   3.6. Service Schedule
   3.7. Reliability
   4.   Service Level Specification examples
   4.1. Virtual Leased Line
   4.2. Bandwidth Pipe for data-services
   4.3. Real-time micro-flows
   4.4. Minimum rate guarantee with allowed excess
   4.5. Qualitative Olympic Services
   4.6. The funnel services
   4.7. Best Effort Traffic
   5.   SLS negotiation requirements
   6.   Security considerations
   7.   Acknowledgements



0. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",



TEQUILA consortium         Expires March 2001                   [Page 2]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 ([RFC-2119]).

1. Introduction

1.0 Changes w.r.t. the previous version

   This is the second version of an Internet Draft of the issue of
   Service Level Specifications (SLS). The first version <draft-
   tequila-sls-00.txt

1.1 Motivation

   This document is presented to the IETF community to gauge the
   interest for advancing the work on the specification of a Service
   Level Specification (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 service providers try to currently address,
   especially when considering the deployment of such services over
   administrative domains. From this perspective, it seems useful to
   consider the specification of an SLS template these service providers
   would agree upon, so as to enforce an inter-domain QoS policy. This
   is the basic motivation for presenting this document to the IETF
   community.

   Mailing list: sls@ist-tequila.org

   This list provides the medium for discussion on SLS template
   definition and SLS negotiation protocol requirements. One of its
   objectives is to gauge interest for the related work within the IETF
   on these specific topics.

   To subscribe to the list send an email to - majordomo@ist-tequila.org
   - with the sentense - subscribe sls@ist-tequila.org - in the body and
   nothing in the subject line.

1.2 Objective

   This document presents an outline for the definition of the Service
   Level Specification parameters, the semantics that go behind this
   representation, and some early ideas on the requirements on
   negotiation of SLSs.

   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



TEQUILA consortium         Expires March 2001                   [Page 3]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   level of automation and dynamic negotiation of Service Level
   Specifications between customers and 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. The automation in itself is e.g. necessary to
   allow roaming (dial-in) and to enable mobile users to have access and
   negotiate a transport Service Level, independent of their point of
   attachment to the network.

   Second, the design and the deployment of Bandwidth Broker
   capabilities [TWOBIT] in a multi-vendor 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
      to the IP network managed by the service provider);

      - within an administrative domain (for intra-domain SLS
      negotiation purposes);

      - 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. E.g, the negotiation could make use of various other
   protocols such as http, rsvp, IPCP, DHCP, etc. The latter is ffs, and
   as such not part 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). 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:

      - SLSs depicting qualitative services should yield the
      specification of relative QoS indicators, such as a low IP



TEQUILA consortium         Expires March 2001                   [Page 4]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


      datagram loss ratio. 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 assumptions 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].

   Customers of such services include Internet Service Providers (ISP),
   who may well establish QoS-based peering agreements between
   themselves, and usual customers of ISPs, like those who compose both
   the residential and the corporate market.

   The terminology used in this draft is in agreement with the DiffServ
   Working Group terminology introduced and specified in [RFC-2475],
   section 1.2 "terminology".

3. SLS content & template

   The following describes the attributes of the Service Level
   Specification. It should be remarked that some SLS-features are not
   yet specified in this draft. For example, the Internet2 QoS Working
   Group specifies an SLS for the EF-based Premium Service [QBONE]. One
   of the attributes, i.e. "Route", is used for inter-domain routing
   aspects. This and other SLS features are for further study.

3.1. 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.




TEQUILA consortium         Expires March 2001                   [Page 5]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   An SLS is associated with uni-directional traffic flows. Note however
   that this does not exclude the provisioning by providers of
   bidirectional transport service contracts, 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

      - (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 description. (see section 3.2 and 3.3). If the
   ingress is a single interface identifier, then the traffic envelop
   and flow description concerns the incoming IP packet stream at the
   unique ingress point. If (only) the egress is a single interface,



TEQUILA consortium         Expires March 2001                   [Page 6]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   i.e. (N|any,1), then the traffic envelop and flow description
   concerns the outgoing (aggregate) traffic on the egress link. More
   details about the latter can be found in the example 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. Fore example a
   layer-two identifier in case of e.g. ethernet, or for unnumbered
   links like in e.g. PPP(Point-to-Point Protocol, [RFC-1661])-based
   access configurations. The interface identifier(s) may also
   implicitly be derived from the source or destination address
   information in the Flow Description field (see next section 3.2)
   combined with e.g. BGP4 (Border Gateway Protocol, version 4, [RFC-
   1771]) routing information.

3.2. Flow Description

   The flow description of an SLS associated to a given service offering
   indicates for which IP packets the QoS guarantees for that specific
   service offering is to be enforced.

   A flow description identifies a stream of IP datagrams sharing at
   least one common characteristic. An SLS contains one (and only one)
   flow description, which MAY formally be specified by providing one or
   more of the following attributes:

   flow description = (Differentiated Services information, source
   information, destination information, application information)

      - Differentiated Services information = DSCP value | set of DSCP
      values | any

      The Differentiated Services Code Point (DSCP) IP header field is
      defined in [RFC-2474].

      - Source information = source address | set of  source addresses |
      source prefix | set of source prefixes | any

      - Destination information = destination address | set of
      destination addresses | destination prefix | set of destination



TEQUILA consortium         Expires March 2001                   [Page 7]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


      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 description may be expressed by information attributes
   related to the source/destination nodes, the application or the DS
   field in the IP header. The flow description provides the necessary
   information for classifying the packets at a DS boundary node.

   This datagram classification can either be Behaviour Aggregate (BA)
   or Multi-Field (MF)classification based.

   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 description is e.g.
   specified by a set of two IP source addresses, then any packet with
   either of the two concerned source addresses belongs to the IP packet
   stream identified by this flow description.

   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 (description) packet stream (analogous
   to the example above with the IP source addresses). 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 description using three
   DSCP-values, indicating the three drop precedences levels,
   respectively colored in green, yellow and red.

   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.

   Finally note also that the IP routing scheme MAY put restrictions on
   combining scope and flow description within an SLS.



TEQUILA consortium         Expires March 2001                   [Page 8]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   In general, if (only) the flow description 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 use. Indeed, it is the
   responsibility of the service provider to define the most appropriate
   route for this traffic, by enforcing the corresponding traffic
   engineering and routing policy. Thus, the (ingress, egress)
   information (which is in this case not in the SLS) is then derived
   from the flow description and the routing policy of the service
   provider.

   On the other hand, if the flow description AND scope are specified in
   the SLS, respectively by the pairs (IP-src, IP-dest) and (IP-ingr,
   IP-egr) 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-src to
   IP-dest.

   Further routing considerations are outside the scope of this
   document.

   Finally remark that the exclusion of the many-to-many communication
   scope model puts similar constraints on the source/destination fields
   of the Flow Description.

3.3 Traffic Envelop and Traffic Conformance

   The traffic envelop describes the traffic (conformance)
   characteristics of the IP packet stream identified by the flow
   description. 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 as 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 description) will have to comply with, thus



TEQUILA consortium         Expires March 2001                   [Page 9]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   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.

   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 Transport 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 [REF] is based on two token



TEQUILA consortium         Expires March 2001                  [Page 10]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


      buckets with rates r1 and r2 (larger 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.


3.4. Excess Treatment

   This section describes how the service 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 Traffic Conformance Algorithm are (re-)
      marked with a particular DSCP-value (yellow or red). The extra
      parameter is the DSCP.


3.5. Performance Guarantees

   The performance parameters describe the service guarantees the
   network offers to the customer for the packet stream described by the
   flow description and over the geographical/topological extent given



TEQUILA consortium         Expires March 2001                  [Page 11]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   by the scope.

   There are four performance parameters:

      - delay, time interval, optional quantile

      - jitter, time interval, optional quantile

      - packet loss, time interval

      - throughput, time interval

   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 description. 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, measured over (any) time period with a length equal to the
   (indicated) time interval.

   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, time
   interval = 5 minutes, 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; and this for any measurement period of
   5 minutes.




TEQUILA consortium         Expires March 2001                  [Page 12]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   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 (and including) ingress and egress
   packet loss = -------------------------------------------------------
                 offered (injected) packets at ingress

   The ratio is measured over (any) time period with a length equal to
   the (indicated) time interval.


   The throughput is the rate measured at egress counting all packets
   identified by the flow description. 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.


   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) troughput 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.



TEQUILA consortium         Expires March 2001                  [Page 13]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   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 described by the SLS is said to be quantitative
   IF at least one of the 4 performance parameters is quantified.


   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



TEQUILA consortium         Expires March 2001                  [Page 14]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


      - 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 provider policy (e.g. high = 2 x  medium ; medium = 2 x low).

   The above taxonomy yields the following combinations of qualitative
   services.

    -------------------------------------------------------
    |\ 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    |
    |------------------------------------------------------|
                            Combinations table

   The service guarantee described 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 described by the SLS is said to be best-effort
   if it is NOT quantified nor qualified.


3.6. Service schedule

   The service schedule indicates the start time and end time of the
   service, i.e. when is the service available.

   This might be expressed as collection of the following parameters:

      - Time of the day range

      - Day of the week range

      - Month of the year range

   Some examples are:
      - Time of the day range
        08h00-18h00



TEQUILA consortium         Expires March 2001                  [Page 15]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


      - Day of the week range
        A single day

        A group of sequential days

      - Month of the year range
        A single month

        A group of sequential months

      - Year range
        A single year

        A group of sequential years

   Remark: service schedule "from now on" [now, infinity] can be
   captured by putting the above to their full range.

3.7. 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.8 Others

   Other parameters such as route, reporting guarantees, security,
   scheduled maintenance, etc... remain for further study.

4. Service Level Specification examples.

   Within this section a number of example instantiations of SLSs are
   presented to illustrate the potential use of the SLS template defined
   above.

4.1. Virtual Leased Line

   The following specifies the SLS for a (uni-directional) VLL with
   quantified throughput guarantee of e.g 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 description: (source,destination) IP-addresses, DSCP=EF.




TEQUILA consortium         Expires March 2001                  [Page 16]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   - 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

   Notice that in this example, the throughput guarantee is a derived
   parameter from the packet loss p=0, the conditioning token bucket
   parameter r=1 Mbps and the excess treatment=dropping.

4.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 mentiones the scope (pipe), the flow
   description 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 description: (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. 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)




TEQUILA consortium         Expires March 2001                  [Page 17]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   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.

4.3. Real-time micro-flows

   - Scope: one-to-one communication (Ingress, Egress) specified

   - Flow description: (source IP-address, destination IP-address,
   source port number, destination port number, protocol)

   - Traffic Conditioning: token bucket (b,r), peak rate p= r = 64 Kbps

   - Excess Treatment = dropping.

   - Performance Parameters: delay = 10 msec, packet loss = 10E-6,
   guaranteed throughput R ~ r.

4.4 Minimum rate guarantee with allowed excess

   The following could be 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)

   - Flow description: e.g. DSCP-value indicating a possible AF-PHB.

   - 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.


4.5. 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-



TEQUILA consortium         Expires March 2001                  [Page 18]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   many (hose)

   - Flow description: 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.

4.6. 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
                  \---------------/

                          Figure 4: Funnel model

   In [Figure 4], customer A requires that specific traffic entering his
   network from B,C and D does not exceed the rate a_out.

   - Scope: Funnel (N|all,1).

   - Flow description: 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-



TEQUILA consortium         Expires March 2001                  [Page 19]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   value indicated above.

   - Excess treatment: dropping (this is actually the service offered by
   the network).

   - Performance Parameter: not specified.


4.7. Best effort traffic

   - Scope : all models

   - Flow description : 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.

5. SLS negotiation requirements

   [This section is informational and preliminary. More detailed study
   is required.]

   A major goal of the availability of an SLS template is helping in the
   deployment of dynamical SLS negotiation procedures between customer
   and providers or between providers. This draft only discussed the SLS
   template and its basic contents. The SLS negotiation protocol is for
   further study. The following lists a number of conditions which
   should be met by a (to be defined) SLS negotiation protocol.

   The SLS negotiation protocol MUST allow for:

   - Original service requests, according the components of the
   specified SLS.

   - Service acknowledgement (ACK), indicating agreement with the
   requested service level.

   - Service rejection (NAK) but indicating the possibility of offering
   a closely related service (or indication of alternative DSCP to use
   for a particular service). The reply message may indicate the related



TEQUILA consortium         Expires March 2001                  [Page 20]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   offering by overwriting the proposed SLS attributes (hints).

   - Service rejection (REJECT) indicating  incapability of providing
   the service.

   - The ACK/NACK procedures require a reliable transport mode for such
   a negotiation protocol.

   - Service modification from both user and provider.

   The following are further requirements for the overall network
   architecture which SHOULD be fulfilled.

      - The protocol should be able to interact with feedback of events
   related to the service. For example performance degradation MAY
   result in re-negotiation of the SLS.

      - The  protocol should preferentially make use of / be an
   extension of existing specifications protocol design work available
   such as RSVP ([RFC-2205]) or PPP/IPCP ([RFC-1661]).


6. Security considerations

   The information which will yield the instantiation of an SLS template
   to address the specific requirements of a customer in terms 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.


7. 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.



TEQUILA consortium         Expires March 2001                  [Page 21]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   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-1771]      A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T.
   Li. March 1995. http://www.ietf.org/rfc/rfc2205.txt?number=1771

   [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]      J. Wroclawski, "Specification of the Controlled-Load
   Network Element Service", RFC 2211, September 1997.

   [RFC-2212]      S. Shenker, C. Partridge, R. Guerin, "Specification
   of Guaranteed Quality of Service", 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

   [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 2698] "A Two Rate Three Color Marker." J. Heinanen, R. Guerin.
   September 1999. www.ietf.org/rfc/rfc2698.txt

   [DS-MODEL] "A Conceptual Model for Diffserv Routers", Y. Bernet et
   al., draft-ietf-diffserv-model-03.txt, Work in Progress, May 2000

   [DS-TERMS] "New terminology for diffserv", D. Grossman, draft-ietf-
   diffserv-new-terms-02.txt, work in progress




TEQUILA consortium         Expires March 2001                  [Page 22]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   [QBONE] "Qbone Architecture (v1.0), Ben Teitelbaum (1999),
   http://www.internet2.edu/qos/wg/papers/qbArch/

   [TWOBIT] "A Two-bit Differentiated Services Architecture for the
   Internet", ftp://ftp.ee.lbl.gov/parpers/dsarch.pdf, 1997

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.

Authors Addresses

   Danny Goderis
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Tel : +32 3 240 7853
   Fax : +32 3 240 9932
   E-mail: Danny.Goderis@Alcatel.be








TEQUILA consortium         Expires March 2001                  [Page 23]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   Yves T'Joens
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium.
   Tel : +32 3 240 7890
   Fax : +32 3 240 9932
   E-mail: Yves.TJoens@Alcatel.be

   Christian Jacquenet
   France Telecom Research and Development (FT R&D)
   Rue des Coutures 42, 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
   Tel : +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
   Tel : +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, UK
   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
   Tel : +44 (0)20 7679 3557
   Fax : +44 (0)20 7388 9325
   E-mail: D.Griffin@ee.ucl.ac.uk









TEQUILA consortium         Expires March 2001                  [Page 24]


Internet Draft          draft-tequila-sls-00.txt           October, 2000


   Panos Georgatsos
   Algosystems S.A.
   Sardeon str. 4, 172 34 Athens, Greece
   Tel : +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
   Tel : +30 31 996385
   Fax : +30 31 996312
   E-mail: leonid@eng.auth.gr

   Pim Van Heuven
   Inter-University Micro-Electronics Centre
   Tel : +32 9 267 3592
   E-mail: pvheuven@intec.rug.ac.be
































TEQUILA consortium         Expires March 2001                  [Page 25]