- TSpec summed may be calculated by: i) the
sum of token bucket rates; ii) the sum of
bucket sizes; iii) the sum of peak rates; iv)
the smallest minimum policed unit; and v)
the maximum packet size, across all flows
in the set. - TSpec as a least common “measure” is one
that is sufficient to describe the traffic of any-
one in the set. It may be calculated by: i) the
largest token bucket rate; ii) the largest bucket
size; iii) the largest peak rate; iv) the smallest
minimum policed unit; and v) the largest max-
imum packet size, across all flows in the set.
It differs from the merged flow by the way
the maximum packet size is found. Note that
merge refers to characteristics of packet flows
while least common refers to requests on the
resource capabilities.
Values of the RSpec field can be considered in
a similar way as for the TSpec field; i.e. a set of
RSpecs is merged into a single RSpec by taking
the largest rate R, Rout= maxj{Rj} and the
smallest slack S, Sout= minj{Sj}.Consider a node along the path, see Figure 21.
When it receives a setup message containing the
TSpec and RSpec fields, it has to estimate the
values to assign to the RSpec parameters on the
outgoing side (when the setup message is passed
on to the following node).The overall rule for determining the new RSpec
values is given by the delay constraint:where Ctot_iis the cumulative sum of “devia-
tion” terms, C, for all network elements in the
upstream (between the destination and node i),
including node i.To ensure no loss of flow, some portion of a
buffer has to be allocated. If a fluid flow model
would be adequate, this amount would simply be
equal to b, the token bucket size. However, tak-
ing into account that the traffic flow may gain
burstiness in the network, some margin should
be considered. An estimate of the needed buffer
space is, ref. [RFC2212]:buffer space =whereCsumand Dsumare considered for the aggregate
using that buffer space.Using these estimates, both expressions for
assigning resources in the node and expressions
for finding the parameter values in the setup
message on the outgoing side are given.In order to provide the performance guarantees
as stated by the IntServ node, several queues are
used per output interface, in combination with
scheduling and buffer management as depicted
in Figure 19. As guarantees are provided on a
per flow basis for the Guaranteed Service, a sep-
arate queue per flow could be needed. However,
a common queue can be used for a group of
flows in case these have similar requirements on
delay and loss. In particular, a common queue
can be used for flows requesting Controlled
Load service.Three groups of queues may therefore be seen;
one set for flows in the Guaranteed Service
class, one set for flows in the Controlled Load
class, and one set for flows in best effort class.
The two latter classes might consist of a com-
mon queue. Appropriate scheduling mechanisms
are then applied to serve the queues such that the
service level guarantees given to the flows are
kept.6 Multi-Protocol Label
Switching, MPLS
At the IP layer (layer 3) a router makes forward-
ing decisions for a packet based on information
in the IP header. The analysis of the packet
header is performed and an algorithm is exe-
cuted in each router to decide upon further treat-
ment. This can be viewed as a two step process,
ref [RFC3031]: i) The packets are classified into
a set of Forwarding Equivalence Classes
(FECs); ii) Each FEC is mapped to a next hop.The following advantages of MPLS are listed in
[RFC3031]:- MPLS forwarding can be done by nodes in-
capable of analysing the IP packet headers,
X=r ,ifb−M
p−r
<Csum
R
+DsumR ,if b−M
p−r≥Csum
R⎧⎨ +Dsum
⎩⎫
⎬
⎭∧{}p>r
p , otherwise⎧⎨⎪
⎪
⎪⎩⎪
⎪
⎪
Figure 21 Relations between
parameters in incoming and
outgoing side of a node have
to be foundRSpec_out (Rout, Sout) RSpec_in (Rin, Sin)Node i
Rin ≥ Rout ≥ r
Sin - Sout = consumed slack in node
Sout+
b
Rout+
Ctoti
Rout
≤Sin+
b
Rin+
Ctoti
RinM+(b−Mp)−·(rp−X)+X·(
Csum
R +Dsum)