rfc2715.txt

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


RFC 2715                     Interop Rules                  October 1999


   As with all broadcast-and-prune protocols, PIM-DM components are
   automatically wildcard receivers for internally-reached sources.
   Unless some form of Domain-Wide-Reports (DWRs) [10] are added to
   PIM-DM in the future, all PIM-DM components also act as wildcard
   receivers for externally-reached sources.  If DWRs are available for
   the domain, then a PIM-DM component acts as a wildcard receiver for
   externally-reached sources only if internally-reached domains exist
   which do not support some form of DWRs.

   One simple heuristic to approximate DWRs is to assume that if there
   are any internally-reached members, then at least one of them is a
   sender.  With this heuristic, the presense of any (S,G) state for
   internally-reached sources can be used instead.  Sending a data
   packet to a group is then equivalent to sending a DWR for the group.

4.3.1.  Generating Alerts

   A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g.,
   the Interop dispatcher) when the first component becomes a wildcard
   receiver for external sources.  This may occur when a PIM-DM
   component starts up which does not support some form of DWRs.

   A (*,*) Prune alert is sent to the iif owner of the (*,*) entry
   (e.g., the Interop dispatcher) when all components are no longer
   wildcard receivers for external sources.  This may occur when a PIM-
   DM component which does not support some form of DWRs shuts down.

   A (S,G) Prune alert is sent to the component owning the iif for a
   forwarding cache entry whenever the last oif is removed from the
   forwarding cache entry, and the iif is owned by another component. In
   PIM-DM, this may happen when:

      o  A PIM (S,G) Join/Prune message with S in the prune list is
         received on a point-to-point interface.
      o  The Oif-Timer in an (S,G) route table entry expires.
      o  A PIM (S,G) Assert message from a preferred neighbor is
         received on the interface.

   A (S,G) Join alert is sent to the component owning the iif for a
   forwarding cache entry whenever the first oif is added to an entry,
   and the iif is owned by another component.  In PIM-DM, this may
   happen when any of the following occur:

      o  The oif's prune timer expires, or
      o  A PIM-DM (S,G) Graft message is received on the interface, or
      o  IGMP notifies PIM-DM that directly-connected group members now
         exist on the interface.




Thaler                       Informational                     [Page 12]

RFC 2715                     Interop Rules                  October 1999


   When it is known that there are no longer any members of a group G in
   the PIM-DM domain which receive data for externally-reached sources
   from the local router, a (*,G) Prune alert is sent to the "iif owner"
   for (*,G) according to the dispatcher.  In PIM-DM, this may happen
   when:

      o  The DWR for G times out.
      o  The members-are-senders approximation is being used and PIM-
         DM's last (S,G) entry for G is timed out.

   When it is first known that there are members of a group G in the
   PIM-DM domain, a (*,G) Join alert is sent to the "iif owner" of
   (*,G), according to the dispatcher.  In PIM-DM, this may happen when
   either of the following occurs:

      o  A DWR is received for G.
      o  The members-are-senders approximation is being used and a data
         packet for G is received on one of the component's interfaces.

4.3.2.  Processing Alerts

   When a PIM-DM component receives an (S,G) Creation alert, it adds the
   component's interfaces to the entry's oif list (according to normal
   PIM-DM behavior) EXCEPT:

      o  the iif,
      o  leaf networks without local members of the entry's group,
      o  and interfaces with scoped boundaries covering the group.

   When a PIM-DM component receives an (S,G) Prune alert, and the
   forwarding cache entry's oiflist is empty, it sends a PIM-DM (S,G)
   Prune message to the upstream neighbor according to normal PIM-DM
   behavior.

   When a PIM-DM component receives a (*,G) or (*,*) Prune alert, it is
   treated as if an (S,G) Prune alert were received for every matching
   (S,G) entry.

   When a PIM-DM component receives an (S,G) Join alert, and an (S,G)
   prune was previously sent upstream, it sends a PIM-DM (S,G) Graft
   message to the upstream neighbor according to normal PIM-DM behavior.

   When a PIM-DM component receives a (*,G) or (*,*) Join alert, then
   for each matching (S,G) entry in the PIM-DM routing table for which a
   prune was previously sent upstream, it sends a PIM-DM (S,G) Graft
   message to the upstream neighbor according to normal PIM-DM behavior.
   In addition, if DWR's are being used, the component sends a DWR Join
   message within its domain.



