Side_1_360

approaches. The main difference is that the

Aquila consortium has introduced the concept

of predefined SLS types that are based on the

generic SLS definition. These predefined SLS

types can be used to simplify the interaction

between the customer and the network. From the

applications viewpoint, a predefined SLS type

supports a range of applications that have similar

communication behaviour and therefore similar

QoS requirements, such as for delay, packet loss,

etc. From an operator’s point of view it simpli-

fies the network management and allows effi-

cient flow aggregation.

In a DiffServ network the SLS parameters should

be used to map the user requirements into inter-

nal QoS mechanisms (e.g. DiffServ classes). The

mapping process between the generic SLS and

the concrete QoS mechanisms can be very com-

plex if the user can freely select and combine the

parameters. Naturally, in a DiffServ network

there will be a restricted number of service

classes handled in the core.

The SLS type in Aquila distinguishes between a

customised SLS and a predefined SLS type. In

the instance of a customised SLS all the parame-

ters can be specified, whereas in the instance of

a predefined SLS only a subset of the parameters

must be specified. The predefined SLS types in

Aquila are:

• PCBR – Premium CBR;


• PVBR – Premium VBR;


• PMM – Premium MultiMedia;


• PMC – Premium Mission Critical.

Both quantitative and qualitative performance

guarantee attributes are foreseen. The quantita-

tive values can be expressed as maximum val-

ues, mean values or percentiles. The qualitative

attributes can be used to express relative guaran-

tees between different classes.

The delay is meant as the one-way delay, the jit-

ter is defined as the variation of one-way delay

(max delay – min delay) of a flow. The details of

the measurement procedure to evaluate statistics

parameters like percentiles or mean values

should be defined.

6.3 TeleManagement Forum (TMF)

As mentioned before, the content of an agree-

ment may differ depending on the interface it

relates to. In other words, an agreement between

a user and a service provider (SP) would differ

from the agreement between two service pro-

viders. When considering an SP-SP agreement,

Telecom Management Forum (ex NMF) defined

business models and related processes which

could be used to define the potential content of

the different SLA types.

The work done in NMF considers so-called end-

to-end SLA11), which should contain agree-

ments about the following issues/topics:

• The service type and customised service tem-
  plate;


• Definition of common business processes
  (e.g. in the context of NMF Business Process
  model);


• Common QoS needs;


• Technical constraints;


• Definition of relevant QoS/performance
  parameters for the end-to-end relationship;


• Notifications and actions in case of problems;


• References to management interface types
  being supported (e.g. X.user, X.coop);


• Common management policies;


• Common security requirements, methods,
  policies;


• Common trouble administration interfaces,
  policies;

11)As mentioned before, there are numerous definitions of the agreement, SLA, etc. The one from

NMF on the “end-to-end SLA” is “an SLA between multiple SPs, which defines common agree-

ments between all parties involved in the service provisioning/consuming process” [NMF701].

Attribute Measurement unit

Quantitative maximum Delay (ms)

Quantitative maximum Jitter (ms)

Quantitative maximum Loss Ratio

Quantitative Delay percentile (percentile; ms)

Quantitative Jitter percentile (percentile; ms)

Quantitative mean Delay (ms)

Quantitative mean Jitter (ms)

Qualitative Delay (medium/low/very low)

Qualitative Jitter (medium/low/very low)

Qualitative Loss Ratio (medium/low/very low)

Table 1 Performance
guarantee attributes