rfc2715.txt

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

   CBTv2 in the future, all CBTv2 components act as wildcard receivers
   for externally-reached sources.  If DWRs are available for the
   domain, then a CBTv2 component acts as a wildcard receiver for
   externally-reached sources only if internally-reached domains exist
   which do not support some form of DWRs.

4.5.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.

   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.

   When the last oif is removed from the core tree for G, a (*,G) Prune
   alert is sent to the "iif owner" for (*,G) according to the
   dispatcher.  Since CBTv2 always sends all data to the core, the only
   time this can occur after the entry is created is when the MBR is the
   core.  In this case, the last oif is removed from the entry when:



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


      o  A QUIT-REQUEST is received on the logical interface, and there
         are no directly-connected members present on the interface, or
      o  IGMP notifies CBT that there are no longer directly-connected
         members present on the interface, and the interface is not a
         CBT child interface for group G.

   When the first CBT outgoing interface is added to an existing core
   tree, a (*,G) Join alert is sent to the "iif owner" of (*,G)
   according to the dispatcher.  Since CBTv2 always sends all data to
   the core, the only time these can occur, other than when the entry is
   created, is when the MBR is the core.  In this case, the first
   logical oif is added to an entry when:

      o  A JOIN-REQUEST for G is received on the interface, or
      o  IGMP notifies CBT that directly-connected group members now
         exist on the interface.

4.5.2.  Processing Alerts

   When a CBTv2 component receives an (S,G) Creation alert, and the
   router is functioning as the designated BR, any CBT interfaces which
   are on the tree for G are added to the forwarding cache entry's oif
   list (according to normal CBTv2 behavior).

   When a CBTv2 component receives an (S,G) Prune alert, the alert is
   ignored, since CBTv2 cannot prune specific sources.  Thus, it will
   continue to receive packets from S since it must receive packets from
   other sources in group G.

   When a CBTv2 component receives a (*,G) Prune alert, and the router
   is not the primary core for G, and the only CBT on-tree interface is
   the interface towards the core, it sends a QUIT-REQUEST to the next-
   hop neighbor towards the core, according to normal CBTv2 behavior.

   When a CBTv2 component receives either an (S,G) Join alert or a (*,G)
   Join alert, and the router is not the primary core for G, and the
   router is not already on the core-tree for G, it sends a CBT (*,G)
   JOIN-REQUEST to the next-hop neighbor towards the core, according to
   normal CBTv2 behavior.












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


4.6.  IGMP-only links

   In this section we describe how the rules in section 2 apply to a
   link which is not within any routing domain, and hence no routing
   protocol messages are exchanged and the interface is not owned by any
   multicast routing protocol component.  We assume that the reader is
   familiar with normal IGMP behavior as specified in [7].  We note that
   IGMPv2 allows joining and pruning entire groups, but not individual
   sources within groups.

   An IGMP-only "component" may only own a single interface; hence an
   IGMP-only domain only consists of a single link.  Since an IGMP-only
   component can only act as a wildcard receiver for internally-reached
   sources if all internally-reached sources are directly-connected,
   then either the IGMP-only domain (link) must be a stub domain, or
   else there must be no other components which are wildcard receivers
   for externally-reached sources.

4.6.1.  Generating Alerts

   When it is known that there are no longer any directly-connected
   members of a group G on the IGMP-only interface, a (*,G) Prune alert
   is sent to the "iif owner" for (*,G) according to the dispatcher.  In
   IGMP, this may happen when:

      o  The group membership times out.

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

      o  A Membership Report is received for G.

4.6.2.  Processing Alerts

   When an IGMP-only component receives an (S,G) Creation alert, and
   there are directly-connected members of G present on its interface,
   it adds the interface to the entry's oif list.

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

   When an IGMP-only component receives a (*,G) Prune alert, the router
   leaves the group G, sending an IGMP Leave message if it was the last
   reporter, according to normal IGMPv2 behavior.





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


   When an IGMP-only component receives a (*,*) Prune alert, it leaves
   promiscuous multicast mode.

   When an IGMP-only component receives either an (S,G) Join alert or a
   (*,G) Join alert, and the component was not previously a member of G
   on the IGMP-only interface (and the component is not a wildcard
   receiver for internally reached sources), it joins the group on the
   interface, causing it to send an unsolicited Membership Report
   according to normal IGMP behavior.

   When an IGMP-only component receives a (*,*) Join alert, it enters
   promiscuous multicast mode.

5.  Security Considerations

   All operations described herein are internal to multicast border
   routers.  The rules described herein do not change the security
   issues underlying individual multicast routing protcols.  Allowing
   different protocols to interact, however, means that security
   weaknesses of any particular protocol may also apply to the other
   protocols as a result.

6. References

   [1]   Ajit S. Thyagarajan and Stephen E. Deering.  Hierarchical
         distance-vector multicast routing for the MBone.  In
         "Proceedings of the ACM SIGCOMM", pages 60--66, October 1995.

   [2]   Pusateri, T., "Distance Vector Multicast Routing Protocol",
         Work in Progress.

   [3]   Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.

   [4]   Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
         Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
         "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
         Specification", RFC 2362, June 1998.

   [5]   Ballardie, A., "Core Based Trees (CBT version 2) Multicast
         Routing", RFC 2189, September 1997.

   [6]   Estrin, Farinacci, Helmy, Jacobson, and Wei, "Protocol
         Independent Multicast (PIM), Dense Mode Protocol
         Specification", Work in Progress.

   [7]   Fenner, W., "Internet Group Management Protocol, Version 2",
         RFC 2236, November 1997.




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


   [8]   Ballardie, A., "Core Based Tree (CBT) Multicast Border Router
         Specification", Work in Progress.

   [9]   Thaler, D., Estrin, D. and D. Meyer, "Border Gateway Multicast
         Protocol (BGMP): Protocol Specification", Work in Progress.

   [10]  Fenner, W., "Domain Wide Multicast Group Membership Reports",
         Work in Progress.

7.  Author's Address

   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]

































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


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Thaler                       Informational                     [Page 22]