French | Spanish | Portuguese | Italian | German | Japanese | Chinese | Korean | Russian | Arabic

Label Switch Routers can create a local binding for a Forwarding Equivalence Class in two ways:

1. Independent Label Switch Routers Control mode
2. Ordered Label Switch Routers Control mode

The Label Switch Router can create a local binding for a Forwarding Equivalence Class independently from the other Label Switch Routers. This is called Independent Label Switch Routers Control mode. In this control mode, each Label Switch Router creates a local binding for a particular Forwarding Equivalence Class as soon as it recognizes the Forwarding Equivalence Class. Usually, this means that the prefix for the Forwarding Equivalence Class is in its routing table. In Ordered Label Switch Routers Control mode, an Label Switch Router only creates a local binding for a Forwarding Equivalence Class if it recognizes that it is the egress Label Switch Router for the Forwarding Equivalence Class or if the Label Switch Router has received a label binding from the next hop for this Forwarding Equivalence Class.

The disadvantage of Independent Label Switch Routers Control is that some Label Switch Routers begin to label switch packets before the complete Label Switch Routers is set up end to end; therefore, the packet is not forwarded in the manner it should be. If the Label Switch Routers is not completely set up, the packet might not receive the correct forwarding treatment everywhere or it might even be dropped. As an example for both control methods, you can look at Label Distribution Protocol as the distribution method for label bindings of IGP prefixes. If the Label Switch Router were running in Independent Label Switch Routers Control mode, it would assign a local binding for each IGP prefix in the routing table. If the Label Switch Router were running in Ordered Label Switch Routers Control mode, this Label Switch Router would only assign a local label binding for the IGP prefixes that are marked as connected in its routing table and also for the IGP prefixes for which it has already received a label binding from the nexthop router (as noted in the routing table). Cisco IOS uses Independent Label Switch Routers Control mode. Asynchronous Transfer Mode switches that are running Cisco IOS use Ordered Label Switch Routers Control mode by default.

Unknown Label

In normal operation, an Label Switch Router should receive only a labeled packet with a label at the top of the stack that is known to the Label Switch Router, because the Label Switch Router should have previously advertised that label. However, it is possible for something to go wrong in the Multiprotocol Label Switching network and the Label Switch Router to start receiving labeled packets with a top label that the Label Switch Router does not find in its LFIB. The Label Switch Router can theoretically try two things: strip off the labels and try to forward the packet, or drop the packet. The Cisco Label Switch Router drops the packet. This is the right thing to do, because this Label Switch Router did not assign the top label, and it does not know what kind of packet is behind the label stack. Is it an IPv4, IPv6 packet, a Layer 2 frame, or something else? The Label Switch Router can try to figure that out by performing an inspection of the Multiprotocol Label Switching payload. But then the same problem as described in the previous section occurs: The Label Switch Router on which the packet or frame becomes unlabeled is likely not able to look up the destination of the packet or frame. Even if the Label Switch Router tries to forward the packet, it is not guaranteed that the packet will not get dropped at a router downstream. The only right thing to do is to drop an incoming packet with an unknown top label.

Reserved Labels

Labels 0 through 15 are reserved labels. An Label Switch Router cannot use them in the normal case for forwarding packets. An Label Switch Router assigns a specific function to each of these labels. Label 0 is the explicit NULL label, whereas label 3 is the implicit NULL label. Label 1 is the router alert label, whereas label 14 is the OAM alert label. The other reserved labels between 0 and 15 have not been assigned yet.

Implicit NULL Label

The implicit NULL label is the label that has a value of 3. An egress Label Switch Router assigns the implicit NULL label to a Forwarding Equivalence Class if it does not want to assign a label to that Forwarding Equivalence Class, thus requesting the upstream Label Switch Router to perform a pop operation. In the case of a plain IPv4-over-Multiprotocol Label Switching network, such as an IPv4 network in which Label Distribution Protocol distributes labels between the Label Switch Routers, the egress Label Switch Router—running Cisco IOS—assigns the implicit NULL label to its connected and summarized prefixes. The benefit of this is that if the egress Label Switch Router were to assign a label for these Forwarding Equivalence Classs, it would receive the packets with one label on top of it. It would then have to do two lookups. First, it would have to look up the label in the LFIB, just to figure out that the label needs to be removed; then it would have to perform an IP lookup. These are two lookups, and the first is unnecessary. The solution for this double lookup is to have the egress Label Switch Router signal the last but one (or penultimate) Label Switch Router in the label switched path (Label Switch Routers) to send the packets without a label. The egress Label Switch Router signals the penultimate Label Switch Router to use implicit NULL by not sending a regular label, but by sending the special label with value 3. The result is that the egress Label Switch Router receives an IP packet and only needs to perform an IP lookup to be able to forward the packet. This enhances the performance on the egress Label Switch Router.

Fragmentation of Multiprotocol Label Switching Packets

If an Label Switch Router receives a labeled packet that is too big to be sent out on a data link, the packet should be fragmented. This is similar to fragmenting an IP packet. If a labeled packet is received and the Label Switch Router notices that the outgoing MTU is not big enough for this packet, the Label Switch Router strips off the label stack, fragments the IP packet, puts the label stack (after the pop, swap, or push operation) onto all fragments, and forwards the fragments. Only if the IP header has the Don’t Fragment (DF) bit set does the Label Switch Router not fragment the IP packet, but it drops the packet and returns an ICMP error message “Fragmentation needed and do not fragment bit set” (ICMP type 3, code 4) to the originator of the IP packet. As with the ICMP message “time exceeded” (type 11, code 0), which is sent when the TTL expires of a labeled packet, the “Fragmentation needed and do not fragment bit set” ICMP message is sent, using a label stack that is the outgoing label stack for the packet that caused the ICMP message to be created.

This means that the ICMP message travels further down the Label Switch Routers until it reaches the egress Label Switch Router of that Label Switch Routers. Then it is returned to the originator of the packet with the DF bit set. In general, fragmentation causes a performance impact and should be avoided. A good method to avoid fragmentation is using the Path MTU Discovery method as described in the next section.

Path MTU Discovery

One method to avoid fragmentation is Path MTU Discovery, which most modern IP hosts perform automatically. In that case, the IP packets sent out have the “Don’t Fragment” (DF) bit set. When a packet encounters a router that cannot forward the packet without fragmenting it, the router notices that the DF bit is set, drops the packet, and sends an ICMP error message “Fragmentation needed and do not fragment bit set” (ICMP type 3, code 4) to the originator of the IP packet. The originator of the IP packet then lowers the size of the packet and retransmits the packet. If a problem still exists, the host can lower the size of the packet again. This continues until no ICMP message is received for the IP packet. The size of the last IP packet successfully sent is then used as maximum packet size for all subsequent IP traffic between the specific source and destination; hence, it is the MTU of the path.