J-Sim INET Tutorial

DVMRP Examples

December 30, 2000

We offer four examples on examining the DVMRP (Distance Vector Multicast Routing Protocol) implementation in J-Sim/INET. Through these examples, we will introduce more RUV commands and also get readers more familiar with the INET framework and some RUV commands we have seen in previous examples.

1. Prerequisites

• Understand how IP multicast and DVMRP work.
• Understand the J-Sim component architecture and the INET framework. Or at least gone through the INET Tutorial homepage.
• The RUV commands and path expression, and basic skills of building a simulation scenario and running a simulation. Or at least gone through the INET Tutorial Example 1.

2. Testing Framework

In all the examples, we will use three scenarios to examine specific operations in DVMRP. The scenarios are demonstrated in a step-by-step interactive manner in the examples. In what follows, we briefly describe the procedures to create the scenarios and what we wish to examine in those scenarios.

2.1 Scenario I: Examine the Route Exchange Operations and How Routes Adapted to Topology Changes

1. Start the simulation (boot up all the routers) and let it run for some time long enough for the unicast routes exchanged among DVMRP's to be stabilized, and then examine the unicast routes in the DVMRP's.
2. Bring down a link, and continue the simulation until DVMRP's discover the link failure (from NEIGHBOR-DOWN events).
3. Examine the unicast routes in DVMRP's during the transitional period of recovery from the link failure.
4. Continue the simulation until DVMRP's are fully recovered from the link failure, and then examine the unicast routes in DVMRP's.
5. Bring back the link, continue the simulation until DVMRP's learn the new routes, and then examine the unicast routes in DVMRP's.

2.2 Scenario II: Examine the Data Forwarding, Forwarding Cache Estabilishment and Maintenance, Prune and Graft Operations

1. Inject a multicast data packet to the network and observe how it is duplicated and forwarded to the entire multicast tree.
2. When the packets reach the leaf routers, observe that the prune process starts and proceeds to the root (source) of the multicast tree.
3. Let the simulation run until the prune process is finished. Examine the prune states in the forwarding cache entries installed by the DVMRP's.
4. Manually generate multicast group join events on routers and observe the graft process and changes of the forwarding cache entries.
5. Let the simulation run until the graft process is finished. Examine the the forwarding cache entries modified by the DVMRP's.

2.3 Scenario III: Examine Prune and Graft Operations in Case of Link Failure

1. Bring down a link that is part of the grafted multicast tree. Continue the simulation to observe how the disconnected branch is grafted back to the multicast tree.
2. Let the simulation run until the graft process is finished. Examine the the forwarding cache entries modified by the DVMRP's. At this point, we may observe some "redundant" branches (i.e., branches that do not lead to any group member).
3. Inject another multicast data packet to prune away redundant branches.
4. Let the simulation run until the prune process is finished. Examine the the forwarding cache entries modified by the DVMRP's.

3. Overview of the Tcl/RUV Commands Used in The Scenarios

To create the above scenarios, we will heavily use several Tcl/RUV commands. Specifically, we need commands to (1) control the simulation flow (stop/resume), (2) examine the unicast routes and forwarding cache entries, (3) bring down/up a link (4) watch changes of unicast routes, forwarding cache entries and delivery of multicast data packets, (5) manually generate multicast group join/leave events and (6) inject a multicast data packet to the network. Tasks (1)-(4) can be easily achieved with existing RUV commands. In particular, we will enable several debug levels* in DVMRP to observe the changes of unicast routes, the prune and graft processes and other significant events. Tasks (5) and (6) are specific to these examples, so we write special Tcl commands to ease the tasks. All the commands used are described in the following in great details:

$sim resumeTo <time in second>

Resume the simulation and make it stop at the specified time.

$sim resumeFor <time interval in second>

Resume the simulation for the specified time interval.

cat n*/dvmrp or cat .../dvmrp

Print the internal states (i.e., the unicast routes) of DVMRP's in all routers.

cat n*/csl/rt or cat .../rt

Print the routing tables from all routers' core service layer (CSL). The routing table in CSL contains the forwarding cache entries installed by DVMRP's.

setflag component true|false <component_path>

Enable/disable a component. A component is enabled by default. One can disable a component to make it refuse to receive any data. We use this command to disable a link to emulate a link failure, and then enable it later to emulate that the link has been repaired and brought back to work.

setflag debug true -at <list of debug levels> n*/dvmrp

Turn on the debug messages at the specified levels* at all DVMRP instances.

watch -c -label FC -add n*/csl/.rt_mcast@event

Add a watcher with label "FC" to listen to all the multicast route (forwarding cache entries) events.

watch -c -label ROUTER_8 -add n8/csl/100@up

Add a watcher with label "ROUTER" to listen to the multicast data packets arriving at the specified router.

setflag garbagedisplay true recursively n*/csl

This command is for watching the first multicast data packets being dropped at the leaf routers of the multicast tree (if the leaf routers do not have group members attached to them), which is the time when the prune process starts at the leaf routers.

send_mcast_pkt -message <message content> -from <a port path> -to <multicast group> -size <size>

This command creates a packet with the body of the specified size and the <message content>. The packet is then injected to the simulation at the specified port and destined to the specified multicast group. In the default address scheme in J-Sim, the multicast addresses take the space of all negative long integers. The port to inject the packet is usually an "up" port at the core service layer of a router.

host_event -join|-leave <multicast group> -host <host path> -router <router path>

This command creates a multicast group join or leave event at the specified router. One may imagine that we manually generate an IGMP event at the specified router. Specifically, the router path could be a path to a router or to one of the ports of the router. If it is a path to a router, then the router behaves as a "multihomed" router, meaning that the router itself becomes a member of the specified multicast group. In this case, the host path must be specified "none". If the path references to a port of a router, then it means that the join/leave event takes place at the host and the host is connected to the port of the router.

The last two commands are specially written for these examples. They are put in the DVMRP_common.tcl file and shared by all the example scripts. Interested readers may check out the source codes from the above link.

4. Examples

1. DVMRP on a four-router network.
   Demonstrates some advanced settings, e.g., configure interfaces, enable/disable a component, set debug flags/watchers, through examining DVMRP operations on a simple topology.
2. DVMRP on a 4-boundary-router and 3-core-router network. (under construction)
   Similar to the first example but on a more complicated topology.
3. DVMRP on a four-router virtual network. (under construction)
   Demonstrates how to use utility functions to construct a virtual network and examines DVMRP operating on such a network.
4. DVMRP on a hierarchical network. (under construction)
   Demonstrates how to use utility functions to construct a CIDR-based hierarchical network and examines DVMRP operating on such a network.

* A derived component may define up to 10 debug levels. The component writers are encouraged to use this facility to organize the debug messages exported by the component. As for users, one can enable/disable a set of debug levels of a component using the "setflag" command:

setflag debug true|false -at <list of debug levels> <component path 1> ?<component path 2>...?

DVMRP defines the following debug levels: