Make your own free website on Tripod.com
Prev TOP NEXT

Objective Achieved

Features of the System

Future Enhancements

Tunnel Implementation

LDP Architecture


5.1 Objective achieved

            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.

5.2 Features of the system

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

5.3 Future enhancements

Tunnel Implementation:

            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.

Architecture for LDP:

            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.




Data structures introduced:

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.


Prev TOP NEXT