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. 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, 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 [3]. 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]) groups. +o CBT component(s) know 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- 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 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 mappings either dynam- ically via a bootstrap mechanism [6] or statically (manual configura- tion). 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) entries. 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. 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 to BGP-4; T. Bates et al. ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiproto- col-01.txt [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: http//netweb.usc.edu/pim [7] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-dvmrp-v3-**.txt. 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 1997. [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]