The objective of the project “Implementation of MPLS (MultiProtocol Label Switching) in Core IP Routing” was to show the deployment of labels in packet forwarding.
Socket Calls were used to simulate a network over the actual LAN. The computers on the LAN were interconnected using bus topology. We demonstrated our implementation of MPLS using four networked computers. Socket calls were used to create a path between them and these paths were assumed to be the physical connections. In this fashion we created our simulated network over which we demonstrated deployment of label switching technique.
We showed the forwarding of packets using conventional IP routing and then the forwarding of packets using label-switching technique. Thus showing the simplicity and efficiency prevalent in the use of labels to forward packets.
In this implementation we have shown the behaviour of LSRs on receipt on labeled packets as well as unlabeled packets and its response to the same.
We demonstrated use of MPLS simplifies the implementation of traffic engineering where the packet follows a predefined route to reach the destination. Thus we have successfully achieved the target.
Version Control:
|
Ver1.1: Began initial coding
Ver1.2: implemented basic server. No network related stuff implemented. Static implementation of reading the LIB table and initializing the various data structures done.
Ver1.3: Implemented network support.
Ver1.4: ‘sendpacket’ and ‘sendlabelpacket’ implemented. LIBENTADD support added
Ver1.5: LIBENTADD support removed. ‘putoniface’, ‘sendpacket’ and ‘sendlabelpacket’ modules debugged.
Daemon Facility:
The server can be started as a daemon process i.e. it resides in memory once initialized, with no direct user control. The error and warning messages are redirected to the specified log file (/tmp/mplsd.log).
Messages logging through ‘syslog’:
The following functions are used to handle error conditions and can be used in both client and server programs. In the former case the error messages are generated on the ‘stderr’ stream, while the latter case uses the 4.3BSD ‘syslog’ facility.
These functions define three levels of error:
1. Nonfatal, return to caller. err_ret.
2. Fatal, terminate process. err_quit.
3. Fatal, terminate process and dump core: err_dump.
Finite State Machine (FSM) for LIB file parsing:
 |
Tab5.1 State function:
|
Sp |
‘\0’ |
‘.’ |
d |
# |
Else |
|
State 0 |
0 |
9 |
10 |
1 |
9 |
10 |
|
State 1 |
2 |
10 |
10 |
1 |
10 |
10 |
|
State 2 |
2 |
10 |
10 |
3 |
10 |
10 |
|
State 3 |
4 |
10 |
10 |
3 |
10 |
10 |
|
State 4 |
4 |
10 |
10 |
5 |
10 |
10 |
|
State 5 |
6 |
10 |
5 |
5 |
10 |
10 |
|
State 6 |
6 |
10 |
10 |
7 |
10 |
10 |
|
State 7 |
8 |
11 |
7 |
7 |
11 |
10 |
|
State 8 |
8 |
11 |
10 |
10 |
11 |
10 |
|
State 9 |
9 |
9 |
9 |
9 |
9 |
9 |
|
State 10 |
10 |
10 |
10 |
10 |
10 |
10 |
|
State 11 |
11 |
11 |
11 |
11 |
11 |
11 |
State 9: Accept continue state: state reached when the line starts with comment
State 10: Reject
State 11: Accept: LIB entry on the line is accepted
Tunneling can be implemented by making provisions for the packets to carry label stack instead of a single label. It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. The tunnel would be a LSP <R1, ..., Rn>, where R1 is the transmit endpoint of the tunnel, and Rn is the receive endpoint of the tunnel. This is called a "LSP Tunnel".
The set of packets that are to be sent through the LSP tunnel constitutes a FEC, and each LSR in the tunnel must assign a label to that FEC (i.e., must assign a label to the tunnel). The criteria for assigning a particular packet to an LSP tunnel is a local matter at the tunnel's transmit endpoint. To put a packet into an LSP tunnel, the transmit endpoint pushes a label for the tunnel onto the label stack and sends the labeled packet to the next hop in the tunnel.
If it is not necessary for the tunnel's receive endpoint to be able to determine which packets it receives through the tunnel, as discussed earlier, the label stack may be popped at the penultimate LSR in the tunnel.
A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as an hop-by-hop routed LSP between the transmit endpoint and the receive endpoint.
Hierarchy: LSP Tunnels within LSPs:
Consider a LSP <R1, R2, R3, R4>. Let us suppose that R1 receives unlabeled packet P, and pushes on its label stack the label to cause it to follow this path, and that this is in fact the Hop-by-hop path. However, let us further suppose that R2 and R3 are not directly connected, but are "neighbors" by virtue of being the endpoints of an LSP tunnel. So the actual sequence of LSRs traversed by P is <R1, R2, R21, R22, R23, R3, R4>.
When P travels from R1 to R2, it will have a label stack of depth 1. R2, switching on the label, determines that P must enter the tunnel. R2 first replaces the Incoming label with a label that is meaningful to R3. Then it pushes on a new label. This level 2 label has a value which is meaningful to R21. Switching is done on the level 2 labels by R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, pops the label stack before forwarding the packet to R3. When R3 sees packet P, P has only a level 1 label, having now exited the tunnel. Since R3 is the penultimate hop in P's level 1 LSP, it pops the label stack, and R4 receives P unlabeled. The label stack mechanism allows LSP tunneling to nest to any depth.
A fundamental concept in MPLS is that two LSRs must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures called Label Distribution Protocol (LDP), by which one LSR informs another of label bindings it has made.
LDP associates a FEC with each LSP it creates. The FEC associated with an LSP specifies which packets are “mapped” to that LSP. LSPs are extended through a network as each LSR “splices” incoming labels for a FEC to the outgoing label assigned to the next hop for the given FEC.
In this section, we consider only label bindings that are used for traffic to be label switched along its hop-by-hop routed path. In these cases, the label in question corresponds to an address prefix in the routing table.
 |
 |
 |
CPIB (Control Plane Information Base):
From: the label binding requestor
Active: contains YES if current entry is part of LIB, contains NO when entry is created but no label binding information exists or the entry is not in use.
Inlab: contains the incoming label value
Outlab: contains the outgoing label value
Outiface: the next hop address
FEC: the concerned FEC.
The MPLS server will read the routing table maintained in the disk file instead of LIB entries. The routing table will have two entries namely: [next hop] and [Destination address]. The destination address can be specified as DEFAULT for any address that does not have an explicit route in the table.
LBLBIND packet structure:
|
LBLBIND |
Label |
FEC |
From |
Type: LBLBIND
Label: the label binding that is propagated by the downstream LSR. The LSR picks a free label value from the pool stores it in the inlabel value and then copies it in the label field of the packet.
FEC: the FEC to which the label corresponds
From: the address of the LSR that forwarded the request
The label binding is the result of successful mapping of FEC on each intermediate
LSR. The architecture uses the Downstream-On-Demand mode of operation for acquiring label bindings. In this mode the upstream LSR makes request to the downstream LSR for the label bindings, the downstream LSR now makes decision depending on whether it is an Egress LSR for the corresponding FEC or whether it needs to further propagate the request to its next hop (which is further derived from the routing table).
LBLREQ packet structure:
|
LBLREQ |
FEC |
From |
Type: LBLREQ
FEC: the FEC for which the label is requested from the upstream LSR
From: the address of the LSR that forwarded the request
This packet initiates the Label request procedure. The upstream LSR generates this request and sends it to the downstream LSR that in turn may reply by sending the label binding or it may further propagate the request (if it is not the egress LSR) by sending the LBLREQ to its downstream LSR with respect to the FEC.