Subject: [pim] Replacing PIM Register packets with MPLS encapsulation

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 11 Feb 2011 06:06:33 +0530

Hi,

I have written a small draft that describes how we could use MPLS tunnels for sending the multicast data traffic to the RP till the SPT is formed, instead of encapsulating them in PIM Register packets.

Abstract

   In PIM-SM the designated router (DR) closest to the source keeps
   sending PIM register packets till it receives an explicit Register-
   Stop message from the rendezvous point (RP) router.  The process of
   encapsulating multicast data traffic to the RP, and the decapsulation
   done by RP are relatively expensive operations for a router to
   perform, depending upon whether or not the router has appropriate
   hardware support for these tasks.

   Since the PIM register messages are native IP packets and routed
   based on IP forwarding tables no resource reservation mechanisms are
   available.  All IP packets will follow common paths that are defined
   by the traditional IGP's algorithm and customizing the path for
   multicast applications is impossible.

   This document proposes using MPLS tunnel(s) to send traffic from the
   source to the RP till the shortest path tree (SPT) from the RP to the
   source is established.  Processing MPLS packets is easy and is
   readily supported on most platforms.

The draft is available here:
http://www.ietf.org/id/draft-bhatia-pim-mpls-register-packets-00.txt

Would love to hear feedback and comments from the WG.

Thanks, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: Eric Rosen <[email-masked]>
Date: Fri, 11 Feb 2011 12:25:51 -0500

The gist of the proposal seems to be:

> source is established.

> The DR close to the source MUST set up an MPLS RSVP-TE tunnel
> [RFC3936] between itself and the RP

> This draft introduces no changes in how the DR sends the Register
> packets.  The same rules apply as defined in[RFC4601].  The only
> thing that changes is that the DR MUST send Register packets using
> the tunnel, instead of the regular registration encapsulation that's
> defined in [RFC4601].

But then how does the RP distinguish a Register packet for (S,G) from an
"ordinary" (S,G) data packet?

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 12 Feb 2011 05:35:10 +0530

> "ordinary" (S,G) data packet?

The regular (S,G) data packets would reach the RP natively over the SPT. Its only the register packets that will use the tunnel. I do explain this in the Appendix.

"When the RP joins the SPT by sending (S,G) Join to its RPF neighbor for the source it will wait till it starts receiving packets natively before sending a Register-Stop message.  Meanwhile, it will continue using the traffic that arrives on the RSVP-TE tunnel and will forward it natively on the RPT tree."

Cheers, Manav

---

From: Sureshkannan <[email-masked]>
Date: Fri, 11 Feb 2011 16:18:58 -0800

Hi Manav,

PIM RP router would accept (s,g) register packet and creates (s,g) entries
even though its not local (s) (interface subnet). In this case, how does RP
differentiate this packet?. Will MPLS gives some info to PIM about this
packet is actually register packet based on tunnel end point ?.

Thanks,
Regards,
Sureshkannan.

On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> The regular (S,G) data packets would reach the RP natively over the SPT.
> Its only the register packets that will use the tunnel. I do explain this in
> the Appendix.
>
> "When the RP joins the SPT by sending (S,G) Join to its RPF neighbor for
> the source it will wait till it starts receiving packets natively before
> sending a Register-Stop message.  Meanwhile, it will continue using the
> traffic that arrives on the RSVP-TE tunnel and will forward it natively on
> the RPT tree."
>
> Cheers, Manav
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 12 Feb 2011 05:55:41 +0530

Hi Suresh,

The RP can identify that its an equivalent of a Register packet if it arrived on an MPLS tunnel as against a packet that arrived natively over the SPT. In case there is a P2MP/regular LSP thats delivering traffic over the SPT, in which case you will get labeled packets there as well, the RP can disambiguate between the two packets by looking at the tunnel label that the packet arrives with.

Cheers, Manav

________________________________
From: Sureshkannan [mailto:[email-masked]]
Sent: Saturday, February 12, 2011 5.49 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]; [email-masked]
Subject: Re: [pim] Replacing PIM Register packets with MPLS encapsulation

Hi Manav,

PIM RP router would accept (s,g) register packet and creates (s,g) entries even though its not local (s) (interface subnet). In this case, how does RP differentiate this packet?. Will MPLS gives some info to PIM about this packet is actually register packet based on tunnel end point ?.

Thanks,
Regards,
Sureshkannan.

Cheers, Manav
_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pim

---

From: David Bard <[email-masked]>
Date: Sun, 13 Feb 2011 04:19:37 +0530

Hi Manav,

You might face an issue if RP is doing a PHP, as in that case you will
not be able to differentiate these packets with the native multicast
packets arriving over the SPT. However, this should not an issue since
the RP must never send a label value 3 to the penultimate LSR. You
might want to add this in your draft.

Overall, i think the idea holds merit and i do support it.

Dave

On Sat, Feb 12, 2011 at 5:55 AM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> Hi Suresh,
>
> The RP can identify that its an equivalent of a Register packet if it
> arrived on an MPLS tunnel as against a packet that arrived natively over the
> SPT. In case there is a P2MP/regular LSP thats delivering traffic over the
> SPT, in which case you will get labeled packets there as well, the RP can
> disambiguate between the two packets by looking at the tunnel label that the
> packet arrives with.
>
> Cheers, Manav
>
> On Fri, Feb 11, 2011 at 4:05 PM, Bhatia, Manav (Manav)
> <[email-masked]> wrote:
>>
>> >

