Re: [pim] a problem about switching to SPT

From 558-mailing-list-admin@catarina.usc.edu Sun Sep 1 08:09:21 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16751 for ; Sun, 1 Sep 2002 08:09:20 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g81C0jW66172 for ; Sun, 1 Sep 2002 05:00:45 -0700 (PDT) (envelope-from 558-mailing-list-admin@catarina.usc.edu) Date: Sun, 1 Sep 2002 05:00:45 -0700 (PDT) Message-Id: <200209011200.g81C0jW66172@catarina.usc.edu> Subject: catarina.usc.edu mailing list memberships reminder From: mailman-owner@catarina.usc.edu To: pim-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: 558-mailing-list-admin@catarina.usc.edu Errors-To: 558-mailing-list-admin@catarina.usc.edu X-BeenThere: 558-mailing-list@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your catarina.usc.edu mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pim-request@catarina.usc.edu) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@catarina.usc.edu. Thanks! Passwords for pim-archive@lists.ietf.org: List Password // URL ---- -------- pim@catarina.usc.edu kimoit http://catarina.usc.edu/mailman/options/pim/pim-archive%40lists.ietf.org From pim-admin@catarina.usc.edu Mon Sep 2 20:35:18 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04040 for ; Mon, 2 Sep 2002 20:35:17 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g830PBW98909; Mon, 2 Sep 2002 17:25:11 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from hotmail.com (f96.law9.hotmail.com [64.4.9.96]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g830OZW98881 for ; Mon, 2 Sep 2002 17:24:35 -0700 (PDT) (envelope-from desai_purvi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Sep 2002 17:34:21 -0700 Received: from 172.142.10.122 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 03 Sep 2002 00:34:21 GMT X-Originating-IP: [172.142.10.122] From: "purvi desai" To: jzwiebel@procket.com, learning_pim@rediffmail.com, sonum@motorola.com Cc: pim@catarina.usc.edu Subject: Re: [pim] ??confused state?? :-) Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 03 Sep 2002 00:34:21.0813 (UTC) FILETIME=[A588F250:01C252E1] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 03 Sep 2002 00:34:21 +0000

Can this sequence happen ( I am going by rfc)
> >>> 1. RP receives Register mesg. from SDR.

> >>> 2. RP de-capsulates the same and sends multicast data towards DDR via IR.

> >>> 3. Register threshold exceeds at RP and hence it sends a SG join towards Source.

> >>> 4. SDR starts sending native data packet along with register mesg towards RP, again via IR.

> >>> 5. IR should maintain both (S, G) and (*, G) entries as a result of which it should fwd the data packets to RP as well as towards DDR.

But here instead of assert, following 6 can happen, looking at data packet forwarding rules of

http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-05.txt

      oiflist = NULL

if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
    oiflist = inherited_olist(S,G)
    if( oiflist != NULL ) {
        restart KeepaliveTimer(S,G)
    }
} else if( iif == RPF_interface(RP) AND SPTbit(S,G) == FALSE) {
   oiflist = inherited_olist(S,G,rpt)
   CheckSwitchToSpt(S,G)
} else {
    # Note: RPF check failed
    if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
       send Assert(S,G) on iif
    } else if ( SPTbit(S,G) == FALSE AND
                iif is in inherited_olist(S,G,rpt) {
       send Assert(*,G) on iif
    }
}

oif! list = oiflist (-) iif
forward packet on all interfaces in oiflist

6. packet is received on valid interface since it is RPF_interface(S) and there is no forwarding si

> >>> 7. IR should also trigger (S, G, rpt) prune towards RP.

> >>> 8. RP should respond to it by pruning off the interface

> >> towards

> >>> IR.

> >>> 9. RP should also send Register Stop towards the SDR.

> >>> 10. SDR should stop sending registers.

> >>> 11. RP should also sent (S, G) prune towards the Source

> >> via

> >>> IR.

> >>> 12. IR has to fwd the (S, G) prune towards SDR !! (should

> >> it

> >>> really do this ?????)

> >>> 13. Source is pruned off at SDR.

> >>>

> >>> And a fresh cycle starting from the step1 begins(once the

> >> keep

> >>> alive timer expires at IR).

> >>>

>From: John Zwiebel

