Inter-Domain Multicast Routing (IDMR) A. Ballardie INTERNET-DRAFT Consultant October 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. 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 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 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. 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 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]