Monday, September 19, 2011

Label Switched Multicast - mLDP

 
On any MPLS cloud, current deployment is in a way that Unicast traffic were label switched while Multicast traffic were not.  Current deployment requires Multicast to be enabled on SP core in order to provide Multicast service to SP Customers. In case of MVPN, Multicast traffic from VPN customer will be encapsulated using GRE with destination as multicast address within SP cloud and will be flooded downstream to other PE devices.

Recent enhancement allows providing Multicast service to end customers without enabling Multicast on SP core. This is done by using Multipoint LSP.  Below are the 2 protocols that can be used to build Multipoint LSP:

1.       Multicast LDP (mLDP)
2.       Point to Multipoint Traffic Engineering Tunnel (P2MP TE)

There are 2 types of Multipoint LSPs as below:

1.       Point to Multipoint LSP
2.       Multipoint to Multipoint LSP

Point to Multipoint LSP

Point to Multipoint LSP is a unidirectional LSP with one Ingress LSR and one or more Egress LSR and labeled data replication happening on Branch LSR. P2MP LSP can be established by both mLDP as well P2MP TE. This can be used in application like IPTV video distribution.

Multipoint to Multipoint LSP

This is bidirectional LSP which is currently supported by mLDP only. This can be used in application like Video conference which required bidirectional communication. MP2MP LSP can be used as P-Tunnel to provide Multicast support over BGP/MPLS IP VPN .

In this document, we will discuss about basics of mLDP and the related configuration to enable P2MP and MP2MP LSP using mLDP.

Terminology
Description
P2MP LSP
LSP with one ingress LSR and more than one egress LSR.
MP2MP LSP
LSP that connects a set of nodes in a way that traffic sent by node will be delivered to all other nodes.
Root Node
This plays an important role with mLDP. Any LSR will establish the LSP towards Root node.
Ingress LSR
LSR that sends data packet into an LSP.
Egress LSR
LSR that removes data packet from LSP for further processing.
Transit/Midpoint LSR
LSR that replicates the label packet from upstream to one or more downstream LSRs.
Bud LSR
LSR that have directly connected receivers ( acts as egress LSR) as well have one or more downstream LSR (replicates packet to downstream LSR)
Leaf Node
Any LSR with receivers are termed as Leaf node. It can be either an Egress or Bud LSR.

mLDP overview:
mLDP also known as Multipoint LDP is an extension of LDP protocol that helps establish P2MP and MP2MP LSP in the network. With mLDP, LSP establishment is receiver driven that egress LSR will create LSP whenever there is an interesting receiver.  On receiving interested receiver, mLDP will create the LSP towards Root node. The Root address will be derived either from BGP next hop of the source or through static configuration.

Support for establishing multipoint LSP should be negotiated as part of Session Initialization message. LDP capabilities have been enhanced with new TLV that will be advertised in the LDP Initialization message to negotiate P2MP (0x0508) and MP2MP (0x0509) support capabilities.

As like LDP, mLDP Label Mapping Message carries FEC TLV and Label TLV. FEC elements which will be carried within FEC TLV specify the set of packet/traffic to be mapped to that specific LSP. mLDP uses three different type of FEC element to build MP-LSP as below,

Ø  P2MP FEC Element
Ø  MP2MP Upstream FEC Element
Ø  MP2MP Downstream FEC Element

Below is the FEC Encoding,

 

Parameter
Description
FEC Type
Type of FEC element. P2MP (0x06); MP2MP Upstream (0x07); MP2MP Downstream (0x08)
Address Family
Root Node Address Type. IPv4 or IPv6
Address Length
Root Node Address Length. IPv4 (32 bits); IPv6 (128 bits)
Root Node Address
Root Node
Opaque Value length
Length of Opaque value in octets
Opaque Values
One or more Opaque values which will be used to identify the MP LSP.

Root Node Address

This field carries address of the Root Node towards which the Multipoint LSP will be established.

Opaque Value


 
Opaque value plays a key role in differentiating MP LSP in the context of Root Node.  Opaque value is TLV based and the value may vary based on the application for which MP LSP is established. For example, it might be (S,G) for PIM SSM transit while will be MDT default value in case of MVPN.

Below is the Opaque TLV format,


 

Opaque Value
Description
Type = 00
Manual or Static provisioned MP LSP
Type = 01
Dynamically provided MP LSP for BGP MVPN (Auto discovery)
Type = 02
Statically provisioned MP LSP for MVPN.

P2MP LSP Establishment



