rfc1075.txt

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

Network Working Group                                        D. Waitzman
Request For Comments: 1075                                  C. Partridge
                                                                 BBN STC
                                                              S. Deering
                                                     Stanford University
                                                           November 1988

               Distance Vector Multicast Routing Protocol

1. Status of this Memo

   This RFC describes a distance-vector-style routing protocol for
   routing multicast datagrams through an internet.  It is derived from
   the Routing Information Protocol (RIP) [1], and implements
   multicasting as described in RFC-1054.  This is an experimental
   protocol, and its implementation is not recommended at this time.
   Distribution of this memo is unlimited.

2. Introduction

   A draft standard for multicasting over IP networks now exists [2],
   but no routing protocols to support internetwork multicasting are
   available.  This memo describes an experimental routing protocol,
   named DVMRP, that implements internetwork multicasting.  DVMRP
   combines many of the features of RIP [1] with the Truncated Reverse
   Path Broadcasting (TRPB) algorithm described by Deering [3].

   DVMRP is an "interior gateway protocol"; suitable for use within an
   autonomous system, but not between different autonomous systems.
   DVMRP is not currently developed for use in routing non-multicast
   datagrams, so a router that routes both multicast and unicast
   datagrams must run two separate routing processes.  DVMRP is designed
   to be easily extensible and could be extended to route unicast
   datagrams.

   DVMRP was developed to experiment with the algorithms in [3].  RIP
   was used as the starting point for the development because an
   implementation was available and distance vector algorithms are
   simple, as compared to link-state algorithms [4].  In addition, to
   allow experiments to traverse networks that do not support
   multicasting, a mechanism called "tunneling" was developed.

   The multicast forwarding algorithm requires the building of trees
   based on routing information.  This tree building needs more state
   information than RIP is designed to provide, so DVMRP is much more
   complicated in some places than RIP.  A link-state algorithm, which
   already maintains much of the state needed, might prove a better
   basis for Internet multicasting routing and forwarding.



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


   DVMRP differs from RIP in one very important way.  RIP thinks in
   terms of routing and forwarding datagrams to a particular
   destination.  The purpose of DVMRP is to keep track of the return
   paths to the source of multicast datagrams.  To make explanation of
   DVMRP more consistent with RIP, the word "destination" is used
   instead of the more proper "source", but the reader must remember
   that datagrams are not forwarded to these destinations, but originate
   from them.

   This memo is organized into the following sections:
           - A description of DVMRP is presented.
           - Tunnels are explained.
           - The routing algorithm is shown.
           - The forwarding algorithm is shown.
           - The various time values are listed.
           - Configuration information is specified.

   This memo does not analyze distance-vector routing, nor fully explain
   the distance-vector algorithm; see [1] for more information on these
   topics.  The process or processes that perform the routing and
   forwarding functions are called "routers" in this memo.

3. Protocol Description

   DVMRP uses the Internet Group Management Protocol (IGMP) to exchange
   routing datagrams [2].

   DVMRP datagrams are composed of two portions: a small, fixed length
   IGMP header, and a stream of tagged data.

   The fixed length IGMP header of DVMRP messages is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Type  |  Subtype      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The version is 1.

   The type for DVMRP is 3.

   The subtype is one of:

   1 = Response; the message provides routes to some destination(s).
   2 = Request; the message requests routes to some destination(s).
   3 = Non-membership report; the message provides non-membership
       report(s).



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


   4 = Non-membership cancellation; the message cancels previous
       non-membership report(s).

   The checksum is the 16-bit one's complement of the one's complement
   sum of the entire message, excluding the IP header.  For computing
   the checksum, the checksum field is zeroed.

   The rest of the DVMRP message is a stream of tagged data.  The reason
   for using a stream of tagged data is to provide easy extensibility
   (new commands can be developed by adding new tags) and to reduce the
   amount of redundant data in a message.  The elements in the stream,
   called commands, are multiples of 16 bits, for convenient alignment.
   The commands are organized as an eight bit command numeric code, with
   at least an eight bit data portion.  Sixteen-bit alignment of all
   commands is required.

   A message that has an error in it will be discarded at the point in
   processing where the error is detected.  Any state changed due to the
   message contents before the error will not be restored to its
   previous values.

   Certain commands have default values defined in their specification.
   As the defaults may be changed as the protocol is developed further,
   a cautious implementation will not send out messages that depend on
   defaults.

   The length of DVMRP messages is limited to 512 bytes, excluding the
   IP header.

