Implementation of Simulated Network

Technical Specifications

Traffic Engineering Implementation

4 Implementation

            Continuous lines show actual physical connections that may exist in the network. These physical connections may be in any form viz. point to point, ring, bus etc.

Dotted lines show the simulated network connections established by the LIB entries.

            Considering the network shown above consisting of 10 computer terminals inter-connected in a bus topology, the simulated network that we have created using socket calls, consists of 4 LSRs(Label Switching Routers). These LSRs are LSR1(node2), LSR2(node 4), LSR3(node8) and LSR4(node 9).

            The IP addresses of the computers on the LAN are as follows:

LIB entries for the computers:

The MPLS server is installed at every LSR and the process is started off by issuing the command line “mpls_server <ip_address>”. The client is started at one of the LSR so as to initiate the packet switching procedure. The client command line is as follows: mpls_client <ip_address>.

Technical Specifications:

MPLS port:                              6789

Monitor Port:                            8888

Max. Client connection:            10

Min. packet data Len:               10

Default TTL:                             30

Log file path:                             /tmp/mplsd.log

Server cmdline:             mpls_server <ip_address>

Client cmdline:              mpls_client <ip_address>

            The client to act as local to the server should operate on the same IP address as that of the server.

Various messages understood by the server:

MONHELLO,             MONDOWN,            

CLIENTPKT,              INLABPKT,               

CLNHELLO,               CLNMSG,       CLNDOWN.

Label 0 Significance:

            Label#0 is used to signify no outgoing label i.e. the current LSR is an egress LSR or the destination LSR for the given FEC and hence the corresponding message in the packet should be displayed. As according to the specification of RFC 3031 this value is termed as Ipv4 implicit NULL value.

LIB file format:

            Rules regarding naming the LIB file.

Suppose the IP address on which the server is going to operate on is 144.16.111.181 then its corresponding lib entries must be stored in lib.144.16.111.181 file on the disk.

Fig4.3 An example LIB file

Comments can start at the start of the line or should be appended after the LIB entry.

The simulated network is formed depending on the entries present the LIB table and hence careful design of LIB table needs to be done. The server sees for any invalid entries present in the LIB table such as duplicate inlab entry or duplicate FEC entry etc but improper design of LIB table may lead to improper or no functioning at all. There is no significance of the inlab corresponding to the machine where the first INLABPKT is generated for CLIENTPKT. Similarly when the packet reaches the Egress LSR there is no significance of the outinterface in this implementation.

4.1 Traffic Engineering Implementation:

LIB Table for above configuration:

Tab4.3 LIB table for Traffic Engg. scenario

Traffic engineering (TE):

Sometimes it is desirable to force a packet to follow a particular route which is explicitly chosen at or before the time the packet enters the network, rather than being chosen by the normal dynamic routing algorithm as the packet travels through the network. This may be done as a matter of policy, this requires the packet to carry an encoding of its route along with it (“source routing”). For example, an ISP may provide two classes of services depending upon the charges paid by the customer. There may be more than one routes that the packet may follow to reach the destination. The class that the ISP will assign a customer may be any one of them (that is one path will be much faster than other) and hence the corresponding packets should be switched in that path only. In MPLS, a label can be used to represent the route, so that the identity of the explicit route need not be carried with the packet.

Traditional TE mechanism:

            In current IP networks the individual packets need to be ‘source routed’ so as to follow a particular path i.e. all the addresses of the individual intermediate nodes need to be stuffed in the packet at the source. There is an upper limit to how many addresses can be stuffed in the packet.

MPLS and TE:

The architecture of MPLS inherently supports TE techniques. The considerations that determine how a packet is assigned to a FEC can become ever more and more complicated, without any impact at all on the routers that merely forward labeled packets.

Example Scenario:

            Suppose there are two end nodes E & F with different paths to be followed (the reason may be anything such as security or priority). There exist two paths between nodes A & D i.e. A-B-D and A-C-D. Consider that E must be given access to path A-C-D and F via path A-B-D. In IP routing, every packet generated for nodes E & F would have to be source routed with IP addresses of the intermediate nodes.

            MPLS eases this job by considering E & F to two different FECs and hence two different sets of label bindings exist for the individual FEC. Thus using MPLS individual packets to nodes E & F does not need to be source routed. Furthermore, the overhead of processing the routes at each intermediate node is also reduced. The total payload of the packet is also dramatically reduced since addresses don’t need to be carried.

Prev TOP NEXT