rfc2189.txt

RFC 的详细文档！

   A network manager can preference a router's DR eligibility by
   optionally configuring an HELLO preference, which is included in the
   router's HELLO messages.  Valid configuration values range from 1 to
   254 (decimal), 1 representing the "most eligible" value. In the
   absence of explicit configuration, a router assumes the default HELLO
   preference value of 255. The elected DR uses HELLO preference zero
   (0) in HELLO advertisements, irrespective of any configured
   preference.  The DR continues to use preference zero for as long as
   it is running.




Ballardie                     Experimental                      [Page 6]

RFC 2189              CBTv2 Protocl Specification         September 1997


   HELLO messages are multicast periodically to the all-cbt-routers
   group, 224.0.0.15, using IP TTL 1. The advertisement period is
   [HELLO_INTERVAL] seconds.

   HELLO messages have a suppressing effect on those routers which would
   advertise a "lesser preference" in their HELLO messages; a router
   resets its [HELLO_INTERVAL] if the received HELLO is "better" than
   its own. Thus, in steady state, the HELLO protocol incurs very little
   traffic overhead.

   The DR election winner is that which advertises the lowest HELLO
   preference, or the lowest-addressed in the event of a tie.

   The situation where two or more routers attached to the same
   broadcast link areadvertising HELLO preference 0 should never arise.
   However, should this situation arise, all but the lowest addressed
   zero advertising router relinquishes its claim as DR immediately by
   unsetting the DR flag on the corresponding interface. The
   relinquishing router(s) subsequently advertise their previously used
   preference value in HELLO advertisements.

4.1.1.  Sending HELLOs

   When a router starts up, it multicasts two HELLO messages over each
   of its broadcast interfaces in successsion. The DR flag is initially
   unset (FALSE) on each broadcast interface.  This avoids the situation
   in which each router on a multi-access subnet believes it is the DR,
   thus preventing the multiple forwarding of join-requests should they
   arrive during this start up period.  If no "better" HELLO message is
   received after HOLDTIME seconds, the router assumes the role of DR on
   the corresponding interface.

   A router sends an HELLO message whenever its [HELLO_INTERVAL]
   expires.  Whenever a router sends an HELLO message, it resets its
   hello timer.

4.1.2.  Receiving HELLOs

   A router does not respond to an HELLO message if the received HELLO
   is "better" than its own, or equally preferenced but lower addressed.

   A router must respond to an HELLO message if that received is lesser
   preferenced (or equally preferenced but higher addressed) than would
   be sent by this router over the same interface. This response is sent
   on expiry of an interval timer which is set between zero (0) and
   [HOLDTIME] seconds when the lesser preferenced HELLO message is
   received.




Ballardie                     Experimental                      [Page 7]

RFC 2189              CBTv2 Protocl Specification         September 1997


4.2.  JOIN_REQUEST Processing

   A JOIN_REQUEST is the CBT control message used to register a member
   host's interest in joining the distribution tree for the group.

4.2.1.  Sending JOIN_REQUESTs

   A JOIN_REQUEST can only ever be originated by a leaf router, i.e. a
   router with directly attached member hosts. This join message is sent
   hop-by-hop towards the core router for the group (see section 8).
   The originating router caches <group, NULL, upstream interface> state
   for each join it originates. This state is known as "transient join
   state".  The absence of a "downstream interface" (NULL) indicates
   that this router is the join message originator, and is therefore
   responsible for any retransmissions of this message if a response is
   not received within [RTX_INTERVAL].  It is an error if no response is
   received after [JOIN_TIMEOUT] seconds.  If this error condition
   occurs, the joining process may be re-invoked by the receipt of the
   next IGMP host membership report from a locally attached member host.

   Note that if the interface over which a JOIN_REQUEST is to be sent
   supports multicast, the JOIN_REQUEST is multicast to the all-cbt-
   routers group, using IP TTL 1.  If the link does not support
   multicast, the JOIN_REQUEST is unicast to the next hop on the unicast
   path to the group's core.

