Network Working Group                                         M. Pullen
Request for Comments: 2490                      George Mason University
Category: Informational                                      R. Malghan
                                                  Hitachi Data Systems
                                                               L. Lavu
                                                          Bay Networks
                                                               G. Duan
                                                                Oracle
                                                                 J. Ma
                                                             NewBridge
                                                                H. Nah
                                               George Mason University
                                                          January 1999


            A Simulation Model for IP Multicast with RSVP

Status of this Memo

  This memo provides information for the Internet community.  It does
  not specify an Internet standard of any kind.  Distribution of this
  memo is unlimited.

Copyright Notice

  Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

  This document describes a detailed model of IPv4 multicast with RSVP
  that has been developed using the OPNET simulation package [4], with
  protocol procedures defined in the C language.  The model was
  developed to allow investigation of performance constraints on
  routing but should have wide applicability in the Internet
  multicast/resource reservation community.  We are making this model
  publicly available with the intention that it can be used to provide
  expanded studies of resource-reserved multicasting.

Table of Contents

  1. Background                                                  2
  2. The OPNET Simulation Environment                            3
  3. IP Multicast Model                                          3
          3.1 Address Format                                     3
          3.2 Network Layer                                      4
          3.3 Node layer                                         5
  4. RSVP Model                                                 13
          4.1 RSVP Application                                  13



Pullen, et. al.              Informational                      [Page 1]

RFC 2490                 IP Multicast with RSVP             January 1999


          4.2 RSVP on Routers                                   14
          4.3 RSVP on Hosts                                     17
  5. Multicast Routing Model Interface                          19
          5.1 Creation of multicast routing processor node      19
          5.2 Interfacing processor nodes                       19
          5.3 Interrupt Generation                              21
          5.4 Modifications of modules in the process model     22
  6. OSPF and MOSPF Models                                      23
          6.1 Init                                              23
          6.2 Idle                                              23
          6.3 BCOspfLsa                                         23
          6.4 BCMospfLsa                                        23
          6.5 Arr                                               23
          6.6 Hello_pks                                         24
          6.7 Mospfspfcalc                                      24
          6.8 Ospfspfcalc                                       25
          6.9 UpstrNode                                         25
          6.10 DABRA                                            25
  7. DVMRP Model                                                26
          7.1 Init                                              26
          7.2 Idle                                              26
          7.3 Probe_Send State                                  26
          7.4 Report_Send                                       26
          7.5 Prune _Send                                       26
          7.6 Graft_send                                        27
          7.7 Arr_Pkt                                           27
          7.8 Route_Calc                                        28
          7.9 Timer                                             28
  8. Simulation performance                                     28
  9. Future Work                                                29
  10. Security Considerations                                   29
  11. References                                                29
  Authors' Addresses                                            30
  Full Copyright Statement                                      31

1. Background

  The successful deployment of IP multicasting [1] and its availability
  in the Mbone has led to continuing increase in real-time multimedia
  Internet applications.  Because the Internet has traditionally
  supported only a best-effort quality of service, there is
  considerable interest to create mechanisms that will allow adequate
  resources to be reserved in networks using the Internet protocol
  suite, such that the quality of real-time traffic such as video,
  voice, and distributed simulation can be sustained at specified
  levels.  The RSVP protocol [2] has been developed for this purpose
  and is the subject of ongoing implementation efforts. Although the
  developers of RSVP have used simulation in their design process, no



Pullen, et. al.              Informational                      [Page 2]

RFC 2490                 IP Multicast with RSVP             January 1999


  simulation of IPmc with RSVP has been generally available for
  analysis of the performance and prediction of the behavior of these
  protocols.  The simulation model described here was developed to fill
  this gap, and is explicitly intended to be made available to the IETF
  community.

2.  The OPNET Simulation Environment

  The Optimized Network Engineering Tools (OPNET) is a commercial
  simulation product of the MIL3 company of Arlington, VA.  It employs
  a Discrete Event Simulation approach that allows large numbers of
  closely-spaced events in a sizable network to be represented
  accurately and efficiently. OPNET uses a modeling approach where
  networks are built of components interconnected by perfect links that
  can be degraded at will.  Each component's behavior is modeled as a
  state-transition diagram.  The process that takes place in each state
  is described by a program in the C language. We believe this makes
  the OPNET-based models relatively easy to port to other modeling
  environments. This family of models is compatible with OPNET 3.5.
  The following sections describe the state-transition models and
  process code for the IPmc and RSVP models we have created using
  OPNET. Please note that an OPNET layer is not necessarily equivalent
  to a layer in a network stack, but shares with a stack layer the
  property that it is a highly modular software element with well
  defined interfaces.

3.  IP Multicast Model

  The following processing takes place in the indicated modules. Each
  subsection below describes in detail a layer in the host and the
  router that can be simulated with the help of the corresponding OPNET
  network layer or node layer or the process layer, starting from
  physical layer.

3.1 Address format

  The OPNET IP model has only one type of addressing denoted by "X.Y"
  where X is 24 bits long and Y is 8 bits long, corresponding to an
  IPv4 Class C network.  The X indicates the destination or the source
  network number and Y indicates the destination or the source node
  number.  In our model X = 500 is reserved for multicast traffic.  For
  multicast traffic the value of Y indicates the group to which the
  packet belongs.








Pullen, et. al.              Informational                      [Page 3]

RFC 2490                 IP Multicast with RSVP             January 1999


3.2 Network Layer

  Figure 1 describes an example network topology built using the OPNET
  network editor.  This network consists of two backbone routers BBR1,
  BBR2, three area border routers ABR1, ABR2,  ABR3 and six subnets F1,
  through F6.  As OPNET has no full duplex link model, each connecting
  link is modeled as two simplex links enabling bidirectional traffic.

                [Figure 1: Network Layer of Debug Model]

3.2.1 Attributes

  The attributes of the elements of the network layer are:

  a. Area Border Routers and Backbone Routers

    1. IP address of each active interface of each router
       (network_id.node_id)
    2. Service rate of the IP layer (packets/sec)
    3. Transmission speeds of each active interface (bits/sec)

  b. Subnets

    1. IP address of each active interface of the router in the subnet
    2. IP address of the hosts in each of the subnet.
    3. Service rate of the IP layer in the subnet router and the hosts.

  c. Simplex links

    1. Propagation delay in the links
    2. The process model to be used for simulating the simplex links
       (this means whether animation is included or not).

3.2.2 LAN Subnets

  Figure 2 shows the FDDI ring as used in a subnet. The subnet will
  have one router and one or more hosts.  The router in the subnet is
  included to route the traffic between the FDDI ring or Ethernet in
  the corresponding subnet and the external network.  The subnet router
  is connected on one end to Ethernet or FDDI ring and normally also is
  connected to an area border router on another interface (the area
  border routers may be connected to more than one backbone router). In
  the Ethernet all the hosts are connected to the bus, while in FDDI
  the hosts are interconnected in a ring as illustrated in Figure 2.

                   [Figure 2: FDDI Ring Subnet Layer]





Pullen, et. al.              Informational                      [Page 4]

