Side_1_360

communicate with the user via Resource Alloca-
tion Requests (RARs) to receive the request for
bandwidth and to indicate success or failure. The
BB will also communicate with the edge routers
to set traffic conditioning parameters corre-
sponding to accept reservations. Examples of
protocols that can be used to communicate with
routers are DIAMETER, SNMP and COPS,
while protocols for communicating with hosts
may include RSVP, COPS, web interfaces
(HTTP) and DIAMETER.

In the interdomain case, the BB is also responsi-
ble for managing interdomain communication
with BBs in neighbouring networks, for the pur-
pose of co-ordinating SLAs across boundaries.
In order to co-ordinate bandwidth assignments
across domains, a single inter-domain BB proto-
col must exist.

Figure 7 shows a sample network configuration.
It consists of three domains AS1, AS2, and AS3
with a BB for each one (BB1, BB2 and BB3).
The SLAs are placed between AS1 and AS2,
and between AS2 and AS3. A BB communicates
with users (terminals or servers) requesting ser-
vice via RARs, other BBs, and network devices
(i.e. routers). In this case, a user can be either an
end system or an application that requests band-
width.

The Bandwidth Broker makes decisions based
on the network topology and the network traffic
characteristics. The network topology consists of
a description of all available network resources:
nodes, links, link metrics, physical link capaci-
ties, allocatable link capacity, resource class
(gold links, links only to be used for premium
customers, ...), etc. The network traffic charac-
teristics are expressed as a set of traffic trunks,

which mainly express a bandwidth requirement

between core edge nodes. This information is

supplied by the policy manager, which is a stor-

age of committed SLSs.

On the basis of the topology and network traffic

characteristics, different indicators can be calcu-

lated by the Bandwidth Broker such as the link

loads. This information can be used to determine

whether a new SLS can be accepted or not. The

position of the Bandwidth Broker is depicted in

Figure 8.

4.3 AAA Functionality

Providing a service commercially it has to be

supported by corresponding AAA functionality.

The Internet Research Task Force (IRTF) has

an Authentication Authorisation Accounting

ARCHitecture Research Group (AAAARCH)

that develops an AAA architecture. This can be

said to apply a policy-based approach.

Accounting can be seen as included in the ser-

vice provisioning process (called integrated

accounting) or it can be offered as a separate ser-

vice (called discrete accounting). In the former

the accounting is coupled to a specific service,

collecting relevant information by using service

specific entities. A configuration for this is de-

picted in Figure 9. Then a common Application

Specific Module (ASM) contains functions for

providing the AAA services. This means that it

transforms instructions from the AAA server

into appropriate commands for the equipment.

Relevant data on the resource usage is returned

by the meters to the ASM, which compiles (con-

version, aggregation, filtering) the metered data

into accounting records and forwards them to the

AAA server.

Figure 8 Location of

Bandwidth Broker

QoS Policy Manager

SLA Monitoring

Performance

Manager

Bandwith

Broker

Routing

Updates

Network

Perf. Stats

CPE POP Core POP CPE

Network Traffic

Database

Network Configuration

Database (topology)