Previous

Content

Next 

2.9. MPLS and Hop by Hop Routed Traffic

  

Some uses of MPLS require that packets with a certain label be forwarded along the same hop-by-hop routed path that would be used when a specified address is in the network layer destination address field. This is done using a technique called "Labels for Address Prefixes", as follows:
Labels for Address Prefixes
 
An IP router R determines the next hop for packet P by finding the address prefix X in its routing table, which is the longest match for P's destination address. In this case, we would associate the address prefix X with one FEC in this form: packets belonging to a given FEC are just those packets which match a given address prefix in the router R's routing table. The FEC can be identified with an address prefix.
 
Note: a packet P may be assigned to FEC F, and F may be identified with address prefix X, even when P's destination address does not match X.
 
Label Distribution Peers for an Address Prefix
 
R1 and R2 are label distribution peers for address prefix X if and only if one of the following conditions holds:
 
  1. R1's route to X is learned via an IGP protocol, and R2 is a neighbor of R1 for that IGP.
     
  2. R1's route to X is learned by a routing algorithm A1, redistributed by a routing algorithm A2, and R2 is a neighbor of R1 in that instance of A2.
     
  3. R1 is the receive endpoint of an LSP tunnel that is within another LSP, and R2 is a transmit endpoint of that tunnel, and R1 and R2 are participant in a common instance of an IGP, and are in the same IGP area (if that IGP has areas), and R1's route to X was learned using that IGP, or is redistributed by R1 into that IGP instance.
     
  4. R1's route to X is learned via BGP, and R2 is a BGP peer of R1.
These rules ensure that for the route to a particular address prefix X:
 
  1. If the route is distributed via an IGP, the label distribution peers are the IGP neighbors.
     
  2. If the route is distributed via BGP, the label distribution peers are the BGP peers.
 
   

 
In cases of LSP tunneling, the tunnel endpoints are label distribution peers.
Distributing labels
 
In order to use MPLS for the forwarding to the hop-by-hop route corresponding to any address prefix, each LSR must:
 
  1. Bind one or more labels L to each address prefix X in its IP routing table;
     
  2. Use a LDP to distribute the binding L-X to each of its label distribution peers for X.
     
  3. If R1 uses BGP to distribute a route to X, naming some other LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has bound L to X, then R1 must distribute the binding L-X to any BGP peer to which it distributes that route.
These rules ensure that labels corresponding to address prefixes which correspond to BGP routes are distributed to IGP neighbors if and only if the BGP routes are distributed into the IGP. Otherwise, the labels bound to BGP routes are distributed only to the other BGP speaker.
 
Using the Hop by Hop path as the LSP
 
If packet P's hop-by-hop path is <R1, ..., Rn>, then, this path is an LSP as long as:
 
  1. There is a single address prefix X, such that, for all i, (1 <= i < n), X is the longest match in Ri's routing table for P's destination address.
     
  2. For all i, (1 < i < n), Ri has bound a label L to X and has distributed that label to R[i-1].
The packet P's LSP will extend only until it encounters a router having a longer best match address prefix for P's destination address. At that point, LSP must end, and the best match algorithm must be executed again. For example, a packet P with destination address 10.2.153.178 will go through the path <R1,R2,R3>. R2 advertises 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. In this case, P can be label switched until R2, but because R2 has performed route aggregation, it must execute the best match algorithm to find a new FEC for P.
 
LSP Egress and LSP Proxy Egress
An LSR R is considered to be an "LSP Egress" LSR for address prefix X if and only if one of the following conditions holds:
  1. R has an address Y, such that X is the address prefix en R's routing table which is the longest match for Y, or
     
  2. R contains in its routing table one or more address prefixes Y such that X is a proper initial substring of Y, but R's "LSP previous hops" for X do not contain any such address prefixes Y; that is, R is a "deaggregation point" for address prefix X.
An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address prefix X if and only if:
  1. R1's next hop for X is R2, and R1 and R2 are not label distribution peers with respect to X (perhaps because R2 does not support MPLS), or
     
  2. R1 has been configured to act as an LSP Proxy Egress for X.
The definition of LSP allows for the LSP Egress to be a node which does not support MPLS; in this case, the penultimate node in the LSP is the LSP Proxy Egress.
The Implicit NULL Label
If one LSR Ru, by consulting its ILM, sees that labeled packet P must be forwarded next to Rd, but that Rd has distributed a binding of Implicit NULL to the corresponding address prefix, then, Ru, instead of replacing the label on top of the label stack, it pops the label stack, and forwards the resulting packet to Rd.
LSR Rd distributes a binding Implicit NULL-X to LSR Ru, if and only if:
  1. Rd must distribute a label binding for X, to Ru; and
     
  2. Rd knows that Ru can support the Implicit Null Label (i.e., it can pop the label stack), and
     
  3. Rd is an LSP Egress (not proxy egress) for X.