1.       Any Leaf node interested in receiving the application stream over P2MP LSP will identify the corresponding Root Node and generate  FEC Element.
2.       The Leaf node will now identify the UPSTREAM router to reach the Root Node (based on RIB entry) and will send Label Mapping for the FEC value.
3.       Any Transit router on receiving P2MP Label Mapping message from DOWNSTREAM router will confirm that the advertising router is not the UPSTREAM for the associated ROOT. Once confirmed, it will check for any existing state entry for the FEC element

a.  If it already has the state entry, advertised label details will be updated in the table for replication.
b.  If it doesn’t have an entry, it will create one and will update the advertised label in table for replication. It now will allocate a local label for the FEC and will advertise to UPSTREAM router towards ROOT.
4.       ROOT node on receiving P2MP label mapping from DOWNSTREAM router will create a state entry if it doesn’t have one and will use the LSP to sent desired traffic.

MP2MP LSP Establishment

 
As we saw earlier, MP2MP LSP is a bidirectional LSP which needs to be signaled both upstream and downstream direction. MP2MP LSP upstream path uses MP2MP UPSTREAM FEC and is ORDERED mode while MP2MP LSP downstream path uses MP2MP DOWNSTREAM FEC.

1.       Any interesting Leaf node will allocate a local label for MP2MP DOWNSTREAM FEC and advertise the same via Label mapping message to upstream LSR.  This LSR will also expect MP2MP UPSTREAM label mapping from upstream LSR for FEC .
2.       Any Transit LSR on receiving label mapping for MP2MP downstream FEC will confirm that it is not received from UPSTREAM LSR for the associated ROOT. Once confirmed, it will check for any existing state entry for the FEC element

a. If it already has the state entry, advertised label details will be updated in the table for replication. It now will check if it has received the UPSTREAM label mapping for the FEC value and if so, will advertise the local upstream label to downstream LSR.
b. If it doesn’t have the state entry, it will create one and will advertise the local downstream label to UPSTREAM LSR towards ROOT. It also now will wait for a UPSTREAM label for the FEC from UPSTREAM LSR before advertising local upstream label to DOWNSTREAM LSR.
3.       ROOT node on receiving MP2MP downstream label mapping from DOWNSTREAM LSR will create a state entry if it doesn’t have one and generate a local upstream label and advertise the same to DOWNSTREAM LSR.
4.       DOWNSTREAM LSR on receiving the upstream label mapping will generate a local upstream label for the FEC and will advertise towards DOWNSTREAM LSR.

Root Node Redundancy

It can be observed that Root Node plays a key role in MP LSP establishment. P2MP LSP and MP2MP downstream LSP will be established towards ROOT while MP2MP upstream LSP will be established from ROOT. So Root node redundancy is a major factor to be addressed as part of network resiliency.

For redundancy, MP LSP will be established to 2 different ROOT node. Any Leaf can receive traffic from any of the ROOT nodes.

In case of P2MP LSP, traffic for a particular FEC should be sent only by one ROOT to avoid packet duplication and inefficient bandwidth utilization.

In case of MP2MP LSP, any leaf node should send the traffic to only one ROOT while can received traffic from any ROOT. This again is to avoid packet duplication and inefficient bandwidth utilization.

Courtesy:

http://tools.ietf.org/html/draft-ietf-mpls-ldp-p2mp-15
http://tools.ietf.org/html/draft-bishnoi-mpls-mldp-opaque-types-01




5 comments:

  1. Wow really amazing blog. thanks for sharing it..

    good job keep ti up...

    http://search-engine-optimising.blogspot.com/

    ReplyDelete
  2. Thank a lot for the post this is great. my question can we use BGP + label instead of LDP label for mLDP?

    Thanks
    Maz

    ReplyDelete
    Replies
    1. Hi,

      mLDP helps you with hop-by-hop label advertisement from leaf towards ROOT. This is not possible with BGP.

      But there are scenarios where both mLDP and BGP can be used. mLDP will be used to build the underlay MP-LSP and BGP can be used to aggregate multiple streams within this (already created) mLDP based MP-LSP with upstream label assignment.

      Delete
  3. Wow...I've been reading about this topic and it wasn't until I read this article that I finally understood how the MP2MP LSP was created. I was having a difficult time adapting to thinking of an LSP as being bi-directional with the whole upstream label mappings and stuff. This article has made this "mental enigma" clear for me.

    Thank you!

    ReplyDelete
    Replies
    1. Hi Pablo,

      Thanks for the comments. Glad that it helps :)

      Delete