Sunday, July 29, 2012

MPLS Upstream Label assignment and Context Label space

RFC 3031 specifies that the decision to bind a label to a specific FEC is made by downstream LSR and distribute from downstream to upstream direction. This limits MPLS architecture to downstream assigned MPLS labels.  In the below topology, Downstream LSR binds label 100 for FEC and advertise to Upstream LSR which will be used when sending traffic from Upstream LSR to Downstream LSR. This is known as Downstream assigned Label. 

With MPLS advancement, there raises a requirement to have the label binding for specific FEC is done by upstream LSR and advertising to Downstream LSR. This is known as Upstream assigned Label. One application that uses upstream label assignment is Multicast over MPLS which is explained later with a simple scenario.

It can be observed that when the label is upstream assigned, the lookup will be done by LSR that is not the LSR that assigned the label. In the above scenario, assume Downstream LSR bind Label 100 for a different FEC (say and also received upstream assigned label for FEC as Label 100. Now when Downstream LSR receives traffic from Upstream LSR with top label as 100, there should some way to differentiate that the top label of 100 is upstream assigned or downstream assigned to send it further to right FEC. So this boils down to below requirement that Downstream LSR should,

  1. Determine that the top label is upstream assigned.
  2. Perform Label lookup in respective Context-specific label space.

Determine the top label is upstream assigned

When Upstream LSR distributes the upstream assigned label to Downstream LSR, it advertises the Tunnel identifier along with the label via LDP.  This tunnel can be either IP or MPLS tunnel terminating on Downstream LSR. 

Downstream LSR will maintain “Upstream Neighbor Label space” per such Upstream LSR. When Downstream LSR receives packet on this tunnel, it understand that the top label is upstream assigned label and uses the Tunnel ID to identify the context label space to perform label lookup.

When the Upstream LSR and Downstream LSR are adjacent to each other on Ethernet link, the Ether type in Ethernet header will be set to 0x8848. It can be noted that RFC 3032 specifies 0x8847 for MPLS unicast and 0x8848 for MPLS Multicast. But later, it was understood that a label lookup in NHLFE can identify if it is Multicast or Unicast under MPLS and no specific Ether type is required. Having said that, RFC 5332 deprecates the association of Ether type 0x8848 for MPLS Multicast and specify the same to be used in case of Upstream Label assignment.

In the above topology, it can be noted that Downstream LSR on receiving Ethernet frame with 0x8848 as Ether type will realize that the payload is MPLS packet which  requires context specific lookup and will perform lookup in Upstream Label neighbor space. While it works fine with one upstream neighbor, it is possible to have multiple upstream LSRs sharing the same multi-access network.

 In such case, while Downstream LSR can identify that the label is upstream assigned by Ether type, it should also need some Context identifier to identify the respective upstream neighbor. RFC 5331 specifies to use context label per upstream neighbor in that multi-access network. This context label will be advertised as Tunnel/Context identifier by Upstream LSR to Downstream LSR while advertising the Upstream Label mapping message. So when any Downstream LSR receives frame with Ether type as 0x8848, it uses the top label as context label to identify the upstream neighbor label and then perform upstream label lookup.

Context Label on LAN

The Context label assigned and advertised by Upstream LSRs must be unique across all context label advertised by other LSRs in same LAN. Currently there are two methods proposed to assign a context label on a particular LAN.

  1.  Manual provisioning of context label on LAN interface.
  2. Auto generated context label.

Since the label size is 20 bits, auto generation of context label is possible only when the LAN interface is configured with IPv4 address AND with mask greater than 12 bits.

While the above explanation gives an overview about Upstream Label assignment, below is a simple example where upstream label can be used.

Using Upstream label assignment in T-mLDP scenario

One of the usage scenarios of upstream label assignment is mentioned in draft-napierala-mpls-targeted-mldp.  Assume in the below topology, D1 and D2 are Downstream LSR with BGP session and T-mLDP session to U1 (Upstream LSR) and there is an existing P2MP LSP (LSP1) from U1 to C1 and D2.

Now when D1 and D2 receives P2MP label mapping from its downstream and if the next hop to ROOT, R is U1, advertising downstream assigned label fromD1 and D2 to U1 will end up in situation where U1 need to send 2 copies of multicast packet to D1 and D2 with respective downstream label. Instead, U1 can advertise an upstream assigned label with LSP1 as Context Identifier to D1 and D2.

Now when U1 send multicast traffic, it will push upstream label as bottom label and LSP1 label as top label and send one copy which will be replicated in any intermittent branch LSR. D1 and D2 on receiving the traffic on LSP1 will realize that this is upstream assigned label and will perform lookup in respective neighbor space and send it across.

1 comment: