Network Working Group D. Goderis
Internet Draft Alcatel
Document: draft-tequila-sls-03.txt D. Griffin
Category: Best Current Practice University College London
Expires April 2004 C. Jacquenet
France Telecom
G. Pavlou
University of Surrey
Editors
October 2003
Attributes of a Service Level Specification (SLS) Template
<draft-tequila-sls-03.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [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 depicts a standard set of information to be
(dynamically) negotiated between a customer and an IP service
provider or between service providers, by means of instantiated
Service Level Specifications (SLS). It also specifies 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...............................................2
2. Conventions used in this document..........................3
3. Changes since the Previous Version.........................3
Goderis et al. Best Current Practice - Exp. April 2004 [Page 1]
Internet Draft Attributes of a SLS Template October 2003
4. Basic Assumptions..........................................3
4.1. A DiffServ-driven Approach.................................3
4.2. Positioning SLS Templates in a Layered Model...............4
5. Service Level Specification Template.......................5
5.1. The Scope Attribute........................................5
5.1.1. Semantics of the Scope Attribute...........................5
5.1.2. Possible Combinations of the Scope Attribute...............5
5.2. The Flow Identifier (Flow ID) Attribute....................6
5.2.1. Semantics of the Flow ID Attribute.........................6
5.2.2. Usage of the Flow ID Attribute.............................7
5.3. The Performance Attribute..................................7
5.3.1. Semantics of the Performance Attribute.....................8
5.3.2. Quantitative aspects of the Performance Attribute..........8
5.3.3. Qualitative aspects of the Performance Attribute...........8
5.4. The Traffic Conformance Attribute..........................9
5.4.1. Semantics of the Traffic Conformance attribute.............9
5.4.2. Usage of the Traffic Conformance attribute................10
5.4.2.1. Basic Conformance Testing...............................10
5.4.2.2. Two-Level Conformance Testing...........................10
5.5. The Excess Treatment Attribute............................10
5.6. The Service Schedule Attribute............................11
5.7. The Reliability Attribute.................................11
5.8. Additional Attributes.....................................11
6. Examples of Instantiated SLS Templates....................11
6.1. SLS for a Virtual Leased Line Service.....................11
6.2. The Funnel Service........................................12
6.3. SLS for Best Effort Traffic...............................13
7. SLS Negotiation Protocol Requirements.....................13
8. Security Considerations...................................14
9. References................................................14
10. Acknowledgments...........................................14
11. Authors' Addresses........................................15
1. Introduction
The deployment of value-added IP service offerings over the Internet
has yielded a tremendous effort for the definition, the specification
and possibly the standardization of the notion of Quality of Service
(QoS), which generally encompasses a wide set of elementary
parameters, such as the maximum transit delay, the inter-packet delay
variation, or the packet loss rate.
Because the subscription to an IP service offering implies the
definition of a contractual agreement between the customer and the
corresponding IP Service Provider (ISP), the level of quality that
will be associated to the deployment of such service will be based
upon a set of the aforementioned parameters both parties will have to
agree upon.
Goderis et al. Best Current Practice - Exp. April 2004 [Page 2]
Internet Draft Attributes of a SLS Template October 2003
From this perspective, this document aims at listing (and promoting a
standard formalism for) a set of basic parameters that will compose
the elementary contents of a SLS, hence yielding the specification of
a (hopefully) standardized SLS template that should dramatically
facilitate the enforcement of IP QoS policies, especially with an
inter-domain context where QoS-based IP service offerings are
deployed over the whole Internet.
Thus, this document presents an outline for the definition of the SLS
parameters and the semantics that go behind this representation. As
such, the document is structured as follows:
- Section 4 lists the basic assumptions this work relies upon, and
also provides a glossary of the terms used in this draft,
- Section 5 specifies the SLS template, while section 6 provides some
example of SLS instantiations, with the goal to show how such
templates could be used,
- Finally, sections 7 and 8 provide a list of requirements as far as
the use of a SLS negotiation protocol is concerned, and some
security considerations, respectively.
2. 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].
3. Changes since the Previous Version
The following changes have been made since the previous version of
the document:
- Most of the text has been cleaned up and the overall organization
of the document has been reviewed,
- A section on SLS negotiation protocol requirements has been added,
- Both the References and Authors' sections have been updated,
- Remaining typos have been corrected.
4. Basic Assumptions
4.1. A DiffServ-driven Approach
The basic assumption of this document is that IP service offerings
will be deployed over a public IP infrastructure (namely the
Internet) where part of if not all the network devices (namely the IP
routers) will be DiffServ-capable, as per [3]. In particular, these
Goderis et al. Best Current Practice - Exp. April 2004 [Page 3]
Internet Draft Attributes of a SLS Template October 2003
routers support Per Hop Behaviors (PHB), like the Assured Forwarding
(AF) PHB ([4]) and the Expedited Forwarding (EF) PHB ([5]).
In this document, ISPs are in charge of the exploitation of the
underlying IP infrastructure that will support the QoS-based IP
service offerings customers will have the ability to subscribe to,
while the level of quality associated to these services is
technically described in SLS templates.
Furthermore, the DiffServ-related terminology used in this document
fully complies with [6].
4.2. Positioning SLS Templates in a Layered Model
The Differentiated Services specification effort has yielded the
identification of a set of elementary functions and concepts, whose
respective interactions can be depicted according to a layered
approach, as per the following figure 1.
+----------------------------------------------------------+
| Service Level Agreement (SLA) |
| * Administrative terms and conditions |
+----------------------------------------------------------+
| Service Level Specification (SLS) |
| * QoS guarantees |
| * Performance indicators |
| * IP traffic characteristics |
+----------------------------------------------------------+
| Per Domain Behaviors (PDB) |
| * QoS capabilities of the DiffServ domain |
| * Edge-to-edge DiffServ aggregates |
+----------------------------------------------------------+
| Per Hop Behaviors (PHB) |
| * QoS capabilities of DiffServ-enabled routers |
+----------------------------------------------------------+
| DiffServ-inferred QoS Functions (implementation-specific)|
| * Schedulers |
| * Algorithmic droppers |
| * Markers |
| * Policers |
+----------------------------------------------------------+
Fig. 1: A Layered Model of DiffServ.
As per figure 1, each of the layer displays its own QoS capabilities.
According to the definition of a Per-Domain Behavior (PDB, [7]), the
specification of such PDBs should include the reference to the (lower
layer) PHB(s) the PDB "layer" relies upon.
Furthermore, the mapping between instantiated SLS templates and PDBs
remains an unexplored area: for example, a SLS is service-oriented
and customer-specific, whereas a PDB is customer-unaware.
Goderis et al. Best Current Practice - Exp. April 2004 [Page 4]
Internet Draft Attributes of a SLS Template October 2003
5. Service Level Specification Template
The following sub-sections provide a description of the attributes
that MAY be conveyed and valued in a given SLS template.
5.1. The Scope Attribute
The Scope attribute of a SLS template indicates where the QoS policy
for the corresponding IP service offering is to be enforced.
Therefore, the scope uniquely identifies the network region where the
QoS policy will be enforced, by defining the boundaries of such
region.
The scope of a SLS MUST be expressed by a couple of ingress and
egress interfaces. Ingress and egress respectively denote the entry
and exit points of the network region that will convey the IP
datagrams associated to the corresponding service offering.
The introduction of the notion of ingress and egress interfaces
implicitly states that SLS templates refer to uni-directional IP
flows, where an IP flow is a set of IP datagrams that share at least
one common characteristic, e.g. the same destination address.
Obviously, the direction dimension of a SLS template does not exclude
the provisioning of bi-directional SLS templates, thanks to the
combination of at least two SLS templates.
5.1.1. Semantics of the Scope Attribute
Scope = (ingress, egress), where:
- Ingress = Interface (I/F) Identifier | Set of I/F Identifiers | Any
- Egress = Interface Identifier | Set of I/F Identifiers | Any
Note that "|" denotes an exclusive OR, while "Any" is logically
equivalent to "Unspecified".
5.1.2. Possible Combinations of the Scope Attribute
The following combinations are permitted:
(1, 1), which reflects a one-to-one (peer-to-peer) communication.
This kind of scope refers to "Pipe" SLS templates in the rest of the
document,
(1, N), which reflects a one-to-many communication (N > 1), e.g. a
videoconferencing service. This kind of scope refers to "Hose" SLS
templates in the rest of the document,
Goderis et al. Best Current Practice - Exp. April 2004 [Page 5]
Internet Draft Attributes of a SLS Template October 2003
(1, Any), which reflects a one-to-any communication, e.g. a
broadcasting service,
(N, 1), which reflects a many-to-one communication, e.g. an IP
Virtual Private Network (VPN) service offering, deployed according to
a hub-and-spoke topology. This kind of scope refers to "Funnel" SLS
templates in the rest of the document,
(Any, 1), which reflects an any-to-one communication (e.g. all the IP
traffic of a stub domain that has a single exit point towards the
Internet).
This scope taxonomy currently excludes the case of many-to-many
communication types, which would be denoted as (M, N) according to
the above semantics: either the ingress or the egress interfaces MUST
be unique, whereas scopes of the (M, N) type could be de-composed
into M instances of scopes of the (1, N) types, a.k.a. M instances of
Hose SLSes.
Also, there SHOULD be a 1:1 relationship between the interface
identifier and the link the interface is attached to. The
corresponding link identifier MAY be an IP address, but it may also
be any other identification means both parties (customer and
provider) would have agreed upon: for example, layer 2 link
identifiers could be used in either Ethernet or PPP (Point-to-Point
Protocol, [8]) access links.
5.2. The Flow Identifier (Flow ID) Attribute
The Flow Identifier (Flow ID) attribute of a SLS template refers to
the IP flow, defined as a set of IP datagrams that share at least one
common characteristic, and which corresponds to the IP service
offering whose level of quality is technically depicted in the
aforementioned SLS. This parameter provides an input for IP datagram
classification to be performed by a DiffServ boundary node. Such a
classification can either reflect a Behavior Aggregate (BA) or a
Multi-Field (MF) taxonomy.
The MF-based classification may either depict micro-flows or macro-
flows, based on the source prefix attribute, for example (see section
5.2.1 below).
5.2.1. Semantics of the Flow ID Attribute
A given SLS template MUST contain one and only one Flow ID attribute,
which MAY formally be described by one or a combination of the
following attribute.
Flow ID = {DiffServ Information, Source information, Destination
Information, Application Information}, where:
Goderis et al. Best Current Practice - Exp. April 2004 [Page 6]
Internet Draft Attributes of a SLS Template October 2003
- DiffServ Information = DSCP Value | Set of DSCP Values | Any
- Source Information = Source IP address | Set of source IP addresses
| Source Prefix | Set of Source Prefixes | Source AS | Any
- Destination Information = Destination IP address | Set of
destination IP addresses | Destination Prefix | Set of Destination
Prefixes | Destination AS | Any
- Application Information = Protocol number | Source Port |
Destination Port | (Source Port, Destination Port) | Any
5.2.2. Usage of the Flow ID Attribute
In the case of a BA-based classification, the DiffServ information
MUST be provided, while the remaining information of the Flow ID
attribute MUST NOT be specified. As an example, an Ordered Aggregate
(OA) that defines a stream of AF-marked IP datagrams could be
described by a single Flow ID attribute using several DSCP values,
indicating as many drop precedence levels. Note that the DSCP value
of the Flow ID's DiffServ information does not necessarily relate to
a specific PHB, but rather is a means (among others) for identifying
an IP flow.
In the case where the Flow IP attribute is valued with the (IP source
address, IP destination address) pair while the Scope attribute is
left unspecified, there is therefore no specific assumption about the
ingress and egress points that the corresponding traffic will cross.
Furthermore, it is the responsibility of the service provider to
select the route (thanks to the enforcement of a routing if not a
traffic engineering policy) that will convey this traffic across the
DiffServ domain.
On the other hand, if both the Scope and Flow ID attributes of a SLS
template have been specified so that the (Ingress I/F, Egress I/F)
pair as well as the (Source IP Address, Destination IP Address) pair
have been explicitly valued, then the route followed by the flow
between the two hosts MUST go through the Ingress and Egress
interfaces.
5.3. The Performance Attribute
The Performance attribute describes the network level of quality that
is associated to the transportation of an IP flow, as it has been
defined by the Flow ID attribute of the SLS template, and within the
limits defined by the Scope attribute of the same SLS template.
The Performance attribute is a set of indicators, and four indicators
have been defined so far, according to the following semantics.
Goderis et al. Best Current Practice - Exp. April 2004 [Page 7]
Internet Draft Attributes of a SLS Template October 2003
5.3.1. Semantics of the Performance Attribute
The following indicators compose the Performance attribute of a SLS
template.
- One-way delay ([9]), measurement period, optional quantile
- Inter-packet delay variation ([10]), measurement period, optional
quantile
- Packet loss rate ([11]), measurement period
- Throughput, measurement period
For a given SLS template, all these indicators refer to an IP flow
which has been described by the valued Flow ID attribute of the SLS,
and within the ingress and egress domain boundaries, as per the Scope
attribute of the SLS. Such indicators are measured during a period of
time which is specified by the "measurement period" indication
associated to each indicator.
The quantile indication is an optional parameter that is relevant to
reflect an empirical gauge of the corresponding performance
indicators. For example, a SLS template whose Performance attribute
would contain the triplet (delay = 10 ms, measurement period = 5 min,
quantile = 10E-3) means that the customer's expectation is that the
probability of delays greater than 10 ms is less than 10E-3 for any
measurement period of 5 minutes.
Such Performance attribute semantics therefore yields the
specification of arrays like N (delay/loss, quantile) pairs. The more
pairs, the better the delay probability can be approximated as a tail
distribution.
As for the throughput indicator, it is measured at the egress point
(as defined in the Scope attribute of the SLS), by counting all the
outgoing IP datagrams described by the Flow ID attribute of the SLS.
5.3.2. Quantitative aspects of the Performance Attribute
One of the performance indicators of the Performance attribute is
said to be quantitative whenever its value is expressed as a numeric
value. Then, the QoS reflected by an instantiated SLS is said to be
quantitative when at least one of the indicators of the Performance
attribute of the SLS is quantified.
5.3.3. Qualitative aspects of the Performance Attribute
If none of the indicators of the Performance attribute of a given SLS
has been quantified, then such indicators MAY be valued so that they
reflect a qualitative QoS. The corresponding values of these
Goderis et al. Best Current Practice - Exp. April 2004 [Page 8]
Internet Draft Attributes of a SLS Template October 2003
indicators MAY therefore be of the following kind: "low", "medium",
"high".
From a commercial perspective, such values MAY be associated to the
definition of QoS-based IP service offerings, such as the "Bronze"
service (e.g. with a delay indicator valued at "high"), the "Silver"
service, (e.g. with a loss indicator valued at "medium"), and the
"Gold" service (e.g. with a (delay, loss) pair valued at "low").
5.4. The Traffic Conformance Attribute
The Traffic Conformance attribute of a SLS template is a set of
indicators that aim at describing how an IP flow (as depicted by the
Flow ID attribute of the SLS) should "look like" (e.g. in terms of
volume (per unit of time)) so that the customer be serviced according
to the level of quality that has been described in the Performance
attribute of the SLS for this traffic.
The indicators of the Traffic Conformance attribute are the input
data for traffic conformance algorithms, whereas traffic conformance
testing functions are operated at the boundaries of a DiffServ
domain, thanks to the contents of the Traffic Conformance attribute
and the aforementioned algorithm.
Basic traffic conformance testing relies upon a set of actions that
yield the identification of "in-profile" and "out-of-profile" IP
datagrams of a given IP flow (as depicted by the Flow ID attribute of
the SLS). From this standpoint, the indicators that have been valued
in the Traffic Conformance attribute of a given SLS describe the
reference values the IP flow will have to comply with, hence the
notions of "in-profile" and "out-of-profile" traffics.
The traffic conformance algorithm is the means that unambiguously
identifies in-profile and out-of-profile IP datagrams, based upon the
valued indicators of the Traffic Conformance attribute of the SLS.
Furthermore, there MAY be cases where traffic conformance testing
actions are iterative, hence the notion of multi-level traffic
conformance testing, where an IP datagram of a given flow will be
tagged (thanks to a particular action taken by the traffic
conformance algorithm) to reflect its belonging to a specific level.
In such cases, the Traffic Conformance attribute of the SLS template
MUST indicate the level the indicators refer to.
5.4.1. Semantics of the Traffic Conformance attribute
Indicators that MAY be conveyed by the Traffic Conformance attribute
include:
- Multi-Level Conformance Testing n (n being an integer)
Goderis et al. Best Current Practice - Exp. April 2004 [Page 9]
Internet Draft Attributes of a SLS Template October 2003
- Peak Rate p (expressed in bits per second or kilobits per second)
- Token Bucket Rate r (expressed in bits per second or kilobits per
second)
- Bucket Depth b (expressed in bytes)
- Maximum Transfer Unit (MTU) M (expressed in bytes)
- Minimum Packet Size m (expressed in bytes).
5.4.2. Usage of the Traffic Conformance attribute
5.4.2.1. Basic Conformance Testing
Basic conformance testing MAY rely upon the use of a token bucket
algorithm, whereas the indicators of the Traffic Conformance
attribute of the SLS template will be the token bucket rate r and the
bucket depth b.
Also, when defining the MTU indicator of the Traffic Conformance
attribute of the SLS, then the corresponding conformance algorithm
will consist in the following:
- If the size of the incoming IP datagram is smaller or equal to MTU,
then the datagram will be forwarded,
- If the size of the incoming datagrams is strictly greater than the
MTU, then the datagram will be dropped.
5.4.2.2. Two-Level Conformance Testing
A two-rate three-colour marker relies upon the use of two token
buckets, whose respective rates are denoted r1 and r2 (with r2 > r1).
Both buckets contain green and yellow tokens, respectively. In this
case (where the indicators of the Traffic Conformance attribute of
the SLS are the (r1, b1) and (r2, b2) characteristics of the token
buckets), a simple traffic conformance algorithm is the following:
- If there are green and yellow tokens left in the respective
buckets, an incoming datagram will be tagged "green",
- If there are yellow tokens left only, an incoming datagram will be
tagged "yellow",
- The incoming datagram will be tagged "red" otherwise.
5.5. The Excess Treatment Attribute
Goderis et al. Best Current Practice - Exp. April 2004 [Page 10]
Internet Draft Attributes of a SLS Template October 2003
The SLS template MUST describe how out-of-profile traffic flows will
be processed, and this is the role of the Excess Treatment attribute.
By default, if the Excess Treatment attribute is not specified in the
SLS template, in excess traffic will be dropped.
As a consequence, the semantics of the Excess Treatment attribute of
the SLS template will consist in describing a specific action to be
taken by the (DiffServ-enabled) router: such actions MAY consist in
re-marking the IP datagrams (i.e. modifying the value of the DSCP
bits), storing in-excess traffic in specific queues, etc. (a
combination of elementary actions, e.g. "re-mark then store" SHOULD
also be possible).
5.6. The Service Schedule Attribute
The Service Schedule attribute of a SLS template reflects the
"working hours" of the corresponding service, by indicating both
start and end times of the service. This attribute might be expressed
as a collection of the following indicators:
- Time of the day range, e.g. a service is available from 08:00 to
17:00,
- Day of the week range, e.g. a service available from Monday to
Friday,
- Month of the year range, e.g. the service is available from June
2003.
5.7. The Reliability Attribute
The Reliability attribute of a SLS reflects the maximum Mean Down
Time (MDT) per year, as well as the maximum Mean Time To Repair
(MTTR) as far as the availability of the service is concerned.
Reference units for the Reliability attribute SHOULD be minutes per
year for the MDT indicator, and seconds for the MTTR indicator.
5.8. Additional Attributes
The current version of this draft has proposed and defined a set of
attributes that SHOULD be conveyed in a SLS template. Obviously,
there may be a need for conveying additional information, and updated
versions of this document should reflect such requirement as
appropriate.
6. Examples of Instantiated SLS Templates
6.1. SLS for a Virtual Leased Line Service
Let us assume the availability of a (unidirectional) Virtual Leased
Line (VLL) service offering, provided with a guaranteed throughput of
Goderis et al. Best Current Practice - Exp. April 2004 [Page 11]
Internet Draft Attributes of a SLS Template October 2003
1 Mbit/s, a guaranteed one-way transit delay of 20 ms for a 10E-3
quantile, as well as a guaranteed packet loss rate of 0%.
Therefore, the value attributes of the corresponding SLS template
will be the following:
- Scope = (1, 1)
- Flow ID = ((Set of) Source Addresses, (Set of) Destination
Addresses, EF marking) - there may be several IP networks that may
communicate through this virtual leased line, and all the IP
traffic that will be conveyed by this VLL will be EF-marked.
- Traffic Conformance = (b, r, drop), where r = 1 Mbit/s (token
bucket algorithm), and out-of-profile traffic will be dropped.
- Performance = (20 ms, 5 min, 10E-3, 0%), where delay = 20 ms,
measured during a period of 5 minutes with an associated quantile
of 10E-3, and with a 0% of packet loss rate (which implies that the
throughput guarantee is identical to the token bucket rate r, hence
1 Mbit/s.
- Service Schedule = (24/24, 7/7) - for example.
- Reliability = (MTTR = 30 s) - for example.
In this example, it's worth mentioning that the throughput guarantee
has been derived from the packet loss rate, the token bucket rate and
the action to be taken for out-of-profile traffic (drop).
6.2. The Funnel Service
The Funnel service would aim at protecting local traffic (within an
enterprise) from Internet traffic, such as HTTP. An example of such
service is depicted in figure 2 below:
/-------------------\
| |
| Network -------|-- B
| / |
A ---------|-------------------|-- C
| \ |
<-a(out) | -------|-- D
| |
\-------------------/
Fig. 2: Example of a Funnel Service.
In figure 2, customer A requires that the traffic entering his
network and coming from B, C or D, does not exceed the a(out) rate.
Goderis et al. Best Current Practice - Exp. April 2004 [Page 12]
Internet Draft Attributes of a SLS Template October 2003
The attributes of the corresponding SLS would therefore be the
following:
- Scope = (N, 1)
- Flow ID = (DSCP). The filter for incoming traffic will be applied
on the DSCP marking.
- Traffic Conformance = (b, r, drop). The token bucket algorithm
reflects the maximum allowed (incoming) throughput (r = a(out)) on
the specified egress interface, as defined in the Scope attribute.
Out-of-profile traffic will be dropped.
6.3. SLS for Best Effort Traffic
The attributes of a Best Effort (BE) SLS would be the following:
- Scope = all combinations that have been defined in section 5.1.2 of
the document.
There would be no indication of the Flow ID attribute, nor the
Traffic Conformance, nor the Performance attributes. Nevertheless,
both the Service Schedule and the Reliability attributes MAY be
valued.
7. SLS Negotiation Protocol Requirements
The information that is conveyed in SLS templates by means of
specific attributes will be negotiated between the customer and the
service provider parties. As such, this information will be exchanged
thanks to a communication protocol, which SHOULD address the
following requirements.
- The SLS negotiation protocol should use of a reliable transport
mode, given the importance of the QoS information to be exchanged
between the customer and the service provider,
- The protocol architecture should provide a means for a dynamic SLS
negotiation and subscription procedure, so that it may introduce a
high level of automation in the actual negotiation and invocation
of the corresponding IP service offerings,
- The protocol should support a reporting mechanism that may be used
for statistical information retrieval,
- The protocol should support the appropriate security mechanisms to
provide some guarantees as far as the preservation of the
confidentiality of the information contained in a SLS template is
concerned.
Goderis et al. Best Current Practice - Exp. April 2004 [Page 13]
Internet Draft Attributes of a SLS Template October 2003
8. Security Considerations
This draft has identified a set of information that will be exchanged
between a customer and a service provider by means of a SLS template
negotiation and instantiation procedure. As such, it raises the issue
of the security associated to the provisioning of such information,
by means of a protocol which should be able to address the
requirements discussed in the previous section 7. In particular, the
following security features SHOULD be considered:
- Identification and authentication of the requesting entity (a.k.a.
the customer), if not both parties,
- Identification and authentication of the peering entities that will
participate in the SLS negotiation process,
- Preservation of the confidentiality of the information to be
exchanged between both parties during the SLS negotiation and
instantiation procedures.
9. 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
[3] Blake, S., et al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[4] Heinanen, J., et al., "Assured Forwarding PHB Group", RFC 2597,
June 1999.
[5] Davie, B., et al., "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[6] Grossman, D., "New Terminology and Clarifications for Diffserv",
RFC 3260, April 2002.
[7] Nichols, K., Carpenter, B., "Definition of Differentiated
Services Per Domain Behaviors and Rules for their Specification",
RFC 3086, April 2001.
[8] Simpson, W., et al., "The Point-to-Point Protocol (PPP)", RFC
1661, STD 0051, July 1994.
[9] Almes, G., Kalidindi, S., "A One-Way-Delay Metric for IPPM", RFC
2679, September 1999.
[10] Demichelis, C., Chimento, P., "IP Packet Delay Variation Metric
for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[11] Almes, G., et al., "One-way Packet Loss Metric for IPPM", RFC
2680, September 1999.
10. Acknowledgments
Part of this work has been funded by the European Commission, within
the context of the TEQUILA (Traffic Engineering for Quality of
Goderis et al. Best Current Practice - Exp. April 2004 [Page 14]
Internet Draft Attributes of a SLS Template October 2003
Service in the Internet At Large Scale, www.ist-tequila.org) project,
which was itself part of the IST (Information Society Technologies)
research program.
The authors would also like to thank W. Almesberger, M. Brunner, S.
De Cnodder, S. Salsano, A. Kamienski, as well as A. Malick for their
useful comments and suggestions that have been sent on the sls@ist-
tequila.org mailing list, and also during private conversations.
11. Authors' Addresses
Maarten Buchli
Alcatel Corporate Research Center
Fr. Wellesplein 1,
2018 Antwerpen
Belgium
Phone: +32 3 240 7081
Email: maarten.buchli@alcatel.be
Richard Egan
Thales Research and Technology Ltd.
Worton Drive
Worton Grange Industrial Estate
Reading, Berkshire RG2 OSB
United Kingdom
Phone: +44 118 923 8375
Email: richard.egan@thalesgroup.com
Panos Georgatsos
Algonet S.A.
206, Sygrou Avenue,
176 72 Kalithea
Athens
Greece
Phone: +30 210 955 8356
Email: pgeorgat@egreta.gr
Leonidas Georgiadis
Aristotel Univ. of Thessaloniki
PO Box 435, Thessaloniki, 54006,
Greece
Phone: +30 31 996385
Email: leonid@eng.auth.gr
Danny Goderis
Alcatel Corporate Research Center
Fr. Wellesplein 1,
2018 Antwerpen
Belgium
Phone: +32 3 240 7853
Email: Danny.Goderis@Alcatel.be
Goderis et al. Best Current Practice - Exp. April 2004 [Page 15]
Internet Draft Attributes of a SLS Template October 2003
David Griffin
Department of Electronic and Electrical Engineering
University College London
Torrington Place, London WC1E 7JE
United Kingdom
Phone: +44 (0)20 7679 7606
Email: dgriffin@ee.ucl.ac.uk
Christian Jacquenet
France Telecom
3, avenue Franois Chteau
CS 36901
35069 Rennes Cedex
France
Phone: +33 2 99 87 63 31
Email: christian.jacquenet@francetelecom.com
George Memenios
Algonet S.A.
206, Sygrou Avenue,
176 72 Kalithea
Athens
Greece
Phone: +30 210 955 8331
Email: memenios@egreta.gr
George Pavlou
Centre for Communication Systems Research (CCSR)
Univ. of Surrey, Guildford, Surrey GU2 7XH,
United Kingdom
Phone: +44 1483 689480
Email: G.Pavlou@eim.surrey.ac.uk
Olivier Poupel
Alcatel Research and Innovation
Route de Nozay
91461 Marcoussis
France
Phone: +33 1 69 63 47 07
Email: olivier.poupel@alcatel.fr
Yves T'Joens
Alcatel Corporate Research Center
Fr. Wellesplein 1, 2018 Antwerpen
Belgium
Phone: +32 3 240 7890
Email: Yves.TJoens@alcatel.be
Sven Van den Bosch
Alcatel Corporate Research Center
Goderis et al. Best Current Practice - Exp. April 2004 [Page 16]
Internet Draft Attributes of a SLS Template October 2003
Fr. Wellesplein 1, 2018 Antwerpen
Belgium
Phone: +32 3 240 8103
Email: sven.van_den_bosch@alcatel.be
Full Copyright Statement
Copyright(C)The Internet Society (2003). 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.
Goderis et al. Best Current Practice - Exp. April 2004 [Page 17]