R. Rajan
                                                     AT&T Labs Research
                                                             E. Celenti
                                                              AT&T Labs
                                                               S. Dutta
Internet Draft                                                AT&T Labs
Document: <draft-somefolks-sls-00.txt>                        November 2000



      Service Level Specification for Inter-domain QoS Negotiation

                     < draft-somefolks-sls-00.txt >


Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [1].


   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 describes a structure for defining Service Level
   Specifications for QoS negotiation over IP networks. The high level
   schema described in this document is intended for use during the
   process of QoS negotiation between a customer entity and a provider
   entity. The purpose of this document is to provide a vendor-
   independent lexicon and extensible structure that can be used to
   describe services and instantiate them.

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 [2].


1. Introduction
   Quality of Service (QoS) refers to the ability of a network to
   provide differentiated treatment to selected network traffic over
   various underlying technologies such as frame relay, ATM, Ethernet,
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   SONET, and IP-routed networks.  The demand for QoS is growing
   rapidly among end-users and service providers are upgrading their
   infrastructure to deliver these capabilities. A number of
   technologies and protocols - DiffServ, RSVP, COPS, policy services,
   etc. - have emerged to help the transition from best-effort
   transport to a QoS capable infrastructure. A major component of the
   versatility afforded by QoS is the ability of the network to provide
   different classes of services based on application and user
   requirements. There are various ways to provide QoS guarantees and
   it is a matter of tradeoffs between overhead, strictness of
   guarantees, and efficient resource utilization.  In this submission
   we exclusively focus on IP QoS within the framework of
   Differentiated Services [RFC 2475].

   This draft is motivated by the need to automate the creation and re-
   negotiation of QoS services, i.e., the need for customers to create,
   modify and manage QoS pipes or hoses across the provider's backbone
   on the fly. Irrespective of whether or not such negotiations are
   human initiated, network management systems must be capable of
   participation in negotiation, translation of negotiated agreements
   to device configurations, and monitoring the network for
   conformance. Here, we are concerned with the component of automation
   relating to the interaction of the customer and provider domains,
   and NOT with network configuration and monitoring within a domain.

   A simple model for this interaction, presented in Figure 1, is to
   consider independent policy servers in the customer and provider
   ([SLSFRAME]) networks that negotiate the attributes of service
   instantiation. (Naturally, "customer" and "provider" are roles
   played by negotiating entities in this process, and are not to be
   confused with "end-users" or "carriers". For instance, two carriers
   negotiating peering agreements may each play the role of the other's
   customer.)

   The customer declares its QoS requirements and the provider decides
   whether or not it can fulfill them. During this process (that
   corresponds to the service invocation defined in [SLSFRAME]), each
   entity takes responsibility for checking the correctness of the
   transaction, and for configuring and monitoring devices in its
   domain, say by translating negotiated parameters into policy rules
   to be evaluated by the Policy Decision Point (PDP) and hence
   distributing them to enforcement points (see [TERMS] for policy
   concepts) using COPS (see [COPS]).

   There are many ways that this transaction may be structured. As an
   illustration to help motivate the concepts in this document, we
   present one negotiation model in Figure 2. In this example, the
   provider first presents the attributes of the offered service to the
   customer in the form of a Service Template Specification (STS). The
   STS carries the provider-specified attributes of the service,
   instructs the customer about which attributes are customer
   specified, and lays some limitations on what values of the latter
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   are acceptable. For instance, the provider may specify that the
   delay encountered by packets of a Gold service will not exceed 20

   Customer                             Provider
   ---------                           ---------
   |       |     Service Negotiation   |       |
   |       |<----------------------- > |       |
   |       |                           |       |
   ---------                            ---------
       |                                   |
       |                                   |
       |                                   |
       V                                   V
   --------- Customer's                --------- Provider's
   |       | Policy                    |       | Policy
   |       | Decision                  |       | Decision
   |       | Point (PDP)               |       | Point (PDP)
   --------|                           ---------
       |                                   |
       | COPS/CLI                          | COPS/CLI
       |                                   |
       V                                   V
   --------- Customer's                --------- Provider's
   |       | Policy                    |       | Policy
   |       | Enforcement               |       | Enforcement
   |       | Point (PEP)               |       | Point (PEP)
   ---------                           ---------
   Figure 1: Example Architecture for Service Negotiation and
   Fulfillment

   milliseconds, and restrict the bandwidth choices of the customer to
   a maximum of 5 Gigabytes/second. The customer fills in the
   parameters needed to complete the service description and sends the
   request back to the provider as a Service Instance Specification
   (SIS.) For instance, the customer may declare in the SIS the need
   for 3 Mbps of bandwidth. The provider is now able to accept or to
   reject the customer's request. The provider may generate further
   updates about the state of the service or its performance.

              (STS)
   P -----------------------> C   - the provider sends the STS to the
                                  Customer

   (SIS)
   P <------------------------ C  - the customer responds by sending
                                  the SIS to the provider

           Accept/Reject
   P -----------------------> C   - the provider decides whether the
                                  customer's request is accepted or not
               Update
   P  -----------------------> C  - the provider issues updates
                                  to the customer.
                     <draft-somefolks-sls-00.txt>    <November> <2000>


              Renegotiate
   P   <---------------------- C  - the customer requests a different
                                  level of service

           Figure 2: Example of the Service Negotiation Process

   Needless to say, the above process can be too complex or too
   simplistic depending on the negotiating entities and operational
   environment. For instance, a VOIP gateway configured to deliver
   high-quality service to a particular user may dispense with all but
   the SIS carrying the bandwidth desired. Another service may dispense
   with updates from the provider.  Yet another service may not be re-
   negotiable. And so on.

   Irrespective of complexity of the service negotiation process
   ([SLSFRAME]), there are a number of concepts, entities and
   attributes that can be used and reused in different aspects of the
   service negotiation process. The Service Level Specification (SLS)
   is intended as a lexicon that defines parameters, and also a schema
   that assigns semantics to valid combinations of these parameters.
   Information models and schema representing them are required for
   systematically understanding and documenting QoS service
   requirements and implementation, for automating the service
   negotiation process to whatever degree desired, and for making use
   of directories/databases to store persistent information about
   customer service subscription and network configurations. This
   document presents approach toward structuring the information needed
   for defining Service Level Specifications for QoS negotiation.


   The design of the SLS in this document is based on the following
   principles:

   1. The SLS should allow different instantiations in different
   languages.  For instance, an XML representation would be useful for
   a web-based transaction, while COPS PIBs may be ideal if the
   negotiating entities are themselves PDPs.

   2. The SLS should allow service negotiations at different levels of
   complexity, and be friendly to as many differrent negotiating
   protocols as possible. Examples of such protocols are HTTP, COPS,
   Diameter and RSVP.

   3. The SLS should NOT standardize services. Vendors and customers
   should. Inasmuch as there are standard services such as those based
   on the Assured Forwarding PHB [RFC-2597] or the Expedited Forwarding
   PHB [RFC-2598], the SLS should be capable of representing them. The
   SLS should be extensible to allow vendors to define their own unique
   offerings.

   4. The SLS should allow a simple STS or SIS to be represented
   simply, while being up to the task of representing a STS or SIS
   based on complex semantics.
                     <draft-somefolks-sls-00.txt>    <November> <2000>





