[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Inter-Domain Multicast Routing (IDMR)                      A. Ballardie
INTERNET-DRAFT                                               Consultant

                                                          November 1997.

      Core Based Tree (CBT) Multicast Border Router Specification

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups. Note that other groups may also distribute work-
   ing documents as Internet Drafts).

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other In-
   ternet Draft.


   This document specifies the behaviour of a CBT multicast border
   router (BR) attaching a CBT multicast domain/region (stub or transit)
   to an inter-domain multicast tree, which may be source-rooted or
   shared, data driven or explicit join.

   This draft assumes a CBT domain's multicast border routers have im-
   plemented Multicast BGP (or other mechanism) such that they can main-
   tain ''come from'' (multicast) paths that reflect local multicast poli-
   cy. These may be independent of unicast (''go to'') paths and policy.
   Provision for this capability in BGP is described in [1].

   The document provides guidelines that are intended to be generally
   aligned with the mechanisms described in the ''Interoperability Rules
   for Multicast Routing Protocols'' [2]. Certain aspects of those rules
   may be interpreted and implemented differently, and therefore some
   discretion is left to the implementor.

Expires June 1998                                               [Page 1]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

   This document assumes the reader is familiar with  the CBT protocol

1.  Changes from Previous Revision

   +o    removed the need for the ABR group

   +o    provided reasons for 'a priori' creation of (*, core) state
        between active core routers and Border Routers (BRs)

   +o    explained the role and interaction (with examples) of DWRs

   +o    explained how source-specific inter-domain control messages are
        processed and propogated

