rfc2490.txt

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

      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.