2. Terms and Usage
   A. DiffServ SLS
   In this work, we exclusively focus on IP QoS enabled services on the
   IP network, by building on the DiffServ model as a starting point.
   As a result, it only discusses requirements for a Layer 3 network
   only, without any attempt to map Layer 3 Services to Layer 2 QoS
   mechanisms. This does not lose extensibility or applicability.

   B. STS and SIS
   The SLS provides a unified syntax, semantics and schema for use in
   the STS, SIS and other aspects of service negotiation, re-
   negotiation and reporting.

   C. Customer and Provider

   Customer - a customer is the negotiating entity that offers data to
   the provider at one or more service access points (SAPs) or end-
   points. We assume the existence of communication channels between
   customer and provider. The term "customer" refers to a role in the
   process, and is not restricted to end-users.

   Provider - a provider is a data carrier who is capable of offering
   different levels of QoS across its network. The provider assumes
   responsibility to transport data packets belonging to the customer
   according to the SIS which both the customer and the provider agreed
   on previously.

   D. Tagging
   The parameters and semantic units of the SLS are meant for use in
   the STS, SIS or other aspects of the negotiation. Depending on the
   service, each parameter may have a pre-defined value or configurable
   or unused.  Even if the parameter is configurable, there may be
   additional constraints such as the data format, units used and its
   set of acceptable values. In order to facilitate such flexibility,
   each attribute or unit of the SLS may be optionally tagged with any
   or all of the following fields _
   i) Specification: CUSTOMER_SPECIFIED or PROVIDER_SPECIFIED; used to
   describe who supplies the value for the attribute during
   negotiation.
   ii) Type: Describes the format of the field, whether it is a string,
   integer or real.
   iii) Description: Reserved for text describing the syntax or
   semantics of the field for ease of use. This would be particularly
   relevant to negotiations that are partially automated, for instance,
   on the provider side alone.
   iv) Values Acceptable: Range or sequence of values that is allowed
   for this field.


