A new MPLS model inside JavaSim

JavaSim is a network simulator written in Java. It is developed by Hung-ying Tyan and some other people at the Ohio State University. This simulator is open source and portable. The Infonet Group of the University of Namur has developed several new components. Indeed, we already provided a BGP model for JavaSim and now we provide an MPLS model.

The MPLS model provided inside JavaSim is not flexible. Indeed, you can associate only statically an outgoing interface and an outgoing label with an incoming label and incoming interface. This is not really adapted if you plan to support RSVP-TE protocols and dynamic Label Switched Path (with stack of labels and associated operations, etc.). That's why we choose to build some new components. Of course, it is a first step towards the support of RSVP-TE inside JavaSim.

Download

 To support MPLS inside Javasim, we have done some modifications inside the simulator. Currently we are using a patched version of JavaSim 1.0. We have also ported our modifications to the latest version of the simulator, that's why we also distribute a patched version of Javasim 1.2.1. The implementation of MPLS is compatible with these two versions of Javasim. Note that our BGP model is currently only available for Javasim 1.0, so if you plan to use MPLS and BGP together, you must use our snapshot of Javasim 1.0.

For all version, you need the infonet util package. Don't forget to install it. Please note that the date refers only when the package has been added to our website ! All packages contains the lastest version of our code !

Source only version Source and compiled version (NOT SUPPORTED)

for all versions

Description of this MPLS model

1. Introduction

We choose to add two components: a forwarding table component and a MPLS component. The forwarding table component keeps all information about configured labels (like the routing table component keeps information about routes). It associates an IP prefix or an incoming label with an outgoing interface and an outgoing label. The MPLS component is located between the down port of the CSL and the packet dispatcher as can be seen on the figure below. It routes packets according to the configuration of the F.T.
CSL image

2. Our model

As mentionned above, we developed two new components, the forwarding table and the MPLS component. To create a MPLS compliant node, we also developed a specific CSL builder called MPLSBuilder. It connects components correctly inside the CSL. As we have seen, the forwarding table keeps information about labels: it links a label or a IP prefix to an outgoing interface and an operation list. This list contains an operator (SWAP, PUSH or POP) and a label as argument. These operators are applied on label carried in the packet. The MPLS component defines a new port on the CSL, the .service_ft port. It allows to configure the FT component from components outside of the CSL. This port can be used by any upper components to configure dynamically the forwarding table.

We also define a new type of packet: the Label Switched Path packet (called LSP in the following). It is used to carry MPLS information like a stack of labels and another packet (an IP packet for instance). The stack of labels is used with the operator to store appropriate label inside the packet. These packets are used by the MPLS component of a node to bypass normal routing.

The MPLS component is located between the down port of the CSL and the packet dispatcher. This component receives packets from other nodes. According to the received packet and the configuration of the forwarding table, this component decides where the packet is sent. If it is an LSP packet, the MPLS component look up inside the FT and forwards the packet according to the record found. If it receives an IP packet, it also looks inside the F.T. to see if it needs to encapsulate this packet inside a new LSP (that's why the forwarding table can associate a label to an IP prefix). If no record is found for a given IP prefix, the packet is sent to the packet dispatcher and routed normally.

3. Configuration and simulation script

3.1 Configuration of the F.T. component

Before sending data, it is necessary to add some information inside the FT component. For this purpose, you can use two methods: 
node/csl/ft addLabelEntry label outif timeout operation
It adds a new entry inside the F.T. This entry links a (incoming) label to a outgoing interface and an operation list. Description of arguments: Example:
! n1/csl/ft addLabelEntry 1 2 90.0 "POP 0"
Add an entry in the F. T. of the node n1. When a LSP packet with the (incoming) label 1 is received, it removes the label at the top of the stack (POP) and sent this packet on (outgoing) interface 2. Note that this entry expires after 90.0 seconds.
node/csl/ft addPrefixEntry destIP destMask outif timeout operation
This function adds a "prefix" entry in the F.T.: it links a IP prefix to an outgoing interface and an operation list. The arguments are: Example
! n2/csl/ft addPrefixEntry 0x05 0xFFFFFFFF 1 30.0 "PUSH 1:PUSH 1:PUSH 2"
Adds a prefix entry. When an IP packet towards the IP address 5 (0.0.0.5) is received, this packet is encapsulated inside a LSP packet, its label stack is appended with 3 new entries: 1, 1 and 2. That means that the label at the top of the label stack is now 2. Then, the packet is sent on interface 1. Note that this entry expires after 30 seconds.


Another way to store information inside the F.T. is to rely on some files. Indeed, it's possible to put in a file the content of the F.T. The following function can be used: 
node/csl/ft loadFromFile path
The argument path of this function gives the path to the file that holds data for the F.T. This argument is a string, so it requires double quotes.

Description of the format of the file. This file is line-based. We can have two types of lines:
L inlabel outif timeout {op label}+
I destIP destMask outif timeout {op label}+
The first character informs about the type of the entry. L stands for "Label entry", I stands for "IP prefix entry". The label entry is used to link a label to its outgoing interface and oprations on labels while the prefix entry is used to link an IP prefix to its outgoing interface, label, ... Note that the line ends with a repetition of the tuple {op label} that means that you can specify more than one operation associated with an entry. Description of each argument:
Example
! n3/csl/ft loadFromFile "./ft.content"
With the following file ft.content:
I 00000005 FFFFFFFF 1 90.0 1 1 1 1
I 00000007 FFFFFFFF 1 90.0 1 1 1 1 1 2
L 1 2 90.0 2 0

This file mentions that 3 records will be added into the F.T. The first one describes an prefix entry. It associates the IP prefix 5 (0.0.0.5), the outgoing interface 1. Two operations are specified: label 1 is pushed twice. The second line is also a prefix entry: prefix 7 (0.0.0.7), outgoing interface 1, operation: PUSH 1 - PUSH 1 - PUSH 2. The last entry is a label entry that links the incoming label 1 with the outgoing interface 2 and the following operation list: POP 0. Note that all entries are valid only 90.0 (simulated) seconds.

3.2 Creating an MPLS compliant node

Instead of using traditional CSL builder, it is required to use our builder, called MPLSBuilder. This module adds all required components inside the CSL and links them together. So you have to add in your code:
set mpls [mkdir infonet.javasim.MPLS.MPLSBuilder .mplsBuilder]
This line creates an MPLS Builder node inside the mpls variable. Now, we can use it to create compliant MPLS nodes:
set nb [mkdir drcl.inet.NodeBuilder .nodeBuilder]
$nb build [! n?] $mpls
These last two lines create a NodeBuilder and creates the topology. See our sample scripts for more details about the setup of the simulation.

Contact information

 If you have some questions or if you need more information, you can contact the authors.
Version of this document: 20030519-03-lsw; last-update: 19-MAY-2003