2.  Interoperability Model & Assumptions

   The interoperability model and mechanisms we present assume:

   +o    CBT domain's multicast border routers have implemented Multicast
        BGP (or other mechanism, e.g. static configuration) such that
        they can maintain "come from" (multicast) paths that reflect
        local multicast policy. These may be independent of unicast ("go
        to") paths and policy.

   +o    logically, a BR has at least two "components", each component
        being associated with a particular multicast routing protocol.
        Each component may have more than one associated interface which
        is running the particular multicast protocol associated with the
        component. One of these components is a CBT component. Figure 1
        provides an example (logical) representation of a border router.

   +o    all components share a common multicast forwarding cache of
        (S,G) entries for the purpose of inter-domain multicast routing.
        S (source) may or may not be wildcarded (*) - if so, this
        denotes an inter-domain shared tree forwarding entry.

        To ensure that all components have a consistent view of the
        shared cache a BR's components must be able to communicate with
        each other; how is implementation dependent.  Additionally, each

Expires June 1998                                               [Page 2]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

        component may have a separate multicast forwarding cache spe-
        cific to that component's multicast routing protocol.

   +o    the presence of a domain-wide reporting (DWR) mechanism [4],
        enabling the dynamic and timely reporting of group joining and
        leaving inside a CBT domain to the domain's border routers. DWRs
        are only necessary for inter-domain scoped groups; they need not
        be sent for intra-domain scoped (administratively scoped [5])

   +o    CBT component(s) know <core, group> mappings of active groups
        present inside a CBT domain.

   +o    mixed multicast protocol LANs are not permitted.

   +o    The term "region" and "domain" are used interchangeably through-

                  |     |           |             |         |   |    X = component
                  |     | comp A    |             | comp B  |   |            interface
                  |     -------------             -----------   |
                  |                                             |    comp = component
                  |         -----------------------------       |
                  |         |     Shared Multicast      |       |
                  |         |   Forwarding Cache (S,G)  |       |
                  |         -----------------------------       |
                  |                                             |
                  |     ------------              ----------    |
                  |     |  comp C   |             | comp D  |   |
                  |     |           |             |         |   |

              Figure 1: Example Representation of a Border Router

3.  Overview

   CBT border routers (BRs) must implement Multicast BGP [1] (or other
   mechanism, e.g. static configuration), enabling them to maintain
   "come from" (multicast) paths for particular source networks (or pre-
   fixes) that may be independent of the unicast ("go to") paths to

Expires June 1998                                               [Page 3]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

   those networks (or prefixes). This implies the specification of mul-
   ticast policies that may be separate and independent of unicast poli-
   cies for a particular prefix. Multicast BGP is only implemented on a
   BR's inter-domain (external) component(s).

   These policies dictate over which (single) BR multicast traffic from
   a particular source is received over. This BR is known as the Desig-
   nated BR (D-BR) for that source (or prefix). Consequently, explicit
   D-BR election is not needed.  For any external network (or prefix),
   only the domain's elected designated border router for that network
   (or prefix) may import multicast data packets from that network (pre-
   fix) into the CBT domain.

   All BRs of all CBT domain types (transit and stub) must belong to
   each active CBT tree inside the domain. This is necessary so that
   externally sourced multicast traffic can be injected onto the correct
   internal distribution tree if group members exist inside the domain
   (as discovered by a domain-wide reporting mechanism). It also pro-
   vides a means for data traffic to transit the CBT domain irrespective
   of the presence of internal group members. Finally, it provides a
   means for getting internally sourced data to the domain's BRs so that
   it may be forwarded beyond the domain boundary (if appropriate).

   A domain's BRs discover internal <core, group> mappings either dynam-
   ically via a bootstrap mechanism [6] or statically (manual configura-

   At initialization time, each of a domain's BRs joins each (active)
   internal core router, thereby creating (*, core) state. This repre-
   sents aggregated state (one tree) for all groups using a particular
   core.  Setting up one tree per group could potentially result in a
   considerable amount of replicated state in the routers on a path
   between a core and a domain BR, which is why we opted for (*, core)
   state rather than (*, G) state. The 'a priori' tree building option
   was chosen because, for (inter-domain) data sourced inside a CBT
   domain, it is not possible to build tree branches from the relevant
   core to the BRs - currently, BRs discover cores, cores do not (cannot
   necessarily) discover BRs. Therefore, BR-core tree branches have to
   be built in advance.

   Internal routes are exported via each of a CBT domain's BRs (or route
   export may be limited to some subset of the domain's BRs, according
   to local policy).

   External routes need not be imported into a CBT domain for the

Expires June 1998                                               [Page 4]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

   purpose of multicast forwarding inside the domain. However, transit
   CBT domains may be required to propogate external routes across the
   domain to neighbouring domains. In the absence of iBGP [10] or simi-
   lar mechanism, an "all-border-routers" (ABR) group could be set up
   for this purpose.

4.  BR Component Interactions

   The precise nature of interactions between a border router's inter-
   domain (external) component(s) and the CBT (internal) component(s) is
   dependent on the inter-domain multicast protocol in use. Such inter-
   actions are therefore outside the scope of this draft.

   From the perspective of an inter-domain multicast tree, any domain
   belonging to the tree can be abstractly viewed as a single router
   with directly attached subnets (the domain's subnets). Control mes-
   sages generated by an inter-domain BR component are handled/inter-
   preted only by BR inter-domain components.  Continuing with our
   abstraction, if a particular inter-domain control message must be
   forwarded by our abstract router, it must be passed from one inter-
   face to another. In reality, this represents the propogation of the
   control message across the (CBT) domain, and this is achieved using
   iBGP, or unicast encapsulation, as appropriate.

   Let's take two different examples to expand our explanation: in the
   first example, the CBT domain is part of a source-rooted inter-domain
   multicast tree. The inter-domain multicast protocol is DVMRP [7]. In
   the second example, the CBT domain is part of an inter-domain shared
   tree (shared tree of domains), with the inter-domain multicast proto-
   col being GUM [8]. In both examples, the CBT domain is assumed to be
   a transit domain.

   In the first example, the inter-domain multicast protocol, DVMRP, is
   data driven.  When an externally sourced data packet arrives at a CBT
   domain BR, the BR external component decides whether to accept the
   packet or discard it. For any particular source, only one of the
   domain's BRs will accept the packet.

   If the packet is accepted, the BR forwards the packet over the rele-
   vant (*, core) tree branch, and any directly attached subnets with
   group member(s).  The BR also sends a DWR Report [4] for the group.

   If a CBT domain BR's external components receives a source specific

Expires June 1998                                               [Page 5]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

   DVMRP "prune" message, the BR decides whether to accept it. If it is
   accepted, it is sent (unicast) to the Designated Border Router (D-BR)
   for the specified source (S) - the D-BR is the upstream (injecting)
   BR for the specified source. The BR also sends a DWR Leave message
   for the group, which may be suppressed if either a) internal group
   member(s) exist, or b) there exists at least one domain BR which is
   not yet able to send a DWR Leave message [4] after previously sending
   a DWR Report (join) message - either data is still arriving, or the
   group forwarding state timer for S has not yet expired.

   If the D-BR for S (its external component) is satisfied there exist
   no internal group members, and there are no downstream interested
   receivers (gleaned from the DWR mechanism), the D-BR can propogate
   the DVMRP prune message to its external upstream neighbour wrt S.

   Now with the second example, assume one of a domain's BR's external
   components receives an explicit join message from an external neigh-
   bouring domain.  The receipt of an explicit join triggers the sending
   of a DWR Report inside the domain for the specified group, G.

   If the included group address falls within a group prefix indicating
   this domain is the group's root domain, the explicit join need not be
   propogated further.

   If this domain is not the root domain for G, the explicit join is
   unicast to the domain BR that is upstream with respect to the root
   domain. This BR is the D-BR (upstream BR) for this group on the
   shared tree.  The D-BR propogates the join to its external upstream
   neighbour wrt G.

   The processing rules following the receipt of a "prune" message by a
   CBT domain's external BR component are exactly the same as those
   described for the first example, with the addition that there are (*,
   G) prunes to consider as well as (S, G) prunes.