3.1 NULL Command

   Format:  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
           |        0      |  |    Ignored    |
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

   Description: The NULL command can be used to provide additional
   alignment or padding to 32 bits.

3.2 Address Family Indicator (AFI) Command

   Format:  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
           |        2      |  |     family    |
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+






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


   Values for family:

      2 = IP address family, in which addresses are 32 bits long.

   Default: Family = 2.

   Description: The AFI command provides the address family for
   subsequent addresses in the stream (until a different AFI command is
   given).

   It is an error if the receiver does not support the address family.

3.3 Subnetmask Command

   Format:  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
           |        3      |  |     count     |
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

   Additional argument, with AFI = IP:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Subnet mask                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Count is 0 or 1.

   Default: Assume that following routes are to networks, and use a mask
   of the network mask of each route's destination.

   Description: The Subnetmask command provides the subnet mask to use
   for subsequent routes.  There are some requirements on the bits in
   the subnetmask: bits 0 through 7 must be 1, and all of the bits must
   not be 1.

   If the count is 0, then no subnet mask applies, assume that the
   following routes are to networks, and use a mask of the network mask
   of each route's destination.  If count is 1, then a subnet mask
   should be in the data stream, of an appropriate size given the
   address family.

   It is an error for count not to equal 0 or 1.

   Subnetmasks should not be sent outside of the appropriate network.

   See [6] for more information regarding IP subnetting.



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


3.4 Metric Command

   Format:  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
           |        4      |  |     value     |
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

   Value is the metric, as an unsigned value ranging from 1 to 255.

   Default: None.

   Description: The metric command provides the metric to subsequent
   destinations.  The metric is relative to the router that sent this
   DVMRP routing update.

   It is an error for metric to equal 0.

3.5 Flags0 Command

   Format:  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
           |        5      |  |     value     |
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

   Meaning of bits in value:

      Bit 7: Destination is unreachable.
      Bit 6: Split Horizon concealed route.

   Default: All bits zero.

   Description: The flags0 command provides a way to set a number of
   flags.  The only defined flags, bits 6 and 7, can be used to provide
   more information about a route with a metric of infinity.  A router
   that receives a flag that it does not support should ignore the flag.
   The command is called flags0 to permit the definition of additional
   flag commands in the future (flags1, etc.).

   This is an experimental command, and may be changed in the future.

3.6 Infinity Command

   Format:  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
           |        6      |  |     value     |
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

   Value is the infinity, as an unsigned value ranging from 1 to 255.



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


   Default: Value = 16.

   Description: The infinity command defines the infinity for subsequent
   metrics in the stream.

   It is an error for infinity to be zero, or less than the current
   metric.

3.7 Destination Address (DA) Command

   Format:  0 1 2 3 4 5 6 7    0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
           |        7      |  |     count     |
           +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

   Array of 'count' additional arguments, with AFI = IP:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Destination Address1                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Destination Address2                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Count is the number of addresses supplied, from 1 to 255.  The length
   of the addresses depends upon the current address family.  The number
   of addresses supplied is subject to the message length limitation of
   512 bytes.

   Default: None.

   Description: The DA command provides a list of destinations.  While
   this format can express routes to hosts, the routing algorithm only
   supports network and subnetwork routing.  The current metric,
   infinity, flags0 and subnetmask, when combined with a single
   destination address, define a route.  The current metric must be less
   than or equal to the current infinity.

   It is an error for count to equal 0.