Subject: RE: [pim] register messages vs. the SPT

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Thu, 5 Feb 2004 14:40:24 -0600

No, after register-suppression timer expires, DR should send Null Register packet to the RP (it is to inform RP that Sender is till active and to refresh the (S,G) state on RP without sending data). Moreover, SPT should not have been built as there are no receivers so far (hope that's what you meant). Even if the receiver had joined, then also DR should just send Null Register packet to RP after the reg-suppression timer expires. In that case, (S,G) state on RP and PIMrtr would be constantly refreshed by data.

--
Sonum

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahul Bahadur
Sent: Thursday, February 05, 2004 12:15 PM
To: [email-masked]
Subject: [pim] register messages vs. the SPT

Hello,

I have a question about register-encapsulation vs. the SPT. Assume the following topology:

source - DR - PIMrtr - RP -------- receiver(s)?

The source is constantly sending traffic.

Initially the DR has no state and sends a register packet to the RP that replies with a register-stop. The DR stops encapsulation starts the 
register-suppression timer.

Now (for some reason) the SPT gets built, i.e., the DR receives an (S,G) join from PIMrtr. The DR starts forwarding data natively.

When the register-suppression timer expires, should encapsulation re-start?

Thanks,
Rahul

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Rahul Bahadur <[email-masked]>
Date: 05 Feb 2004 13:36:38 -0800

I apologize but I did not state two aspects clearly:
1) no, there are no active receivers initially, which is why the RP
sends a register-stop.
2) after register-suppr. timer expires, a NULL-register would be sent.

I believe I understand the behaviour properly now - even if the DR
receives an SPT-join from PIMrtr while the register-suppr. timer is
running (and is consequently forwarding data natively) it should still
send a NULL register packet to the RP after the timer expires.

Thanks again,
Rahul

---

From: Rahul Bahadur <[email-masked]>
Date: 05 Feb 2004 13:36:38 -0800

Thanks again,
Rahul

---

From: John Zwiebel <[email-masked]>
Date: Thu, 5 Feb 2004 15:39:36 -0800

On Feb 5, 2004, at 12:40 PM, Mathur Sonum-CSM109 wrote:

