rfc2715.txt

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

Network Working Group                                           D. Thaler
Request for Comments: 2715                                      Microsoft
Category: Informational                                      October 1999


         Interoperability Rules for Multicast Routing Protocols

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   The rules described in this document will allow efficient
   interoperation among multiple independent multicast routing domains.
   Specific instantiations of these rules are given for the DVMRP,
   MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well
   as for IGMP-only links.  Future versions of these protocols, and any
   other multicast routing protocols, may describe their
   interoperability procedure by stating how the rules described herein
   apply to them.

1.  Introduction

   To allow sources and receivers inside multiple autonomous multicast
   routing domains (or "regions") to communicate, the domains must be
   connected by multicast border routers (MBRs).  To prevent black holes
   or routing loops among domains, we assume that these domains are
   organized into one of the following topologies:

   o  A tree (or star) topology (figure 1) with a backbone domain at the
      root, stub domains at the leaves, and possibly "transit" domains
      as branches between the root and the leaves.  Each pair of
      adjacent domains is connected by one or more MBRs.  The root of
      each subtree of domains receives all globally-scoped traffic
      originated anywhere within the subtree, and forwards traffic to
      its parent and children where needed.  Each parent domain's MBR
      injects a default route into its child domains, while child
      domains' MBRs inject actual (but potentially aggregated) routes
      into parent domains.  Thus, the arrows in the figure indicate both
      the direction in which the default route points, as well as the
      direction in which all globally-scoped traffic is sent.



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


                                 +--------+
                          +----|        |----+
          +---+    +---+  |  ===>      <===  |
          |   |    |   |  +----|   #    |----+
          |   |    | # |     +-----#------+
          | # |  +---#-------|     v      |-----------+
         +--#----|   v       |            |           |-----+
         |  v  ===>        ===> Backbone <===        <===   |
         +-------|   ^       |            |     ^     |-----+
                 +---#-------|     ^      |-----#-----+
                   | # |     +-----#------+ |   #    |-----+
                   |   |       |   #    |   |       <===   |
                   +---+   +---|        |   |        |-----+
                           | ===>       |   +--------+
                           +---+--------+

                 Figure 1: Tree Topology of Domains

   o  An arbitrary topology, in which a higher level (inter-domain)
      routing protocol, such as HDVMRP [1] or BGMP [9], is used to
      calculate paths among domains.  Each pair of adjacent domains is
      connected by one or more MBRs.

   Section 2 describes rules allowing interoperability between existing
   multicast routing protocols [2,3,4,5,6], and reduces the
   interoperability problem from O(N^2) potential protocol interactions,
   to just N (1 per protocol) instantiations of the same set of
   invariant rules.  This document specifically applies to Multicast
   Border Routers (MBRs) which meet the following assumptions:

   o  The MBR consists of two or more active multicast routing
      components, each running an instance of some multicast routing
      protocol.  No assumption is made about the type of multicast
      routing protocol (e.g., broadcast-and-prune vs. explicit-join) any
      component runs, or the nature of a "component".  Multiple
      components running the same protocol are allowed.

   o  The router is configured to forward packets between two or more
      independent domains.  The router has one or more active interfaces
      in each domain, and one component per domain.  The router also has
      an inter-component "alert dispatcher", which we cover in Section
      3.









Thaler                       Informational                      [Page 2]

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                      [Page 3]

RFC 2715                     Interop Rules                  October 1999


