Diffserv  support is implemented into the toolbox. If you don't want to use Diffserv, you just have to avoid putting Diffserv fields in the different XML files, and to never use the Java methods which specify a priority level.
We implemented basic Diffserv-aware TE support into the toolbox and in
particular the MAM (Maximum Allocation Model) bandwidth constraints
model  and the RDM (Russian Doll Model) model .
We now give some brief explanations about MAM. If you would like to have
more information, see . Suppose we have a certain
number of categories of services (called Class-Types or CTs) and the same
number of associated bandwidth constraints (BCs). MAM states that
What we call a priority level in this document is in fact a Traffic
Engineering Class (TEC), i.e. a combination of a CT and a preemption priority allowed
for that CT. During admission control on a link for a reservation at priority
, all we have to check is that the unreserved bandwidth at priority
(stored in the toolbox database) is larger than the bandwidth requested by
this reservation. This unreserved bandwidth per priority level is the data
that should be advertised in IGP link state packets.
We also implemented a basic preemption support.
It is always considered that a higher numerical value corresponds to less priority traffic, i.e. traffic from CT 0 should correspond to more important traffic than traffic from CT 1. And traffic with preemption level 0 has more priority than traffic with preemption level 1.
We will explain here the behaviour you can expect from the Diffserv manager integrated into the toolbox when specifying some Diffserv fields in domain XML files.
diff-servfields into the
<info>field of the domain XML file (see section 3.1.1). However note that the following information will be added automatically
<diff-serv> <priority id="0" ct="0" preemption="0"/> </diff-serv>
Then, concerning links, the following information will be added in the
<static> section (see section 3.1.4)
<diff-serv> <bcm>MAM</bcm> <bc id="0">bandwidth</bc> </diff-serv>
bandwidthis the total bandwidth of the link.
Some fields will also be automatically added in the
<dynamic> section (see section 3.1.4)
<rbw> <priority id="0">bc_id_0</priority> </rbw>
bc_id_0is the value of the bandwidth constraint (bc) with id 0.
Thus the reservable bandwidth at the unique priority 0 is set the link bandwidth. This is the behaviour you expect when you don't want to use Diffserv.
Suppose we specify the following information in the
<diff-serv> <priority id="0" ct="0" preemption="0"/> <priority id="1" ct="0" preemption="1"/> <priority id="4" ct="1" preemption="0"/> <priority id="5" ct="1" preemption="1"/> <priority id="6" ct="1" preemption="2"/> <priority id="7" ct="1" preemption="3"/> </diff-serv>
If you do not specify Diffserv information in the static link fields,
following information will be added in the
<static> section of the link.
<diff-serv> <bcm>MAM</bcm> <bc id="0">bandwidth/2</bc> <bc id="1">bandwidth/2</bc> </diff-serv>
Dynamic information is set accordingly.
<rbw> <priority id="0">bc_id_0</priority> <priority id="1">bc_id_0</priority> <priority id="4">bc_id_1</priority> <priority id="5">bc_id_1</priority> <priority id="6">bc_id_1</priority> <priority id="7">bc_id_1</priority> </rbw>
Note that if you choose to specify some BC values for some links, dynamic information will also be set according to the values you specified.
In fact with the MAM model, preemption between CTs can be useful only if the following condition holds true, which is not of common use.
Here is how the preemption mechanism works :
Preempted LSPs are removed from the domain.
Classes of service can be used to implement Diff-serv Aware MPLS TE (see RFC 3564). The TOTEM toolbox offers the possibility to define different classes of service in the domain. LSPs can then be used to route only traffic for some of the classes of service. This is done by specifying the accepted_cos on the established LSPs (defining an L-LSPs or an E-LSPs).
Note that there is currently no way to define different PHBs for the classes of services and thus enforce the QoS constraints. The bandwidth reserved by the LSP is not used to limit the rate at which traffic is routed on the LSPs. We cannot at the moment define priority queues, WFQ, or bandwidth limitation for the different classes of services. All the traffic is routed on the LSPs (if the class of service is accepted by the LSP) and we cannot observe dropped traffic due to exceeded rate or queue size on a particular node.Simon Balon 2008-06-18