doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc2490.txt b/doc/rfc/rfc2490.txt
new file mode 100644
index 0000000..66b60d5
--- /dev/null
+++ b/doc/rfc/rfc2490.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+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: mpullen@gmu.edu
+
+
+   Ravi Malghan
+   3141 Fairview Park Drive, Suite 700
+   Falls Church VA 22042
+
+   EMail: rmalghan@bacon.gmu.edu
+
+
+   Lava K. Lavu
+   Bay Networks
+   600 Technology Park Dr.
+   Billerica, MA 01821
+
+   EMail: llavu@bacon.gmu.edu
+
+
+   Gang Duan
+   Oracle Co.
+   Redwood Shores, CA 94065
+
+   EMail: gduan@us.oracle.com
+
+
+   Jiemei Ma
+   Newbridge Networks Inc.
+   593 Herndon Parkway
+   Herndon, VA 20170
+
+   EMail: jma@newbridge.com
+
+
+   Hoon Nah
+   C3I Center
+   Mail Stop 4B5
+   George Mason University
+   Fairfax, VA 22030
+
+   EMail: hnah@bacon.gmu.edu
+
+
+
+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]
+