2.  Requirements

   To insure that a MBR fitting the above assumptions exhibits correct
   interdomain routing behavior, each MBR component MUST adhere to the
   following rules:

   Rule 1: All components must agree on which component owns the
           incoming interface (iif) for a forwarding cache entry. This
           component, which we call the "iif owner" is determined by the
           dispatcher (see Section 3).  The incoming component may
           select ANY interface it owns as the iif according to its own
           rules.

   When a routing change occurs which causes the iif to change to an
   interface owned by a different component, both the component
   previously owning the entry's iif and the component afterwards owning
   the entry's iif MUST notice the change (so the first can prune
   upstream and the second can join/graft upstream, for example).
   Typically, noticing such changes will happen as a result of normal
   protocol behavior.

   Rule 2: The component owning an interface specifies the criteria for
           which packets received on that interface are to be accepted
           or dropped (e.g., whether to perform an RPF check, and what
           scoped boundaries exist on that interface).  Once a packet is
           accepted, however, it is processed according to the
           forwarding rules of all components.

   Furthermore, some multicast routing protocols (e.g. PIM) also require
   the ability to react to packets received on the "wrong" interface. To
   support these protocols, an MBR must allow a component to place any
   of its interfaces in "WrongIf Alert Mode".  If a packet arrives on
   such an interface, and is not accepted according to Rule 2, then the
   component owning the interface MUST be alerted [(S,G) WrongIf alert].
   Typically, WrongIf alerts must be rate-limited.

   Rule 3: Whenever a new (S,G) forwarding cache entry is to be created
           (e.g., upon accepting a packet destined to a non-local
           group), all components MUST be alerted [(S,G) Creation alert]
           so that they can set the forwarding state on their own
           outgoing interfaces (oifs) before the packet is forwarded.

   Note that (S,G) Creation alerts are not necessarily generated by one
   of the protocol components themselves.







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


   Rule 4: When a component removes the last oif from an (S,G)
           forwarding cache entry whose iif is owned by another
           component, or when such an (S,G) forwarding cache entry is
           created with an empty oif list, the component owning the iif
           MUST be alerted [(S,G) Prune alert] (so it can send a prune,
           for example).

   Rule 5: When the first oif is added to an (S,G) forwarding cache
           entry whose iif is owned by another component, the component
           owning the iif MUST be alerted [(S,G) Join alert] (so it can
           send a join or graft, for example).

   The oif list in rules 4 and 5 must also logically include any virtual
   encapsulation interfaces such as those used for tunneling or for
   sending encapsulated packets to an RP/core.

   Rule 6: Unless a component reports the aggregate group membership in
           the direction of its interfaces, it MUST be a "wildcard
           receiver" for all sources whose RPF interface is owned by
           another component ("externally-reached" sources).  In
           addition, a component MUST be a "wildcard receiver" for all
           sources whose RPF interface is owned by that component
           ("internally-reached" sources) if any other component of the
           MBR is a wildcard receiver for externally-reached sources;
           this will happen naturally as a result of Rule 5 when it
           receives a (*,*) Join alert.

   For example, if the backbone does not keep global membership
   information, all MBR components in the backbone in a tree topology of
   domains, as well as all components owning the RPF interface towards
   the backbone are wildcard receivers for externally-reached sources.

   MBRs need not be wildcard receivers (for internally- or externally-
   reached sources) if a higher-level routing protocol, such as BGMP, is
   used for routing between domains.

2.1.  Deleting Forwarding Cache Entries

   Special care must be taken to follow Rules 4 and 5 when forwarding
   cache entries can be deleted at will.  Specifically, a component must
   be able to determine when the combined oiflist for (S,G) goes from
   null to non-null, and vice versa.

   This can be done in any implementation-specific manner, including,
   but not limited to, the following possibilities:






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


   o  Whenever a component would modify the oiflist of a single
      forwarding cache entry if one existed, one is first created.  The
      oiflist is then modified and Rules 4 and 5 applied after an (S,G)
      Creation alert is sent to all components and all components have
      updated the oiflist.  OR,

   o  When a forwarding cache entry is to be deleted, a new alert [(S,G)
      Deletion alert] is sent to all components, and the entry is only
      deleted if all components then grant permission.  Each component
      could then grant permission only if it had no (S,G) route table
      entry.

2.2.  Additional Recommendation

   Using (*,G) Join alerts and (*,G) Prune alerts can reduce bandwidth
   usage by avoiding broadcast-and-prune behavior among domains when it
   is unnecessary.  This optimization requires that each component be
   able to determine which other components are interested in any given
   group.

   Although this may be done in any implementation-dependent method, one
   example would be to maintain a common table (which we call the
   Component-Group Table) indexed by group-prefix, listing which