>To: Prashant Jhingran , Mathur Sonum-CSM109

>CC:

>Subject: Re: [pim] ??confused state?? :-)

>Date: Thu, 29 Aug 2002 11:45:25 -0700

>On 8/28/02 10:19 PM, "Prashant Jhingran"

>wrote:

> > hi Sonum,

> > Thanks for a prompt reply, I am convinced regarding the

> > Assert mechanism suggested by you but my doubt is now regarding

> > the IR and SDR interaction. SDR will continue to send native data

> > packets only if it shall receive (S, G) joins...now do u mean to

> > say that IR will keep on sending SG joins towards SDR (as it will

> > be having an inherited oif in the (S, G) entry) ???....

> > Lets also assume that the receiver has a pretty high data

> > threshold so it never switches to SPT, meaning never tries to form

> > a SPT.

> >

>One point of clarification, when the RP asserts and loses, it will

> delete the interface from the (S,G) olist and at that point send

> the (S,G) prune, ie. -before- the (S,G,R) prune is sent from IR.

> (One must recognize that the data rate may change the order in

> which these events happen. Ie the last-hop router -may- have

> joined to the SPT prior to the assert happening beteen the RP and

> IR which would then result in the order of events Sonum stated.

> The important thing to understand here is that order doesn't matter)

>The question Prashant has to ask himself is: "why does IR forward

> the (S,G) prune received from the RP to the SDR?"

>I would say that it won't. (BTW, the topology map didn't come

> through very well so, I'm making certain assumptions that may

> be incorrect.)

>Why won't the prune be forwarded? What is the (*,G) state in

> IR? Doesn't it have a (*,G) with an OIF toward the DDR (receiver)?

> Yes, therefore the (S,G) will have "inherited" that interface when

> the (S,G) state is created by the (S,G) join triggered from

> the RP when it joins the SPT. -OR- DDR will have joined the SPT

> so that same interface will be an "immediate" interface.

>In any case, IR does not have a NULL olist for (S,G) and so will not

> trigger a prune toward SDR.

>Going back to the original steps outlined:

> Step 5: Yes IR has both (*,G) and (S,G), but all packet

> forwarding for this source will be via the (S,G) route

> which will 'inherit' the (*,G) olist. The router should

> -never- forward on both (*,G) and (S,G) at the same time

> or you will have forwarding loops in your network.

> Step 6: Yes an assert does happen. But the SPT -always- wins over

> the RPT so the RP will delete its interface from the Olist, which

> (as already stated) causes a triggered (S,G) prune toward the source.

> Step 7: NO, absolutely not. IR is an -intermediate- router. Only the

> last-hop router has the power to make the decision whether or not

> an (S,G,R) prune is TRIGGERED. Yes, if DDR has joined the SPT and

> sent an (S,G,R) prune to IR then IR does indeed forward that message.

> (NOTE: its the description of the prune message being "TRIGGERED" that

> I'm discussing. IR does indeed send periodic (S,G,R) prunes because

> the IIF for the (*,G) and (S,G) are different. It would be

> very easy to ignore this subtle difference. Kind of like saying

> "IGMP join" rather than "IGMP report", which can get very confusing

> when you shorten this to just "join" vs "report" because now you

> are talking about a PIM join vs an IGMP report. Perhaps I should

> have just left this one alone. ).

> Step 8: Yes, it is important to identify the interface as

> 'inherited' though.

> Step 12: Does IR have a NULL olist? Yes, then a prune is sent to

> SDR. But how can IR have a NULL olist if it is receiving

> (*,g) joins from DDR? It can't, so no Prune is forwarded.

> {NOTE: this is assuming I understand your topology.)

>Since there may be a misunderstanding about the topology...

>The following assumes that DDR and IR and RP all have an

> interface on the same subnet and that DDR does -NOT- wish

> to join to the SPT. This 'should be' a very rare occurrence

> and so you may not want to get into this too deeply.

> -- if the RP forwards a packet down the shared tree, then DDR

> must have (S,G) state and so will trigger a (S,G) join toward

> the source, meaning the assert between the RP and IR which

> results in a (S,G) prune from the RP, will cause a (S,G) join

> override to be sent from DDR.

> -- if DDR has an infinite SPT threshold, when it sees the (S,G)