4.2.2.  Receiving JOIN_REQUESTs

   On broadcast links, JOIN_REQUESTs which are multicast may only be
   forwarded by the link's DR. Other routers attached to the link may
   process the join (see below). JOIN_REQUESTs which are multicast over
   a point-to-point link are only processed by the router on the link
   which does not have a local interface corresponding to the join's
   network layer (IP) source address. Unicast JOIN_REQUESTs may only be
   processed by the router which has a local interface corresponding to
   the join's network layer (IP) destination address.

   With regard to forwarding a received JOIN_REQUEST, if the receiving
   router is not on-tree for the group, and is not the group's core
   router, and has not already forwarded a join for the same group, the
   join is forwarded to the next hop on the path towards the core. The
   join is multicast, or unicast, according to whether the outgoing
   interface supports multicast.  The router caches the following
   information with respect to the forwarded join: <group, downstream
   interface, upstream interface>. Subsequent JOIN_REQUESTs received for
   the same group are cached until this router has received a JOIN_ACK
   for the previously sent join, at which time any cached joins can also
   be acknowledged.



Ballardie                     Experimental                      [Page 8]

RFC 2189              CBTv2 Protocl Specification         September 1997


   If this transient join state is not "confirmed" with a join
   acknowledgement (JOIN_ACK) message from upstream, the state is timed
   out after [TRANSIENT_TIMEOUT] seconds.

   If the receiving router is the group's core router, the join is
   "terminated" and acknowledged by means of a JOIN_ACK. Similarly, if
   the router is on-tree and the JOIN_REQUEST arrives over an interface
   that is not the upstream interface for the group, the join is
   acknowledged.

   If a JOIN_REQUEST for the same group is scheduled to be sent over the
   corresponding interface (i.e. awaiting a timer expiry), the
   JOIN_REQUEST is unscheduled.

   If this router has a cache-deletion-timer [CACHE_DEL_TIMER] running
   on the arrival interface for the group specified in a multicast join,
   the timer is cancelled.

4.3.  JOIN_ACK Processing

   A JOIN_ACK is the mechanism by which an interface is added to a
   router's multicast forwarding cache; thus, the interface becomes part
   of the group distribution tree.

4.3.1.  Sending JOIN_ACKs

   The JOIN_ACK is sent over the same interface as the corresponding
   JOIN_REQUEST was received. The sending of the acknowledgement causes
   the router to add the interface to its child interface list in its
   forwarding cache for the group, if it is not already.

   A JOIN_ACK is multicast or unicast, according to whether the outgoing
   interface supports multicast transmission or not.

4.3.2.  Receiving JOIN_ACKs

   The group and arrival interface must be matched to a <group, ....,
   upstream interface> from the router's cached transient state. If no
   match is found, the JOIN_ACK is discarded.  If a match is found, a
   CBT forwarding cache entry for the group is created, with "upstream
   interface" marked as the group's parent interface.

   If "downstream interface" in the cached transient state is NULL, the
   JOIN_ACK has reached the originator of the corresponding
   JOIN_REQUEST; the JOIN_ACK is not forwarded downstream.  If
   "downstream interface" is non-NULL, a JOIN_ACK for the group is sent





Ballardie                     Experimental                      [Page 9]

RFC 2189              CBTv2 Protocl Specification         September 1997


   over the "downstream interface" (multicast or unicast, accordingly).
   This interface is installed in the child interface list of the
   group's forwarding cache entry.

   Once transient state has been confirmed by transferring it to the
   forwarding cache, the transient state is deleted.

4.4.  QUIT_NOTIFICATION Processing

   A CBT tree is "pruned" in the direction downstream-to-upstream
   whenever a CBT router's child interface list for a group becomes
   NULL.

4.4.1.  Sending QUIT_NOTIFICATIONs

   A QUIT_NOTIFICATION is sent to a router's parent router on the tree
   whenever the router's child interface list becomes NULL. If the link
   over which the quit is to be sent supports multicast transmission, if
   the sending router is the link's DR the quit is unicast, otherwise it
   is multicast.

   A QUIT_NOTIFICATION is not acknowledged; once sent, all information
   pertaining to the group it represents is deleted from the forwarding
   cache immediately.

   To help ensure consistency between a child and parent router given
   the potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX]
   QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous
   one.

   The sending of a quit (the first) also invokes the sending of a
   FLUSH_TREE message over each downstream interface for the
   corresponding group.

