Diffserv support

Diffserv [3] 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.

Current state of Diffserv support

We implemented basic Diffserv-aware TE support into the toolbox and in particular the MAM (Maximum Allocation Model) bandwidth constraints model [4] and the RDM (Russian Doll Model) model [5]. We now give some brief explanations about MAM. If you would like to have more information, see [4]. 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

$$Reserved\_Bandwith(CT_c) \leq BC_c$$ (1)

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 (TEC) $i$ , all we have to check is that the unreserved bandwidth at priority $i$ (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.

Conventions

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.

Default behaviour

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.

No Diffserv fields in domain XML files

If you don't need Diffserv support, do not put any diff-serv fields 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>

under the <info> element.

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>

where bandwidth is 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>

where bc_id_0 is 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.

Info field specified but static or dynamic information missing

Suppose now that you want to specify some priority levels but don't want to specify specific information for static and dynamic fields of all links. In this case, here is the default behaviour.

Suppose we specify the following information in the <info> field.

 <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>

Thus we have 2 CTs: 2 accepted preemption levels for the first and 4 for the second.

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>

One constraint is thus defined for each CT, and their value is equal to the maximum reservable bandwidth divided by the number of CTs.

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.

Adding a reservation

Suppose you want to establish an LSP of priority $i$ (i.e. a couple of CT and preemption level) with reservation $b$ . You have to check for each link in the path the unreserved bandwidth for this priority level is bigger than $b$ . If it is, you can add this reservation. Now, you may want to not specify a priority (this parameter being often optional). In this case the considered priority level is the least priority existing one (i.e. least priority CT, and in this class type, lowest preemption level).

Preemptions

A basic preemption mechanism had been developed to allow preemption inside CTs and inter CTs.

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.

$$\sum_c BC_c > Max\_Reservable\_Bandwidth$$ (2)

Here is how the preemption mechanism works :

• Lowest preemption levels are looked first for LSPs to preempt.
• If only one LSP can be preempted at least preemption level to free enough bandwidth, it is preempted.
• If not, arbitrary LSPs of least preemption levels are preempted.

Preempted LSPs are removed from the domain.

DS-TE

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.