RFC 2490                 IP Multicast with RSVP             January 1999


  FDDI provides general purpose networking at 100 Mb/sec transmission
  rates for large numbers of communicating stations configured in a
  ring topology.  Use of ring bandwidth is controlled through a timed
  token rotation protocol, wherein stations must receive a token and
  meet with a set of timing and priority criteria before transmitting
  frames.  In order to accommodate network applications in which
  response times are critical,  FDDI provides for deterministic
  availability of ring bandwidth by defining a synchronous transmission
  service. Asynchronous frame transmission requests dynamically share
  the remaining ring bandwidth.

  Ethernet is a bus-based local area network (LAN) technology.  The
  operation of the LAN is managed by a media access protocol (MAC)
  following the IEEE 802.3 standard, providing Carrier Sense Multiple
  Access with Collision Detection (CSMA/CD) for the LAN channel.

3.3 Node layer

  This section discusses the internal structure of hosts and routers
  with the help of node level illustrations built using the Node editor
  of OPNET.

3.3.1 Basic OPNET elements

  The basic elements of a node level illustration are

  a. Processor nodes: Processor nodes are used for processing incoming
  packets and generating packets with a specified packet format.

  b. Queue node: Queue nodes are a superset of processor nodes. In
  addition to the capabilities of processor nodes,  queue nodes also
  have capability to store packets in one or more queues.

  c. Transmitter and Receiver nodes: Transmitters simulate the link
  behavior effect of packet transmission and Receivers simulate the
  receiving effects of packet reception.  The transmission rate is an
  attribute of the transmitter and receiving rate is an attribute of
  the receiver. These values together decide the transmission delay of
  a packet.

  d. Packet streams: Packet streams are used to interconnect the above
  described nodes.

  e. Statistic streams:  Statistic streams are used to convey
  information between the different nodes: Processor, Queue,
  Transmitters and Receivers nodes respectively.





Pullen, et. al.              Informational                      [Page 5]

RFC 2490                 IP Multicast with RSVP             January 1999


3.3.2 Host description

  The host model built using OPNET has a layered structure. Different
  from the OPNET layers (Network, Node and Process layer) that describe
  the network at different levels, protocol stack elements are
  implemented at OPNET nodes. Figure 3 shows the node level structure
  of a FDDI host.

                     [Figure 3: Node Level of Host]

  a. MAC queue node: The MAC interfaces on one side to the physical
  layer through the transmitter (phy_tx) and receiver (phy_rx) and also
  provides services to the IP layer.  Use of ring bandwidth is
  controlled through a timed token rotation protocol, wherein hosts
  must receive a token and meet with a set of timing and priority
  criteria before transmitting frames.  When a frame arrives at the MAC
  node, the node performs one of the following actions:

    1. If the owner of the frame is this MAC, the MAC layer destroys
       the frame since the frame has finished circulating through the
       FDDI ring.
    2. if the frame is destined for this host, the MAC layer makes a
       copy of the frame, decapsulates the frame and sends the
       descapsulated frame (packet) to the IP layer.  The original
       frame is transmitted to the next host in the FDDI ring
    3. if the owner of the frame is any other host and the frame is not
       destined for this host, the frame is forwarded to the adjacent
       host.

  b. ADDR_TRANS processor node: The next layer above the MAC layer is
  the addr_trans processor node. This layer provides service to the IP
  layer by carrying out the function of translating the IP address to
  physical interface address.  This layer accepts packets from the IP
  layer with the next node information, maps the next node information
  to a physical address and forwards the packet for transmission.  This
  service is required only in one direction from the IP layer to the
  MAC layer.  Since queuing is not done at this level, a processor node
  is used to accomplish the address translation function, from IP to
  MAC address (ARP).

  c. IP queue node: Network routing/forwarding in the hierarchy is
  implemented here. IP layer provides service for the layers above
  which are the different higher level protocols by utilizing the
  services provided by the MAC layer.  For packets arriving from the
  MAC layer, the IP layer decapsulates the packet and forwards the
  information to an upper layer protocol based upon the value of the
  protocol ID in the IP header.  For packets arriving from upper layer
  protocols,  the IP layer obtains the destination address,  calculates



Pullen, et. al.              Informational                      [Page 6]

RFC 2490                 IP Multicast with RSVP             January 1999


  the next node address from the routing table, encapsulates it with a
  IP header and forwards the packet to the addr_trans node with the
  next node information.

  The IP node is a queue node. It is in this layer that packets incur
  delay which simulates the processing capability of a host and
  queueing for use of the outgoing link.  A packet arrival to the IP
  layer will be queued and experience delay when it finds another
  packet already being transmitted, plus possibly other packets queued
  for transmission.  The packets arriving at the IP layer are queued
  and operate with a first-in first-out (FIFO) discipline.  The queue
  size, service rate of the IP layer are both promoted attributes,
  specified at the simulation run level by the environment file.

  d. IGMP processor node: The models described above are standard
  components available in OPNET libraries.  We have added to these the
  host multicast protocol model IGMP_host, the router multicast model
  IGMP_gwy, and the unicast best-effort protocol model UBE.

  The IGMP_host node (Figure 4) is a process node.  Packets are not
  queued in this layer.  IGMP_host provides unique group management
  services for the multicast applications utilizing the services
  provided by the IP layer. IGMP_host maintains a single table which
  consists of group membership information of the application above the
  IGMP layer.  The function performed by the IGMP_host layer depends
  upon the type of the packet received and the source of the packet.

                    [Figure 4: IGMP process on hosts]

  The IGMP_host layer expects certain type of packets from the
  application layer and from the network:

  1. Accept join group requests from the application layer (which can
     be one or more applications):  IGMP_host maintains a table which
     consists of the membership information for each group.  When a
     application sends a  join request,  it requests to join a specific
     group N.  The membership information is updated.  This new group
     membership information has to be conveyed to the nearest router
     and to the MAC layer.  If the IGMP_host is already a member ofthis
     group (i.e. if another application above the IGMP_host is a member
     of the group N), the IGMP_host does not have to send a message to
     the router or indicate to the MAC layer.  If the IGMP_host is not
     a member currently,  the IGMP_host generates a join request for
     the group N (this is called a "response" in RFC 1112) and forwards
     it to the IP layer to be sent to the nearest router.  In addition
     the IGMP_host also conveys this membership information to the MAC
     layer interfacing to the physical layer through the OPNET
     "statistic wire" connected from the IGMP_host to the MAC layer, so



Pullen, et. al.              Informational                      [Page 7]

