The job of the MPLS server is to accept
the request from the client or from other server and process the request.
The request can be for processing the CLIENTPKT type packets that are handled
by the sendpacket interface. Other request can be for processing the labeled
packets INLABPKT type. This is handled by sendlabelpacket interface. The FTN
table is made use of by sendlabel interface by which it gets the NHLFE for
the FEC. This NHLFE is provided as an input to the putoniface interface which
sends the packet to the next hop depending on the outiface value. Similarly
ILM table is checked to see if the incoming label is present in the table.
The output of this interface is again an NHLFE entry.

3.2 Data Structures

Data structures:

struct label

{

unsigned int
label : 20 ;

unsigned int
exp : 3 ;

unsigned int
s : 1 ;

unsigned int
ttl : 8 ;

};

This is the standard label data structure that holds
the values and other details of the label. The structure corresponds to the
standard specified in RFC 3032 (MPLS Label stack encoding).

Label: the value of the label

Exp: experimental use (not implemented)

S: bottom of the stack

TTL: time to live field

struct nhlfe

{

struct label
outlab ;

struct in_addr
outiface ;

struct nhlfe
*next ;

};

The "Next
Hop Label Forwarding Entry" (NHLFE) is used when forwarding a labeled
packet. Note that at a given LSR, the packet's "next hop" might
be that LSR itself. In this case, the LSR would need to pop the top-level
label, and then "forward" the resulting packet to itself. It would
then make another forwarding decision, based on what remains after the label
stacked is popped. This may still be a labeled packet, or it may be the native
IP packet. This implies that in some cases the LSR may need to operate on
the IP header in order to forward the packet. If the packet's "next hop"
is the current LSR, then the label stack operation MUST be to "pop the
stack". It contains information:

Outlab: the outlabel that should be attached to the packet

Outiface: the next hop address

Next:
the pointer that maintains the linked list

struct ftn

{

struct in_addr
fec ;

struct nhlfe
*nexthop ;

struct ftn *next
;

};

The “FEC-to-NHLFE” (FTN) maps each FEC to a set of NHLFEs. It is used when
forwarding packets that arrive unlabeled, but which are to be labeled before
neing forwaded. It contains information:

FEC:
the value of FEC of which corresponding NHLFE is to be found out

Nexthop: the pointer to the NHLFE

Next: the pointer that maintains the linked list

struct ilm

{

struct label
inlab ;

struct nhlfe
*outinfo ;

struct ilm *next
;

};

The "Incoming Label Map"
(ILM) maps each incoming label to a set of NHLFEs. It is used when forwarding
packets that arrive as labeled packets. It contains information:

Inlab: the label
that arrived on the incoming labeled packet

Outinfo: the pointer
to the NHLFE

Next: the pointer
that maintains the linked list

Packet Structures:

CLIENTPKT:

CLIENTPKT

FEC

Msglen

Msg….

CLIENTPKT : type

FEC : the destination
machine to which the packet is to be sent

Msglen : the length
of the message following the current field

Msg : the actual
msg that is to be transmitted

This is the packet
that the server receives from the local client. This packet initiates the
label switching mechanism. The server maps the FEC to the next hop label forwarding
entry by searching the corresponding FEC entry in the FTN list. After the
mapping is successful, a labeled packet is created with the corresponding
mapped label i.e. the mapped label is used as the outlab.

INLABPKT:

INLABPKT

Label

Msglen

Msg….

INLABPKT : type

Label : label
that is the result of FEC to NHLFE mapping or ILM to NHLFE mapping.

Msglen : the length
of the message following the current field

Msg : the actual
msg that is to be transmitted

This is a request to a server
from another server. The label contained in the packet is used as an inlabel
and the data structure ILM is used to map inlabel to outlabel.

3.3 Procedural Design

No

The server is back end tool which accepts requests on the
sockets and serves the request depending on the type. The server starts by
reading the LIB table from the disk file. Various data structures such as
FTN, NHLFE, ILM etc are initialized depending on the LIB table. The sockets
are opened for accepting the requests. The server then waits for connections
from the local clients or the remote server. Whenever the server gets in the
request it forks a child to further process the request. The server can be
terminated by depressing <Ctrl-C> if the daemon facility is not started
else an SIGTERM signal can terminate the server process. The cleanup module
is called during termination procedure which closes all the open sockets.
Any messages are redirected depending on the clauses of the syslog utility.
A log file is maintained which keeps track of all the messages directed by
the server.

The main task of the client is to initiate a packet switching procedure.
The client works only in conjunction with the local server i.e. the server resident
on the same IP address. The client reads in the FEC value from the user that
is specified as the destination IP address by the user and also the user specifies
the message that should be copied into the packet. The packet is then constructed
using above values and the type is specified as CLIENTPKT for the packet and
is transferred over the socket to local server for further processing.PrevTOPNEXT