For every IGP IP prefix in its IP routing table, each Label Switch Router creates a local binding that is, it binds a label to the IPv4 prefix. The Label Switch Router then distributes this binding to all its Label Distribution Protocol neighbors. These received bindings become remote bindings. The neighbors then store these remote and local bindings in a special table, the label information base (LIB). Each Label Switch Router has only one local binding per prefix, at least when the label space is per platform. If the label space is per interface, one local label binding can exist per prefix per interface. Therefore, you can have one label per prefix or one label per prefix per interface, but the Label Switch Router gets more than one remote binding because it usually has more than one adjacent Label Switch Router.

Out of all the remote bindings for one prefix, the Label Switch Router needs to pick only one and use that one to determine the outgoing label for that IP prefix. The routing table (sometimes called the routing instance base, or RIB) determines what the next hop of the IPv4 prefix is. The Label Switch Router chooses the remote binding received from the downstream Label Switch Router, which is the next hop in the routing table for that prefix. It uses this information to set up its label forwarding information base (LFIB) where the label from the local binding serves as the incoming label and the label from the one remote binding chosen via the routing table serves as the outgoing label. Therefore, when an Label Switch Router receives a labeled packet, it is now capable of swapping the incoming label it assigned, with the outgoing label assigned by the adjacent next-hop Label Switch Router. Each Label Switch Router allocates one label per IPv4 prefix. The local binding is this one prefix and its associated label.

Label Forwarding Instance Base

The LFIB is the table used to forward labeled packets. It is populated with the incoming and outgoing labels for the Label Switch Routerss. The incoming label is the label from the local binding on the particular Label Switch Router. The outgoing label is the label from the remote binding chosen by the Label Switch Router from all possible remote bindings. All these remote bindings are found in the LIB. The LFIB chooses only one of the possible outgoing labels from all the possible remote bindings in the LIB and installs it in the LFIB.

The remote label chosen depends on which path is the best path found in the routing table. In the example of IPv4-over-Multiprotocol Label Switching, the label is bound to an IPv4 prefix. However, the LFIB can be populated with labels that Label Distribution Protocol does not assign. In the case of Multiprotocol Label Switching traffic engineering, the labels are distributed by Resource Reservation Protocol. In the case of Multiprotocol Label Switching Virtual Private Network, the Virtual Private Network label is distributed by Border Gateway Protocol. In any case, the LFIB is always used to forward an incoming labeled packet.

Multiprotocol Label Switching Payload

The Multiprotocol Label Switching label has no Network Level Protocol identifier field. This field is present in all Layer 2 frames to indicate what the Layer 3 protocol is. How does the Label Switch Router know what the protocol is behind the label stack? Or, in other words, how does the Label Switch Router know what the Multiprotocol Label Switching payload is? Most Label Switch Routers do not need to know, because they will receive a labeled packet, swap the top label, and send the packet on the outgoing link. This is the case for intermediate Label Switch Routers or P routers. Intermediate Label Switch Routers do not need to know what the Multiprotocol Label Switching payload is because all the information needed to switch the packet is known by looking at the top label only.

If the label stack consists of more than one label, the labels below the top label might not be assigned by the Label Switch Router and thus the intermediate Label Switch Router might have no knowledge what they are. Furthermore, the Label Switch Router might not know what the transported Multiprotocol Label Switching payload is. Because intermediate Label Switch Routers look only at the top label to make a forwarding decision, this is not a problem. For the forwarding based on the top label to be correct, the intermediate Label Switch Router must have a local and remote binding for the top label. An egress Label Switch Router that is removing all labels on top of the packet must know what the Multiprotocol Label Switching payload is, because it must forward the Multiprotocol Label Switching payload further on.

The egress Label Switch Router must know what value to use for the Network Level Protocol identifier field in the outgoing frame. That egress Label Switch Router is the one that made the local binding, which means that that Label Switch Router assigned a local label to that Forwarding Equivalence Class, and it is that label that is used as an incoming label on the packet. Therefore, the egress Label Switch Router knows what the Multiprotocol Label Switching payload is by looking at the label, because it is the egress Label Switch Router that created the label binding for that Forwarding Equivalence Class, and it knows what that Forwarding Equivalence Class is.

Multiprotocol Label Switching Label Spaces

Label Switch Router A can advertise label L1 for Forwarding Equivalence Class 1 to Label Switch Router B and label L1 for Forwarding Equivalence Class 2 to Label Switch Router C, but only if Label Switch Router A can later distinguish from which Label Switch Router the packet with label L1 was received. In the case that Label Switch Router B and Label Switch Router C are directly connected to Label Switch Router A via point-to-point links, this can easily be achieved by the Multiprotocol Label Switching implementation on the Label Switch Router. The fact that the label L1 is only unique per interface lends its name to this label scope: per-interface label space.

Different Multiprotocol Label Switching Modes

An Label Switch Router can use different modes when distributing labels to other Label Switch Routers. This section covers three distinct modes, as follows:

1. Label distribution mode
2. Label retention mode
3. Label Switch Routers control mode Each mode has its own characteristics. This section explains the advantages of each.

Label Distribution Modes

The Multiprotocol Label Switching architecture has two modes to distribute label bindings:

1. Downstream-on-Demand (DoD) label distribution mode
2. Unsolicited Downstream (UD) label distribution mode In the DoD mode, each Label Switch Router requests its next-hop (that is, downstream) Label Switch Router on an Label Switch Routers, a label binding for that Forwarding Equivalence Class.

Each Label Switch Router receives one binding per Forwarding Equivalence Class only from its downstream Label Switch Router on that Forwarding Equivalence Class. The downstream Label Switch Router is the next-hop router indicated by the IP routing table. In the UD mode, each Label Switch Router distributes a binding to its adjacent Label Switch Routers, without those Label Switch Routers requesting a label. In the UD mode, an Label Switch Router receives a remote label binding from each adjacent Label Switch Router. In the case of DoD, the LIB shows only one remote binding, whereas in the case of UD, you are likely to see more than one. The label distribution mode used depends on the interface and the implementation. In Cisco IOS, all interfaces except LC-Asynchronous Transfer Mode interfaces use the UD label distribution mode. All LC-Asynchronous Transfer Mode interfaces use the DoD label distribution mode.

Label Retention Modes

Two label retention modes are possible:

1. Liberal Label Retention mode
2. Conservative Label Retention mode

In Liberal Label Retention mode, an Label Switch Router keeps all received remote bindings in the LIB. One of these bindings is the remote binding received from the downstream or next hop for that Forwarding Equivalence Class. The label from that remote binding is used in the LFIB, but none of the labels from the other remote bindings are put in the LFIB; therefore, not all are used to forward packets. Why keep the labels around that are not used? Routing is dynamic in a network. At any time, the routing topology can change—for example, due to a link going down or a router being removed—therefore, the next-hop router for a particular Forwarding Equivalence Class can change. At that time, the label for the new next-hop router is already in the LIB and the LFIB can be quickly updated with the new outgoing label. The second label retention mode is Conservative Label Retention mode. An Label Switch Router that is running this mode does not store all remote bindings in the LIB, but it stores only the remote binding that is associated with the next-hop Label Switch Router for a particular Forwarding Equivalence Class. In short, the Liberal Label Retention mode gives you quicker adaptation to routing changes, whereas Conservative Label Retention mode gives you fewer labels to store and a better usage of the available memory on the router. In Cisco IOS, the retention mode for LC-Asynchronous Transfer Mode interfaces is the Conservative Label Retention mode. It is the Liberal Label Retention mode for all other types of interfaces.