3. SLS Components
                     <draft-somefolks-sls-00.txt>    <November> <2000>



   The information contained in each SLS is structured into the
   following description units and sub-units:
   - Common Unit
        - Customer/Provider/Service instance descriptors
        - Validity sub-unit
   - Topology Unit
        - SAP sub-unit
        - Graph sub-unit
   - QoS Unit
        - Scope sub-unit
           - Traffic descriptor sub-unit
           - Load descriptor sub-unit
           - Qos parameters sub-unit
   - Monitoring Unit
           - Scope sub-unit
           - Reporting parameters sub-unit

   A. The Common Unit
   The Common Unit contains information describing the general terms of
   the service offering. There is at most one Common Unit defined per
   SLS. The common unit contains fields that identify the provider,
   customer, service type and time. (These identifiers could contain
   names as well as signatures for non-repudiability). Further, the
   common unit contains a Validity sub-unit that identifies the period
   of applicability of the SLA.

   B. The Topology Unit
   The Topology Unit describes the number and nature of the end points
   that a service instance can have, and the relationship of traffic
   generation and consumption amongst them. The Topology unit is
   composed of one SAP sub-unit, and one or more Graph sub-units.

   SAP Sub-Unit: The SAP sub-unit is a list of end-points that are used
   in constructing the topology. The reason for keeping this list
   separate is that end-point descriptions may be complex -- using IP
   addresses or provider/customer specific attributes. There is little
   need to repeat these descriptions in every topology unit or in the
   QoS unit.  Using the SAP sub-unit allows us to assign document
   specific serial numbers to each end-point, that can be re-used
   wherever needed.

   Graph Sub-unit: When used in describing a topology, an end-point may
   be a source, destination or both. A source end point generates but
   does not consume traffic, while a destination consumes traffic
   without generating it. The graph sub-unit comprises of a list of
   sources and destinations, with special semantics that describes
   their inter-relationship. Further, we allow one or more Graph sub-
   units to be included in a single Topology unit. In order to better
   understand the design consider that service topologies can range
   from the simplest (single source or destination) to highly complex
   (several multiple-source to multiple- destination hoses.)
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   Some sample topologies are:

   o--------->  A "hose" with one source and any destination

   o<---------  A "hose" with one destination and any source

   o<-------->  A bi-directional "hose" with one end point generating
                and receiving traffic from any other end point.

   o--------->o A uni-directional "pipe" between two end-points: a
                source and a destination

   o<-------->o A bi-directional "pipe" with two end-points, both
                sources and destinations

      /--------->o A point-to-multipoint "pipe" with one source and
     /---------->o multiple destinations.
   o|----------->o
     \---------->o
      \--------->o

         /------>o  A point-to-multipoint "funnel" where the traffic
        /------->o  generated by the source is arbitrarily distributed
   o-->|-------->o  among the end points.
        \------->o
         \------>o


   Given the variety of scenarios that need to be represented in a
   general form we use the following principles in modeling topologies:
   a) Allow different types of basic topologies to be represented in a
   unit.
   b) Allow multiple instances of basic topology units that can be
   super-posed to represent complex topologies.

   The three basic topology types that we suggest using are:

            PIPE
        o------------>o

            FUNNEL

              |-------->o                           |<--------o
              |                                     |
              |-------->o                           |<--------o
              |                                     |
        o-->--|-------->o          or         o--<--|<--------o
              |                                     |
              |--------?o                           |<--------o
              | :                                   | :
              | :                                   | :
              |--------?o                           |<--------o
                     <draft-somefolks-sls-00.txt>    <November> <2000>





            HOSE:
                o----->-----|                        |<--------o
                            |                        |
                o----->-----|                        |<--------o
                            |                        |
                o----->-----|--------o---------------|<--------o
                            |                        |
                o----->-----|                        |<--------o
                            |                        | :
                          : |                        | :
                o----->-----|                        |<--------o

   The end-points of the pipe, funnel or hose can be specific IP
   addresses, or the wildcard ANY which specifies that traffic going t
   any host is part of the topology. Note that the funnel topology is
   more general than pipe, and that the hose is more general than the
   first two. The reason for specifying them seperately is to allow the
   right model for the task.

   C. The QoS Unit

   QoS Unit is a complex description block used to describe the traffic
   streams that are the subject of the SLA, and the nature and extent
   of service differentiation provided to them. The QoS unit ascribes
   quantitative or qualitative levels of service to some or all parts
   of the topology unit. A number of attributes and concepts in this
   unit may be shared with the Policy Working Group specifications
   [PCIM]. Future versions of this document will be reworked to take
   care of the dependencies.

   In designing the schema it is important to be aware of the following
   issues:

   a) Not all QoS parameters are used in describing every service. For
   instance, many services do not specify jitter.

   b) QoS parameters may be pre-specified by the provider (in the STS)
   or be configurable by the customer (in the SLS).

   c) QoS parameters may apply to all the traffic described by the
   topology unit (for example, a maximum delay for all traffic), or be
   specific to one Graph sub-unit (mean delay for a point-to-point
   pipe), or be specific to one end-point within a Graph sub-unit
   (leaky bucket descriptor for traffic offered by one source).

   Keeping in view the above issues, we design the QoS unit with three
   components:

   Scope: This describes the topology unit, graph sub-unit or end-point
   to which this QoS unit applies. We provide for the general case
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   where the QoS unit has parameters that apply to the entire topology,
   as well as more specific cases. If there are multiple QoS units, the
   more specific instances override the more general ones.

   Traffic Descriptor: This is used to identify the packet streams
   (within the scope) that are subject to the SLA. In particular, the
   traffic descriptor includes the port numbers and protocol number
   that is subject to agreement.

   Load Descriptor: This describes the quantity of offered traffic
   described through a leaky bucket (for instance) that is considered
   within profile, as well as the treatment of excess or out-of-profile
   traffic.

   QoS Parameters: These include delay, jitter and loss parameters that
   describe the characteristics of the packet or flow transport to be
   provided under the agreement.

   D. The Monitoring Unit
   The Monitoring Unit has a structure similar to the QoS Unit and it
   defines a set of parameters that need to be collected and reported
   back to the customer in order to be compared with the Service Level
   Agreement (SLA) ones. This specification of the Monitoring unit is
   preliminary, and is included here as a placeholder.

