- Measurement schemes, like describing points
of observation, events to register and ways of
aggregating the data; - Reaction patterns, e.g. describing ways to act
in case any of the conditions are not fulfilled; - Management review process, like presenting
procedure for reviewing the agreement; and - Signatories.
This template is traditionally used for agreeing
on the provision of e.g. telephony service
between different Public Network Operators
(PNOs).
6.2 Internet Engineering Task Force
(IETF)
The presence and the effect of SLAs in the IP
world should be discussed bearing in mind both
existing best-effort services and the IntServ
[rfc1633] / DiffServ [rfc2475] architectures
suggested by IETF.
The best-effort service implies no guarantees
for the service provision, and hence asks for no
agreements in the operational phase. One argu-
ment is that available resources are shared indis-
criminately between the users; one service for
all. Some explicit statements describing the vol-
ume of traffic to be exchanged, e.g. between two
peering ISPs, can be found. On the other hand,
when DiffServ/IntServ-RSVP architectures are
implemented, the SLA becomes more pro-
nounced as a way of regulating the conditions
for service provisioning between a customer and
a provider, e.g. between an enterprise using the
services provided by an ISP.
Work currently under development within IETF
[policy], allows for a description of SLA schemes
in an abstract common language. SLA schemas
are described by a set of attributes. The attributes
may either be common to both IntServ/DiffServ
or specific for each of them. The common att-
ributes can include name, scope, type, address
range and max rate. Specific attributes for Diff-
Serv are e.g. Type Of Service (TOS) field masks
and patterns, and for IntServ e.g. flow service
type, maximum flows, token bucket parameters,
etc. On the other hand, SLA can be structured by
use of references. This allows the definition of
generic service profiles like a premium, gold,
standard service package, or a generic customer
class profile like economy, professional, etc.
IETF has focused more on TCS/TCA as de-
scribed in Chapter 2, and lately a lot of work is
done on this topic. As already mentioned SLS
describes the technical details related to the level
of the service provided to a traffic stream. It is a
rather new term, established in the IST Tequila
project, which at the moment is trying to consol-
idate interests on this topic and start a WG in
IETF. Four IETF drafts have been published on
this topic, and a number of RFCs related to the
DiffServ framework are handling issues related
to SLS and TCS.Here, a description of the template Tequila sug-
gests [many] and some examples of its usage
done by Aquila [aquila] are presented. A similar
template is elaborated on in AT&Tâs contribu-
tion [some].6.2.1 TCS and SLS in a DiffServ
Architecture
As the work in DiffServ WG progressed, it was
agreed that the notions of SLAs and TCAs
would be taken to represent the broader context,
and that new terminology used to describe those
elements of service and traffic conditioning is
introduced â namely SLS and TCS.The SLS may specify the packet classification
and (re)-marking rules and also traffic profiles
and actions to traffic streams that are within the
traffic profile as well as traffic streams outside
the traffic profile. The DS codepoint (DSCP) to
be used for mapping into the various DiffServ
classes may also be defined in the SLS. If multi-
field classifiers are used other elements in the
packet header have to be used for classification.
These elements have to be agreed on in the TCS.A TCS has as its scope the acceptance and treat-
ment of traffic meeting certain conditions and
arriving from a peer domain on a certain link.
More specifically, the TCS asserts that traffic of
a given DiffServ class, meeting specific policing
conditions, entering the domain on a given link,
will be treated according to a particular (set of)
Per Hop Behaviours (PHBs) and if the destina-
tion of the traffic is not in the receiving domain,
then the traffic will be passed on to another
domain (which is on the path toward the destina-
tion according to the current routing table state)
with which a similar (compatible and compara-
ble) TCS exists specifying an equivalent (set of)
PHB(s).The parameters10)included in the TCS/SLS may
be:10)Due to the unidirectional nature of connections, the two directions of a flow across the boundary
will need to be considered separately.