Thaler                       Informational                     [Page 13]

RFC 2715                     Interop Rules                  October 1999


4.4.  PIM-SM

   In this section we describe how the rules in section 2 apply to
   Sparse-mode PIM.  We assume that the reader is familiar with normal
   PIM-SM behavior, as specified in [4].

   To achieve correct PIM-SM behavior within the domain, the PIM-SM
   domain MUST be convex so that Bootstrap messages reach all routers in
   the domain.  That is, the shortest-path route from any internal
   router to any other internal router must lie entirely within the PIM
   domain.

   Unless some form of Domain-Wide-Reports (DWRs) [10] are added to
   PIM-SM in the future, all PIM-SM components act as wildcard receivers
   for externally-reached sources.  If DWRs are available for the
   domain, then a PIM-SM component acts as a wildcard receiver for
   externally-reached sources only if internally-reached domains exist
   which do not support some form of DWRs.

   A PIM-SM component acts as a wildcard receiver for internally-reached
   sources if and only if any other component is a wildcard receiver for
   externally-reached sources.  It does this by periodically sending
   (*,*,RP) Joins to all RPs for non-local groups (for example,
   239.x.x.x is considered locally-scoped, and PIM-SM components do not
   send (*,*,RP) Joins to RPs supporting only that portion of the
   address space).  The period is set according to standard PIM-SM rules
   for periodic Join/Prune messages.

   To properly instantiate Rule 1, whenever PIM creates a PIM (S,G)
   entry for an externally-reached source, and the next hop towards S is
   reached via an interface owned by another component, the iif should
   always point towards S and not towards the RP for G.  In addition,
   the Border-bit is set in all PIM Register messages for this entry.

   Finally, the PIM-SM component acts as a DR for externally-reached
   receivers in terms of being able to switch to the shortest-path tree
   for internally-reached sources.

4.4.1.  Generating Alerts

   A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g.,
   the Interop dispatcher) when the first component becomes a wildcard
   receiver for external sources.  This may occur when a PIM-SM
   component starts up and decides to act in this role.







Thaler                       Informational                     [Page 14]

RFC 2715                     Interop Rules                  October 1999


   A (*,*) Prune alert is sent to the iif owner of the (*,*) entry
   (e.g., the Interop dispatcher) when all components are no longer
   wildcard receivers for external sources.  This may occur when a PIM-
   SM component which was acting in this role shuts down.

   A (S,G) Prune alert is sent to the component owning the iif for a
   forwarding cache entry whenever the last oif is removed from the
   entry and the iif is owned by another component.  In PIM-SM, this may
   happen when:

      o  A PIM (S,G) Join/Prune message with S in the prune list is
         received on a point-to-point interface, or
      o  A PIM (S,G) Assert from a preferred neighbor was received on
         the interface, or
      o  A PIM Register-Stop message is received for (S,G), or
      o  The interface's Oif-Timer for PIM's (S,G) route table entry
         expires.
      o  The Entry-Timer for PIM's (S,G) route table entry expires.

   When it is known that there are no longer any members of a group G in
   the PIM-SM domain which receive data for externally-reached sources
   from the local router, a (*,G) Prune alert is sent to the "iif owner"
   for (*,G) according to the dispatcher.  In PIM-SM, this may happen
   when:

      o  A PIM (*,G) Join/Prune message with G in the prune list is
         received on a point-to-point interface, or
      o  A PIM (*,G) Assert from a preferred neighbor was received on
         the interface, or
      o  IGMP notifies PIM-SM that directly-connected members no longer
         exist on the interface.
      o  The Entry-Timer for PIM's (*,G) route table entry expires.

   A (S,G) Join alert is sent to the component owning the iif for a
   forwarding cache entry whenever the first logical oif is added to an
   entry and the iif is owned by another component.  In PIM-SM, this may
   happen when any of the following occur:

      o  A PIM (S,G) Join/Prune message is received on the interface, or
      o  The Register-Suppression-Timer for (S,G) expires, or
      o  The Entry-Timer for an (S,G) negative-cache state route table
         entry expires.

   When it is first known that there are members of a group G in the
   PIM-SM domain, a (*,G) Join alert is sent to the "iif owner" of
   (*,G), according to the dispatcher.  In PIM-SM, this may happen when
   any of the following occur:




