 |
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.
 |
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.
 |
 |
 |
|||
|
|||
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.
Prev TOP NEXT