is most in the spirit of DiffServ and at the same
time the service type that gives the least control
of the traffic distribution.
In the Figure 5 scenario we have in principle
three different ways of transporting traffic be-
tween edge routers. A given service component
traffic will be mapped to a CoS. The traffic can
then
a Be mapped to a PSC and carried by pure Diff-
Serv;
b Be mapped to an L-LSP designated for this
CoS solely;
c Be mapped to an E-LSP designated to this
CoS together with other CoS (up to 8 BAs).
In either case the possibility of reserving
resources must be discussed. This is of vital
importance for controlling traffic and assuring
QoS in a network with dynamically changing
traffic.
For the time being MPLS distinguishes itself as
the most promising way for introducing a con-
trol framework, both for service types ii and iii.
For service type iii a measurement based solu-
tion is proposed. For service type ii the traffic
volume in a given direction can be controlled by
the call admission control. But our framework
for dynamically changing the LSP bandwidth
parameters (see above) still applies. The decision
will then be based on the number of active calls
instead of traffic volume measurements.
Dimensioning and re-dimensioning for service
type ii can be done using
a An effective bandwidth approach for estimat-
ing the relationship between number of calls
and trunk (LSP) bandwidth demand;
b A call level module for dimensioning the
trunk bandwidth using traffic forecasts (call
level) and a call blocking objective.
Dimensioning and re-dimensioning for service
type iii requires new methods, and in the follow-
ing sections we discuss a framework where net-
work resources are re-dimensioned or re-config-
ured based on actual measurements of traffic in
the network.
A Measurement-based Approach for
Traffic Control
As discussed above the possibilities of reserving
resources is of vital importance for controlling
traffic and assuring QoS in a network with
dynamically changing traffic.
For LSPs some options can be discussed:i Scheduling is done on the individual LSP
level such that each LSP is given the reserved
bandwidth. The scheduler can then be used as
a shaper if no excess bandwidth is made
available to the LSPs. This may not be a scal-
able solution with a full mesh LSP network
between edge routers in the domain.ii Scheduling is done on an aggregated level
with one queue for each CoS, or rather a set
of CoS. This solution is better from a scala-
bility viewpoint, but only the aggregated
bandwidth of all traffic of the same queue is
guaranteed. The LSP bandwidth must there-
fore be enforced, or at least in some way con-
trolled, before queueing on the output inter-
face module (LSP parameter control).We presume that option ii is chosen. This gives
the following distribution of QoS mechanisms in
an edge router with MPLS:- Access interface upstream (direction from cus-
tomer): Classification, metering, action (drop
or (re)mark), forwarding; - Access interface downstream (direction
towards customer): Classification, metering,
action, queueing, algorithmic dropping and
possibly shaping; - Core interface upstream: Label encapsulation,
parameter control per LSP (classification,
metering, action), queueing, algorithmic drop-
ping and possibly shaping; - Core interface downstream: LSP termination
and forwarding.
The SLA monitoring is here indicated to take
place at the access interface of the edge router.
As mentioned above this should be done as near
to the user as possible. The SLA monitoring
could therefore be done in a router between the
user and the edge router.A conceptual model of the interface to the core
network is given in Figure 6, presuming a
unique mapping from LSP to DiffServ queue
(e.g. L-LSPs).The LSP monitoring in the edge routers will
be the basis for the bandwidth reservations as
described above. If this monitoring can be a
basis for reliable control of resources, e.g. by
introducing enough slack, LSP policing is not
necessary.