rfc1075.txt

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

RFC 1075       Distance Vector Multicast Routing Protocol  November 1988


   cause hosts to respond with IGMP membership reports after a small
   delay.  Hosts will send the report for a group to the group's
   multicast address.

   The membership requests should have an IP TTL of 1.

   The routers on a network elect or "designate" a single router to do
   the queries.  The designated router is the router with the lowest IP
   address on that network.  Upon startup a router considers itself to
   be the designated router until it learns (presumably through routing
   messages) of a router with a lower address.  To learn about the group
   members present on a network at startup, a router should multicast a
   number of membership requests, separated by a small delay.  We
   suggest sending three requests separated by four seconds.

   The multicast router must receive all datagrams sent to all multicast
   addresses.  Upon receiving an IGMP membership report for a group from
   an interface, it must either record the existence of that group on
   the interface and record the time, or update the time if the group is
   already recorded.  The recorded group memberships must be timed-out.
   If a group member report is not received for a recorded group after
   MEMBERSHIP_TIMEOUT seconds, the recorded group should be deleted.

6. Forwarding Algorithm

   The section describes the multicast forwarding algorithm and the
   state that must be kept for the algorithm.

   The forwarding algorithm is applied to determine how multicast
   datagrams arriving on a physical interface or a tunnel should be
   handled.  If multicast datagrams were flooded, a datagram received on
   one virtual interface would be forwarded out of every other virtual
   interface.  Because of redundant paths in the internet, datagrams
   would be duplicated.  The child and leaf information, that the
   routing algorithm supplies, is used to prune branches in the tree to
   all possible destinations.

   In route entries, there is a dominant router address for each virtual
   interface.  This address is the address of some router that has a
   route with a lower metric (and whose metric does not equal infinity)
   to the destination, on that virtual interface.  The dominant router
   address is not set for the next-hop virtual interface.

   Also in route entries, there is a subordinate router address for each
   virtual interface.  This address is the address of some router that
   considers this router to be the parent of the virtual network.
   Therefore, the subordinate router address is not set for a virtual
   interface to a leaf network.



Waitzman, Partridge & Deering                                  [Page 19]

RFC 1075       Distance Vector Multicast Routing Protocol  November 1988


   The algorithm for manipulating the children and leaf lists in route
   entries is:

   Upon router startup:
           Create a route entry for each virtual interface, with:
               - all other virtual interfaces in its child list,
               - an empty leaf list,
               - no dominant router addresses, and
               - no subordinate router addresses.
           Start a hold down timer for each virtual interface, with
           a value of LEAF_TIMEOUT.

   Upon receiving a new route:
           Create the route entry, with:
               - all virtual interfaces, other than the one on which the
                 new route was received, in its child list,
               - empty leaf list,
               - no dominant router addresses, and
               - no subordinate router addresses.
           Start the hold down timer for all virtual interfaces, other
           than the one on which the new route was received, with a
           value of LEAF_TIMEOUT.

   Upon receiving a route on virtual interface V from neighbor N with a
   lower metric than the one in the routing table (or the same metric as
   the one in the routing table, if N's address is less than my address
   for V), for that route:
     If V is in the child list, delete V from the child list.
     If there is no dominant router for V and if V is not (now) the
     next-hop virtual interface, record N as the dominant router.

   Upon receiving a route on virtual interface V from neighbor N with a
   larger metric than the one in the routing table (or the same metric
   as the one in the routing table, if N's address is greater than my
   address for V), for that route:
     If N is the dominant router for V, delete N as the dominant router
     and add V to the child list.

   Upon receiving a route from neighbor N on virtual interface V with a
   metric equal to infinity (the split horizon flag should also be set),
   for that route:
     If V is in the leaf list, delete V from the leaf list.
     If there is no subordinate router for V, record N as the
     subordinate router.

   Upon receiving a route from neighbor N on virtual interface V with a
   metric other than infinity (and no split horizon flag), for that
   route:



Waitzman, Partridge & Deering                                  [Page 20]

RFC 1075       Distance Vector Multicast Routing Protocol  November 1988


     If N is the subordinate router for V, delete N as the subordinate
     router and start the hold down timer for V.

   Upon timer expiration for a virtual interface (V), for each route:
     If there is no subordinate router for V, add V to the leaf list.

   Upon failure of neighbor N on virtual interface V, for each route:
     If N is the dominant router for V, delete N as the dominant router
     and add V to the child list.
     If N is the subordinate router for V, delete N as the subordinate
     router and start the hold down timer for V.

   The forwarding algorithm is:

   IF the IP TTL is less than 2:
   THEN    CONTINUE with next datagram.

   find the route to the source of the IP datagram.

   IF no route exists:
   THEN    CONTINUE with next datagram.

   IF the datagram was not received on the next-hop virtual interface
   for the route:
   THEN    CONTINUE with next datagram.

   IF the datagram is tunneled:
   THEN    replace the datagram's source address with the first address
           in the IP loose source route.
           replace the datagram's destination address with the second
           address in the IP loose source route.
           delete the loose source route and the null option from the
           datagram and adjust the IP header length fields to reflect
           the deletion.

   If the datagram destination is group 224.0.0.0 or group 224.0.0.1:
   THEN    CONTINUE with next datagram.

   FOR each virtual interface V
   DO      IF V is in the child list for the source of the datagram:
           THEN    IF V is not in the leaf list for the source
                   OR there are members of the destination group on V:
                   THEN    IF the IP TTL is greater then V's threshold:
                           THEN    subtract 1 from the IP TTL
                                   forward the datagram out V






