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

Versions: 00 01 02

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

                                                          October 1997.


      Core Based Tree (CBT) Multicast Border Router Specification
                <draft-ietf-idmr-cbt-br-spec-00.txt>

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.


Abstract

   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.

   This draft assumes a CBT domain's multicast border routers have im-
   plemented Multicast BGP such that they can maintain ''come from'' (mul-
   ticast) paths that reflect local multicast policy. These may be inde-
   pendent of unicast (''go to'') paths and policy. Provision for this ca-
   pability 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'' [3]. Certain aspects of those rules
   may be interpreted and implemented differently, and therefore some
   discretion is left to the implementor.



Expires April 1998                                              [Page 1]


INTERNET-DRAFT      CBT Border Router Specification         October 1997


   This document assumes the reader is familiar with  the CBT protocol
   [4].



1.  Interoperability Model & Assumptions

   The interoperability model and mechanisms we present assume:

   +o    CBT domain's multicast border routers have implemented Multicast
        BGP 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.
        [If multicast BGP cannot be assumed, multicast "come from" paths
        must be statically configured].

   +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
        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 [5],
        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 [6])
        groups.

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

   +o    mixed multicast protocol LANs are not permitted.



Expires April 1998                                              [Page 2]


INTERNET-DRAFT      CBT Border Router Specification         October 1997


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


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


              Figure 1: Example Representation of a Border Router



2.  Overview

   CBT border routers (BRs) must implement Multicast BGP [1], enabling
   them to maintain "come from" (multicast) paths for particular source
   networks (or prefixes) that may be independent of the unicast ("go
   to") paths to those networks (or prefixes). This implies the specifi-
   cation of multicast policies that may be separate and independent of
   unicast policies 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.

   For transit CBT domains, each BR must belong to the "All Border
   Routers (ABR)" multicast group, which comprises a CBT tree spanning
   all the domain's border routers. This is necessary so that externally



Expires April 1998                                              [Page 3]


INTERNET-DRAFT      CBT Border Router Specification         October 1997


   sourced multicast traffic is able to transit the CBT domain. It is
   also used for propogating any control messages generated by the
   inter-domain multicast routing protocol between the inter-domain com-
   ponents of a domain's BRs.

   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). A domain's BRs
   discover internal <core, group> mappings either dynamically via a
   bootstrap mechanism [9] or statically (manual configuration). Each of
   a domain's BRs joins each (active) core router, thereby creating (*,
   core) state - this represents aggregated state for all groups using a
   particular core.

   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
   domains may be required to propogate external routes across the
   domain to neighbouring domains. The ABR multicast tree is used for
   this purpose.



3.  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
   the ABR tree, described earlier.



Expires April 1998                                              [Page 4]


INTERNET-DRAFT      CBT Border Router Specification         October 1997


   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 [2]. 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 [10]. In both examples, the CBT domain is assumed to be
   a transit domain.

   In the first example, assume one of the CBT domain's downstream BR's
   external components receives a source specific DVMRP "prune" message.
   This is propogated over the ABR tree and processed only by the Desig-
   nated Border Router (D-BR) for the specified source (S) - the D-BR is
   the upstream BR for the specified source (note: iBGP ensures that all
   BRs know which is the "injecting" BR for a particular source).

   To propogate the prune message to its external upstream neighbour,
   the D-BR for S must have received an S specific prune message from
   each of the domain's downstream BRs. If it has it may propogate the
   prune message. Otherwise, it simply caches from which downstream BRs
   it has recieved an S specific prune.

   In the second example, assume one of a domain's BR's external compo-
   nent receives an explicit join message from an external neighbouring
   domain.  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 is not the case, the explicit join is propogated to the BR
   that is upstream with respect to the root domain (gleaned from uni-
   cast routing), using the ABR tree. This BR is the D-BR (upstream BR)
   for this group on the shared tree.



4.  Longest Match Routing

   When data arrives at a BR, a longest match, i.e. (S, G) is first
   attempted using the shared forwarding cache.  For any (S, G) match,
   the data must arrive over the entry's incoming interface, else it is
   discarded. If the data arrives over the correct interface for S, a
   copy of the data packet is forwarded over each interface listed in
   the entry's outgoing interface list.

   If only (*, G) can be matched, a copy of the data pkt is forwarded
   over each interface listed in the entry except the incoming



Expires April 1998                                              [Page 5]


INTERNET-DRAFT      CBT Border Router Specification         October 1997


   interface.

   If no entry is found in the multicast forwarding cache, the data is
   discarded.



5.  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
   domains may be required to propogate external routes across the
   domain to neighbouring domains. The ABR multicast tree is used for
   this purpose.


   Acknowledgements

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

   <to be completed>



References

  [1] Multiprotocol Extensions for BGP-4; T. Bates et al.
  ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiproto-
  col-01.txt

  [2] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri;
  ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-dvmrp-v3-**.txt.
  Working draft, 1997.

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

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



Expires April 1998                                              [Page 6]


INTERNET-DRAFT      CBT Border Router Specification         October 1997


  [5]  IETF IDMR Working Group minutes, July 1995.
  (ftp://cs.ucl.ac.uk/darpa/IDMR/IETF-JUL95/idmr-minutes-july95.txt).

  [6] Administrative Scoping...

  [7] RFC 2117, Protocol Independent Multicast (PIM) Sparse Mode Speci-
  fication; D. Estrin et al; ftp://ds.internic.net/rfc/rfc2117.txt.
  August 1997.

  [8] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner;
  ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-v2-06.txt.
  Working draft, 1997. (to appear as RFC XXXX).

  [9] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Rout-
  ing; D. Estrin et al.; Technical Report, available from:
  http//netweb.usc.edu/pim

  [10] Grand Unified Multicast; D. Estin et al. (Editors);
  ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-gum-00.txt

  <to be completed>



























Expires April 1998                                              [Page 7]


INTERNET-DRAFT      CBT Border Router Specification         October 1997


Author Information:

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











































Expires April 1998                                              [Page 8]


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