RFC 2490                 IP Multicast with RSVP             January 1999


     that the MAC layer knows the membership information immediately
     and begins to accept the frames destined for the group N. (An
     OPNET statistic wire is a virtual path to send information between
     OPNET models.)
  2. Accept queries arriving from the nearest router and send responses
     based on the membership information in the multicast table at the
     IGMP_host layer:  A query is a message from a router inquiring
     each host on the router's interface about group membership
     information. When the IGMP_host receives a query, it looks up the
     multicast group membership table, to determine if any of the
     host's applications are registered for any  group.  If any
     registration exists, the IGMP_host schedules an event to generate
     a response after a random amount of time corresponding to each
     active group.  The Ethernet example in Figure 5 and the
     description in the following section describes the scenario.

                  ---------------------------------------
                       |        |         |         |
                       |        |         |         |
                     +---+    +---+     +---+     +---+
                     | H1|    | H2|     | H3|     | R |
                     +---+    +---+     +---+     +---+

          Figure 5: An Ethernet example of IGMP response schedule

     The router R interfaces with the subnet on one interface I1 and to
     reach the hosts.  To illustrate this let us assume that hosts H1
     and H3 are members of group N1 and H2 is a  member of group N2.
     When the router sends a query, all the hosts receive the query at
     the same time t0.  IGMP_host in H1 schedules an event to generate
     a response at a randomly generated time t1 (t1 >= t0) which will
     indicate the host H1 is a member of group N1.  Similarly H2 will
     schedule an event to generate a response at t2 (t2 >= t0)to
     indicate membership in group N2 and H3 at t3 (t3 >= t0) to
     indicate membership in group N3.  When the responses are
     generated, the responses are sent with destination address set to
     the multicast group address.  Thus all member hosts of a group
     will receive the responses sent by the other hosts in the subnet
     who are members of the same group.

     In the above example if t1 < t3,  IGMP_host in H1 will generate a
     response to update the membership in group N1 before H3 does and
     H3 will also receive this response in addition to the router. When
     IGMP_host in H3 receives the response sent by H1,  IGMP_host in H3
     cancels the event scheduled at time t3, since a response for that
     group has been sent to the router.  To make this work, the events





Pullen, et. al.              Informational                      [Page 8]

RFC 2490                 IP Multicast with RSVP             January 1999


     to generate response to queries are scheduled randomly, and the
     interval for scheduling the above described event is forced to be
     less than the interval at which router sends the queries.
  3. Accept responses sent by the other hosts in the subnet if any
     application layer is a member of the group to which the packet is
     destined.
  4. Accept terminate group requests from the Application layer. These
     requests are generated by application layer when a application
     decides to leave a group. The IGMP_host updates the group
     information table and subsequently will not send any response
     corresponding to this group (unless another application is a
     member of this group).  When a router does not receive any
     response for a group in certain amount of time on a specific
     interface, membership of that interface is canceled in that group.

  e. Unicast best-effort (UBE) processor node: This node is used to
  generate a best effort traffic in the Internet based on the User
  Datagram Protocol (UDP).  The objective of this node is to model the
  background traffic in a network. This traffic does not use the
  services provided by RSVP. UBE node aims to create the behaviors
  observed in a network which has one type of application using the
  services provided by RSVP to achieve specific levels of QoS and the
  best effort traffic which uses the services provided by only the
  underlying IP.

  The UBE node generates traffic to a randomly generated IP address so
  as to model competing traffic in the network from applications such
  as FTP. The packets generated are sent to the IP layer which routes
  the packet based upon the information in the routing table. The
  attributes of the UBE node are:

  1. Session InterArrival Time (IAT): is the variable used to schedule
     an event to begin a session. The UBE node generates an
     exponentially distributed random variable with mean Session IAT
     and begins to generate data traffic at that time.
  2. Data IAT: When the UBE generates data traffic, the interarrival
     times between data packets is Data IAT. A decrease in the value of
     Data IAT increases the severity of congestion in the network.
  3. Session-min and Session-max: When the UBE node starts generating
     data traffic it remains in that session for a random period which
     is uniformly distributed between Session-min and Session-max.

  f. Multicast Application processor node: The application layer
  consists of one or more application nodes which are process nodes.
  These nodes use the services provided by lower layer protocols IGMP,
  RSVP and IP.  The Application layer models the requests and traffic
  generated by Application layer programs. Attributes of the
  application layer are:



Pullen, et. al.              Informational                      [Page 9]

RFC 2490                 IP Multicast with RSVP             January 1999


  1. Session IAT: is the variable used to schedule an event to begin a
     session.  The Application node generates an exponentially
     distributed random variable with mean Session IAT and begins to
     generate information for a specific group at that time and also
     accept packets belonging to that group.
  2. Data IAT: When Application node generates data traffic, the inter
     arrival time between the packets uses Data IAT variable as the
     argument.  The distribution can be any of the available
     distribution functions in OPNET.
  3. Session-min and Session-max: When an application joins a session
     the duration for which the application stays in that session is
     bounded by Session-min and Session-max.  A uniformly distributed
     random variable between Session-min and Session-max is generated
     for this purpose. At any given time each node will have zero or
     one flow(s) of data.
  4. NGRPS: This variable is used by the application generating
     multicast traffic to bound the value of the group to which an
     application requests  the IGMP to join.  The group is selected at
     random from the range [0,NGRPS-1].

                     [Figure 6: Node Level of Gateway]

3.3.3 Router description

     There are two types of routers in the model, a router serving a
     subnet and a backbone router.  A subnet router has all the
     functions of a backbone router and in addition also has a
     interface to the underlying subnet which can be either a FDDI
     network or a Ethernet subnet. In the following section the subnet
     router will be discussed in detail.

     Figure 6 shows the node level model of a subnet router.

     a. The queueing technique implemented in the router is a
     combination of input and output queueing.  The nodes rx1 to rx10
     are the receivers connected to incoming links.  The router in
     Figure 6 has a physical interface to the FDDI ring or Ethernet,
     which consists of the queue node MAC, transmitter phy_tx, and the
     receiver phy_rx.  The backbone routers will not have a MAC layer.
     The services provided and the functions of the MAC layer are the
     same as the MAC layer in the host discussed above.

     There is one major difference between the MAC node in a subnet
     router and that in a host.  The MAC node in a subnet router
     accepts all arriving multicast packets unlike the MAC in a host
     which accepts only the multicast packets for groups of which the





Pullen, et. al.              Informational                     [Page 10]

RFC 2490                 IP Multicast with RSVP             January 1999


     host is a member. For this reason the statistic wire from the IGMP
     to MAC layer does not exist in a router (also because a subnet
     router does not have an application layer).

     b. Addr_trans: The link layer in the router hierarchy is the
     addr_trans processor node which provides the service of
     translating the IP address to a physical address. The addr_trans
     node was described above under the host model.

     c. IP layer: The router IP layer which provides services to the
     upper layer transport protocols and also performs routing based
     upon the information in the routing table. The IP layer maintains
     two routing tables and one group membership table.

     The tables used by the router model are:

     1. Unicast routing table: This table is an single array of one
     dimension, which is used to route packets generated by the UDP
     process node in the hosts.  If no route is known to a particular
     IP address, the corresponding entry is set to a default route.
  2. Multicast routing table: This table is a N by I array where N is
     the maximum number of multicast groups in the model and I is the
     number of interfaces in the router.  This table is used to route
     multicast packets. The routing table in a router is set by an
     upper layer routing protocol (see section 4 below). When the IP
     layer receives a multicast packet with a session_id corresponding
     to a session which is utilizing the MOSFP, it looks up the
     multicast routing table to obtain the next hop.
  3. Group membership table: This table is used to maintain group
     membership information of all the interfaces of the router.  This
     table  which is also an N by I array is set by the IGMP layer
     protocol.  The routing protocols use this information in the group
     membership table to calculate and set the routes in the Multicast
     routing table.

  Sub-queues: The IP node has three subqueues, which implement queuing
  based upon the priority of arriving packets from the neighboring
  routers or the underlying subnet. The queue with index 0 has the
  highest priority.  When a packet arrives at the IP node, the packets
  are inserted into the appropriate sub-queue based on the priority of
  their traffic category: control traffic, resource- reserved traffic,
  or best effort traffic.  A non-preemptive priority is used in
  servicing the packets.  After the servicing, packets are sent to the
  one of the output queues or the MAC. The packets progress through
  these queues until the transmitter becomes available.






