Side_1_360

An example is the service for traffic trans-

ported e.g. from Telenor R&D at Kjeller

to the Telenor headquarters in Oslo. This

approach is depicted in Figure 6.a, where

the points A, B and C are defined as input/

outputs for a traffic stream.

• Funnel approach– defines aggregate QoS
  between a specific ingress point to multiple
  egress points. An example is the QoS for IP
  transport services from the VoD server
  to any IP-based user. This approach is
  depicted in Figure 6.b, where the ingress
  point goes to a range of egress points for
  a traffic stream.


• Cloud approach– defines aggregate QoS
  between multiple points in the network. An
  example can be IP-based transport services
  realised within one network (note that one
  network here implies the network con-
  trolled/owned by a single operator). This
  approach is depicted in Figure 6.c, where
  any of the points attached to the ‘cloud’ can
  be either ingress or egress point for a traffic
  stream.

3.Service provider SLA– this type of the SLAs

are of special interest in the IP-based environ-

ment, since they open for many 3rdparty

providers, and a myriad of service providers

may be present. The operator has control over

the server side but not over the customer side

or the network performance. An example of

such an SLA can be relevant when designing

the SLA for an Application Service Provider

(ASP), or when offering web-hosting/co-loca-

tion service.

4.2 QoS Part in SLA for IP-based

Services

Following the generic structure presented in

Chapter 3, the content of an SLA for an IP ser-

vice may be made. Devising details is not possi-

ble if there are no ‘clear’ business model (i.e.

roles and relationships), service description and

implementation that all influence the final choice

of QoS parameters, grouping into QoS classes,

and the values of the parameters.

The issues of how the ITU-T’s I.350 3x3 matrix

approach may be applied for an IP transport ser-

vice and how the parameters are devised, are dis-

cussed next. According to [I.350] QoS parame-

ters could be primary or derived, and may be

expressed in a more technical or more “humans

understandable” language. Primary parameters

are those that are necessary to measure to prove

the performance as agreed, while derived param-

eters are actually functionally dependable on

the primary parameters and do not need to be

directly observed (i.e. measured/monitored).

Considering the primary QoS parameters, the

3x3 matrix approach identifies three generic

functions:

• Access;


• Information transfer;


• Disengagement.

Also three criteria for characterising the realisa-

tion of the generic functions are defined:

• Speedcharacterises the temporal aspects of
  QoS associated with a function, showing time
  related efficiency characteristics, e.g. latency/
  delay.


• Accuracycharacterises the degree of correct-
  ness with which a given function is realised,
  e.g. ratio of errored packets.


• Dependabilitycharacterises the degree of cer-
  tainty that a function is performed, e.g. ratio
  of failures on total attempts.

Although the above definitions for primary QoS

parameters apply to telecommunication services,

they can be generalised even for other types of

services.

As mentioned before, derived QoS parameters

are defined as functions of others. In particular,

derived QoS parameters can be defined on the

basis of observed values taken by primary QoS

parameters, and of decision thresholds for each

relevant primary QoS parameter. One example

of derived QoS parameters could be those char-

acterising the availability of a service.

When making a list of requirements the end-user

may express the request in a form of non-techni-

cal parameters. Such issues should be taken into

account by the provider and mapped into techni-

cal parameters related to those aspects.

Tunnel Approach to SLAs

Funnel Approach to SLAs Cloud Approach to SLAs

I

E

E

I

E

E

I

E

E

Figure 6 Types of SLAs for a
network connectivity service