Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_n_r/draft-pullen-ipv4-rsvp-00.txt

Text File | 1996-11-26 | 41KB | 830 lines

INTERNET DRAFT                                  J.M.Pullen
Expiration: 25 April 1997                         George Mason University
                                                Ravi Malghan
                                                  COMSAT Incorporated
                                                Lava K. Lavu
                                                  George Mason University
                                                25 November 1996


             A Simulation Model for IP Multicast with RSVP
                    <draft-pullen-ipv4-rsvp-00.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   ``work in progress''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-
   Drafts Shadow Directories on ftp.is.co.za (Africa),
   nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   This document describes a detailed model of IPV4 multicast with
   RSVP that has been developed using the OPNET simulation package
   but could be ported to any descrete event simulation package
   with 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.

1.  Background

   The successful deployment of IP multicasting [1] and its availability in
   the Mbone has led to continuing increase in real-time multimedia
   Intermet 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 and voice can be sustained at
   specified levels.  The RSVP protocol [2] has been developed for this
   purpose and is the subject of considerable ongoing implementation
   efforts.  Although the developers of RSVP have used simulation in their
   design process, no simulation of IPmc with RSVP is 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 (which 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.  Perhaps more importantly, given the widespread
   availability of OPNET, it makes them highly efficient so that extended
   period of network behavior can be simulated in considerable detail, even
   for large networks.

   The folowing sections describe the state-transition models and process
   code for the IPmc and RSVP models we have created using OPNET.


3.  IP Multicast Model

   The state-transition diagrams for the IPmc model are available at
   http://bacon.gmu.edu/qosip/igmp  {In the  postscript
   version we will include them at this point.}

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

3.1.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.  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.

3.1 Network Layer

   Fig 6.1 describes an example network topology built using the OPNET
   network editor.  This network consists of two backbone routers BR2,
   BR4, three area border routers BR0,  BR1,  BR3 and six subnets F0,
   through F5.  As OPNET has no full duplex link model, each connecting
   link is modeled as two simplex links enabling bi-directional traffic.

3.1.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.1.2 FDDI Subnets

   Fig 6.2 shows the FDDI ring in a subnet and a Ethernet in a subnet.
   Both of the subnets will have one router and one or more  hosts.  The
   routers in the subnet are 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 generally connected to an area border router on another
   interface (the subnet routers are connected to more than one backbone
   router).  In the Ethernet all the hosts are connected to the bus
   and in FDDI ring the hosts are interconnected as illustrated in
   figure 6.2.

   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.

3.1.3 Ethernet subnets

   Ethernet is a bus-based local area network (LAN) technology.  The
   operation of the LAN is managed by a media access protocol (MAC) which
   has been standardized by the IEEE under the name 802.3.  The role of
   this MAC protocol is to provide efficient and fair sharing of the
   communication channel connecting the stations of the LAN.

3.2 Node layer

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


3.2.1 Basic 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 speed is an
   attribute of the transmitter and receiving speed 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.

