[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PIM-URGENT
On Thu, 22 Oct 1998, Ahmed A-G Helmy wrote:
> > 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.
I created 10 node flat random graphs, the following scenario is one of
the problems I encountered during the simulations.
2----------3 4
| | |
7 0---------|
| | |
1----------6---------5---------9
|
8
I managed to draw the most part of the graph to describe the links for all
relevant receivers, pls take note not all the links are shown :-(
also links between nodes are purely for connection and they all
represent exactly one hop.
In this case, node 1, 0 2, 3, 9 are receivers for a multicast grp, node 0
is also acting as data source. The algorithm select node 8 as the RP. The
result shown that source 0 sending encapsulated pkt from node 0 -> node 6
-> node 8(RP), at the same time, node 0 send native data pkt from node 0
-> node 3 (one of the receiver of the grp). Through the entire simuation
process, there is no single decapsulated pkt have been forwarded from RP
node 8 to any other receiver( node 1, 2, 9). Looks like there is a problem
in building shared tree.
Also in this scenario, it clarify the argument about data
forwarding on the direct link between rx and src, as you can see node 3 is
on a direct link to node 0-the src, but node 3 is not on the direct link
that will lead to the RP.
Another scenario is the following,
0
|
8-------------1
| |
1----------2------5-------------9
| |
4------7
In this case, node 0, 1,2,3,9 are rx, and node 0 is the src again. Source
node 0 send encapsulated data pkt to the RP- node 7 (0->8->5->7), after
node 7 decap the pkt, it will forward on to rx, ( 7->5->2->3, another
branch is from 5->9),as you can see there is a direct link between 9->1,
but the pkt never been forwarded to node 1 for the entire simulation
process.
>
> >
> > 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...
understood. I can accept certain pkt loss, but not all.
> 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.
I have my explaination above...
> >
> > 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).
I am trying to trace the routing entry now, see what could be go wrong
there.
> > 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
> inteface support, may break some functionality of PIM.
This is exactly what I worried about :-(
> 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]
I am already very grateful for all your help :-)
> >
> > Tks,
> >
> > shuqian
> >
> >
> >
>