Introduction

External Impact

• 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 daedelus 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.

Internal Impact

• 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 describing the input arguments to is a Tcl idiom that 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.

Detailed Record of Changes