>
> No, after register-suppression timer expires, DR should send Null  
> Register packet to the RP (it is to inform RP that Sender is till  
> active and to refresh the (S,G) state on RP without sending data).  
> Moreover, SPT should not have been built as there are no receivers so  
> far (hope that's what you meant). Even if the receiver had joined,  
> then also DR should just send Null Register packet to RP after the  
> reg-suppression timer expires. In that case, (S,G) state on RP and  
> PIMrtr would be constantly refreshed by data.
>
> --

First the spec then reality...
Not quite true or there would be no need for the N-bit:

   N    The Null-Register bit. Set to 1 by a DR that is probing the RP
        before expiring its local Register-Suppression timer. Set to 0
        otherwise.

However, this is a case of following the spec to the letter vs doing  
somthing
that is "good enough" to accomplish the job.

By this I mean that the spec defines a "rp-probe time"

   Timer Name: Register Stop Timer (RST(S,G))

+---------------------------+---------------------- 
+--------------------+
   |Value Name                 |Value                 | Explanation       
   |
    
+---------------------------+---------------------- 
+--------------------+
   |Register_Suppression_Time  |Default: 60 seconds   | Period during     
   |
   |                           |                      | which a DR stops  
   |
   |                           |                      | sending  
Register-  |
   |                           |                      | encapsulated  
data  |
   |                           |                      | to the RP after   
   |
   |                           |                      | receiving a       
   |
   |                           |                      | RegisterStop      
   |
    
+---------------------------+---------------------- 
+--------------------+
   |Register_Probe_Time        |Default: 5 seconds    | Time before RST   
   |
   |                           |                      | expires when a  
DR  |
   |                           |                      | may send a Null-  
   |
   |                           |                      | Register to the  
RP |
   |                           |                      | to cause it to    
   |
   |                           |                      | resend a          
   |
   |                           |                      | RegisterStop      
   |
   |                           |                      | message.          
   |
    
+---------------------------+---------------------- 
+--------------------+

But what is the register used for?  To create state in the PIM-RP.

I'm going to cover lots of possibilities but not recommend anything in
particular, However, if I were implementing a new PIM, I'd want to make  
sure
I met all the following.

So back to creating state on the RP, that can easily be done with just a
NULL register to create (S,G) state.  Yes, that means that there will  
not
be a data packet to send down the shared-path, but consider that if the
RP does not have (*,G) state you'll have done all that encapsulating for
no reason.  How expensive that encapsulating is, I don't care to debate.

OK, if you -do- have (*,G) state, what is the first-thing the RP is  
suppose
to do?  Yes, decapsulate and send the packet down the shared-tree, but  
then
-also- join immediately to the shortest-path to create the X-line  
getting
data to flow up to the RP.

Now, you have to worry about sending your register-stop.  If you wait as
required by the spec for data to arrive natively, you could end up with
the first-hop and the rp having full forwarding queues in their Route  
Processor
(since data encap and decap happens on the route processor -- let us not
get into worrying about whether or not a vendor can install a separate
processor to take care of this encapsulation since I agree it can be  
done,
but I would question why one would want/need to do it as you will see.)

So, I submit to you that sending a single register to the RP and having  
the
RP join to the SPT (X-line) would be "good enough".  Not according to  
the
spec, but definitely "good enough".

Arguments about how this decision will result in lost packets to the  
receiver
are valid, but considering how horrible PIM ASM is at delivering all  
the packets
anyway -- who cares.

Now, there is the question about whether or not an encapped data packet  
is
required in the register.  Remember the RP is going to join to the SPT
and once the X-line is set up packets will get forwarded down the shared
tree at all intersections with the X-line.  (ie, all these turn-around
routers are going to get set up).  This happens according to the spec  
now
so it isn't like its an either/or situation.

So, I submit that including an encapsulated packet could be considered
another over-engineered aspect of PIM-SM.

Now, remember that the last-hop router is going to join to the SPT  
anyway.
It has been shown that PIM-ASM, although designed to do so, can not
effectively switch between the shared-tree and shortest-path in a
manner that is reliable enough to not drop packets (or deliver
duplicate packets, if not both).

The PIM-RP is used for source discovery.  In a more well-developed
protocol and if we hadn't been on drugs for the last 10 years, we would
have realized that having the network do source discovery -- especially
when talking about interdomain multicast -- is insane.  (Now is when
this discussion will drift off into the SSM/Bidir vs Sparse mode  
argument.
Do understand that we -must- get there and we have to do whatever it
takes to get there and all objections to the contrary which insist that
ASM is working are moot because ASM requires too many resources from
the network and it always will -- but that doesn't mean that we can
drop ASM today.

So we need to keep (S,G) alive on the PIM-RP for source discovery.
PIM registers are the only way this can be accomplished.

AFAIC, I don't care if they are encapsulated, or NULL registers
just as long as they get there every 3 minutes.

NOTE, the spec specifies that NULL registers are sent as a "probe"
and that if a register-stop isn't received that an encapsulated
register is sent.  In practice this "should" mean that the
encapsulated register should never get sent.  It isn't clear to
me why an RP that receives a NULL register but doesn't respond
with a register stop will do any better with an encapsulated
register, but I suppose an implementation might drop NULL registers
(because of CRC errors or whatever) and not drop encaped registers.

So, bottom line, NULL registers _should_ be "good enough" for most
implementations.  Make sure your NULL registers work.  Make sure
that you can deal with a checksum over just the pim header and
over the entire packet since some implementations do one and
some do the other.

Now your ASM is "good enough" and you can move on to getting
SSM/Bidir developed and deployed and use your political skills
to get switches to support IGMPv3 snooping (or get GARP developed)
and get applications to support SSM and Bidir and get some reliable
source discovery system that doesn't require the network to store
those sources.

Oh, and finally, find a way to deal with Beau's SSM DOS attack.

Pretending that ASM is going to work to get multicast to move beyond
what it is now is putting our heads in the sand.

(Caveat, certain equipment vendors have a bounded network problem
for which ASM may quite nicely meet all their requirements and for
which SSM and Bidir may not add any functionality.  Great.  No
argument.  But if your multicast is suppose to run across the internet
or even in a large enterprise with large BW requirements, its time
to move on.)

> Initially the DR has no state and sends a register packet to the RP  
> that replies with a register-stop. The DR stops encapsulation starts  
> the
> Now (for some reason) the SPT gets built, i.e., the DR receives an  
> (S,G) join from PIMrtr. The DR starts forwarding data natively.
>

---

From: John Zwiebel <[email-masked]>
Date: Thu, 5 Feb 2004 15:39:36 -0800