Waitzman, Partridge & Deering                                  [Page 21]

RFC 1075       Distance Vector Multicast Routing Protocol  November 1988


7. Time Values

   This section contains a list of the various rates and timeouts, their
   meanings, and their values.  All values are in seconds.

   How dynamic the routing environment is effects the following rates.
   A lower rate will allow quicker adaptation to a change in the
   environment, at the cost of wasting network bandwidth.

   FULL_UPDATE_RATE = 60
           - How often routing messages containing complete routing
             tables are sent.

   TRIGGERED_UPDATE_RATE = 5
           - How often triggered routing messages may be sent out.

   Raising the following rates and timeouts may increase the time that
   packets may be forwarded to a virtual interface unnecessarily.

   QUERY_RATE = 120
           - How often local group membership is queried.

   MEMBERSHIP_TIMEOUT = 2 * QUERY_RATE + 20
           - How long a local group membership is valid without
             confirmation.

   LEAF_TIMEOUT = 2 * FULL_UPDATE_RATE + 5
           - How long the hold down timer is for a virtual interface.

   Increasing the following timeouts will increase the stability of the
   routing algorithm, at the cost of slower reactions to changes in the
   routing environment.

   NEIGHBOR_TIMEOUT = 4 * FULL_UPDATE_RATE
           - How long a neighbor is considered up without confirmation.
             This is important for timing out routes, and for setting
             the children and leaf flags.

   EXPIRATION_TIMEOUT = 2 * FULL_UPDATE_RATE
           - How long a route is considered valid without confirmation.
             When this timeout expires, packets will no longer be
             forwarded on the route, and routing updates will consider
             this route to have a metric of infinity.

   GARBAGE_TIMEOUT = 4 * FULL_UPDATE_RATE
           - How long a route exists without confirmation.  When this
             timeout expires, routing updates will no longer contain any
             information on this route, and the route will be deleted.



Waitzman, Partridge & Deering                                  [Page 22]

RFC 1075       Distance Vector Multicast Routing Protocol  November 1988


8. Configuration options

   A router should be configurabled with the following information:

   - Tunnel descriptions: local end-point, remote end-point, metric, and
     threshold.  If no threshold is provided, the metric should be used
     as the default threshold.

   - For a physical interface: metric, infinity, threshold and
     subnetwork mask.  If no threshold is provided, the metric should be
     used as the default threshold.

9. Conclusion

   This memo has presented DVMRP, an extensible distance-vector-style
   routing protocol, and a TRPB routing algorithm.  An implementation of
   the ideas presented in this document has been done, and is being
   tested.

   The added features in DVMRP, as compared to RIP, give it flexibility
   at the cost of more complex processing.  DVMRP still has the
   disadvantages of being a distance-vector algorithm.  Because link-
   state algorithms maintain much of the state information that DVMRP
   has to maintain in excess of what RIP needs, a multicast link-state
   routing protocol should be developed.

   The TRPB algorithm can cause unneeded datagrams to be sent.  The
   Reverse Path Multicasting algorithm (RPM) [3] might be a better
   algorithm.  The NMR and NMR-cancel DVMRP messages are designed to
   support RPM.  Further research is needed on this topic.

10. Acknowledgements

   We would like to thank Robb Foster, Alan Dahlbom, Ross Callon, and
   the IETF Host Working Group for their ideas.

11. Bibliography

     [1]  Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
          University, June 1988.

     [2]  Deering, S., "Host Extensions for IP Multicasting", RFC 1054,
          Stanford University, May 1988.

     [3]  Deering, S., "Multicast Routing in Internetworks and Extended
          LANs", SIGCOMM Summer 1988 Proceedings, August 1988.

     [4]  Callon, R., "A Comparison of 'Link State' and 'Distance



Waitzman, Partridge & Deering                                  [Page 23]

RFC 1075       Distance Vector Multicast Routing Protocol  November 1988


          Vector' Routing Algorithms", DEC, November 1987.

     [5]  Postel, J., "Internet Protocol", RFC 791, USC/Information
          Sciences Institute, September 1981.

     [6]  Mills, D., "Toward an Internet Standard Scheme for
          Subnetting", RFC 940, University of Delaware, April 1985.












































Waitzman, Partridge & Deering                                  [Page 24]