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 10.1.1.0/24 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 192.168.1.0/24) and also received upstream assigned label for FEC
10.1.1.0/24 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,
- Determine that the top label is upstream assigned.
- 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.
- Manual provisioning of context label on LAN interface.
- 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
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.
Very deep and good decription...!!!
ReplyDeleteI like this explanation. Thanks.
ReplyDeleteA generic comment, Is there any EVPN related stuff ?
ReplyDelete