4. Schema

   This section represents a detailed description of the previously
   mentioned entities, their attributes and their sources.

   A brief word on the notation below. We use the name of the field or
   unit followed in square parentheses [] by the cardinality and an
   indication on whether this particular attribute is provider
   specified (PS) or customer specified (CS) or either (PS/CS).

   A. The Common Unit [1:PS/CS] (Cardinality 1 in an SLO, and may be
   provider specified or customer specified).

   - Service name [1:PS] String containing the name of the offered
   service.

   - Provider Identifier [0..1:PS] Field containing the name and other
   attributes of the provider, for instance the signature. The exact
   syntax and semantics of this field are TBD.

   - Customer Identifier [0..1:PS/CS] Field containing the name and
   other attributes of the customer, for instance the signature. The
   exact syntax and semantics of this field are TBD.

   - Time Stamp [0..1:PS/CS] Identifies the time of creation of the
   Service Level Objects (SLO as defined in [TERMS]).
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   -Validity Sub-Unit [0..1:PS/CS] Field containing information
   regarding the duration of time during which the service is to be
   instantiated. While the customer usually specifies the time period
   information, there are occasions where the provider may wish to
   restrict or specify these attributes. This sub-unit has considerable
   overlap with the time Period Condition specified by the Policy
   Working Group in [PCIM]. Re-use of their schema is recommended here.

   B. Topology Unit [0..1:PS/CS]
   The customer, subject to restrictions placed by the provider usually
   specifies the topology.  The topology unit consists of one SAP sub-
   unit and one or more Graph sub-units.

   B1. SAP Sub-unit [1:PS/CS] has one occurrence in a Topology Unit. It
   consists of:

   - Number Of SAP Items [1:PS/CS] A field denoting the the cardinality
   of the list.

   - SAP Item [1..N:PS/CS] Identifies a SAP end-point. Each Sap Item
   further consists of - Serial Number [1: PS/CS] non-negative integer
   uniquely assigned to this end point for identification within this
   transaction. Serial numbers must be unique within the Sap Item.
   Serial numbers 0 and 1 are reserved as explained below.

        - SAP Identifier [1: PS/CS] String used to identify the service
        end-point. Two reserved names that have special semantics are:
        + ANY a name that refers to any service end-point; this end
        point uses Serial Number 0
        + THIS a term used to refer to the service end-point that can
        be identified from context (for instance from the source IP
        address of the entity originating the SIS). This end-point uses
        Serial Number 1.

        The SAP Identifier may be of different types. For instance, it
        can be an IP address of the customer interface attached to the
        provider network; a layer 2 identifier; or a string unique
        within the provider-customer context.  The type is carried in
        the optional TAG.

   B2. Graph Sub-unit [0..N:PS/CS]

   - The tag "Type" is used to describe the basic topological structure
   chosen to represent the relationship among end points. Allowed
   values are PIPE, FUNNEL and HOSE. PIPE implies that the number of
   sources and destinations must each be 1. A FUNNEL implies that
   either the number of sources or the number of destinations must be
   1. A HOSE has no such restriction.

   - Graph Identifier [1: PS/CS] Non-negative integer that uniquely
   identifies this instance of a graph sub-unit within the transaction,
   for reference from other units. The value 0 is reserved for
   reference to ALL the Graph sub-units.
                     <draft-somefolks-sls-00.txt>    <November> <2000>



   - Number of Sources [1: PS/CS] Positive integer that specifies the
   number of sources for a particular topology unit description.

   - Number of Destinations [1:PS/CS] Positive integer that specifies
   the number of sources for a particular topology unit description

   - Source Item [1..N:PS/CS] Non-negative integer that refers to a
   end-point serial number in the SAP sub-unit.

   - Destination Item [1..N:PS/CS]  Non-negative integer that refers to
   a end-point serial number in the SAP sub-unit.

   C. QoS Unit [1..N:PS/CS]

   C1. Scope Sub-Unit [1:PS/CS] Specifies the scope of this QoS unit.
        -Graph Identifier : Positive integer that refers to one of the
        Graph sub-units in the topology. If the Graph Identifier is 0,
        then the specifications are global and apply to all the end-
        points and graph sub-units. A larger Graph Identifier over-
        rides a smaller one.
        -SAP Identifier [0..N:PS/CS]: Non-negative integer that refers
        to one of the end-points used in the Graph Identifier given
        above. This field cannot be used if the Graph Identifier is 0.

   C2. Traffic Descriptor Sub-Unit [1:PS/CS] Describes the packet
   streams for which the QoS Unit attributes are defined. This sub-unit
   has considerable overlap with the Packet Stream Condition specified
   by the Policy Working Group in [PCIM].
   Its attributes are:

        -DSCP [0..1:PS/CS] is a string defining the diffServCodePoint
        associated with the flow defined by the scope sub-unit.

        -sourcePort [0..N:PS/CS] Define a set of port numbers that the
        traffic   originates from. It is expressed as a set of
        integers.

        -destinationPort [0..N:PS/CS] Specify a set of port numbers
        that the traffic is destined to. It is expressed as a set of
        integers.

        -protocol [0..1:PS/CS] An integer that defines the protocol
        number that the traffic uses.

        -Layer2Specification [0..1:PS/CS]

   C3. Load Descriptor Sub-Unit [0..N:PS/CS] Describes the offered or
   received conformant traffic, as well as the actions to be taken for
   the out-of-profile traffic. It consists of the following attributes:

        - DescriptorType  [1:PS/CS] is a string from an enumerated list
        that describes the policing mechanism used to control the
                     <draft-somefolks-sls-00.txt>    <November> <2000>


        traffic. Currently, we define one value - LEAKYBUCKET used to
        indicate bucket policing.

        - MTUSize [0..1:PS/CS] integer specifying the Maximum
        Transmission Unit size

        - MeanRate [0..1:PS/CS] is a positive number that describes the
        average rate of arrival of conformant traffic as measured over
        the time interval. It applies to Leaky Bucket mechanism.

        - TimeInterval [0..1:PS/CS] is a positive integer that defines
        the time interval over which the mean rate measurement is
        valid. It is specific to Leaky Bucket mechanism.

        - BurstSize [0..1:PS/CS] is a positive integer that describes
        the tolerance to burst over the time intervals. It is specific
        to Leaky Bucket mechanism.

        - ExcessTrafficTreatment [1:PS/CS] is a string from an
        enumerated list that specifies the actions to be applied to the
        out-of-profile traffic. Its value can be DROP if excess traffic
        is to be dropped, REMARK:XXX if excess traffic is to be treated
        as a different priority class with DSCP XXX, RESHAPE if excess
        traffic is to be reshaped to the submitted load descriptor.

   If REMARK is chosen as the excess traffic treatment, another nested
   load descriptor sub-unit may be defined for the remarked traffic. It
   will include the new DSCP and the new set of attributes for that
   traffic to conform with.

   C4. QoS Parameters Sub-Unit [1:PS/CS] describes the quality
   parameters to be provided for the traffic described by the scope
   sub-unit. The exact definition of each of the following terms and
   the semantics of their combinations is yet to be decided.

   - Delay Descriptor [0..1:PS/CS] specifies the delay imparted to
   conformant packets by the network. It can be specified by:

        -delayPriority[0..1:PS/CS] is a string specifying the relative
        delay priority of this traffic.

        -maxDelay [0..1:PS/CS] is a positive integer specifying in
        milliseconds an upper bound on the delay seen by each
        conformant packet of the flow

        -maxRTT [0..1:PS/CS] is a positive integer specifying in
        milliseconds the maximum round trip time for the flow, taking
        the forward and reverse paths into account

        -Percentile [0..1:PS/CS] is a positive integer less than 100
        defining the percentile associated with meanDelay, maxDelay or
        minDelay. It describes the portion of packets that will meet
        the standard delay.
                     <draft-somefolks-sls-00.txt>    <November> <2000>



   - Loss Descriptor  [0..1:PS/CS] describes the packet loss
   characteristics of the conformant traffic:

