RFC 2715 (rfc2715) - Page 3 of 22

Interoperability Rules for Multicast Routing Protocols

RFC 2715                     Interop Rules                  October 1999


   o  Only one multicast routing protocol is active per interface (we do
      not consider mixed multicast protocol LANs).  Each interface on
      which multicast is enabled is thus "owned" by exactly one of the
      components.

   o  All components share a common forwarding cache of (S,G) entries,
      which are created when data packets are received, and can be
      deleted at any time.  Only the component owning an interface may
      change information about that interface in the forwarding cache.
      Each forwarding cache entry has a single incoming interface (iif)
      and a list of outgoing interfaces (oiflist).  Each component
      typically keeps a separate multicast routing table with any type
      of entries.

   Note that the guidelines in this document are implementation-
   independent.  The same rules given in Section 2 apply in some form,
   regardless of the implementation.  For example, they apply to each of
   the following architectural models:

   o  Single process (e.g., GateD): Several routing components in the
      same user-space process, running on top of a multicast-capable
      kernel.

   o  Multiple peer processes: Several routing components, each as a
      separate user-space process, all sitting on top of a multicast-
      capable kernel, with N*(N-1) interaction channels.

   o  Multiple processes with arbiter: Multiple independent peer routing
      component processes which interact with each other and with the
      kernel solely through an independent arbitration daemon.

   o  Monolith: Several routing components which are part of the
      "kernel" itself.

   We describe all interactions between components in terms of "alerts".
   The nature of an alert is implementation-dependent (e.g., it may
   consist of a simple function call, writing to shared memory, use of
   IPC, or some other method) but alerts of some form exist in every
   model. Similarly, the originator of an alert is also implementation-
   dependent; for example, alerts may be originated by a component
   effecting a change, by an independent arbiter, or by the kernel.

1.1.  Specification Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.




Thaler                       Informational