Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

IP/MPLSView Support for DS-TE LSP

 

IP/MPLSView supports both DiffServe-aware Single-Class LSPs and DiffServ-aware Multi-Class LSPs, according to the specifications in existing hardware. These LSPs can be parsed from existing router configuration files, or they can be manually created from scratch using IP/MPLSView for a paper network design.

Class Types

IP/MPLSView’s class type terminology corresponds with that used in JUNOS configurations. The four class type names are CT0, CT1, CT2, and CT3. These class type names appear in the JUNOS configuration statements:

Single-class LSP

Multi-class LSP

label-switched-path lsp-name {
bandwidth {
ctnumber bandwidth;
}
}
label-switched-path lsp-name {
bandwidth {
ct0 bandwidth;
ct1 bandwidth;
ct2 bandwidth;
ct3 bandwidth;
}
}

EXP Bits

The Experimental bits, or EXP bits, in the MPLS header are used to define the class to which a packet belongs. A unique EXP bit pattern is associated with each class type and forwarding class defined on a DiffServ-aware router. IP/MPLSView allows the user to define the mapping between EXP bits, class types, and forwarding classes.

CoS Classes

The CoS class defined in IP/MPLSView is equivalent to the forwarding class configured in JUNOS, as in the following configuration structure.

Cos Policies

IP/MPLSView’s CoS policy is equivalent to the scheduler map defined in JUNOS. A CoS policy contains information on how to treat each CoS class referenced by the CoS policy. The treatment given to each CoS class at a router is determined by the CoS policy assigned to that router. Applying a CoS policy to a router is similar to applying scheduler maps to the interfaces on that router, as in the configuration structure below.

IP/MPLSView allows the user to define a robust set of Cos policies and to easily assign them to any router in a network. The CoS Policy determines the amount of bandwidth reserved on a link for each traffic class contained in the policy. The bandwidth reservation scheme for each router affects how DiffServ-aware LSPs are routed in the network.

Bandwidth Model

IP/MPLSView supports both MAM and RDM bandwidth models. The MAM bandwidth model used when configuring DiffServ-aware LSPs in IP/MPLSView is equivalent to the extended-MAM bandwidth model used in JUNOS configuration, as shown below.

The choice of whether to use MAM or RDM in IP/MPLSView affects the way in which bandwidth is assigned to a multi-class LSP, and the manner in which bandwidth is reported for a link with bandwidth partitions for multiple classes. For example, in a situation where CT0, CT1, CT2 and CT3 are all reserved 10M, the link partition will be reported differently depending on whether the bandwidth model is MAM or RDM, as shown in the table below.

MAM

RDM

CT0: 10M

CT1: 10M

CT2: 10M

CT3: 10M

CT0: 40M

CT1: 30M

CT2: 20M

CT3: 10M

In the above example, for MAM, each class gets 10M. For RDM, each class also gets 10M. However, in RDM, CT2 has access to the 10M belonging to CT3, and thus has 20M total available. CT1 has its own 10M plus the 20M available to CT2, and thus ends up with 30M total. Since CT0 is at the top of the stack, it receives its own 10M plus all the bandwidth available to the classes below it, for a total of 40M.

Similarly, if one were to configure a multi-class LSP with 90M reserved for CT0 and 10M reserved for CT3, the configuration would look differently depending on the bandwidth model used. This is shown in the table below.

MAM

RDM

CT0: 90M

CT1: 0M

CT2: 0M

CT3: 10M

CT0: 100M

CT1: 0M

CT2: 0M

CT3: 10M