- meanLoss [0..1:PS/CS] is a positive integer that describes the
average loss suffered by packets of a conformant flow. This attribute
is used for quantitative description of the service performance.

        - lossPriority [0..1:PS/CS] is a string that describes the
        relative experience of loss between different flow aggregates.
        A smaller loss priority implies a higher drop rate. This
        attribute is used for qualitative description of the service
        performance.

   - Jitter Descriptor [0..1:PS/CS] describes the jitter that will be
   experienced by a conformant flow

        -maxJitter [0..1:PS/CS] is a positive integer that describes
        the maximum jitter that will be experienced by conformant
        packets.

        -meanJitter [0..1:PS/CS] is a positive integer that describes
        the average jitter seen by a conformant flow. It is used for
        quantitative description of the service performance.

        -JitterPriority [0..1:PS/CS] is a string that describes the
        relative experience of jitter between different flow
        aggregates. It is used for qualitative description of the
        service performance.

        -Percentile [0..1:PS/CS] is a positive integer less than 100
        that specifies the percentile of conformant packets for which
        the maxJitter and meanJitter parameters apply.

   - Service Availability Descriptor [0..1:PS/CS] Describes service
   down-times and exceptional conditions during which service terms are
   not applicable.

        -Maximum Down-Time [0..1:PS] is a positive number that
        indicates the maximum time that the service will be down.

        -Measurment Interval [0..1:PS] is a positive number that
        indicates the interval over which the Maximum Down-Time is
        measured.

        -linkFailureTolerance [0..1:PS/CS] is a positive number that
        indicates the number of simultaneous link failures against
        which this service instance should be protected.

        -nodeFailureTolerance [0..1:PS/CS] is a positive number that
        indicates the number of simultaneous node failures against
        which this service instance should be protected.
                     <draft-somefolks-sls-00.txt>    <November> <2000>



   D. Monitoring Unit [1..N:PS/CS] describes the quality parameters
   that are to be reported for a topology unit, graph sub-unit or end-
   point. It is structured similarly to the QoS Unit, consisting of a
   scope sub-unit and quality parameters specifications included in the
   Reporting Parameters sub-unit.

   D1. Scope Sub-Unit [1:PS/CS] Specifies the scope of this Monitoring
   unit.

        -Graph Identifier : Positive integer that refers to one of the
        Graph sub-units in the topology. If the Graph Identifier is 0,
        then the specifications are global and apply to all the end-
        points and graph sub-units. A larger Graph Identifier over-
        rides a smaller one.

        -SAP Identifier [0..N:PS/CS]: Non-negative integer that refers
        to one of the end-points used in the Graph Identifier given
        above. This field cannot be used if the Graph Identifier is 0.

   D2. Reporting Parameters Sub-Unit

        -Delay Frequency [0..1:PS/CS] is a positive integer that
        describes the frequency of delay updates in 100 ms units

        -Jitter Frequency [0..1:PS/CS] is a positive integer that
        describes the frequency of jitter updates in 100 ms units

        -Loss Frequency [0..1:PS/CS] is a positive integer that
        describes the frequency of loss updates in 100 ms units

