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