Side_1_360

According to [ID_sfsls], the following principles

should be obeyed when designing the SLS and

corresponding negotiation process:

• Different languages/protocols should be
  allowed.


• Negotiation at different levels and of different
  complexity should be supported.


• The services should not be standardised.


• The structures of STS and SIS should be sim-
  ple for simple services, yet also allow for
  complex services.

The components of an SLS can according to

[ID_sfsls] be grouped as (note that this assumes

DiffServ-based services):

• Common unit: describes the terms of offering
  the service, e.g. identifying the provider, cus-
  tomer, service type, etc. The period of validity
  is a central component.


• Topology unit: describes the nature and num-
  ber of end points, further divided into one Ser-
  vice Access Point, SAP, sub-unit and a num-
  ber of graph sub-units. The SAP sub-unit
  gives a list of end points that specify the
  topology (like hose, pipe or funnel). The
  end points can for instance be given by IP
  addresses. The graph sub-unit gives a list of
  sources and destinations and how these are
  related. Unidirectional and bidirectional rela-
  tions may be described.


• QoS related unit: describes the traffic flows
  and the service differentiation provided.
  Quantitative and qualitative service levels
  may be given for some or all parts of the
  topology unit. This unit may further be

divided into: i) scope – giving the topology

unit (graph sub-unit or end point) relevant; ii)

traffic descriptor – describing the traffic flows

(including DSCP, port numbers, protocol

information and specification of lower layer);

iii) load descriptor – gives the quantity of

offered traffic, e.g. given by leaky bucket

parameters, as well as treatment of excess of

out-of-profile traffic; iv) QoS parameters –

delay, jitter and loss for the traffic flow.

• Monitoring unit: defines a set of parameters
  that are to be collected and reported between
  the customer and provider. The structure
  might be similar to the QoS-related unit.

Example of a schema to apply is also included

in [ID_sfsls] in addition to some selected exam-

ples.

4.2 Bandwidth Brokers

The Bandwidth Broker (BB) node is similar to

a Policy Decision Point (PDP), see Section 5, in

the sense that it makes decisions regarding band-

width provisioning. However, bandwidth bro-

kers tend to operate at a higher level than PDPs.

PDPs are typically connected to a (small) num-

ber of Policy Execution Points (PEPs) within an

administrative domain. They tend to be topol-

ogy-aware as a result of their role, e.g. in the

RSVP admission control process. Bandwidth

Brokers are aimed more at the interfaces be-

tween domains. They tend to be less aware of

the topologies within domains.

A BB refers to an abstraction that automates the

admission control decisions for service requests

in a network domain. This means that it is

responsible for keeping track of the current allo-

cation of reserved traffic, it is configured with

policies that define which traffic flows belong

to which traffic classes, and it interprets new

requests in the light of these policies and the cur-

rent bandwidth usage. In this sense, a BB can be

considered as a special type of policy server that

is responsible for those related policies for a net-

work domain. A BB is not necessarily a policy

manager but policy management and bandwidth

brokering will need to work together in provid-

ing integrated policy services and admission

control. Another important function of a BB is to

configure network devices according to admitted

QoS requests.

The concept of BB can be applied for managing

intradomain and/or interdomain traffic.

In the intradomain case, the BB manages the

resources based on the SLA that has been agreed

upon between domains. One or more protocols

are used to exchange information between a host

and a BB, and a BB and a router. The BB will

Figure 7 Communication
among BBs

BB1 BB2 BB3

AS1 AS2 AS3

SLSs SLSs

RARs

Inter-domain Communication

Intra-domain Communication

edge router

service

users