[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
compute-branch
Hi,
In metord
CtrMcastComp instproc compute-branch { src group member }
(~ns/tcl/ctr-mcast/CtrMcastComp.tcl), I found the following lines.
1 if {$tmp == $target} {
2 if {$treetype($group) == $SPT || $tmp == $src} {
3 #when the member is also the source
4 set iif -2
5 } else {
6 #when member is at RP, find iif from RP to source
7 set upstreamtmp [$ns upstream-node $tmp $src]
8 set iilink [$ns RPF-link $src [$upstreamtmp id] $tmp]
9 set iif [[$iilink set dest_] id]
10 }
11 } else {
12 set upstreamtmp [$ns upstream-node $tmp $target]
13 set iilink [$ns RPF-link $target [$upstreamtmp id] $tmp]
14 set iif [[$iilink set dest_] id]
15 }
I think it's not adequate to use upstream-node (line7) to find the node
upstream. According to "ns Notes and Documentation", the root of the shared
tree is now $target, and all packets from $src are unicast to $target. In
my opinion, we should find the upstream node downwards from $src but not
upwards from $target ($tmp), though the results are the same when all the
costs of links are the same. When the upward cost and downward cost are
different, line 7 will give an error answer. All other upstream-node deserve
no changes. Becasue in real world, multicast tree is built upwards, just in
the same way with this method. I substituted line 7 and 8 with the following
lines (ugly codes :-)).
set hh_tmp $src
while {$hh_tmp!=$tmp} {
set upstreamtmp [$ns set Node_($hh_tmp)]
set hh_tmp [[$ns upstream-node $hh_tmp $tmp] id]
}
set iilink [$ns set link_([$upstreamtmp id]:$tmp)]
After substituting, ns can run smoothly even there is only a simplex link
from $src to $target. This property can be used to simulate one-way
satellite broadcast.
Another problem is that switch-treetype can only change the type to SPT
whatever the former type is, while in "ns Notes and Documentation", it says
"or vice-versa".
Any discussion is welcome.
Best regards,
Huang mailto:[email protected]