Pullen, et. al.              Informational                     [Page 11]

RFC 2490                 IP Multicast with RSVP             January 1999


  Attributes of the IP node are:

  1. Unique IP address for each interface (a set of transmitter and
     receiver constitute an interface).
  2. Service rate: the rate with which packets are serviced at the
     router.
  3. Queue size: size of each of the sub queues used to store incoming
     packets based on the priority can be specified individually

  d. Output queues: The output queues perform the function of queueing
  the packets received by the IP layer when the transmitter is busy. A
  significant amount of queuing takes place in the output queues only
  if the throughput of the IP node approaches the transmission capacity
  of the links.  The only attribute of the queue node is:

  Queue size: size of the queue in each queue node.  If the queue is
  full when a packet is received, that packet is dropped.

  e. IGMP Node: Also modeled in the router is the IGMP for implementing
  multicasting, the routing protocol, and RSVP for providing specific
  QoS setup.

  The IGMP node implements the IGMP protocol as defined in RFC 1112.
  The IGMP node at a router (Figure 7) is different from the one at a
  host. The functions of the IGMP node at a router are:

  1. IGMP node at a router sends queries at regular intervals on all
     its interfaces.
  2. When IGMP receives a response to the queries sent, IGMP updates
     the multicast Group membership table in the IP node and triggers
     on MOSPF LSA update.
  3. Every time the IGMP sends a query, it also updates the multicast
     group membership table in the IP node if no response has been
     received on for the group on any interface,  indicating that a
     interface is no longer a member of that group.  This update is
     done only on entries which indicate an active membership for a
     group on a interface where the router has not received a response
     for the last query sent.
  4. The routing protocol (see ection 4 below) uses the information in
     the group membership table to calculate the routes and update the
     multicast routing table.
  5. When the IGMP receives a query (an IGMP at router can receive a
     query from a directly connected neighboring router), the IGMP node
     creates a response for each of the groups it is a member of on all
     the interfaces except the one through which the query was
     received.
  6. The IGMP node on a backbone router is disabled, because IGMP is
     only used when a router has hosts on its subnet.



Pullen, et. al.              Informational                     [Page 12]

RFC 2490                 IP Multicast with RSVP             January 1999


                    [Figure 7: IGMP process on routers]

4.  RSVP model

  The current version of the RSVP model supports only fixed-filter
  reservation style. The following processing takes place in the
  indicated modules. The model is current with [2].

4.1 RSVP APPLICATION

4.1.1  Init

  Initializes all variables and loads the distribution functions for
  Multicast Group IDs, Data, termination of the session. Transit to
  Idle state after completing all the initializations.

4.1.2  Idle

  This state has transitions to two states, Join and Data_Send. It
  transit to Join state at the time that the application is scheduled
  to join a session or terminate the current session, transit to
  Data_Send state when the application is going to send data.

4.1.3  Join

  The Application will send a session call to local RSVP daemon. In
  response it receives the session Id from the Local daemon. This makes
  a sender or receiver call. The multicast group id is selected
  randomly from a uniform distribution.  While doing a sender call the
  application will write all its sender information in a global session
  directory.

  If the application is acting as a receiver it will check for the
  sender information in the session directory for the multicast group
  that it wants to join to and make a receive call to the local RSVP
  daemon.  Along with the session and receive calls, it makes an IGMP
  join call.

  If the application chooses to terminate the session to which it was
  registered, it will send a release call to the local RSVP daemon and
  a terminate call to IGMP daemon.  After completing these functions it
  will return to the idle state.

                   [Figure 8: RSVP process on routers]







Pullen, et. al.              Informational                     [Page 13]

RFC 2490                 IP Multicast with RSVP             January 1999


4.1.4 Data_Send

  Creates a data packet and sends it to a multicast destination that it
  selects. It update a counter to keep track of how many packets that
  it has sent. This state on default returns to Idle state.

4.2 RSVP on Routers

  Figure 8 shows the process model of RSVP on routers.

4.2.1 Init

  This state calls a function called RouterInitialize which will
  initialize all the router variables. This state will go to Idle state
  after completing these functions.

4.2.2 Idle

  Idle state transit to Arr state upon receiving a packet.

4.2.3 Arr

  This state checks for the type of the packet arrived and calls the
  appropriate function depending on the type of message received.

  a. PathMsgPro: This function was invoked by the Arr state when a path
  message is received. Before it was called, OSPF routing had been
  recomputed to get the latest routing table for forwarding the Path
  Message.

  1. It first checks for a Path state block which has a matching
     destination address and if the sender port or sender address or
     destination port does not match the values of the Session object
     of the Path state block, it sends an path error message and
     returns. (At present the application does not send any error
     messages, we print this error message on the console.)
  2. If a PSB is found whose Session Object and Sender Template Object
     matches with that of the path message received, the current PSB
     becomes the forwarding PSB.
  3. Search for the PSB whose session and sender template matches the
     corresponding objects in the path message and whose incoming
     interface matches the IncInterface. If such a PSB is found and the
     if the Previous Hop Address, Next Hop Address, and SenderTspec
     Object doesn't match that of path message then the values of path
     message is copied into the path state block and Path Refresh
     Needed flag is turned on. If the Previous Hop Address, Next Hop





Pullen, et. al.              Informational                     [Page 14]

RFC 2490                 IP Multicast with RSVP             January 1999


     Address of PSB differs from the path message then the Resv Refresh
     Needed flag is also turned on, and the Current PSB is made equal
     to this PSB.
  4. If a matching PSB is not found then a new PSB is created and and
     Path Refresh Needed Flag is turned on, and the Current PSB is made
     equal to this PSB.
  5. If Path Refresh Needed Flag is on, Current PSB is copied into
     forwarding PSB and Path Refresh Sequence is executed. To execute
     this function called PathRefresh is used.  Path Refresh is sent to
     every interface that is in the outgoing interfaces list of
     forwarding path state block.
  6. Search for a Reservation State Block whose filter spec object
     matches with the Sender Template Object of the forwarding PSB and
     whose Outgoing Interface matches one of the entry in the
     forwarding PSB's outgoing interface list. If found then a Resv
     Refresh message to the Previous Hop Address in the forwarding PSB
     and execute the Update Traffic Control sequence.

  b. PathRefresh: This function is called from PathMsgPro. It creates
  the Path message sends the message through the outgoing interface
  that is specified by the PathMsgPro.

  c. ResvMsgPro: This function was invoked by the Arr state when a Resv
  message is received.

  1. Determine the outgoing interface and check for the PSB whose
     Source Address and Session Objects match the ones in the Resv
     message.
  2. If such a PSB is not found then send a ResvErr message saying that
     No Path Information is available. (We have not implemented this
     message, we only print an error message on the console.)
  3. Check for incompatible styles and process the flow descriptor list
     to make reservations, checking the PSB list for the sender
     information. If no sender information is available through the PSB
     list then send an Error message saying that No Sender information.
     For all the matching PSBs found, if the Refresh PHOP list doesn't
     have the Previous Hop Address of the PSB then add the Previous Hop
     Address to the Refresh PHOP list.
  4. Check for matching Reservation State Block (RSB) whose Session and
     Filter Spec Object matches that of Resv message. If no such RSB is
     found then create a new RSB from the Resv Message and set the
     NeworMod flag On. Call this RSB as activeRSB. Turn on the Resv
     Refresh Needed Flag.
  5. If a matching RSB is found, call this as activeRSB and if the
     FlowSpec and Scope objects of this RSB differ from that of Resv
     Message copy the Resv message Flowspec and Scope objects to the
     ActiveRSB and set the NeworMod flag On.