5. Use Case Scenario - VLL Implementation and Specifications

   This section describes the implementation and the specifications
   needed for a particular service offer. We chose the VLL service for
   this example.

   5.1 VLL features and Implementation
   The Virtual Leased Line (VLL) service is targeted for applications
   and customers that require predictable point-to-point performance. A
   virtual leased line is a point-to-point pipe with a guaranteed peak
   transmission rate.  No packets are lost due to network congestion;
   delay and jitter are very low. Appropriate applications include
   Voice over IP, transaction processing, and multimedia applications
   that require low queuing delay and jitter.  VLL offers a simple,
   well understood performance model (approximating leased line
   performance), and so should be appealing for any application,
   including web applications, where predictable performance is highly
   valued.

   The reserved rate may be renegotiated, and so vary over time.
   Packets arriving at a rate exceeding R are either dropped or
   buffered at the point of origination of the flow. Furthermore, no
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   packet of a flow is dropped due to congestion (losses, however, may
   occur due to other factors).

   The traffic is assumed to be classified and marked with DSCP 100110
   on the customer premises. The provider polices incoming traffic and
   drops out of profile packets.

   5.2. Specifications

   A sample Service Instance Specification for this service is as
   below.

   A. Common Unit
   - Service name: Virtual Leased Line
   - Provider Identifier: XXX
   - Customer Identifier: YYY
   - Time Stamp : 010120001352
   - Validity Sub-Unit
          - DateFrom :11/01/2000
          - DateTo: 11/01/2001
          - TimeFrom: 9:00
          - TimeTo: 17:00


   B. Topology Unit
   B1. SAP Sub-Unit
        - Number of SAP Items :2 #(only point to point pipes are
        supported for VLL)
       - SAP Item 1
          - Serial number: 12345
          - SAP Identifier: 130.16.120.51
       - SAP Item 2
          - Serial number: 6789
          - SAP Identifier: 125.15.136.20

   B2. Graph Sub-Unit
       - Type : PIPE
       - Graph Identifier: 1
       - Number of Sources: 1 #(unidirectional flow)
       - Number of Destinations: 1
       - Source Item: 12345 #(Source-SAP serial number)
       - Destination Item: 6789 #(Destination-SAP serial number)

   C. QoS Unit
   C1. Scope Sub-Unit
       - Graph Identifier: 1 #End-point is left unspecified

   C2. Traffic Descriptor Sub-Unit
       - DSCP 10010

   C3. Load Descriptor Sub-Unit
       - DescriptorType: Leaky Bucket
       - MeanRate: 5000 #The units tag specifies kbps, say.
                     <draft-somefolks-sls-00.txt>    <November> <2000>


        - BurstSize: 1MTU #provider specified and ingress interface
        specific
       - PeakRate: 10000 #Provider Specified
       - ExcessTrafficTreatment: DROP #Provider Specified

   C4. QoS Parameters Sub-Unit
       -Delay Descriptor
             -maxDelay: 50 ms  #provider specified
             -Percentile: 90 #provider specified
       -Loss Descriptor
             -lossPriority: 3 #Low loss, provider specified
       -Availability Descriptor
            -maxDownTime:  1  #provider specified in units of hours
            -measurement Interval: 1 #(provider specified in units of
        years

