MPLS

Multiprotocol Label Switching (MPLS) is an Internet Engineering Task Force (IETF)-specified framework that provides for the designation, routing, forwarding and switching of traffic flows through the network.

It performs the following :

• Specifies mechanisms to manage traffic flows of various granularities, such as flows between different hardware, machines, or even flows between different applications
• Remains independent of the layer-2 and layer-3 protocols
• Provides a means to map IP addresses to simple, fixed-length labels used by different packet-forwarding and packet-switching technologies
• Interfaces to existing routing protocols, such as Resource ReSerVation Protocol (RSVP) and Open Shortest PathFirst (OSPF)
• Supports IP, ATM, and Frame Relay layer-2 protocols

In MPLS, data transmission occurs on Label-Switched Paths (LSPs). LSPs are a sequence of labels at each and every node along the path from the source to the destination. LSPs are established either prior to data transmission (control-driven) or upon detection of a certain flow of data (data-driven). The labels, are underlying protocol-specific identifiers, There are several label distribution protocols used today, such as Label Distribution Protocol (LDP) or RSVP or piggybacked on routing protocols like border gateway protocol (BGP) and OSPF. Each data packet encapsulates and carries the labels during their journey from source to destination. High-speed switching of data is possible because the fixed-length labels are inserted at the very beginning of the packet or cell and can be used by hardware to switch packets quickly between links.

MPLS is a versatile solution to address the problems faced by present-day networks-speed, scalability, quality-of-service (QoS) management, and traffic engineering. MPLS has emerged as an elegant solution to meet the bandwidth-management and service requirements for next-generation IP-based backbone networks.

For more information on MPLS

Multi Protocol Label Switching (MPLS) is a set of procedures for augmenting network layer packets with “label stacks”, thereby turning them into labeled packets. It defines the encoding used by a label switching router to transmit such packets over PPP and LAN links. It is an Ethernet Tag Switching protocol. This protocol attaches labels to IP and IPv6 protocols in the network layer, after the data link layer headers, but before the network layer headers. It inserts a 4 or 8 byte label.

The format of the MPLS label stack is shown in the following illustration:

Label
The field contains the actual value for the label. This gives information on the protocol in the network layer and further information needed to forward the packet.

CoS
Class of Service. The setting of this field affects the scheduling and/or discard algorithms which are applied to the packet as it is transmitted through the network.

S
Bottom of the Stack, 1-bit field set to one for the last entry in the label stack and zero for all other label stack entries.

TTL
Time to Live, 8-bit field used to encode a time to live value.

LDP
Internet Draft: draft-ietf-mpls-ldp-07.txt

In the MPLS (Multi Protocol Label Switching) 2 label switching routers (LSR) must agree on the meaning of the labels used to forward traffic between and through them. LDP (Label Distribution Protocol) is a new protocol that defines a set of procedures and messages by which one LSR (Label Switched Router) informs another of the label bindings it has made.

The LSR uses this protocol to establish label switched paths through a network by mapping network layer routing information directly to data-link layer switched paths. These LSPs may have an endpoint at a directly attached neighbor (like IP hop-by-hop forwarding), or may have an endpoint at a network egress node, enabling switching via all intermediary nodes. A FEC (Forwarding Equivalence Class) is associated with each LSP created. This FEC specifies which packets are mapped to that LSP.

Two LSRs (Label Switched Routers) which use LDP to exchange label mapping information are known as LDP peers and they have an LDP session between them. In a single session, each peer is able to learn about the others label mappings, in other words, the protocol is bi-directional.

There are 4 sorts of LDP messages:

1. Discovery messages
2. Session messages
3. Advertisement messages
4. Notification messages.

Using discovery messages, the LSRs announce their presence in the network by sending Hello messages periodically. This hello message is transmitted as a UDP packet. When a new session must be established, the hello message is sent over TCP. Apart from the Discovery message; all other messages are sent over TCP.

The notification messages signal errors and other events of interest.

There are 2 kinds of notification messages:

1. Error notifications; these signal fatal errors and cause termination of the session
2. Advisory notifications; these are used to pass on LSR information about the LDP session or the status of some previous message received from the peer.