Pullen, et. al.              Informational                     [Page 15]

RFC 2490                 IP Multicast with RSVP             January 1999


  6. Call the Update Traffic Control Sequence. This is done by calling
     the function UpdateTrafficControl
  7. If Resv Refresh Needed Flag is On then send a ResvRefresh message
     for each Previous Hop in the Refresh PHOP List. This is done by
     calling the ResvRefresh function for every Previous Hop in the
     Refresh PHOP List.

  d. ResvRefresh: this function is called by both PathMsgPro and
  ResvMsgPro with RSB and Previous Hop as input. The function
  constructs the Resv Message from the RSB and sends the message to the
  Previous Hop.

  e. PathTearPro: This function is invoked by the Arr state when a
  PathTear message is received.

  1. Search for PSB whose Session Object and Sender Template Object
     matches that of the arrived PathTear message.
  2. If such a PSB is not found do nothing and return.
  3. If a matching PSB is  found, a PathTear message is sent to all the
     outgoing interfaces that are listed in the Outgoing Interface list
     of the PSB.
  4. Search for all the RSB whose Filter Spec Object matches the Sender
     Template Object of the PSB and if the Outgoing Interface of this
     RSB is listed in the PSB's Outgoing interface list delete the RSB.
  5. Delete the PSB and return.

  f. ResvTearPro: This function is invoked by the Arr state when a
  ResvTear message is received.
  1. Determine the Outgoing Interface.
  2. Process the flow descriptor list of the arrived ResvTear message.
  3. Check for the RSB whose Session Object, Filter Spec Object matches
     that of ResvTear message and if there is no such RSB return.
  4. If such an RSB is found and Resv Refresh Needed Flag is on send
     ResvTear message to all the Previous Hops that are in Refresh PHOP
     List.
  5. Finally delete the RSB.

  g. ResvConfPro: This function is invoked by the Arr state when a
  ResvConf message is received. The Resv Confirm is forwarded to the IP
  address that was in the Resv Confirm Object of the received ResvConf
  message.

  h. UpdateTrafficControl: This function is called by PathMsgPro and
  ResvMsgPro and input to this function is RSB.

  1. The RSB list is searched for a matching RSB that matches the
     Session Object, and Filter Spec Object with the input RSB.
  2. Effective Kernel TC_Flowspec are computed for all these RSB's.



Pullen, et. al.              Informational                     [Page 16]

RFC 2490                 IP Multicast with RSVP             January 1999


  3. If the Filter Spec Object of the RSB doesn't match the one of the
     Filter Spec Object in the TC Filter Spec List then add the Filter
     Spec Object to the TC Filter Spec List.
  4. If the FlowSpec Object of the input RSB is greater than the
     TC_Flowspec then turn on the Is_Biggest flag.
  5. Search for the matching Traffic Control State Block(TCSB) whose
     Session Object, Outgoing Interface, and Filter Spec Object matches
     with those of the Input RSB.
  6. If such a TCSB is not found create a new TCSB.
  7. If matching TCSB is found modify the reservations.
  8. If Is_Biggest flag is on turn on the Resv Refresh Needed Flag
     flag, else send a ResvConf Message to the IP address in the
     ResvConfirm Object of the input RSB.

4.2.4 pathmsg: The functions to be done by this state are done through
  the function call PathMsgPro described above.

4.2.5 resvmsg: The functions that would be done by this state are done
  through the function call ResvMsgPro described above.

4.2.6 ptearmsg: The functions that would be done by this state are done
  through the function call PathTearPro described above.

4.2.7 rtearmsg: The functions that would be done by this state are done
 through the function call ResvTearPro described above.

4.2.8 rconfmsg: The functions that would be done by this state are done
 through the function call ResvConfPro described above.

4.3 RSVP on Hosts

  Figure 9 shows the process of RSVP on hosts.

4.3.1  Init

  Initializes all the variables. Default transition to idle state.

                    [Figure 9: RSVP process on hosts]

4.3.2  idle

  This state transit to the Arr state on packet arrival.

4.3.3  Arr

  This state calls the appropriate functions depending on the type of
  message received. Default transition to idle state.




Pullen, et. al.              Informational                     [Page 17]

RFC 2490                 IP Multicast with RSVP             January 1999


  a. MakeSessionCall: This function is called from the Arr state
  whenever a Session call is received from the local application.

  1. Search for the Session Information.
  2. If one is found return the corresponding Session Id.
  3. If the session information is not found assign a new session Id to
     the session to the corresponding session.
  4. Make an UpCall to the local application with this Session Id.

  b. MakeSenderCall: This function is called from the Arr state
  whenever a Sender call is received from the local application.

  1. Get the information corresponding to the Session Id and create a
     Path message corresponding to this session.
  2. A copy of the packet is buffered and used by the host to send the
     PATH message periodically.
  3. This packet is sent to the IP layer.

  c. MakeReserveCall: This function is called from the Arr state
  whenever a Reserve call is received from the local application. This
  function will create and send a Resv message. Also, the packet is
  buffered for later use.

  d. MakeReleaseCall: This function is called from the Arr state
  whenever a Release call is received from the local application. This
  function will generate a PathTear message if the local application is
  sender or generates a ResvTear message if the local application is
  receiver.

4.3.4  Session                  This state's function is performed by
  the MakeSessionCall function.

4.3.5  Sender

  This state's function is han by the MakeSenderCall function.

4.3.6  Reserve
                                                  This state's function
  is performed by the MakeReserveCall function.

4.3.7  Release

  This state's function is performed by the MakeReleaseCall function.








Pullen, et. al.              Informational                     [Page 18]

RFC 2490                 IP Multicast with RSVP             January 1999


5. Multicast Routing Model Interface

  Because this set of models was intended particularly to enable
  evaluation by simulation of various multicast routing protocols, we
  give particular attention in this section to the steps necessary to
  interface a routing protocol model to the other models.  We have
  available implementations of DVMRP and OSPF, which we will describe
  below.  Instructions for invoking these models are contained in a
  separate User's Guide for the models.