> assert, it has to create (S,G) state and again, when the

> RP prune is seen override that message.

>This (S,g) state creation isn't directly

> addressed by the spec, but in 4.2.2 the note after

> "Update_SPTbit" that says: "Additionally a router sets SPTbit(S,G)

> to TRUE when it receives an Assert(S,G) on RPR_interface(S)."

> implies that (S,G) state must be created.

>Alternatively, IR is sending an (S,G,R) prune and DDR has

> (*,G) state which means it has to override that prune. See

> section 4.5.9 Figure 9. You are in the "not pruned" state so you

> have to trigger an (S,G,R) join override so the RP does not

> delete the inherited interface, so it does not send the (S,g)

> prune to IR.

>What one hopes is that by this time, the RP has sent a register-stop

> to SDR so the assert process won't happen any longer. Which is

> why I advocate creation of (S,G) state on DDR when it sees the

> upstream assert, but this is an implementation option.

>Ask yourself though, do you want to have to send a (S,G,R) join

> override for every (S,G,R) prune you see?

>(Of course, if DDR joins to the SPT, this becomes a non-issue and

> since this list is working very diligently on SSM this

> problem will quickly become a non-issue.)

> >

> > On Thu, 29 Aug 2002 Mathur Sonum-CSM109 wrote :

> >>

> >> Prashant,

> >>

> >> After step 6, RP will send Assert packet, but this Assert (with

> >> RPT bit set) will be ignored by IR as IR has no (*,G) downstream

> >> on that interface. So there should not be any chaos. And there

> >> will not be more than one Assert messages as this branch will be

> >> Pruned by RP when RP gets (S,G,RPT) Prune from IR.

> >>

> >> As soon as IR gets the first native data packet, it sends

> >> (S,G,RPT) Prune towards RP, and RP will then send (S,G) Prune to

> >> IR. This (S,G) Prune will not be forwarded by IR to SDR. This is

> >> because IR will have interface towards receiver in the downstream

> >> list of (S,G) entry. IR will be in the (S,G) forwarding state,

> >> which would be refreshed by data packets. RP will remain in

> >> Pruned state and should send Register Stop to the next and

> >> subsequent periodic Null Register messages.

> >>

> >> Hope my assumptions are correct about the topology.

> >> --

> >> Sonum

> >>

> >>> -----Original Message-----

> >>> From: Prashant Jhingran [mailto:learning_pim@rediffmail.com]

> >>> Sent: Wednesday, August 28, 2002 6:55 AM

> >>> To: pim@catarina.usc.edu

> >>> Subject: [pim] ??confused state?? :-)

> >>>

> >>> hi all,

> >>> Please have a look at the following topology:-

> >>>

> >>> The following topology can be a part of a large multicast

> >>> network.

> >>>

> >>> RECEIVER SENDER

> >>> |_| DDR |_| SDR

> >>> | |

> >>> | _____________|

> >>> |___|

> >>> | | IR

> >>> |___|

> >>> |

> >>> |___| other links

> >>> | |_

> >>> _|___| RP

> >>> | |

> >>>

> >>> Now my doubt is regarding the sequence of events which

> >> shall

> >>> take place once the SDR starts sending Register messages

> >> towards

> >>> the RP.

> >>> Lets assume that the (*, G) tree is already stabilished before

> >> the

> >>> source starts pumping datapackets.

> >>>

> >>> At the RP,interface to reach both the source and the receivers

> >> is

> >>> same so there is a possibility of an assert like but not

> >> exactly

> >>> assert situation at the RP,if not always but at least for

> >> some

> >>> time.

> >>>

> >>> I feel that the following should be the sequence of

> >> events:-

> >>>

> >>> 1. RP receives Register mesg. from SDR.

> >>> 2. RP de-capsulates the same and sends multicast data

> >> towards

> >>> DDR via IR.

> >>> 3. Register threshold exceeds at RP and hence it sends a SG

> >> join

> >>> towards Source.

> >>> 4. SDR starts sending native data packet along with

> >> register

> >>> mesg towards RP, again via IR.

> >>> 5. IR should maintain both (S, G) and (*, G) entries as a

> >> result

> >>> of which it should fwd the data packets to RP as well as

> >> towards

> >>> DDR.