---

From: Yiqun Cai <[email-masked]>
Date: Sat, 12 Feb 2011 20:29:52 -0800

I do have some concerns with the proposal.

Most of the RP implementations today attempt to switch to source trees upon
receiving a register.  After that, most, if not all, the processing is
related to the handling of null registers. The overhead of extracting the
(S,G) information from the null register is not that significant, because it
is a fixed sized header from a fixed offset.  So I don't see using an MPLS
tunnel can improve scalability or performance substantially.

On the other hand, using an MPLS tunnel requires some mechanism, static or
dynamic, to distribute labels between the RP and the DRs (and maybe everyone
in between too).  This overhead has to be discussed when evaluating the
improvement over the existing registering mechanism.

Finally, the draft doesn't address how the proposal can work with Anycast RP
as described by RFC3446 and RFC4610.  As Anycast RP is the most common and
important choice of RP engineering in today's network,  not addressing this
issue will make the solution very difficult to deploy.

Thanks.

-- 
Yiqun

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 13 Feb 2011 14:17:54 +0530

Hi Yiqun,

This mechanism is exclusively meant for networks that are MPLS enabled, so setting up a tunnel and distributing labels between the DRs and the RPs should not be a concern. If it's the RSVP control traffic that you are concerned with then we can use the RSVP Refresh reduction mechanism as described in RFC 2961. If it's the state that you are concerned with then we could go in for a LDP based solution.

I agree that this draft must also address Anycast RP; will do that in the next revision.

Quickly, would the following approach work? 

Instead of the RP (one closest to the source) ensuring that all PIM Register messages reach the other RPs in the Anycast-RP set, cant the DR set up separate RSVP tunnels to each RP. Alternatively the DR can set up one P2MP LSP with all the RPs. The mechanism would then be the same as described in the current draft. No changes there. Using one Path message to describe all the S2L sub-LSPs the control traffic too would be limited.

Cheers, Manav

> -----Original Message-----
> From: Yiqun Cai [mailto:[email-masked]] 
> Sent: Sunday, February 13, 2011 10.00 AM
> To: David Bard; Bhatia, Manav (Manav)
> Cc: [email-masked]

---

From: Eric Rosen <[email-masked]>
Date: Mon, 14 Feb 2011 09:21:37 -0500

Manav> The RP can identify that its an equivalent of a Register packet if it
Manav> arrived on an MPLS tunnel as against a packet that arrived natively
Manav> over the SPT

I really don't understand this.  If you were running PIM on an overlay
topology that consists of pseudowires, e.g., every packet whatsoever would
be arriving on an MPLS tunnel.  In another scenario, an (S,G) data packet
might be arriving from its prior hop over a backup tunnel.  

David> However, this should not an issue since the RP must never send a
David> label value 3 to the penultimate LSR.

Under any circumstances?  I don't think you want to turn off php for all
traffic just because you're functioning as an RP.

Perhaps the supposition is that the DR sets up a special TE tunnel to the
RP, where the purpose of that tunnel is exclusively to carry register
packets, and the tunnel does not use php.  But this would require additional
signaling between the DR and the RP so that the RP knows that the tunnel is
being used only for register packets originating from that DR.

---

From: Yiqun Cai <[email-masked]>
Date: Mon, 14 Feb 2011 14:02:00 -0800

> being used only for register packets originating from that DR.

That is where I see overhead outweighs the benefits.

-- 
Yiqun

---

From: Yiqun Cai <[email-masked]>
Date: Mon, 14 Feb 2011 14:03:02 -0800

On 2/13/11 12:47 AM, "Bhatia, Manav (Manav)"
<[email-masked]> wrote:

> Hi Yiqun,
> 
> This mechanism is exclusively meant for networks that are MPLS enabled, so
> setting up a tunnel and distributing labels between the DRs and the RPs should
> not be a concern. If it's the RSVP control traffic that you are concerned with
> then we can use the RSVP Refresh reduction mechanism as described in RFC 2961.
> If it's the state that you are concerned with then we could go in for a LDP
> based solution.
> 
> Instead of the RP (one closest to the source) ensuring that all PIM Register
> messages reach the other RPs in the Anycast-RP set, cant the DR set up
> separate RSVP tunnels to each RP. Alternatively the DR can set up one P2MP LSP
> with all the RPs. The mechanism would then be the same as described in the
> current draft. No changes there. Using one Path message to describe all the
> S2L sub-LSPs the control traffic too would be limited.
> 

Today,  both Anycast RP solutions require only participation from the RPs.
DRs are not involved.  DRs see only one RP per group (range).

-- 
Yiqun

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 15 Feb 2011 04:40:10 +0530

Eric,
 
> might be arriving from its prior hop over a backup tunnel.  

Fair enough. Then can we change this to say that RP can identify that its an equivalent of a Register packet if it arrived on an MPLS tunnel that was explicitly set up with the DR? It can disambiguate that based on the outermost tunnel value.

> packets, and the tunnel does not use php.  

Yes.

> But this would 
> require additional

This should not be too difficult. One could for example use LSP_Attribute object which would allow setting a flag indicating that this LSP is meant only for carrying register packets originating from the DR.

Cheers, Manav