Re: PIM-URGENT

[Ahmed A-G Helmy <ahelmy@catarina.usc.edu>]

> Hi, Ahmed
> 

Hi Shuqian,

> I have been doing simulation using the PIM simulator in ns2 for a while, I
> have some concerns about the pim simulator in ns2. There are certain
> occurrence that PIM simulator is not working properly, i.e. it doesn't
> forward the pkt to the desired receivers, the shared tree not build
> correctly(there are no shared tree built at all, for some cases), and the
> RP is not doing its job (the RP doesn't forward the decapsulated data pkt
> to the receivers along the shared tree). Among 10 random graphs simulated,
> there are 2-3 cases like this. When I look at the trace file, I can see
> the join messages are correctly sent to the RP from individual receiver,
> and I assume that's how the routing state on the reverse path been
> established, based on the pim spec.

can you be more specific as to which scenarios actually break, and what 
exactly happens then.. !! this way we can probably help you better,
... it seems from what you're saying that the multicast forwarding cache 
in c++ may be the problem (if the state at the tcl level is built 
correctly), .... is there anything special about these 2 cases that 
doesn't exist in the rest of the 10 cases ?!
theoretically, I can't figure out a reason of why it shouldn't work... 
but then again, I'd have to take a closer look at the specific scenarios.

> 
> As an impression, pim simulator is a simplified version of pim spec (or
> pimd)?? how simplify is it? I can see for some of the graphs, the
> simulator does not perform pim function, such as building of shared tree
> rooted at RP.

the simulator was not supposed to do the complete pim functionality,... 
for example, it does not support periodic timers. So one possibility is 
that if you're employing loss modules and a message is lost, it may not 
be retransmitted after (what you think is) the refresh period...

but from the experiments I (and others) have conducted, the building of the 
shared tree was working fine ... [it may well be the case that some 
scenarios have not been tried out !]
how large are your graphs, are they flat or transit-stub/hierarchical... 
what kind of distribution of membership are you using.

> 
> Another scenario I encountered in the simulation is that if there is a
> direct link between the source and one of the receiver, the source will
> straightaway send naked data packet to the receiver and bypass the RP. Is
> this true only for leaf node? because if I have a chain of receiver
> following the first receiver(who has a direct link to the source), then
> this is a very serious problem, where is the shared tree and what the RP
> is doing in this case? 

if the src and the receiver are on the same link, the packets get 
delivered directly... that is the correct behavior. In reality (more 
specifically for the workstation implementation), there's the host part 
and the router part of the machine, when the sender starts sending, it 
sends the packets out the interface onto the link ... and the DR of the 
link (in the simulator this is the same node as the sender) would pick up 
the packets to register to the RP... note that once the packets were sent 
onto the link any members of the group on that link will get it natively.
The rules of the protocol prevent the RP's decapsulated packets from 
flowing down to the same link again. Otherwise you get packet duplicates 
at the receiver and register looping, which is a serious problem !

I don't see the problem in the scenario you're describing,.. the RP will be 
delivering packets to the rest of the tree, just not that specific link 
where the source resides.

> 
> Could you share with me  your knowledge about this pim simulator, how can
> I possibly check the routing table or the forward cache to know whether it
> is properly set (I suspect some receivers didn't receive the data packet
> is due to no forwarding cache built???)

you can easily check the forwarding cache by checking out the 
replicator_($srcID:$group) in the node's multicast classifier (check the 
file under tcl/mcast/ns-mcast.tcl).

> 
> The simulation result is very important as part of my research project, it
> has to make some sense or be representative of pim in certain degree,
> although there could be some simplification made compared to the spec, I
> assume??  

by the way, the latest versions of ns, with some modified multicast and 
interface support, may break some functionality of PIM.

hope this helps,

Regs,
-A

[btw, I may be out of town/country for the next weeks... so sorry if I 
don't respond promptly]

> 
> Tks,
> 
> shuqian
> 
> 
>