5.1  Creation of multicast routing processor node

  Interfacing a multicast routing protocol using the OPNET Simulation
  package requires the creation of a new routing processor node in the
  node editor and linking it via packet streams.  Packet streams are
  unidirectional links used to interconnect processor nodes, queue
  nodes, transmitters and receiver nodes.  A duplex connection between
  two nodes is represented by using two unidirectional links to connect
  the two nodes to and from each other.

  A multicast routing processor node is created in the node editor and
  links are created to and from the processors(duplex connection) that
  interact with this module, the IGMP processor node and the IP
  processor node.  Within the node editor, a new processor node can be
  created by selecting the button for processor creation (plain gray
  node on the node editor control panel) and by clicking on the desired
  location in the node editor to place the node.  Upon creation of the
  processor node, the name of the processor can be specified by right
  clicking on the mouse button and entering the name value on the
  attribute box presented.  Links to and from this node are generated
  by selecting the packet stream button (represented by two gray nodes
  connected with a solid green arrow on the node editor control panel),
  left clicking on the mouse button to specify the source of the link
  and right clicking on the mouse button to mark the destination of the
  link.

5.2  Interfacing processor nodes

  The multicast routing processor node is linked to the IP processor
  node and the IGMP processor node each with a duplex connection. A
  duplex connection between two nodes is represented by two uni-
  directional links interconnecting them providing a bidirectional flow
  of information or interrupts, as shown in Figure 6.  The IP processor
  node (in the subnet router) interfaces with the multicast routing
  processor node, the unicast routing processor node, the Resource
  Reservation processor node(RSVP), the ARP processor node( only on





Pullen, et. al.              Informational                     [Page 19]

RFC 2490                 IP Multicast with RSVP             January 1999


  subnet routers and hosts), the IGMP processor node, and finally the
  MAC processor node (only on subnet routers and hosts) each with a
  duplex connection with exceptions for ARP and MAC nodes.

5.2.1  Interfacing ARP and MAC processor nodes

  The service of the ARP node is required only in the direction from
  the IP layer to the MAC layer(requiring only a unidirectional link
  from IP processor node to ARP processor node).  The MAC processor
  node on the subnet router receives multicast packets destined for all
  multicast groups in the subnet, in contrast to the MAC node on subnet
  hosts which only receives multicast packets destined specifically for
  its multicast group.  The MAC node connects to the IP processor node
  with a single uni-directional link from it to the IP node.

5.2.2  Interfacing IGMP, IP, and multicast routing processor nodes

  The IGMP processor node interacts with the multicast routing
  processor node, unicast routing processor node, and the IP processor
  node. Because the IGMP node is linked to the IP node, it is thus able
  to update the group membership table(in this model, the group
  membership table is represented by the local interface(interface 0)
  of the multicast routing table data structure) within the IP node.
  This update triggers a signal to the multicast routing processor node
  from the IGMP node causing it to reassess the multicast routing table
  within the IP node.  If the change in the group membership table
  warrants a modification of the multicast routing table, the multicast
  routing processor node interacts with the IP node to modify the
  current multicast routing table according to the new group membership
  information updated by IGMP.

5.2.2.1  Modification of group membership table

  The change in the group membership occurs with the decision at a host
  to leave or join a particular multicast group.  The IGMP process on
  the gateway periodically sends out queries to the IGMP processes on
  hosts within the subnet in an attempt to determine which hosts
  currently are receiving packets from particular groups.  Not
  receiving a response for a pending IGMP host query specific to a
  group indicates to the gateway IGMP that no host belonging to the
  particular group exists in the subnet.  This occurs when the last
  remaining member of a multicast group in the subnet leaves.  In this
  case the IGMP processor node updates the group membership able and
  triggers a modification of the multicast routing table by alerting
  the multicast routing processor node.  A prune message specific to
  the group is initiated and propagated upward establishing a  prune
  state for the interface leading to the present subnet, effectively
  removing this subnet from the group-specific multicast spanning tree



Pullen, et. al.              Informational                     [Page 20]

RFC 2490                 IP Multicast with RSVP             January 1999


  and potentially leading to additional pruning of spanning tree edges
  as the prune message travels higher up the tree.  Joining a multicast
  group is also managed by the IGMP process which updates the group
  membership table leading to a possible modification of the multicast
  routing table.

5.2.2.2  Dependency on unicast routing protocol

  The multicast routing protocol is dependent on a unicast routing
  protocol (RIP or OSPF) to handle  multicast routing.  The next hop
  interface to the source of the packet received, or the upstream
  interface, is determined using the unicast routing protocol to trace
  the reverse path back to the source of the packet.  If the packet
  received arrived on this upstream interface, then the packet can be
  propagated downstream through its downstream interfaces (excluding
  the interface in which the packet was received). Otherwise, the
  packet is deemed to be a duplicate and dropped, halting the
  propagation of the packet downstream.  This repeated reverse path
  checking and broadcasting eventually generates the spanning tree for
  multicast routing of packets.  To determine the reverse path forward
  interface of a received multicast packet propagated up from the IP
  layer, the multicast routing processor node retrieves a copy of the
  unicast routing table from the IP processor node and uses it to
  recalculate the multicast routing table in the IP processor node.

5.3  Interrupt Generation

  Using the OPNET tools, interrupts to the multicast routing processor
  node are generated in several ways.  One is the arrival of a
  multicast packet along a packet stream (at the multicast routing
  processor node) when the packet is received by the MAC node and
  propagated up the IP node where upon discarding the IP header
  determination is made as to which upper layer protocol to send the
  packet.  A second type of interrupt generation occurs by remote
  interrupts from the IGMP process alerting the multicast routing
  process of an update in the group membership table.  A third occurs
  when the specific source/group (S,G) entry for a multicast packet
  received at the IP node does not exist in the current multicast
  routing table and a new entry needs to be created.  The IP node
  generates an interrupt to the multicast routing processor node
  informing it to create a new source/group entry on the multicast
  routing table.

5.3.1  Types of interrupts

  The process interrupts generated within the OPNET model can be
  handled by specifying the types of interrupts and the conditions for
  the interrupts using the interrupt code, integer number representing



Pullen, et. al.              Informational                     [Page 21]

RFC 2490                 IP Multicast with RSVP             January 1999


  the condition for a specific interrupt.  The conditions for
  interrupts are specified on the interrupt stream linking the
  interrupt generating state and the state resulting from the
  interrupt.  For self-interrupts (interrupts occurring among states
  within the same process), interrupts of type OPC_INTRPT_SELF are
  used.  For remote interrupts (interprocess interrupts), the
  conditions for specific interrupts are specified from the idle state
  to the state resulting from the interrupt within the remote process.

  The remote interrupts are of type, OPC_INTRPT_REMOTE.  A third type
  of interrupt is the OPC_INTRPT_STRM, which is triggered when packets
  arrive via a packet stream, indicating its arrival.  The condition of
  this interrupt is also specified from the idle state to the resultant
  state by the interrupt condition stream defined by a unique interrupt
  code.  For all of these interrupts, the interrupt code is provided
  within the header block (written in C language) of the interrupted
  process.  When the condition for the interrupt becomes true, a
  transition is made to the resultant state specified by the interrupt
  stream.