All LDP messages have a common structure that uses a Type-Length-Value (TLV) encoding scheme. This TLV encoding is used to encode much of the information carried in LDP messages. The Value part of a TLV-encoded object (TLV), may itself contain one or more TLVs.

Messages are sent as LDP PDUs. Each PDU can contain more than one LDP message. Each LDP PDU is an LDP header followed by one or more LDP message:

The structure of the LDP header is shown below:

2 bytes	2 bytes
Version	PDU Length
LDP Identifier 6 bytes
LDP header structure

Version
The protocol version number. The present number is 1.

PDU Length
The total length of the PDU excluding the version and the PDU length field.

LDP identifier
This field uniquely identifies the label space of the sending LSR for which this PDU applies. The first 4 octets encode the IP address assigned to the LSR. The lst 2 indicate a label space within the LSR.

LDP messages

All LDP messages have the following format.

U
The U bit is an unknown message bit.

Message type
The type of message. The following message types exist:

Message length
The length in octets of the message ID, mandatory parameters and optional parameters:

Message ID
32-bit value used to identify the message.

Parameters:
The parameters contain the TLVs. There are both mandatory and optional parameters. Some messages have no mandatory parameters, and some have no optional parameters.

TLV format

U
The U bit is an unknown TLV bit.

F
Forward unknown TLV bit.

Type
Encodes how the Value field is to be interpreted.

Length
Specifies the length of the Value field in octets.

Value
Octet string of Length octets that encodes information to be interpreted as specified by the Type field.

The following are optional TLV parameters:

Optional TLV Parameters

Interested in more details about testing this protocol?

CR-LDP
Draft-ietf-mpls-ldp-06;
Draft-ietf-mpls-cr-ldp-03;
Draft-fan-mpls-lambada-signalling-00

CR-LDP (constraint-based LDP) contains extensions for LDP to extend its capabilities. This allows extending the information used to setup paths beyond what is available for the routing protocol

CR-LDP is the same as LDP but has the following additional TLV parameters.

Interested in more details about testing this protocol?

RSVP-TE
draft-ietf-rsvp-spec-13.txt;
draft-ietf-rsvp-md5-02.txt;
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt;
draft-fan-mpls-lambda-signaling-00.txt

The RSVP-TE (traffic extension) protocol is an addition to the RSVP protocol (see TCP) with special extensions to allows it to set up optical paths in an agile optical network.

The RSVP protocol defines a session as a data flow with a particular destination and transport-layer protocol. However, when RSVP and MPLS are combined, a flow or session can be defined with greater flexibility and generality. The ingress node of an LSP (Label Switched Path) uses a number of methods to determine which packets are assigned a particular label. Once a label is assigned to a set of packets, the label effectively defines the flow through the LSP. We refer to such an LSP as an LSP tunnel because the traffic through it is opaque to intermediate nodes along the label switched path. New RSVP Session, Sender and Filter Spec objects, called LSP Tunnel IPv4 and LSP Tunnel IPv6 have been defined to support the LSP tunnel feature. The semantics of these objects, from the perspective of a node along the label switched path, is that traffic belonging to the LSP tunnel is identified solely on the basis of packets arriving from the "previous hop" (PHOP) with the particular label value(s) assigned by this node to upstream senders to the session. In fact, the IPv4(v6) that appears in the object name only denotes that the destination address is an IPv4(v6) address. When referring to these objects generically, the qualifier LSP Tunnel is used.

In some applications it is useful to associate sets of LSP tunnels. This can be useful during reroute operations or in spreading a traffic trunk over multiple paths. In the traffic engineering application, such sets are called traffic engineered tunnels (TE tunnels). To enable the identification and association of such LSP tunnels, two identifiers are carried. A tunnel ID is part of the Session object. The Session object uniquely defines a traffic engineered tunnel. The Sender and Filter Spec objects carry an LSP ID. The Sender (or Filter Spec) object, together with the Session object, uniquely identify an LSP tunnel.

Apart from the existing message types listed in RSVP an additional message type is available:

In addition, the following additional Protocol Object Types exist:

Interested in more details about testing this protocol?