rfc2490.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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