Thaler                       Informational                     [Page 15]

RFC 2715                     Interop Rules                  October 1999


      o  A PIM (*,G) Join/Prune message is received on the interface, or
      o  A PIM (*,*,RP) Join/Prune message is received on the interface,
         or
      o  (*,G) negative cache state expires, or
      o  IGMP notifies PIM that directly-connected group members now
         exist on the interface.

4.4.2.  Processing Alerts

   When a PIM-SM component receives an (S,G) Creation alert, it does a
   longest match search ((S,G), then (*,G), then (*,*,RP)) in its
   multicast routing table.  All outgoing interfaces of that entry are
   then added to the forwarding cache entry.  Unless the PIM-SM
   component owns the iif, the oiflist is also modified to support
   sending PIM Registers with the Border-bit set to the corresponding
   RP.

   When a PIM-SM component receives an (S,G) Prune alert, and the
   forwarding cache entry's oiflist is empty, then for each PIM (S,G)
   state entry covered, it sends an (S,G) Join/Prune message with S in
   the prune list to the upstream neighbor according to normal PIM-SM
   behavior.

   When a PIM-SM component receives a (*,G) Prune alert, it sends a
   (*,G) Join/Prune message with G in the prune list to the upstream
   neighbor towards the RP for G, according to normal PIM-SM behavior.

   When a PIM-SM component receives an (S,G) Join alert, it sends an
   (S,G) Join/Prune message to the next-hop neighbor towards S, and
   resets the (S,G) Entry-timer, according to normal PIM-SM behavior.

   When a PIM-SM component receives a (*,G) Join alert, then it sends a
   (*,G) Join/Prune message to the next-hop neighbor towards the RP for
   G, and resets the (*,G) Entry-timer, according to normal PIM-SM
   behavior.

   When a PIM-SM component receives a (*,*) Join alert, then it sends
   (*,*,RP) Join/Prune messages towards each RP.

   When a PIM-SM component receives a (*,*) Prune alert, then it sends a
   (*,*,RP) Prune towards each RP.










Thaler                       Informational                     [Page 16]

RFC 2715                     Interop Rules                  October 1999


4.5.  CBTv2

   In this section we describe how the rules in section 2 apply to
   CBTv2.  We assume that the reader is familiar with normal CBTv2
   behavior as specified in [5]. We note that, like MOSPF, CBTv2 allows
   joining and pruning entire groups, but not individual sources within
   groups.

   Interoperability between a single CBTv2 stub domain and a DVMRP
   backbone is outlined in [8].  Briefly, CBTv2 MBR components are
   statically configured such that, whenever an external route exists
   between two or more MBRs, one is designated as the primary, and the
   others act as non-forwarding (to prevent duplicate packets) backups.
   Thus, a CBTv2 domain must not serve as transit between two domains if
   another route between them exists.

   We now describe how a CBTv2 implementation may extend this to
   interoperate with all other multicast routing protocols.  A CBTv2
   component acts as a wildcard receiver for internally-reached sources
   if and only if any other component is a wildcard receiver for
   externally-reached sources.  It does this by sending JOIN-REQUESTs
   for all non-local group ranges to all known cores, as described in
   [8].

   Unless some form of Domain-Wide-Reports (DWRs) [10] are added to