rfc2715.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

   components are interested in each group(prefix).  Thus, any
   components which are wildcard receivers for externally-reached
   sources (i.e., those whose RPF interface is owned by another
   component) would be listed in all entries of this table, including a
   default entry.  This table is thus loosely analogous to a forwarding
   cache of (*,G) entries, except that no distinction is made between
   incoming and outgoing interfaces.

3.  Alert Dispatchers

   We assume that each MBR has an "alert dispatcher".  The dispatcher is
   responsible for selecting, for each (S,G) entry in the shared
   forwarding cache, the component owning the iif.  It is also
   responsible for selecting to which component(s) a given alert should
   be sent.

3.1.  The "Interop" Dispatcher

   We describe here rules that may be used in the absence of any inter-
   domain multicast routing protocol, to enable interoperability in a
   tree topology of domains.  If an inter-domain multicast routing
   protocol is in use, another dispatcher should be used instead.  The
   Interop dispatcher does not own any interfaces.





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


   To select the iif of an (S,G) entry, the iif owner is the component
   owning the next-hop interface towards S in the multicast RIB.

   The "iif owner" of (*,G) and (*,*) entries is the Interop dispatcher
   itself.  This allows the Interop dispatcher to receive relevant
   alerts without owning any interfaces.

3.1.1.  Processing Alerts

   If the Interop dispatcher receives an (S,G) Creation alert, it adds
   no interfaces to the entry's oif list, since it owns none.

   When the Interop dispatcher receives a (*,G) Prune alert, the
   following actions are taken, depending on the number of components N
   which want to receive data for G.  If N has just changed from 2 to 1,
   a (*,G) Prune alert is sent to the remaining component. If N has just
   changed from 1 to 0, a (*,G) Prune alert is sent to ALL components
   other than the 1.

   When the Interop dispatcher receives a (*,G) Join alert, the
   following actions are taken, depending on the number of components N
   which want to receive data for G.  If N has just changed from 0 to 1,
   a (*,G) Join alert is sent to ALL components other than the 1.  If N
   has just changed from 1 to 2, a (*,G) Join alert is sent to the
   original (1) component.

3.2.  "BGMP" Dispatcher

   This dispatcher can be used with an inter-domain multicast routing
   protocol (such as BGMP) which allows global (S,G) and (*,G) trees.

   The iif owner of an (S,G) entry is the component owning the next-hop
   interface towards S in the multicast RIB.

   The iif owner of a (*,G) entry is the component owning the next-hop
   interface towards G in the multicast RIB.

3.2.1.  Processing Alerts

   This dispatcher simply forwards all (S,G) and (*,G) alerts to the iif
   owner of the associated entry.

4.  Multicast Routing Protocol Components

   In this section, we describe how the rules in section 2 apply to
   current versions of various protocols.  Future versions, and
   additional protocols, should describe how these rules apply in a
   separate document.



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


4.1.  DVMRP

   In this section we describe how the rules in section 2 apply to
   DVMRP.  We assume that the reader is familiar with normal DVMRP
   behavior as specified in [2].

   As with all broadcast-and-prune protocols, DVMRP components are
   automatically wildcard receivers for internally-reached sources.
   Unless some form of Domain-Wide-Reports (DWRs) [10] (synonymous with
   Regional-Membership-Reports as described in [1]) are added to DVMRP
   in the future, all DVMRP components also act as wildcard receivers
   for externally-reached sources.  If DWRs are available for the
   domain, then a DVMRP 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.1.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 DVMRP 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 DVMRP
   component which does not support some form of DWRs shuts down.

   An (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 DVMRP, this may
   happen when:

      o  A DVMRP (S,G) Prune message is received on the logical
         interface.

   An (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 DVMRP, this may
   happen when any of the following occur:





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


      o  The oif's prune timer expires, or
      o  A DVMRP (S,G) Graft message is received on the logical
         interface, or
      o  IGMP [7] notifies DVMRP that directly-connected members of G
         now exist on the interface.

   When it is known, for a group G, that there are no longer any members
   in the DVMRP 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 DVMRP, this may happen
   when:

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

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

      o  A DWR is received for G, or
      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.1.2.  Processing Alerts

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

      o  the iif,
      o  interfaces without local members of the entry's group, and for
         which DVMRP (S,G) Prune messages have been received from all
         downstream dependent neighbors.
      o  interfaces for which the router is not the designated forwarder
         for S,
      o  and interfaces with scoped boundaries covering the group.

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

   When a DVMRP component receives a (*,G) or (*,*) Prune alert, it is
   treated as if an (S,G) Prune alert were received for every existing
   DVMRP (S,G) entry covered.  In addition, if DWRs are being used, a
   DWR Leave message is sent within its domain.




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


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

   When a DVMRP component receives a (*,G) or (*,*) Join alert, it is
   treated as if an (S,G) Join alert were received for every existing
   DVMRP (S,G) entry covered.  In addition, if DWRs are being used, the
   component sends a DWR Join message within its domain.

4.2.  MOSPF

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

   Although interoperability between MOSPF and dense-mode protocols
   (such as DVMRP) is specified in [3], we describe here how an MOSPF
   implementation may interoperate with all other multicast routing
   protocols.

   An MOSPF 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.  An MOSPF component acts as a wildcard
   receiver for externally-reached sources only if internally-reached
   domains exist which do not support some form of Domain-Wide-Reports
   (DWRs) [10].  Since MOSPF floods membership information throughout
   the domain, MOSPF itself is considered to support a form of DWRs
   natively.

4.2.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 an MOSPF
   component starts up and decides to act in this role.

   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 an
   MOSPF component which was acting in this role shuts down.

   When it is known that there are no longer any members of a group G in
   the MOSPF domain, a (*,G) Prune alert is sent to the "iif owner" for
   (*,G) according to the dispatcher.  In MOSPF, this may happen when
   either:





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


      o  IGMP notifies MOSPF that there are no longer any directly-
         connected group members on an interface, or
      o  Any router's group-membership-LSA for G is aged out.

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

      o  IGMP notifies MOSPF that directly-connected group members now
         exist on the interface, or
      o  A group-membership-LSA is received for G.

4.2.2.  Processing Alerts

   When an MOSPF component receives an (S,G) Creation alert, it
   calculates the shortest path tree for the MOSPF domain, and adds the
   downstream interfaces to the entry's oif list according to normal
   MOSPF behavior.

   When an MOSPF component receives an (S,G) Prune alert, the alert is
   ignored, since MOSPF can only prune entire groups at a time.

   When an MOSPF component receives a (*,G) Prune alert, and there are
   no directly-connected members on any MOSPF interface, the router
   "prematurely ages" out its group-membership-LSA for G in the MOSPF
   domain according to normal MOSPF behavior.

   When an MOSPF component receives either an (S,G) Join alert or a
   (*,G) Join alert, and G was not previously included in the router's
   group-membership-LSA (and the component is not a wildcard multicast
   receiver), it originates a group-membership-LSA in the MOSPF domain
   according to normal MOSPF behavior.

   When an MOSPF component receives a (*,*) Prune alert, it ceases to be
   a wildcard multicast receiver in its domain.

   When an MOSPF component receives a (*,*) Join alert, it becomes a
   wildcard multicast receiver in its domain.

4.3.  PIM-DM

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






Thaler                       Informational                     [Page 11]