This causes the penultimate LSR on an LSP to pop the label stack, saving the LSP Egress the work of having to look up two labels in order to make its forwarding decision.
Binding of Implicit NULL may be distributed only to penultimate LSR having the capacity to pop the label stack (for example, an ATM switch can't do that). If the penultimate LSR in an LSP for address prefix X is an LSP Proxy Egress, it acts just as if the LSP Egress had distributed a binding to Implicit NULL for X.
Egress-Targeted Label Assignment
When an LSP Ingress Ri, knows that packets of several FECs must all follow the same LSP, terminating at, say, LSP Egress Re, then it can use a single label for all such FECs, if and only if the following conditions hold:
  1. The address of LSR Re is itself in the routing table as a "host route", and
     
  2. There is some way for Ri to determine that Re is the LSP Egress for all packets in a particular set of FECs.
Then Ri may bind a single label to all FECs in the set. This is known as "Egress-Targeted Label Assignment".
How can LSR Ri determine that LSR Re is the LSP Egress for all packets in a particular FEC? Some possible ways are:
  1. If the network is running an IGP, and all nodes in the area support MPLS, then the link state routing algorithm can provide to Ri enough information to determine the routers through which packets in that FEC must leave the routing domain or area.
     
  2. If the network is running BGP, Ri may be able to determine that packets in a particular FEC must leave the network via some particular router which is the "BGP Next Hop" for that FEC.
     
  3. It is possible to use LDP to pass information about which address prefixes are "attached" to which egress LSRs, having the advantage of not depending on the presence of IGP.
When egress-targeted label assignment is used, the number of labels supported by the network is greatly reduced. One possible approach to use it, is to configure egress-targeted label assignment by default, but to configure particular LSRs to not use it for one or more of the address prefixes for which it is an LSP Egress. The following rule is imposed:
  • If a particular LSR is not an LSP Egress for some set of address prefixes, then it should assign labels to the address prefixes in the same way as is done by its LSP next hop for those address prefixes. Suppose Rd is Ru's next hop for address prefixes X1 and X2; then, if Rd assigns the same label to X1 and X2, Ru should as well. If Rd assigns different labels to X1 and X2, then Ru should as well.
For example, we could configure all LSRs to use egress-targeted label assignment, and then configure a handful of LSRs to assign different labels to some address prefixes which are, let's say, multihomed. Having a multihomed prefix X, one would only need to configure this in LSRs which are LSP Egress or LSP Proxy Egress for X.
 
Label Stack and Implicit Peering
 
Let's suppose that Re is an LSP Proxy Egress for 10 address prefixes, and that it reaches each address prefix through a distinct interface. One could assign a single label to all 10 address prefixes. Re will be the LSP Egress for the 10 prefixes. It has, then, to pop the label and look up later on the network layer address of each packet in order to forward them.
 
Another solution could be to use 10 different labels. Then, Re will be the LSP Proxy Egress for the 10 address prefixes. Re will not have to look up the network layer address in order to forward the packets. However, it requires to use a large number of labels.
 
A third solution would be to bind all 10 address prefixes to the same level 1 label (bounded to the Re's address itself), and then to bind each address prefix to a distinct level 2 label. This label will be an attribute of the level 1 label binding, which we call the "stack attribute". The following rules are then imposed:
 
When LSR Ru is ready to label a packet, and the longest match for the packet's destination address is X, and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru a binding L1-X, along with a stack attribute L2, then:
 
  1. Ru must push L2 and then L1 onto the packet's label stack and forward the packet to Rd;
     
  2. When Ru distributes binding for X to its peers, it must include L2 as a stack attribute;
     
  3. Whenever the stack attribute changes (for example, given a change in the Ru's LSP next hop for X), Ru must distribute the new stack attribute.
Observe that label value bound to X may change along the LSP but the stack attribute is passed unchanged. This attribute is set by the LSP Proxy Egress Re, this way, Re becomes an "implicit peer" with each other LSR in the routing area or domain.
 
   

 
Multi-Path Routing
When mutiple routes exist for a particular stream, an LSR may assign multiple labels to the stream, one for each route. This way, the reception of a second label binding from a neighbor for a particular address prefix should be taken as meaning that either label can be used to represent that address prefix.
LSP Trees as Multipoint-to-Point Entities
Having two packets P1 and P2, whose destination address' longest match is address prefix X. Suppose that path for P1 is <R1,R2,R3>, and path for P2 is <R4,R2,R3>. Let's suppose that R3 binds L3 to X and distributes this binding to both, R1 and R4. When R2 receives P1, its incoming label will be L2; then it will overwrite L2 with L3 and forwards P1 to R3. When R2 receives P2, its incoming label will be also L2; then, again, it will overwrite L2 with L3 and forwards P2 to R3.
When P1 and P2 are traveling from R2 to R3, they carry the same label, and to MPLS, they can't be distinguished. Thus, instead of talking about two LSPs, <R1,R2,R3> and <R4,R2,R3>; we might talk about a single "Multipoint-to-Point LSP Tree", which we denote as <{R1,R4},R2,R3>.
Tunneling between BGP Border Routers
Let's suppose we have an AS domain A, having a number of BGP Border Routers, and a mesh of BGP connections among them, over which BGP routes are distributed. To reduce the "route distribution load" on domain A's routers, it is desirable to avoid distributing BGP routes to routers which are not BGP Border Routers. This can be done by means of LSP Tunnels as follows:
  1. In the AS, each BGP Border Router distributes to every other BGP Border Router, a label for each address prefix that it distributes to that router via BGP.
     
  2. The AS's IGP maintains a host route for each BGP Border Router. Each interior router distributes its labels for these host routes to each of its IGP neighbors.
     
  3. Then, let's suppose that:
     
     
    1. BGP Border Router B1 receives an unlabeled packet P;
       
    2. Address prefix X in B1's routing table is the longest match for P's destination address;
       
    3. The route to X is a BGP route;
       
    4. The BGP Next Hop for X is B2;
       
    5. B2 has bound label L1 to X, and has distributed this binding to B1;
       
    6. IGP next hop for B2 address is I1;
       
    7. B2 address is in B1's and I1's routing tables a host route;
       
    8. I1 has bound label L2 to B2's address and has distributed this binding to B1.
    		  

    Then, B1 must replace the label on top of packet P with label L1, then pushes on label L2, and forwards the packet to I1.
With these procedures, a given packet P follows a level 1 LSP where all members are BGP Border Routers, and between each pair of BGP Border Routers, a level 2 LSP where all routers are IGP routers. We have created a Hop-by-Hop Routed LSP Tunnel between the BGP Border Routers. They become explicit label distribution peers with each other BGP Border Router.
These tunnels can be created even between two BGP Border Routers not belonging to the same AS. Let's suppose that B1 and B2 are in AS 1. B3 is in AS 2 and it is a BGP neighbor of B2. In this case, an LSP tunnel can be set up directly between B1 and B3 as follows:
  1. B3 distributes routes to B2 using EBGP, optionally assigning labels to address prefixes;
     
  2. B2 redistributes those routes to B1 using IBGP, indicating that the BGP next hop for them is B3. If B3 has assigned labels to address prefixes, B2 passes these labels along, unchanged, to B1.
     
  3. AS1's IGP has a host route for B3.
 
Other uses of Hop-by-Hop Routed LSP Tunnels
 
Any situation in which one might otherwise have used an encapsulation tunnel, is one in which it is appropriate to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the packet with a new header having tunnel's receive endpoint address as destination address, we push a label corresponding to the address prefix which is the longest match for the tunnel's receive endpoint address.
 
The packet could be or could not be already labeled. If not, the tunnel's endpoint creates a label stack pushing a label value that has been distributed to it by the tunnel's receive endpoint, and then the label which corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. If the packet is already labeled, it must first replace the top label value with the label value that was distributed to it by the tunnel's receive endpoint, and then, in the same way, the label which corresponds to the tunnel itself.
 
The tunnel endpoints are explicit label distribution peers. The label they need to exchange are of no interest to the LSRs along the tunnel.
 
Important keywords to understand and remember
 
  Labels for Address Prefixes
Label Distribution Peers for an Address Prefix
LSP Egress
LSP Proxy Egress
Implicit NULL Label
Egress-Targeted Label Assignment
Implicit Peering
Multi-path Routing
Multipoint-to-Point LSP Tree
BGP Border Router's Tunnel (Hop-by-Hop Routed LSP Tunnel between BGP Border Routers)
Explicit Label Distribution Peer		  
 
   

 
   

Previous

Content

Next