4.1.  Propogation of (S, G) Joins/Prunes

   As described above, control messages generated or received by a
   domain's BR external component(s) are only processed by BR external
   components. This makes it possible for CBT domains to correctly pro-
   cess source-specific control messages. These messages can effect
   changes to a BR's shared forwarding cache, which consists of (S, G)

Expires June 1998                                               [Page 6]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

   In this draft we have assumed that each of a multicast domain's BRs
   maintains a Multicast RIB [1] - we do not mandate how the information
   in this RIB is discovered, but one possibility is the use of BGP-4+
   [1].  Whatever the mechanism, a BR knows which of the multicast
   domain's BRs is injecting for which sources (prefixes).

   This information makes it easy to process source-specific control
   messages, such as (S, G) joins/prunes - the message is processed by
   the receiving BR, then unicast to the injecting BR for S (i.e. the D-
   BR for S).

5.  CBT Domain Core Placement with Inter-Domain BGMP/GUM

   For the case where BGMP is deployed as the inter-domain multicast
   protocol, it may be beneficial to place a CBT domain's core routers
   at the domain boundary such that the groups that map to a particular
   core router correspond to those that map to a particular domain. This
   preferences inter-domain multicast packet distribution - the paths
   between any receivers inside the CBT domain may be sub-optimal due to
   the positioning of the core on the domain boundary. However, this may
   not have a significant impact on performance inside the domain.

   Implicit in Boundary Router core positioning is that most/all exter-
   nally sourced multicast packets arrive via the root-domain. If this
   is not the case (e.g. an (S, G) join was previously forwarded by the
   CBT domain BRs creating (S, G) state in the BR external components)
   packet distribution and performance inside the CBT domain is impacted
   no differently than when a packet is sourced inside the domain and
   there exist internal group member(s).

   Unlike the PIM [9] case, irrespective of core router positioning, no
   encapsulation is necessary inside the CBT domain.

6.  Routing Information Flow

   Internal routes are exported via each of a CBT domain's BRs (or route
   export may be limited to some subset of the domain's BRs, according
   to local policy).

   External routes need not be imported into a CBT domain for the pur-
   pose of multicast forwarding inside the domain. However, transit CBT

Expires June 1998                                               [Page 7]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

   domains may be required to propogate external routes across the
   domain to neighbouring domains. iBGP or similar alternate mechanism
   is used for this purpose.


   Special thanks goes to Paul Francis, NTT Japan, for the original
   brainstorming sessions that led to the development of CBT.

   <to be completed>


  [1] Multiprotocol Extensions to BGP-4; T. Bates et al.

  [2] Interoperability Rules for Multicast Routing Protocols; D. Thaler;
  ftp://home.merit.edu/pub/users/thalerd/interop.ps; November 1996.

  [3] Core Based Trees (CBT) Multicast Routing: Protocol Specification;
  A.  Ballardie; RFC 2189; ftp://ds.internic.net/rfc/rfc2189.txt.
  September 1997.

  [4] Domain Wide Multicast Group Membership Reports; W. Fenner; Dis-
  tributed to the IDMR mailing list, November 1997. To appear as a Work-
  ing Draft.

  [5] ftp://ds.internic.net/internet-drafts/draft-finlayson-ttl-admin-
  scope-00.txt; R. Finlayson; Working Draft, March 1997.

  [6] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Rout-
  ing; D. Estrin et al.; Technical Report, available from:

  [7] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri;
  Working draft, 1997.

  [8] Grand Unified Multicast (GUM); D. Thaler, D. Estrin, and D. Meyer
  (Editors); ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-
  gum-01.txt; Working Draft, October 1997.

Expires June 1998                                               [Page 8]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

  [9] Protocol Independent Multicast (PIM) Sparse Mode Specification; D.
  Estrin et al; RFC 2117; ftp://ds.internic.net/rfc/rfc2117.txt.  August

  [10] A Border Gateway Protocol 4 (BGP-4); Y. Rekhter and T. Li; RFC
  1771, March 1995.  ftp://ds.internic.net/rfc/rfc1771.txt

Expires June 1998                                               [Page 9]

INTERNET-DRAFT      CBT Border Router Specification        November 1997

Author Information:

   Tony Ballardie,
   Research Consultant.
   e-mail: ABallardie@acm.org

Expires June 1998                                              [Page 10]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/