RE: [pim] PIM Register & Register-Stop process

"David McWalter" <DMcW@dataconnection.com> Wed, 01 February 2006 14:00 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IXG-0005S1-M5; Wed, 01 Feb 2006 09:00:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IXE-0005Qe-6n for pim@megatron.ietf.org; Wed, 01 Feb 2006 09:00:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01290 for <pim@ietf.org>; Wed, 1 Feb 2006 08:58:51 -0500 (EST)
Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4IiF-0006mE-4s for pim@ietf.org; Wed, 01 Feb 2006 09:12:01 -0500
Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 14:00:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [pim] PIM Register & Register-Stop process
Date: Wed, 01 Feb 2006 14:00:11 -0000
Message-ID: <986E07666EAE1C459DC81492A7FA4CEA0F19B7@enfimail1.datcon.co.uk>
Thread-Topic: [pim] PIM Register & Register-Stop process
Thread-Index: AcYnNFddvvt/qJVoTceb5usBAsbvcgAAYCZw
From: David McWalter <DMcW@dataconnection.com>
To: Nikhil Ninan <nikhil@erg.abdn.ac.uk>
X-OriginalArrivalTime: 01 Feb 2006 14:00:11.0606 (UTC) FILETIME=[D1601F60:01C62737]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0
Cc: pim@ietf.org
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0514504524=="
Sender: pim-bounces@ietf.org
Errors-To: pim-bounces@ietf.org

1) This is in the overview, section 3.  The DR waits for the SPT data before pruning off the RPT.
..  When the first traffic starts to arrive from the SPT, the DR or
upstream router starts to drop the packets for G from S that arrive via
the RP tree.  In addition, it sends an (S,G) Prune message towards the
RP.  This is known as an (S,G,rpt) Prune.  ...
 
2) The RP will have keepalive timer KAT(S,G) from the Register messages, plus (*,G,I) and (S,G,rpt,I) state on the downstream interface from the Join(*,G) and Prune(S,G,rpt) it has received, and continues to receive periodically.
 
3) No.  PIM is pretty much hop-by-hop.  PIM routers don't try to work out the state of remote routers across the network; just adjacent ones.
 
4) No.  If the RP joins the SPT, it gets multicast data hop-by-hop just like anyone else.  When it gets the Prune(S,G,rpt), it'll leave the SPT again and not forward any (S,G) data at all.
 
Try searching for this stuff in the PIM spec.  It's all in there.
http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt
 
DMcW.
 
-----Original Message-----
From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org]On Behalf Of Nikhil Ninan
Sent: 01 February 2006 13:35
To: pim@ietf.org
Subject: [pim] PIM Register & Register-Stop process
Importance: High



Hello,

         My next question, this is the situation:          

When a source DR gets multicast packets it encapsulates them and sends it to the RP by unicast. The RP will check, if there doesn't exist receivers for the group, will send a Register-Stop message and also starts within itself for the group. The source DR as to keep sending null-register packets to the RP before the timer expires thereby maintaining the state for the group. Now if a receiver joins the group the RP will send a (S, G, spt) Join to the source DR. Now the source DR sends multicast data to the RP, which in turn will forward it to the receiver's DR through the (*, G, rpt) Join that the receiver's DR had sent earlier. Once the Receiver's DR learns the address of the source, it sends a (S, G, spt) Join directly to the source DR and the source DR will forward multicast traffic directly to the receiver's DR.

 

1.)     Now does the receiver's DR send the prune to the RP tree first? And when does the source DR send a prune to the RP?

2.)     Now if this was the only receiver for the group & the traffic is flowing through the source tree then what states will be maintained by the RP for the group, assuming that the source is transmitting??

3.)     And does the RP know that there is direct forwarding of traffic between the source DR and receiver DR?

4.)     Is the multicast data forwarded to the RP always encapsulated, even if the RP sends (S, G, spt) Join to the source DR as above???

 

Cheers

Nikhil

_______________________________________________
pim mailing list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim