The DiffServ architecture [rfc2475] developed in
the IETF defines an SLA as a “service contract
that specifies the forwarding service a customer
should receive”. The SLA may include traffic
conditioning rules which (at least in part) consti-
tute a TCA. The DiffServ WG [diffserv] is
changing their understanding of this term, since
the terms SLS and TCS (see Sections 2.3 and
2.5) are introduced. The DiffServ WG came to
believe that the notion of an ‘agreement’ implied
considerations of a pricing, contractual or other
business nature, as well as those that were
strictly technical. There could also be other tech-
nical considerations in such an agreement (e.g.
service availability) which are not addressed by
DiffServ WG. Therefore the DiffServ WG
agreed that new terminology would be used to
describe those elements of service and traffic
conditioning that are addressed by DiffServ.
According to the latest draft on the DiffServ
terminology [id-term], terms of SLS and TCS
are introduced, as explained later.
Hence, SLA and TCA terms are considered in
a broader sense than in [rfc2475], [rfc2474],
[rfc2597], and this change will be introduced
in the RFCs published by this WG.
SLAs are further discussed both in general and
for IP in particular in Chapter 3.
2.3 Service/Service Component
Technical Level – SLSs
An SLS consists of technical parameters and
conditions related to serving a traffic flow using
an IP transport service. An SLS would typically
include:
- The type and nature of the service to be pro-
vided. All the components should be identi-
fied and described. The description of compo-
nents related to particular interfaces is not a
trivial task. - The QoS of the service provided (this part will
be elaborated on in the following section). - The process of monitoring service provision
(and QoS), i.e. which statistics to collect and
present. - Any technical consequences and the reaction
pattern for the cases when either the user or
the provider did not obey conditions agreed.
Additionally, the constraints on user behaviour
may be included (e.g. the type of equipment nec-
essary to experience the quality as agreed).
Escape clauses may be included to define when
the statements from the agreement do not apply
- e.g. a fire damaged the provider’s equipment,
etc.
Note that SLS is a rather new term, introduced in
1999 by the IST project TEQUILA, and the
topic is still under development. The definition
given at the beginning of this section is adapted
from [id-term] where DiffServ WG suggests the
introduction of the SLS term. Their understand-
ing of an SLS is that it is “a set of parameters
and their values which together define the ser-
vice offered to a traffic stream by a DS domain”.
The definition of ‘Traffic stream’ is unchanged
from [rfc2475], that is “an administratively sig-
nificant set of one or more microflows which
traverse a path segment. A traffic stream may
consist of the set of active microflows which are
selected by a particular classifier.” Simply, it
means that a traffic stream can be an individual
microflow or a group of microflows (i.e. in a
source or destination DS domain), or it can be a
Behaviour Aggregate (BA). Thus, an SLS may
apply in the source or destination DS domain to
a single microflow or group of microflows, as
well as to a BA in any DS domain.The results available in the IETF and in
TEQUILA and other projects adopting SLS
notions are presented in Chapter 6.2.4 Traffic level – TCAs
This term is related to the provisioning of IP ser-
vices and is defined by the IETF. According to
[rfc2475] TCA is defined as “an agreement spec-
ifying classifier rules and any corresponding
traffic profiles and metering, marking, discard-
ing and/or shaping rules which are to apply to
the traffic streams selected by the classifier. A
TCA encompasses all of the traffic conditioning
rules explicitly specified within a SLA along
with all of the rules implicit from the relevant
service requirements and/or from a DS domain’s
service provisioning policy.”Note that the TCA refers to rules executed at the
border of a DiffServ domain. Thus a TCA is
given for a certain class, identified according to
the fields relevant for DiffServ. Examples of
these sets for fields are found in [rfc2475] like:i) Multi-Field (MF): combination of one or more
header fields, such as source address, destina-
tion address, DS field, protocol ID, source
port and destination port numbers, and other
information such as incoming interface, or,ii)Behaviour Aggregate (BA): based on the DS
codepoint only.TCA refers to a traffic flow, its characteristics
and mechanisms to use in order to ensure/
enforce that the characteristics are followed.