IP Multicast Simulation in OPNET
Xin Wang, Chien-Ming Yu, Henning Schulzrinne
Columbia University
Department of Computer Science
New York, New York
Email: xinwang@cs.columbia.edu,
hgs@cs.columbia.edu
Paul A. Stirpe
Reuters
88 Parkway Drive South
Hauppuage, New York
email: paul.stirpe@reuters.com
receiver hosts and multicast-enabled first hop routers on
the LAN. Internet Group Management Protocol (IGMP)
[2] is the primary group management protocol used in
the Internet community. IGMP is used between hosts
and their immediate multicast-enabled routers to query,
report, and refresh the multicast group information on
LAN.
ABSTRACT
IP multicast is an emerging wide area network
technology that provides the capability for efficient
information dissemination from senders to potentially
large sets of receivers. IP multicast distribution trees or
pathways are enabled via a combination of the LANbased Internet Group Management Protocol (IGMP)
working in concert with multicast routing protocols. The
financial industry is beginning to utilize IP multicast as a
delivery mechanism for near real-time information
dissemination. However, financial services typically
have stringent availability requirements. Therefore, the
failure recovery characteristics of IP multicast are of
interest to investigate. In this paper, we report on the
simulation design of the Protocol Independent Multicast
Dense Mode (PIM DM) multicast routing model, the
IGMP group management model, and other models for
OPNET. Furthermore, the modifications required to
several OPNET IP models to support multicast are
detailed. The simulation was used to investigate the
failure recovery characteristics of IP multicast.
There are several types of unicast routing protocols
currently in use, including dynamic and static. RIP is a
distance vector type protocol whereas Open Shortest
Path First (OSPF) is link state based [1]. A superior
characteristic of link state protocols is that they can react
more rapidly to topologic changes as compared to
distance vector or static topologies.
A third component protocol required to enable multicast
communications over the WAN is multicast routing
protocols. Multicast routing protocols often use the
metrics and topology information that is maintained by
the underlying unicast routing protocol to build and
maintain multicast packet delivery trees, and forward
multicast packets. Multicast routing protocols may be
integrated with a unicast routing protocols or may be
independent of the underlying unicast routing protocol.
Distance Vector Multicast Routing Protocol (DVMRP)
[5] is tightly coupled with RIP, and Multicast Open
Shortest Path First (MOSPF) [3] to OSPF, whereas
Protocol Independent Multicast (PIM) [6] is independent
of the underlying unicast routing protocol and may run
over any unicast routing protocol.
The protocol models developed herein include IGMP for
multicast group membership management, OSPF as the
unicast routing protocol, and PIM DM [4] as the
multicast routing protocol.
INTRODUCTION
There has been much discussion about the use of IP
multicast technology for efficient information
dissemination. IP Multicast enables a network to send
messages to a group of anonymous receivers, as
compared to unicast or broadcast that targets one or all
recipients respectively. It has the potential to utilize less
network and host resources in providing this service.
Applications, such as Internet radio, realtime financial
information dissemination, software distribution all can
potentially benefit from the use of IP multicast.
Simulation models for an IP multicast system are
developed for the investigation of end-to-end multicast
failure recovery behavior and performance. When a link
or router failure occurs in a network, the multicast data
delivery service can be interrupted for a period of time.
Multicast group membership management, unicast
routing protocols, and multicast routing protocols are all
required to enable end-to-end multicast communications.
Group membership management is needed between
1
In financial systems, for example, services that are
carried using multicast must be able to rapidly recover
from network failures.
only pull-down those multicast channels for groups that
are of interest to receivers on the LAN.
PIM DM is a broadcast and prune protocol and is best
suited for networks where most receivers are “densely”
populated and bandwidth is plentiful. When a source
commences sending UDP traffic with an IP destination
group address the first hop router(s) floods the data out
its interfaces except the interface on which the data
arrive. Subsequent routers do the same during this
broadcast phase of the protocol. When the multicast
channel reaches a leaf router (one that is LAN connected
to potential receivers), the group information maintained
by the router is examined and either the multicast data is
forwarded onto the LAN or the router prunes back the
channel. This allows only those receivers that have
expressed interest in the group to have the channel
extended to them. The broadcast and prune process
repeats every three minutes. There is also the ability for
a new receiver to asynchronously attach to the multicast
channel via a grafting mechanism.
This paper outlines the simulation models that where
developed within OPNET for IP multicast. Several
models were developed to provide multicast network
capabilities. The models include IGMP, PIM DM,
modifications to the IP forwarding engine, a random
topology generator, an multicast sender and receiver
application model, and a link fault injector, as well as
several probes to acquire simulation statistics. In the
next section, an introduction to the protocols is
provided, followed by a description of the
simulation models.
MODELS OVERVIEW
The establishment of end-to-end multicast
communication channels requires several protocols to
work in concert. To establish a multicast channel over a
native multicast enabled WAN, a sender application
need only to send UDP packets onto the LAN using a
class D IP address (group address) in the destination
field of the IP header. The multicast enabled routers in
the network are responsible for constructing the
multicast channel, and extending it to the interested
receivers.
OSPF is a link state unicast routing protocol that
provides robust fail-over characteristics, compared to
other unicast routing protocols. It can dynamically
detect topological changes and calculate new loop-free
routes after a period of convergence. Each router in the
network maintains a replicated database. Routers
execute Dijkstra's algorithm on their database to
calculate a shortest-path route to a given destination
subnet. Routers exchange database information
periodically, or when network element failures occur, via
a standard flooding algorithm. OSPF was first
introduced into OPNET in version 3.5A by Mil3 and is
the version on which this work was completed.
At the receiver side, however, the group management
protocol IGMP must execute between receiver hosts and
their default routers to allow hosts to express interest in
particular multicast groups. The receiving application
must explicitly express interest to its transport stack, in
attaching to a specified group and UDP port. The IGMP
component executing on the receiver host then forwards
the group interest, specified by the class D IP address, to
the routers on the receiver’s LAN. A selected router
(designated router) subsequently attaches to and
forwards all multicast channels for the specified group
onto the LAN network. The host’s transport stack filters
data received from different sources for the same group
de-multiplexing via the UDP port number specified by
the receiving application. If multiple sources send using
the same group and destination UDP port number,
application level filtering would be required at the
receiving application to distinguish amongst the
information streams.
In the next section, an overview is given for the IGMP,
PIM DM models, as well as the other required
modifications and capabilities developed for the
multicast simulation.
THE SIMULATION MODELS
A network consists of numbers of routers and hosts.
Routers connect directly to other routers or to local area
networks (LAN), where hosts or other routers are
connected.
To support IP multicast, we modify the original OPNET
IP models (IP_RTE and IP_ENCAP) to process
multicast packets and thus carry-out multicast
forwarding. The PIM_DM model is added into the
network node models and provides routing control for
multicast packets. In addition, the IGMP router and host
Periodically, IGMP executing in the router queries the
hosts on the LAN to maintain the accuracy of its group
knowledge. This allows the designated router (DR) to
2
models are added, to work with the PIM model. In order
to inject traffic into a network, an application model
which generates either unicast or multicast UDP
datagrams is developed.
Inside each of the following models, we will mention the
uses of the above methods to interact with other
modules.
IP MULTICAST FORWARDING: THE IP_RTE
MODEL
There are two communication mechanisms and one
model-wide registry used to get, give, or exchange
information from one model instance to another. They
are:
IGMP
PIM
r,w
r,w
r,w
Mlocal
OSPF
r
Mroute
r
The main function of IP_RTE is to act as the IP
forwarding engine and process IP packets that go
through this module either from higher layers or from
network. There are several modifications required to the
standard IP_RTE model in order to support IP Multicast
as illustrated in Figure 1. Those modifications are
outlined below.
r
IP_RTE: PROCESSING PACKETS ARRIVING FROM
HIGHER LAYERS
r,w
r,w
IP Encap
Unicast
route
r
Packets arriving from upper layer models like OSPF,
PIM DM, UDP, etc., need to be forwarded out towards
their destination. In this case, IP_RTE will either get
one or more interface addresses specified by the upper
layer model as an outgoing interface, or needs to
perform a lookup in the routing tables to get a list of one
or more outgoing interfaces. There are a few
circumstances in which packets will reach IP_RTE from
the upper layer.
IP Forwarding
Network
Figure 1: Basic router simulation model structure
1. Model-wide Registry: This can be effectively used in
conjunction with the existing communication
mechanisms for various modeling requirements. The
process registry defines a group of procedures that allow
OPNET defined processes to record, access, and share
information in a model-wide (or global) registry.
Usually, we use this type of communication mechanism
to share information needed by other modules, such as
dynamic unicast routing table, the dynamic multicast
routing table or interface table information.
Unicast data packets: IP_RTE needs to find the outgoing
interface from the dynamic unicast routing table.
Multicast data packets:
1. Inside a host, this situation happens when the host is
the source of data packets. So far our hosts only
have exactly one interface connected to the
broadcast media; we use this interface address as an
outgoing interface.
2. Inside a router, this situation happens when the
dynamic multicast routing (mroute) table did not
contain an entry of the source-destination that
matched this incoming packet when this packet
arrived at the router. This packet was forwarded up
to PIM. PIM creates an entry for this sourcedestination and sends it down to IP_RTE again. For
this case, outgoing interfaces are obtained from the
mroute table.
2. Packet-Based Communications: This is used when
there are packets needed to be relayed or exchanged
inside the simulation network.
3. Interface Control Information: This type of
communication mechanism is generally associated with
Packet-Based communications, that is, stream events.
This happens because the information not carried by
packets themselves needs to be sent to the receiving
process. Sometimes, an ICI is associated with remote a
interrupt so that the interrupted module can retrieve
information even when the model instances are not
physically connected inside a node or outside a node.
Multicast control packets: when IP_RTE receives
packets destined to a reserved multicast address
(multicast control packets), IP_RTE will process them in
a different way compared to a pure datagram data
packet. Multicast control packets are forwarded out
through the interface specified by the higher layer.
3
When a packet arrives from the IP_RTE layer, the
reverse procedure of the above situation needs to be
performed. That is, attributes from the incoming packet
are converted into an ICI that is associated with the
datagram sent to the higher layer.
IP_RTE: PACKET PROCESSING ARRIVING FROM
THE NETWORK
Packets from the network will either be forwarded to the
higher layer, forwarded out, or destroyed. When a packet
from network arrives and reaches it's destination, this
packet will be forwarded up to IP_ENCAP. IP_ENCAP
then dispatches this packet to the corresponding module.
Some packets need to be forwarded out again. Control
packets are forwarded up to IP_ENCAP if their reserved
control address is registered. Incoming data packets that
have reached their destination are forwarded to
IP_ENCAP. All other incoming packets are destroyed.
PIM DM MODEL
The main function of PIM_DM is to create and maintain
routing information for multicast packets inside the
router nodes. The interaction between the PIM_DM
model and the IGMP model is also important to properly
maintain the mroute table, as will be discussed shortly.
The mroute table needs to be registered so that IP_RTE
can reference it and know how to forward multicast data
and control packets. Furthermore, dynamic unicast
routing information is received from the OSPF process
registry. After the mroute table is constructed, IP_RTE
can use both dynamic unicast and multicast routing
information during its packet forwarding process. At this
point, the PIM hello message is scheduled to be
forwarded to all PIM neighboring routers.
Unicast data packets: IP_RTE will either forward them
to upper layers if they reach their destination or out
again onto the network towards their destination.
Multicast data packets: When a router receives this type
of packet, it will lookup in the mroute table to find an
entry that matches this packet. If the entry is found in the
mroute table, IP_RTE forwards the packet out onto the
one or more interfaces specified in the mroute table
entry. If an entry that matches this packet is not found,
the packet is sent to the PIM model that will create an
mroute entry for this packet and in turn send it down to
IP_RTE again. At this time, IP_RTE knows how to
forward this packet, using the just established mroute
table entry.
For a host node model, IP_RTE checks the incoming
multicast data packet against the mlocal, maintained by
IGMP.
The PIM DM model is now ready to process the
incoming packets. There are two types of packets that
can arrive at the PIM DM model; IGMP and all PIM
messages. The IGMP messages are used to update the
mlocal table and the PIM messages are used to update
the mroute table. All the PIM messages are processed as
is specified in the PIM_DM protocol specification.
IGMP MODELS
Multicast control packets: If the IP address of the
incoming packets is a reserved address, IP_RTE will
forward it to the higher layer via IP_ENCAP.
IP_ENCAP in turn will forward it to the corresponding
module.
IGMP is a group management protocol that has two
components; one that executes in hosts and one that
executes in routes.
IP_ENCAP MODEL
The IGMP router model initializes and then periodically
sends IGMP general queries on all its LAN interfaces to
collect group information. The IGMP router model may
receive an IGMP leave group message from a host and
subsequently remove that group specific information
from the mlocal table (after executing a group specific
query, as per the IGMP specification). PIM_DM is
notified when the first member of the group joins the
group, and when the last member of the group has left
the group.
IGMP ROUTER MODEL
This model processes all packets from upper modules
that want to use the IP service provided by IP_RTE, and
by all packets arriving from the IP_RTE. When a packet
arrives from the higher layer, an IP packet needs to be
created to encapsulate this packet. In turn, the attributes
of this IP packet need to be set from the ICI
corresponding to this stream event and a new ICI will be
installed. There are two ICI formats used for this
purpose. One is for general datagrams from higher
layers.
When a router receives an IGMP message, if the
message is a query from another router, it determines
whether it remains in the Querier role. If the message is
4
a report from a host, the IGMP model refreshes the
report timer for that group on the interface received, or
insert the group for the interface into the IGMP mlocal
table if it is not yet in the table, and notifies PIM of the
state change. If the message is an IGMP leave message
from a host, IGMP schedules a group specific query for
that group on the interface from which the message was
received.
place. If the time value is zero, then the join or leave will
be called immediately. However in some circumstance
users might want to schedule a join and leave based on
previously defined values instead of scheduling an
immediately join or leave.
The APP model also provides an API to allow dynamic
join or leaves to occur. For dynamically called joins and
leaves, a new state is defined that can receive interrupts
from prospective models.
IGMP HOST MODEL
The IGMP host model is responsible for two activities. It
can receive join or leave requests from the application
model (APP). It also responds to membership queries.
When the module receives a join or leave from an
application (higher layer), it needs to update the IGMP
table inside the host to indicate the group address and
number of applications on this host joining this specific
group. When a host receives a membership query, it will
schedule an interrupt so that a response state will send a
membership report to the routers on the LAN.
CONCLUSIONS
THE APPLICATION MODULE (APP)
A description of an IP multicast OPNET simulation is
provided. The simulation models consist of several new
node models, including PIM DM and IGMP.
Additionally, many changes were required of OPNET
within the IP forwarding function to support multicast.
The detailed enhancements to the OPNET IP_RTE and
IP_ENCAP models were outlined. Since space is
limited, several supporting models are mentioned but not
discussed, including a random topology generator, link
failure injection model and several multicast probes.
The application model is used for injecting multicast
data packets into networks and issuing join or leave
message requests to the IGMP host model.
The simulation is being used to investigate the
failure recovery characteristics of IP multicast for
highly available systems, such as those in the
financial services industry.
Data packets from this application module are sent to the
UDP layer, which in turn encapsulates them with a UDP
header, such as port number, and sends them down to
IP_ENCAP. The App model has to specify the
destination address and remote port number in order to
send packets. On the multicast receiver side, the App
model needs to register the port number on which it is
going to receive the multicast packets.
REFERENCES
[1] Moy, J., OSPF Version 2. Draft Standard RFC 1583,
March, 1994.
[2] Fenner, W. Internet Group Management Protocol,
Version 2, RFC2236, November 1997.
[3] Moy, J., "Multicast Extensions to OSPF", RFC
1584, Proteon, Inc., March 1994.
[4] Stephen Deering, Deborah Estrin, Dino Farinacci,
Van Jacobson, Ahmed Helmy, David Meyer, Liming
Wei. PIM Dense Mode Specification. draft-ietf-pimv2-dm-02.txt
[5] Waitzman, D., Partridge, C., Deering , S., Distance
Vector Multicast Routing Protocol. RFC 1075, Nov01-1988.
[6] Deering, S., Estrin, D., Farinacci, D., Jacobson, V.,
Liu, C., and Wei, L., The PIM Architecture for
WAN Multicast Routing. ACM Transactions on
Networks, April 1996.
When reaching their destination, data packets will be
forwarded to IP_ENCAP from IP_RTE. IP_ENCAP
dispatches packets by protocol identifier. In this case, the
identifier is UDP and packets are forwarded up to UDP
module. After the UDP layer receives the multicast
packet, it dispatches the packet to the appropriate App
model, based on its destination port number.
Besides sending and receiving data packets, the App
model also communicates with the IGMP host model.
The interaction between these two models consists of
join and leave group messages. Join and leave group
messages are specified by the user either in the initial
state or dynamically during the simulation run time. If
join and leave are specified in the initial state, users need
to input a time argument, which corresponds to the
simulation time at which the join or leave will take
5