Planned changes to the ns multicast internals

["Kannan Varadhan" <kannan@ISI.EDU>]

This is just a brief note to describe the changes we are making
to the internal multicast routing protocols in ns.  If you are
only using multicast routing as a infrastructure mechanism,
and the protocol you use is one of dense mode, or centralized
multicast routing, then these changes need not affect you.
More particularly, these changes can simplify your coding, and
also provide improved features that you would use.  However,
if you are looking at multicast routing, or are using PIM
as your multicast routing protocol, then these changes could
affect you adversely.  To understand the nature of the impact,
we would like to hear from you as to exactly what your multicast
routing work is, or how and why you are using PIM, and to better
understand your needs and concerns.

These changes are scheduled to occur before the next release,
currently impending.  Subsequently, we are also considering
the implementation of a sparse mode multicast routing protocol
as well.  Some of the issues we expect to address are:

- redesign of the network interfaces code.  This would make it
	easier to compose complex links etc. without requiring
	knowledge of the internal structure of links and nodes.
	Thus, this eliminates the need for kludges such as:

		if link head is DuplexNetworkInterface ; then
			do something
		else
			do something else
		fi

- provide increased tracing support in multicast

- devolve support for the MultiLink and MultiLinkofInterfaces
	forms of LANs.

	However, we plan to add support to the LAN models
	done by the Daedalus group at Berkeley.

- eliminate the flag variable, Simulator::NumberInterfaces_.  Users
	no longer need worry or specify this variable.  This 
	setting will be quietly ignored, even if the user sets it.

- Similarly, the flag variable, Simulator::EnableMcast_ is to be phased out,
	in favour of a method based invocation of the same.  The premise
	is that, in an OO environment, methods good, flags bad.

- we expect to work on the dense mode, and centralized multicast code,
	and over a brief span of time, provide a simple sparse mode
	implementation of multicast.

	At least the first two items will be completed before the
	impending release.

	In particular, we do not plan to upgrade the PIM implementation 
	in ns at this time.

For those people working on internal multicast routing, there may be
additional impact.  This also impacts those who are using the PIM
implementation in ns at the present time:

- cleanup some of the internal multicast code, to make it easier
	to experiment with multicast routing protocols.
	in particular, we plan to restructure the internals to
	conform to the idioms of the appropriate programming
	language.  Since most of multicast is in OTcl, this means
	that the OTcl code will change.  One common example of
	change is code such as:

	<mrtproto> instproc <method> { argslist } { ...  }

	will change to

	<mrtproto> instproc <method> { args } { ...  }

		In this case, the args form of input arguments to
		a procedure call is a Tcl idiom, and hence is
		*more natural* to OTcl; however, it means that
		functions that call this method should no longer
		wrap their arguments into a single list.  In
		particular, this will cause OTcl to pass the
		arguments as a doubly nested list, and likely
		confuse such methods.

	This also involves other changes to the internal calling
	APIs that could affect the way the base classes interact
	with your routing protocol.  We will attempt to document
	all the details as we accomplish these changes.  These
	will appear on the changes web pages, at
	http://www-mash.cs.berkeley.edu/ns/mcast.html periodically.

This entire message is also available at the same address,
http://www-mash.cs.berkeley.edu/ns/mcast.html.


Kannan

--
kannan@isi.edu
http://www.isi.edu/~kannan