3.2.2 Host description

   The host model built using OPNET has a layered structure which is very
   similar to the TCP/IP protocol suite. Fig 6.3 shows the node level
   structure of a FDDI 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.

   c. IP queue node: The next layer in the hierarchy is the IP layer.  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 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 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 operates 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.

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

   The IGMP_host node 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.

   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 (it 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 of this
      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 that the MAC
      layer begins to accept the frames destined for the group N.

   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 Fig 6.4 and the description in the
      following section describes the scenario.

      (See Fig 6.4, An example Ethernet architecture.)  The router R
      interfaces with the Ethernet on one interface I1 and H1, H2,  H3
      are the hosts on the Ethernet.  To illustrate this let us assume
      that the 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 Ethernet 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 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.  The Ethernet example in Fig 6.4 described the function
      to be performed when a IGMP_host receives the response sent by
      other hosts in the subnet.
   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 from now on will not send any response
      corresponding to this group (unless any other 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,  the
      membership is canceled for that group on that interface.


   e. Unicast best-effort (UBE) processor node: This node is used model 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 QOSPF or

   RSVP.  UBE node aims to create the scenarios observed in a network
   which has one type of application using the services provided by
   QOSPF, 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 create congestion in the network.  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 a
      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 period which is
      uniformly distributed between Session-min and Session-max.

   e. 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:
   1. Session IAT: is the variable used to schedule an event to begin a
      session.  The Application node generates a 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.
   4. NGRP: 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.

3.2.3 Router description

   There are two types of routers.  A router in 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. Fig 6.5 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, rx2, rx3 and rx4 are the
   receivers connected to incoming T1 links.  The router in Fig 6.5 has a
   physical interface to the FDDI ring,  which consists of the queue node

   MAC, transmitter phy_tx, and the receiver phy_rx.  The backbone
   routers will not have the MAC layer.  The services provided and the
   functions of the MAC layer are the same as in the host discussed
   earlier.

   There is one major difference between the MAC node in an subnet router
   that in a host.  The MAC node in a subnet router accepts all the
   multicast packets unlike the MAC in a host which accepts only the
   multicast packets for groups of which the IGMP_host.  For this reason
   the statistic wire from the IGMP to MAC layer does not exist in a
   router.

   b. Addr_trans: The next 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 has
   already been described under the most model.

   c. IP layer: The next layer in the hierarchy is the 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.

   d. The tables used by the router model are:
   1. Unicast routing table:  This table is a single dimensional array,
      which is used to route packets generated by the UDP process node in
      the hosts.  If no route is available to a particular IP address,
      the corresponding entry is set to a default route in the array.
   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 a upper
      layer routing protocol which for this project is the QOSPF layer.
      When the IP layer receives a multicast packet with a session_id
      corresponding to a session which is utilizing the QOSPF and RSVP,
      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 QOSPF (or any routing protocol) uses this
      information in the group membership table to calculate and set the
      routes in the Multicast routing table.

   e. Sub-queues: The IP layer has three sub queues built in it,
   which implement queuing based upon the priority of arriving packets
   from the neighboring routers or the underlying subnet. The
   architecture of the router queues is illustrated in Fig 6.6.
   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: resource-
   reserved traffic, best effort traffic, or control traffic.  A non-
   preemptive priority is used in servicing the packets.  After the
   servicing, packets are sent to the one of the output queues q_1
   through q_I or the MAC.  The packets progress through these queues
   until the transmitter becomes available.

   f. 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

   g. Output queues: The output queues perform the function of queuing
   the packets served 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.  Attribute of the queue node are:
   1. Queue size: size of the queue in each queue nodes.

3.2.4 IGMP implementation at a router

  The next layers in the hierarchy level are the IGMP for implementing
  multicasting, the routing protocol, and RSVP for providing specific
  QoS setup.

  a. IGMP Node: The IGMP node implements the IGMP protocol as defined in
  RFC 1112.  The IGMP node at a router 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 it's
     interfaces.
  2. When IGMP receives a response to the queries sent, IGMP updates the
     multicast Group membership table in the IP node.
  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 (which we have implemented as QOSPF, see
     companion paper) 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.


4.  RSVP model

   The current version of the RSVP model supports only fixed-filter
   reservation style.  The state-transition diagrams for the RSVP model are
   available at

   http://bacon.gmu.edu/qosip/rsvp

   The following processing takes place in the indicated modules.

4.1 RSVP APPLICATION

4.1.1  Init

   Initializes all variables and load the distribution functions
   for Multicast Group Id's, termination of the session. Transit
   to Idle state after completing all the initializations.

4.1.2  Idle

   This state has transitions to four states, Arr, Join, Data_Send and
   EndSim. It transit to Arr state upon Packet Arrival, transit to
   Join state when the Join interrupt was true, transit to Data_Send
   state when the Send_Data interrupt was true, transit to EndSim state
   when simulation ends.

4.1.3  Arr

   In this state if a data packet arrives the application will
   increment the Data Received counter, and if a Session message
   from Local RSVP daemon arrives it update it's Registered
   Session directory. After completing these functions it will return
   to the idle state.

4.1.4  Join

   The Application will send a session call to local RSVP
   daemon and once it receives the session Id from the Local
   daemon it 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 makes a receive
   call to the local RSVP daemon.

   Along with these two calls it makes a IGMP join call.

   If the application chooses to terminate the session it
   was registered to, 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.

4.1.5  Data_Send

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

4.1.6  EndSim

   This state gives statistics of how many packets have
   received and how many packets have been sent.

4.2 RSVP ON ROUTER

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.
   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 in our application we are not sending any error
      messages, we are printing this error message on to 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 is made as 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
      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 available (At present we are not
      implementing this message and just printing this error message on
      to console).
   3. Check for the 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 PSB's 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.
   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 was
      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 was 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.
   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

4.3.1  Init

   Initializes all the variables. Default transition to idle state.

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.

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

   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  EndSim

   This state does not do anything.

4.3.5  Session

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

4.3.6  Sender

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

4.3.7  Reserve

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

4.3.8  Release

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


5.  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.

6.  References

   [1] Deering, "Host Requirements for IP Multicasting", RFC 1112,
       August 1989

   [2] Braden et. al., "Resource Reservation Protocol Version 1 Functional
       Specification", work in progress (draft-ietf-rsvp-spec-14)
       November 1996

   [3] MIL3 Inc., "OPNET: Optimized Network Engineering Tools, Simulation
       Kernel Manual", November 1991



 Authors' Addresses

  J. Mark Pullen
  Computer Science/4A5
  George Mason University
  Fairfax, VA 22032
  [e-mail]

  Ravi Malghan
  COMSAT Laboratories
  22300 COMSAT Drive
  Clarksburg, MD 20871-9475
  [e-mail]

  Lava K. Lavu
  C3I Center/4B5
  George Mason University
  Fairfax, VA 22030
  [e-mail]


Expiration: 25 April 1997