> >>> 6. Now RP receives datapacket on the (*, G) Out going

> >> interface

> >>> and as a result might indicate Assert..but truly speaking

> >> assert

> >>> can happen on a multi-access link !!!

> >>> And the chaos begins!!!

> >>> 7. IR should also trigger (S, G, rpt) prune towards RP.

> >>> 8. RP should respond to it by pruning off the interface

> >> towards

> >>> IR.

> >>> 9. RP should also send Register Stop towards the SDR.

> >>> 10. SDR should stop sending registers.

> >>> 11. RP should also sent (S, G) prune towards the Source

> >> via

> >>> IR.

> >>> 12. IR has to fwd the (S, G) prune towards SDR !! (should

> >> it

> >>> really do this ?????)

> >>> 13. Source is pruned off at SDR.

> >>>

> >>> And a fresh cycle starting from the step1 begins(once the

> >> keep

> >>> alive timer expires at IR).

> >>>

> >>> I would like to have comments on my thinking and please

> >> suggest

> >>> the correct set of actions.I feel the above topology is very

> >>> different from the normal ones and it would be nice to have

> >>> comments from the authors too. Please note that i am following

> >> the

> >>> draft and not the old RFC.

> >>>

> >>> thanks and regards,

> >>> Prashant

> >>>

> >>> _______________________________________________

> >>> pim mailing list

> >>> pim@catarina.usc.edu

> >>> http://catarina.usc.edu/mailman/listinfo/pim

> >>>

> >

> > _______________________________________________

> > pim mailing list

> > pim@catarina.usc.edu

> > http://catarina.usc.edu/mailman/listinfo/pim

> >

>_______________________________________________

>pim mailing list

>pim@catarina.usc.edu

>http://catarina.usc.edu/mailman/listinfo/pim

Join the world�s largest e-mail service with MSN Hotmail. Click Here
_______________________________________________ pim mailing list pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Mon Sep 2 20:37:30 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04082 for ; Mon, 2 Sep 2002 20:37:30 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g830SJW98973; Mon, 2 Sep 2002 17:28:19 -0700 (PDT) (envelope-from pim-admin@catarina.usc.edu) Received: from hotmail.com (f151.law9.hotmail.com [64.4.9.151]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g830OwW98887 for ; Mon, 2 Sep 2002 17:24:58 -0700 (PDT) (envelope-from desai_purvi@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Sep 2002 17:34:45 -0700 Received: from 172.142.10.122 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 03 Sep 2002 00:34:44 GMT X-Originating-IP: [172.142.10.122] From: "purvi desai" To: jzwiebel@procket.com, learning_pim@rediffmail.com, sonum@motorola.com Cc: pim@catarina.usc.edu Subject: Re: [pim] ??confused state?? :-) Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 03 Sep 2002 00:34:45.0053 (UTC) FILETIME=[B36316D0:01C252E1] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 03 Sep 2002 00:34:44 +0000

Can this sequence happen ( I am going by rfc)
> >>> 1. RP receives Register mesg. from SDR.

> >>> 2. RP de-capsulates the same and sends multicast data towards DDR via IR.

> >>> 3. Register threshold exceeds at RP and hence it sends a SG join towards Source.

> >>> 4. SDR starts sending native data packet along with register mesg towards RP, again via IR.

> >>> 5. IR should maintain both (S, G) and (*, G) entries as a result of which it should fwd the data packets to RP as well as towards DDR.

But here instead of assert, following 6 can happen, looking at data packet forwarding rules of

http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-05.txt

      " oiflist = NULL

       if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
           oiflist = inherited_olist(S,G)
            if( oiflist != NULL ) {
            restart KeepaliveTimer(S,G)
        }
     } else if( iif == RPF_interface(RP) AND SPTbit(S,G) == FALSE) {
      oiflist = inherited_olist(S,G,rpt)
   CheckSwitchToSpt(S,G)
} else {
    # Note: RPF check failed
    if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
       send Assert(S,G) on iif
    } else if ( SPTbit(S,G) == FALSE AND
&nbs! p;               iif is in inherited_olist(S,G,rpt) {
       send Assert(*,G) on iif
    }
}

oiflist = oiflist (-) iif
forward packet on all interfaces in oiflist