6. Security Considerations

   Given the nature of information included in a SLS, some security
   related procedures are required prior to the initiation of any
   negotiation process.

   Both parties involved in a negotiation process (the customer and the
   provider of services) should be identified for non-repudiability of
   the transaction.

   Independent of the service offer resolution (whether the service
   request was accepted or rejected) the confidentiality of exchanged
   information should be preserved using encryption.


7. References


1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.

2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997


   [COPS] "The COPS (Common Open Policy Service) Protocol" D. Durham,
   J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry.  January 2000.
   RFC2748

   [COPSRSVP]  "COPS Usage for RSVP",  S. Herzog, J. Boyle, R . Cohen,
   D. Durham, R. Rajan, A. Sastry, RFC2749

   [PCIM] "Policy Core Information Model - Version 1 Specification", B.
   Moore, E. Ellison, J. Strassner, and A. Westerinen.  July 2000,
   draft-ietf-policy-core-info-model-07.txt.

   [TEQUILA] "Service Level Specification Semantics, Parameters and
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   negotiation requirements.", D. Goderis, Y. T'joens, C. Zaccone, C.
   Jacquenet, G. Memenios, G. Pavlou, R. Egan, D. Griffin, P.
   Georgatsos, L. Georgiadis. July, 2000
   http://search.ietf.org/internet-drafts/draft-tequila-diffserv-sls-
   00.txt

   [POLFRAME] "Policy Framework QoS Information Model", Y. Snir, Y.
   Ramberg, J. Strassner, R. Cohen, draft-ietf-policy-qos-info-model-
   01.txt

   [QOSPOLSC] "QoS Policy Schema", Y. Snir, Y. Ramberg, J. Strassner,
   R.Cohen, Feb 2000, http://www.ietf.org/internet-drafts/draft-ietf-
   policy-qos-schema-01.txt

   [QOSDEVIM]  , "Information Model for Describing Network Device QoS
   Mechanisms", Internet Draft , J. Strassner, W. Weiss, D. Durham, A.
   Westerinen, <draft-ietf-policy-qos-device-info-model-00.txt>

   [QOSIM] "QoS Policy Information model", internet draft , Y. Snir, Y
   Ramberg, J. Strassner, R. Cohen ,  <qos-policy-info-model-00.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 2475] "An Architecture for Differentiated Services", S. Blake,
   D. Black, M.Carlson,E.Davies,Z.Wang,W.Weiss,
   www.ietf.org/rfc/rfc2475.txt

   [TERMS] "Policy Terminology",  A. Westerinen, J. Schnizlein, J.
   Strassner, Mark Scherling, Bob Quinn, Jay Perry, Shai Herzog, An-Ni
   Huynh, Mark Carlson
   http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-
   00.txt

   [SLSFRAME] ] "Service Level Specification and Usage Framework", Y.
   T'Joens, D. Goderis, R. Rajan, S. Salsano, C. Jacquenet, G.
   Memenios, G. Pavlou, R. Egan, D. Griffin, P. Vanheuven, P.
   Georgatsos, L. Georgiadis, draft-manyfolks-sls-framework-00.txt

8.   Acknowledgments

   The authors would like to acknowledge Yves T'Joens, Carlos
   Kamienski, Gabor Fodor and the members of TEQUILA project, for their
   input.

9. Author's Addresses

   Raju Rajan
   AT&T Labs Research
   180 Park Avenue,
                     <draft-somefolks-sls-00.txt>    <November> <2000>


   Florham Park, NJ 07932
   USA
   Email: rajan@research.att.com

   Eliza Celenti
   AT&T Labs
   200 Laurel Avenue,
   Middletown, NJ 07748
   USA
   Email: elizacelenti@att.com

   Sumita Dutta
   AT&T Labs
   307 MIDDLETOWN LINCROFT RD,
   LINCROFT, NJ 07738-1526
   USA
   Email: sdutta@att.com
                     <draft-somefolks-sls-00.txt>    <November> <2000>



Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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 implmentation 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