Previous

Content

Next 

2.3. The Label Stack

  

Google
The label model is a general model in which a labeled packet carries a number of labels, organized as a LIFO stack. We refer to this as a "label stack". Although MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of labels may have been "above it" in the past, or that some number of other labels may be "below it" at present.
An unlabeled packet can be thought of as a packet whose label stack is empty (the label stack has depth 0). If a packet's label stack is of depth m, the label at the bottom is level 1 label, label above it is level 2 label, and label at the top is level m label.
The Next Hop Label Forwarding Entry (NHLFE)
 
The NHLFE is used when forwarding a labeled packet. It contains the following information:
 
  1. The packet's next hop.
     
  2. The operation to perform on the packet's label stack; this can be:
     
    1. Replace the top label with a specified new label (swapping).
       
    2. Pop the label stack.
       
    3. Replace the top label with a specified new label, and then push one or more specified new labels onto the label stack.
    		  
  3. The data link encapsulation to use when transmitting the packet.
     
  4. The way to encode the label stack when transmitting the packet.
     
  5. Any other information needed in order to properly dispose of the packet.
The "next hop" might be the LSR itself. In such a case, the label stack operation MUST BE to "pop the stack". The packet must be forwarded to itself, which implies another forwarding decision, based on what remains on the stack. This may still be a labeled packet or the native IP packet. This implies that in some cases the LSR may need to operate directly on the IP header in order to forward the packet.
 
Incoming Label Map (ILM)
 
ILM maps each incoming label to a set of NHLFEs. It is used when forwarding packets that arrive as labeled packets. If the ILM maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded.
 
The procedure for choosing an element is beyond the scope of this specification (an open issue). Having a label mapping to a set of NHLFEs could be useful, for example, for doing load balancing over multiple equal-cost paths.
 
   

 
FEC-to-NHLFE Map (FTN)
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 being forwarded.
If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedure for choosing an element from the set is beyond the scope of this specification.
With this approach, the instructions to forward a packet are always contained in one structure called NHLFE, which is always consulted independently whether the incoming packet is an MPLS packet (just a labeled packet) or a flat IP packet (unlabeled packet). The forwarding decision is transparent and independent of the type of incoming packets. LB.
Label swapping
In order to forward a labeled packet, a LSR examines the label at the top of the label stack. It uses the ILM to map this label to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack. It then encodes the new label stack into the packet, and forwards the result.
In order to forward an unlabeled packet, a LSR analizes the network layer header, to determine the packet's FEC. It then used the FTN to map this to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack (popping the label stack would be, of course, illegal in this case). It then encodes the new label stack into the packet, and forwards the result.
It is important to note that when label swapping is in use, the next hop is always taken from the NHLFE; this may in some cases be different from what the next hop would be if MPLS were not in use.
Scope and Uniqueness of Labels
A given LSR Rd may bind label L1 to FEC F, and distribute that binding to the peer Ru1. Rd may also bind label L2 to FEC F (same FEC), and distribute that binding to the peer Ru2. Whether or not L1 == L2 is not determined by the architecture; this is a local matter.
A given LSR Rd may bind label L to FEC F1, and distributes that binding to the peer Ru1. Rd may also bind label L to FEC F2, and distributes that binding to the peer Ru2. If (and only if) Rd can tell, when it receives a packet whose top label es L, whether the label was put there by Ru1 or by Ru2, then the architecture does not require that F1 == F2. In such case, we may say that Rd is using a different "label space" for the labels it distributes to Ru1 than for the labels it distributes to Ru2.
In general, Rd can only tell whether it was Ru1 or Ru2 that put the particular label value L at the top of the label stack if the following (both) conditions hold:
  • Ru1 and Ru2 are the only peers to which Rd has distributed a binding of label value L, and
     
  • Ru1 and Ru2 are each directly connected to Rd via a Point-to-Point (P2P) interface.
Having Ru1 and Ru2 connected to Rd via a P2P interface requires that each upstream router has been connected to Rd using a different interface in Rd.

 
Ru1 is connected to Rd using a P2P link through interface Ia, and Ru2 is connected to Rd using a P2P link through interface Ib. LB.
 
When these conditions hold, an LSR may use labels that have "per interface" scope, i.e., which are only unique per interface. We may say that the LSR is using a "per-interface label space". When these conditions do not hold, the labels must be unique over the LSR which has assigned them, and we may say that the LSR is using a "per-platform label space".
 
If a particular LSR Rd is attached to a particular LSR Ru over two P2P interfaces, then Rd may distribute to Ru a binding L-F1, as well as a binding L-F2, where F1 != F2, if and only if each binding is valid only for packets which Ru sends to Rd over a particular one of the interfaces. In all other cases, Rd must not distribute to Ru bindings of the same label value to two different FECs.
 
This prohibition holds even if the binding are regarded as being at different "levels of hierarchy". In MPLS, there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant.
 
The question arises as to whether it is possible for an LSR to use multiple per-platform label spaces, or to use multiple per-interface label spaces for the same interface. This is not prohibit by the architecture. However, in such cases the LSR must have some means, not specified by the architecture, of determining for a particular incoming label, which label space that label belongs to.
 
Important keywords to understand and remember
 
   

 
  Label stack
Top label
Empty label stack
Level m label entry
NHLFE
push
swap
pop
Native IP packet
ILM
Load balancing
Equal-cost paths
FTN
P2P Interface
Per-interface label space
Per-platform label space
Levels of hierarchy		  
   

Previous

Content

Next