5.3.2  Conditions for interrupts

  Several interrupt connections exist to interface the IGMP processor
  node, IP processor node , and the multicast routing processor node
  with each other in the present OPNET Simulation Model.  Also, the IP
  processor node interfaces with the unicast routing protocol which
  interfaces with the IGMP processor node.  An OPC_INTRPT_STRM
  interrupt is generated when a multicast packet arrives via a packet
  stream from the IP processor node to the multicast routing processor
  node.  A remote interrupt of type, OPC_INTRPT_REMOTE, is generated
  from the IGMP process to the IP process when a member of a group
  relinquishes membership from a particular group or a new member is
  added to a group.  This new membership is updated in the group
  membership table located in the IP node by the IGMP process which
  also generates a remote interrupt to the multicast routing protocol
  process, causing a recalculation of the multicast routing table in
  the IP module.

5.4  Modifications of modules in the process model

  Modifications of routing protocol modules (in fact all of the modules
  in the process model) are made transparently throughout the network
  using the OPNET Simulation tools.  An addition or modification of a
  routing module in any subnet will reflect on all the subnets.







Pullen, et. al.              Informational                     [Page 22]

RFC 2490                 IP Multicast with RSVP             January 1999


6.  OSPF and MOSPF Models

  OSPF and MOSPF models [5] are implemented in the OSPF model
  containing fourteen states. They only exist on routers. Figure 10
  shows the process model. The following processing takes place in the
  indicated modules.

6.1 init

  This state initializes all the router variables. Default transition
  to idle state.

6.2 idle

  This state has several transitions. If a packet arrives it transits
  to arr state. Depending on interrupts received it will transit to
  BCOspfLsa, BCMospfLsa, hello_pks state. In future versions, links
  coming up or down will also cause a transition.

6.3 BCOspfLsa

  Transition to this state from idle state is executed whenever the
  condition send_ospf_lsa is true, which happens when the network is
  being initialized, and when ospf_lsa_refresh_timout occurs. This
  state will create Router, Network, Summary Link State Advertisements
  and pack all of them into an Link State Update packet. The Link State
  Update Packet is sent to the IP layer with a destination address of
  AllSPFRouters.

          [Figure 10: OSPF and MOSPF process model on routers]

6.4 BCMospfLsa

  Transition to this state from idle state is executed whenever the
  condition send_mospf_lsa is true. This state will create Group
  Membership Link State Advertisement and pack them into Mospf Link
  State Update Packet. This Mospf Link State Update Packet is sent to
  IP layer with a destination address of AllSPFRouters.

6.5 arr

  The arr state checks the type of packet that is received upon a
  packet arrival. It calls the following functions depending on the
  protocol Id of the packet received.

  a. OspfPkPro: Depending on the type of OSPF/MOSPF packet received the
  function calls the following functions.




Pullen, et. al.              Informational                     [Page 23]

RFC 2490                 IP Multicast with RSVP             January 1999


  1. HelloPk_pro: This function is called whenever a hello packet is
     received. This function updates the router's neighbor information,
     which is later used while sending the different LSAs.
  2. OspfLsUpdatePk_pro: This function is called when an OSPF LSA
     update packet is received (router LSA, network LSA, or summary
     LSA). If the Router is an Area Border Router or if the LSA belongs
     to the Area whose Area Id is the Routers Area Id, then it is
     searched to determine whether this LSA already exists in the Link
     State database. If it exists and if the existing LSA's LS Sequence
     Number is less than the received LSA's LS Sequence Number the
     existing LSA was replaced with the received one. The function
     processes the Network LSA only if it is a designated router or
     Area Border Router.  It processes the Summary LSA only if the
     router is a Area Border Router.  The function also turns on the
     trigger ospfspfcalc which is the condition for the transition from
     arr state to ospfspfcalc.
  3. MospfLsUpdatePk_pro: This function is called when a MOSPF LSA
     update packet is received. It updates the group membership link
     state database of the router.

6.6 hello_pks

  Hello packets are created and sent with destination address of
  AllSPFRouters. Default transition to idle state.

6.7 mospfspfcalc

  The following functions are used to calculate the shortest path tree
  and routing table. This state transit to upstr_node upon detupstrnode
  condition.

  a. CandListInit: Depending upon the SourceNet of the datagram, the
  candidate lists are initialized.

  b. MospfCandAddPro: The vertex link is examined and if the other end
  of the link is not a stub network and is not already in the candidate
  list it is added to the candidate list after calculating the cost to
  that vertex. If this other end of the link is already on the shortest
  path tree and the calculated cost is less than the one that shows in
  the shortest path tree entry update the shortest path tree to show
  the calculated cost.

  c. MospfSPFTreeCalc: The vertex that is closest to the root that is
  in the candidate list is added to the shortest path tree and its link
  is considered for possible inclusions in the candidate list.

  d. MCRoutetableCalc: Multicast routing table is calculated using the
  information of the MOSPF shortest Path tree.



Pullen, et. al.              Informational                     [Page 24]

RFC 2490                 IP Multicast with RSVP             January 1999


6.8 ospfspfcalc

  The following functions are used in this state to calculate the
  shortest path tree and using this information the routing table.
  Transition to ospfspfcalc state on ospfcalc condition. This is set to
  one after processing all functions in the state.

  a. OspfCandidateAddPro: This function initializes the candidate list
  by examining the link state advertisement of the Router. For each
  link in this advertisement, if the other end of the link is a router
  or transit network and if it is not already in the shortest-path tree
  then calculate the distance between these vertices. If the other end
  of this link is not already on the candidate list or if the distance
  calculated is less than the value that appears for this other end add
  the other end of the link to candidate list.

  b. OspfSPTreeBuild: This function pulls each vertex from the
  candidate list that is closest to the root and adds it to the
  shortest path tree.  In doing so it deletes the vertex from the
  candidate list. This function continues to do this until the
  candidate list is empty.

  c. OspfStubLinkPro: In this procedure the stub networks are added to
  shortest path tree.

  d. OspfSummaryLinkPro: If the router is an Area Border Router the
  summary links that it has received is examined. The route to the Area
  border router advertising this summary LSA is examined in the routing
  table. If one is found a routing table update is done by adding the
  route to the network specified in the summary LSA and the cost to
  this route is sum of the cost to area border router advertising this
  and the cost to reach this network from that area border router.

  e. RoutingTableCalc: This function updates the routing table by
  examining the shortest path tree data structure.

6.9 upstr_node

  This state does not do anything in the present model. It transitions
  to DABRA state.

6.10 DABRA

  If the router is an Area Border Router and the area is the source
  area then a DABRA message is constructed and send to all the
  downstream areas. Default transition to idle state.





Pullen, et. al.              Informational                     [Page 25]

RFC 2490                 IP Multicast with RSVP             January 1999


7. DVMRP Model

  The DVMRP model is implemented based on reference [6], DVMRP version
  3. There are nine states. The DVMRP process only exists on Routers.
  Figure 11 shows the states of the DVMRP process.

7.1 Init

  Initialize all variables, routing table and forwarding table and load
  the simulation parameters. It will transit to the Idle state after
  completing all the initializations.

7.2 Idle

  The simulation waits for the next scheduled event or remotely invoked
  event in the Idle State and transit to the state accordingly. In the
  DVMRP model, Idle State has transitions to Probe_Send, Report_Send,
  Prune_Send, Graft_Send, Arr_Pkt, Route_Calc and Timer states.

                  [Figure 11. DVMRP process on routers]