4.4.2.  Receiving QUIT_NOTIFICATIONs

   The group reported in the QUIT_NOTIFICATION must be matched with a
   forwarding cache entry. If no match is found, the QUIT_NOTIFICATION
   is ignored and discarded.  If a match is found, if the arrival
   interface is a valid child interface in the group entry, how the
   router proceeds depends on whether the QUIT_NOTIFICATION was
   multicast or unicast.

   If the QUIT_NOTIFICATION was unicast, the corresponding child
   interface is deleted from the group's forwarding cache entry, and no
   further processing is required.





Ballardie                     Experimental                     [Page 10]

RFC 2189              CBTv2 Protocl Specification         September 1997


   If the QUIT_NOTIFICATION was multicast, and the arrival interface is
   a valid child interface for the specified group, the router sets a
   cache-deletion-timer [CACHE_DEL_TIMER].

   Because this router might be acting as a parent router for multiple
   downstream routers attached to the arrival link, [CACHE_DEL_TIMER]
   interval gives those routers that did not send the  QUIT_NOTIFICA-
   TION, but received it over their parent interface, the opportunity to
   ensure that the parent router does not remove the link from its child
   interface list.  Therefore, on receipt of a multicast
   QUIT_NOTIFICATION over a parent interface, a receiving router
   schedules a JOIN_REQUEST for the group for sending at a random
   interval between 0 (zero) and HOLDTIME seconds.  If a multicast
   JOIN_REQUEST is received over the corresponding interface (parent)
   for the same group before this router sends its own scheduled
   JOIN_REQUEST, it unschedules the multicasting of its own
   JOIN_REQUEST.

4.5.  ECHO_REQUEST Processing

   The ECHO_REQUEST message allows a child to monitor reachability to
   its parent router for a group (or range of groups if the parent
   router is the parent for multiple groups). Group information is not
   carried in ECHO_REQUEST messages.

4.5.1.  Sending ECHO_REQUESTs

   Whenever a router creates a forwarding cache entry due to the receipt
   of a JOIN_ACK, the router begins the periodic sending of ECHO_REQUEST
   messages over its parent interface. The ECHO_REQUEST is multicast to
   the "all-cbt-routers" group over multicast-capable interfaces, unless
   the sending router is the DR on the interface over which the
   ECHO_REQUEST is being sent, in which case it is unicast (as is the
   corresponding ECHO_REPLY).

   ECHO_REQUEST messages are sent at [ECHO_INTERVAL] second intervals.

   Whenever an ECHO_REQUEST is sent, [ECHO_INTERVAL] is reset.

   If no response is forthcoming, any groups present on the parent
   interface will eventually expire [GROUP_EXPIRE_TIME]. This results in
   the sending of a QUIT_NOTIFICATION upstream, and sends a FLUSH_TREE
   message downstream for each group for which the upstream interface
   was the parent interface.







Ballardie                     Experimental                     [Page 11]

RFC 2189              CBTv2 Protocl Specification         September 1997


4.5.2.  Receiving ECHO_REQUESTs

   If an ECHO_REQUEST is received over any valid child interface, the
   receiving router schedules an ECHO_REPLY message for sending over the
   same interface; the scheduled interval is between 0 (zero) and
   HOLDTIME seconds. This message is multicast to the "all-cbt-routers"
   group over multicast-capable interfaces, and unicast otherwise.

   If a multicast ECHO_REQUEST message arrives via any valid parent
   interface, the router resets its [ECHO_INTERVAL] timer for that
   upstream interface, thereby suppressing the sending of its own
   ECHO_REQUEST over that upstream interface.

4.6.  ECHO_REPLY Processing

   ECHO_REPLY messages allow a child to monitor the reachability of its
   parent, and help ensure the group state information is consistent
   between them.

4.6.1.  Sending ECHO_REPLY messages

   An ECHO_REPLY message is sent in response to receiving an
   ECHO_REQUEST message, provided the ECHO_REQUEST is received over any
   one of this router's valid child interfaces. An ECHO_REPLY reports