7.3 Probe_Send State

  A DVMRP router sends Probe messages periodically to inform other
  DVMRP routers that it is operational. A DVMRP router lists all its
  known neighbors' addresses in the Probe message and sends it to All-
  DVMRP-Routers address. The routers will not process any message that
  comes from an unknown neighbor.

7.4 Report_Send

  To avoid sending Report at the same time for all DVMRP routers, the
  interval between two Report messages is uniformly distributed with
  average 60 seconds. The router lists source router's address,
  upstream router's address and metric of all sources into the Report
  message and sends it to All-DVMRP-Routers address.

7.5 Prune_Send

  The transition to this state is triggered by the local IGMP process.
  When a host on the subnetwork drops from a group, the IGMP process
  asks DVMRP to see if the branch should be pruned.

  The router obtains the group number from IGMP and checks the IP
  Multicast membership table to find out if there is any group member
  that is still in the group. If the router determines that the last
  host has resigned, it goes through the entire forwarding table to
  locate all sources for that group. The router sends Prune message,



Pullen, et. al.              Informational                     [Page 26]

RFC 2490                 IP Multicast with RSVP             January 1999


  containing source address, group address and prune lifetime,
  separately for each (source, group) pair and records the row as
  pruned in the forwarding table.

7.6 Graft_Send

  The transition to this state is triggered by the local IGMP process.
  Once a multicast delivery has been pruned, Graft messages are
  necessary when a host in the local subnetwork joins into the group. A
  Graft message sent to the upstream router should be acknowledged hop
  by hop to the root of the tree guaranteeing end-to-end delivery.

  The router obtains the group number from IGMP and go through the
  forwarding table to locate all traffic sources for that group. A
  Graft message will be sent to the upstream router with the source
  address and group address for each (source, group) pair. The router
  also setups a timer for each Graft message waiting for an
  acknowledgement.

7.7 Arr_Pkt

  All DVMRP control messages will be sent up to DVMRP layer by IP. The
  function performed by the DVMRP layer depends upon the type of the
  message received.

  a. Probe message: The router checks the neighbors' list in Probe
  message, update its their status to indicate the availability of its
  neighbors.

  b. Report message: Based on exchanging report messages, the routers
  can build the Multicast delivery tree rooted at each source. A
  function called ReportPkPro will be called to handle all possible
  situations when receiving a report message. If the message is a
  poison reverse report and not coming from one of the dependent
  downstreams, the incoming interface should be added to the router's
  downstream list. If the message is not a poison reverse report but it
  came from one of the downstreams, this interface should be deleted
  from the downstreams list. And then, the router compared the metric
  got from the message with the metric of the current upstream, if the
  new metric is less than the older one, the router's upstream
  interface should be updated.

  c. Prune message: The router extracts the source address, group
  address and prune lifetime, marks the incoming interface as pruned in
  the dependent downstream list of the (source, group) pair. If all
  downstream interfaces have been pruned, the router will send a prune
  message to its upstream.




Pullen, et. al.              Informational                     [Page 27]

RFC 2490                 IP Multicast with RSVP             January 1999


  d. Graft message: The router extracts the source and group address,
  active the incoming interface in the dependent downstream list of the
  (source, group) pair. If the (source, group) pair has been pruned,
  the router will reconnect the branch by sending a graft message to
  its upstream interface.

  e. Graft Acknowledge message: The router extracts the source and
  group address, clear the graft message timer of the (source, group)
  pair in the forwarding table.

7.8 Route_Calc

  The transition to this state is triggered by the local IP process.
  Once the IP receives a packet, it will fire a remote interrupt to the
  DVMRP and ask the DVMRP to prepare the outgoing interfaces for the
  packet. The DVMRP process obtains the packet's source address and
  group address from the IP and checks the (source, group) pairs in the
  forwarding table to decide the branches that have the group members
  on the Multicast delivery tree. The Group Membership Table on IP will
  be updated based on this knowledge.

7.9 Timer

  This state is activated once every second. It checks the forwarding
  table, if the Graft message acknowledgment timer is expired, The
  router will retransmit the Graft message to the upstream. If the
  prune state lifetime timer is expired, the router will graft this
  interface so that the downstream router can receive the packets to
  the group again. The router also checks if the (source, group) pair
  is pruned by the upstream router, if so, it will send a graft message
  to the upstream interface.

8. Simulation performance

  Our simulations of three network models with MOSPF routing have
  showed good Scalability of the protocol. The running platform we used
  is a SGI Octane Station with 512 MB main memory and MIPS R10000 CPU,
  Rev 2.7. Here we list the real running time of each model along with
  its major elements and the packet inter-arrival times for the streams
  generated in the hosts.











Pullen, et. al.              Informational                     [Page 28]

RFC 2490                 IP Multicast with RSVP             January 1999


Simulated      Debug Model       Intermediate Model      Large Model
 time         11 Routers           42 routers           86 routers
               12 Hosts             48 hosts             96 hosts

             Reserve Data         Reserve Data         Reserve Data
                0.01s                0.02s                 0.02s
          Best-effort Data      Best-effort Data      Best-effort Data
                0.01s                0.025s               0.025s

 100 s        3 hours               14 hours             30 hours
 200 s        7 hours               30 hours               - - -

9.  Future work

  We hope to receive assistance from the IPmc/RSVP development
  community within the IETF in validating and refining this model.  We
  believe it will be a useful tool for predicting the behavior of
  RSVP-capable systems.

10.  Security Considerations

  This RFC raises no security considerations.

11.  References

  [1] Deering, S., "Host Requirements for IP Multicasting", STD 5,
      RFC 1112, August 1989.

  [2] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
      "Resource Reservation Protocol (RSVP) -- Version 1 Functional
      Specification", RFC 2205, September 1997.

  [3] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
      RFC 2210, September 1997.

  [4] MIL3 Inc., "OPNET Modeler Tutorial Version 3", Washington, DC,
      1997

  [5] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.

  [6] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work
      in Progress.









Pullen, et. al.              Informational                     [Page 29]

RFC 2490                 IP Multicast with RSVP             January 1999


Authors' Addresses

  J. Mark Pullen
  C3I Center/Computer Science
  Mail Stop 4A5
  George Mason University
  Fairfax, VA 22032

  EMail: [email protected]


  Ravi Malghan
  3141 Fairview Park Drive, Suite 700
  Falls Church VA 22042

  EMail: [email protected]


  Lava K. Lavu
  Bay Networks
  600 Technology Park Dr.
  Billerica, MA 01821

  EMail: [email protected]


  Gang Duan
  Oracle Co.
  Redwood Shores, CA 94065

  EMail: [email protected]


  Jiemei Ma
  Newbridge Networks Inc.
  593 Herndon Parkway
  Herndon, VA 20170

  EMail: [email protected]


  Hoon Nah
  C3I Center
  Mail Stop 4B5
  George Mason University
  Fairfax, VA 22030

  EMail: [email protected]



Pullen, et. al.              Informational                     [Page 30]

RFC 2490                 IP Multicast with RSVP             January 1999


Full Copyright Statement

  Copyright (C) The Internet Society (1999).  All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Pullen, et. al.              Informational                     [Page 31]