Inter-Domain Multicast Routing (IDMR) A. J. Ballardie INTERNET-DRAFT University College London April, 1996 Core Based Tree (CBT) Multicast Interoperability - Stage 1 Status of this Memo This document is an Internet Draft. Internet Drafts are working do- cuments 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 describes how a CBT-only stub domain can be attached to the Internet's multicast backbone (MBONE [1]). The mechanisms described allow the two domains to interoperate seamlessly, without requiring any special encapsulation. The extra functionality that en- ables interoperability is required only by border routers (BRs) on the boundary between the two domains. 1. Introduction CBT is a next-generation network layer multicast routing protocol currently being advanced through the IDMR working group [2] of the IETF. CBT builds a single delivery tree which is shared by both senders and receivers. Consequently, CBT's forwarding rules differ considerably from those of source-based tree schemes like DVMRP [3], the protocol currently deployed on the MBONE. Expires September, 1996 [Page 1] INTERNET-DRAFT CBT Interoperability - Stage 1 February 1996 Multicast interoperability is defined in various stages, the first stage being the attachment of non-DVMRP stub domains to the DVMRP backbone. Stage 1 interoperabilty mechanisms are currently being written for other multicast protocols such as PIM [4]. Subsequent stages (e.g. attaching a CBT transit domain to the backbone) will appear later when the near-term evolutionary model of the MBONE has been clearly defined and agreed upon by the participants of the IDMR working group. This work is currently in progress. This document then, defines interoperability between a CBT-only stub domain, and the Internet's multicast backbone, which deploys DVMRP. This document assumes the reader is familiar with both the CBT proto- col [5], and DVMRP [3], as well as IGMP [6]. NOTE: the use of the term "domain" throughout does not necessarily imply that such domains correspond to an underlying unicast domain. 2. Interoperability: Goals & Assumptions The three primary goals that the interoperability mechanisms described in this document set out to achieve, are that + no additional encapsulation should be required when passing mul- ticast data across the boundary between the CBT and backbone domains. + routing information flow across the domain boundary should be minimised. + the interoperability mechanisms should be simple so as to facil- itate easy deployment in a domain's border routers (BRs), which further facilitates efficiency in terms of forwarding multicast data across a domain boundary. The mechanisms we describe make minimal assumptions with regards to the available support mechanisms that complement a domain-oriented MBONE. Over the past year, the IDMR working group has made proposals which are geared towards evolving independent multicast domains, interconnected by way of a topological hierarchy (currently consist- ing of just two levels). For example, it has been proposed to segment the multicast address space into well-defined administrative scope ranges that roughly correspond to the current "TTL scopes" in DVMRP, and configure routers on those boundaries so that they know they Expires September, 1996 [Page 2] INTERNET-DRAFT CBT Interoperability - Stage 1 February 1996 define a particular administrative scope boundary. This would allow a domain's BRs to know whether to extend a domain-wide distribution tree into the wider area, and thus forward multicast data for the said group across the domain boundary, or not. To complement this proposals have been made to extend IGMP to include so-called domain- wide queries and reports, so that BRs can establish, dynamically, group presence within a domain. This document does not assume any of these mechanisms are present. If, at some stage in the future, these become available, this document will be modified accordingly. As a consequence of the absence of more automated domain-wide mechan- isms, border routers' behaviour largely reflects statically config- ured information. The next section describes in more detail what information needs to be configured at a CBT domain's border. 3. Interoperability Requirements To attach a CBT stub domain to the DVMRP backbone, the following are necessary: + border routers (BRs) are required, by definition, to deploy both CBT and DVMRP multicast routing protocols, with one protocol configured per interface. Both protocols are not permitted to run on the same interface. + an IPC (inter-process communication) communications channel must be established between the two routing daemons on any one router (see footnote 1). + a CBT domain boundary must have a so-called designated BR and backup designated BR (if available), both of which are elected statically (manually). The designated BR is the border router responsible for injecting data into and out of the CBT domain. It is also responsible for exporting _________________________ 1 an IPC communications channel is required by each BR, allowing internal communication between DVMRP, run- ning on the BR's interface to the backbone, and CBT, running on the interface inside the CBT domain. This channel is required for passing routes and multicast data between the CBT domain and the backbone. Expires September, 1996 [Page 3] INTERNET-DRAFT CBT Interoperability - Stage 1 February 1996 (selected) routes out of a CBT domain. Exterior (backbone) routes are not required by routers inside a CBT domain due to the nature of CBT forwarding. 4. Configured Border Router Information The following is a list of items that must be configured at a CBT domain's designated BR and backup designated BR: + group addresses that correspond to INTER-domain groups. + mappings. + designated BR (boolean). + backup designated BR present (boolean). With regards to mappings, the core(s) are internal to the CBT domain, but the corresponding group is of INTER-domain scope. It is expected that each core set (corelist) be used for several CBT trees inside the domain; exactly how many should be configurable. 5. Border Router Behaviour Border router behaviour is somewhat dependent on whether more than a single BR is present on the boundary of a domain; a typical stub domain has only one BR - this is the simple, and probably most typi- cal, case. However, some stubs may be multi-homed, and we discuss this in section 5.4. 5.1. Routing Information Flow This section deals with the exchange of routing information between a CBT domain and the backbone. Any route exchange that needs to take place does so via the IPC channel established between the different routing deamons within the same router, i.e. a CBT deamon passes routes to the DVMRP deamon, which then advertises them to the back- bone at whatever intervals the DVMRP protocol dictates. Expires September, 1996 [Page 4] INTERNET-DRAFT CBT Interoperability - Stage 1 February 1996 A CBT domain need never import routes from the backbone, since the nature of CBT forwarding does not require this information. The reverse is not true; the backbone requires routes from the CBT domain, so that, for traffic sourced inside the CBT domain, backbone DVMRP routers can correctly perform their RPF check, upon which their data forwarding decision is based. Note that it is not necessary for the designated BR to inject all routes into the backbone (although this should be the default behaviour). Since data flows out via the designated BR, depending on the underlying unicast protocol, the designated BR potentially knows from which internal subnetworks data is being sourced, and therefore could advertise only the routes to those subnetworks. Potentially, this could greatly reduce the flow of routing information across the interface from the designated BR's CBT deamon to its DVMRP deamon. 5.2. Joining INTER-domain Groups Any BR not prohibited from forwarding data across a CBT domain boun- dary must inspect a multicast data packet's source address before forwarding. This source address check must be performed on both inbound and outbound data packets; this is to prevent packet looping should a border router(s) become part of a delivery tree loop that originated on the backbone (CBTs are loop free inside a CBT domain). For a singly-homed stub CBT domain, data flows across the domain boundary via the designated BR. Therefore, the designated BR must join the internal CBT tree for each configured INTER-domain group; the corresponding core(s) are provided as part of the configured information. At BR initialisation, CBT joining could be fairly intense; to reduce internal overhead and preserve bandwidth, for INTER-domain groups sharing the same core set (corelist), only a single, aggregated CBT join need be sent. For this to be possible, the range of groups the aggregation represents must be a contiguous group address range, such that it can be specified with a CIDR-like mask. The "group mask" field, proceeding the "group identifier" field of a CBT control packet [5], is used to represent an aggregated CBT join. This field contains the value zero on non-aggregated joins. Expires September, 1996 [Page 5] INTERNET-DRAFT CBT Interoperability - Stage 1 February 1996 5.3. Data Flow Data is only injected into a domain provided that domain has group membership registered (configured) at the border for the correspond- ing group. Data flows into, and out of, a CBT domain via the desig- nated BR, provided the source address check, described above, is satisfied. The source address check at the BR is likely to degrade, CBT's normally high, forwarding performance. 5.4. Multi-Homed Stub CBT Domains If more than one of a CBT domain's BRs is attached to the DVMRP back- bone, we recommend the implementation of a backup designated BR, con- figured so as to mirror the designated BR. If any additional BRs are present, we recommend their across-boundary forwarding be disabled; we could implement forwarding optimizations that includes them, but the complexity of doing is probably not warranted for the stub domain case. Such optimizations will be investigated for Stage 2 Interopera- bility, which will be defined shortly. 5.4.1. Backup Designated Border Router The configured information of the backup designated BR must mirror that of the designated BR. The backup remains passive (i.e. it does not join any internal CBT trees, and it does not forward data across the domain boundary) unless the designated BR becomes unreachable. This implies reachability monitoring between the backup and desig- nated BR; this is implemented by means of a simple keepalive protocol (an extension to the CBT protocol [5]), whereby periodically (confi- gurable, default 2 mins), the backup sends a KEEPALIVE message to its peer, which responds with a KEEPALIVE-ACK. If, after some configur- able number of retries (default 3) at 30 second intervals, the desig- nated BR does not respond, the backup assumes the role of designated BR, joins any internal CBT trees, as per its configured information, and activates data packet forwarding. It may well be that a domain partition has occurred, and the desig- nated BR is still active and forwarding traffic on behalf of its par- tition; the activation of the backup serves the other partition. Thus, the presence of a backup designated router provides the CBT Expires September, 1996 [Page 6] INTERNET-DRAFT CBT Interoperability - Stage 1 February 1996 domain with added robustness and reliability. The backup continues unicasting KEEPALIVES to the designated BR periodically. If it becomes reachable again, the backup quits all internal CBT trees, disables forwarding, and other than sending periodic keepalives, resumes its otherwise passive role. 6. Summary This memo describes simple and efficient mechanisms required to attach a CBT-only stub domain to the Internet's multicast backbone (MBONE), which currently deploys DVMRP. These mechanisms need only be implemented by a CBT domain's border routers. What we describe allows for native multicast data flow into or out of a CBT domain, such that the forwarding rules of neither CBT or DVMRP are violated. No assumptions have been made as to the availability of domain- oriented multicast support features, such as those proposed recently (e.g. administratively scoped address, domain-wide IGMP messages); the described approach relies heavily on configured information, and this conforms to current operational capabilities. Acknowledgements Special thanks goes to Paul Francis, NTT Japan, for the original brainstorming sessions that led to the development of CBT. Thanks also to Ken Carlberg (SAIC), Eric Crawley (Bay Networks, Inc.), and other participants of the IDMR working group, for various comments and suggestions. References [1] MBONE, The Multicast BackbONE; M. Macedonia and D. Brutzman; available from http://www.cs.ucl.ac.uk/mice/mbone_review.html. [2] IDMR working group of the IETF, home page: http://www.cs.ucl.ac.uk/ietf/idmr [3] DVMRP. Described in "Multicast Routing in a Datagram Expires September, 1996 [Page 7] INTERNET-DRAFT CBT Interoperability - Stage 1 February 1996 Internetwork", S. Deering, PhD Thesis, 1990. Available via anonymous ftp from: gregorio.stanford.edu:vmtp/sd-thesis.ps. [4] D. Estrin et al. USC/ISI, Work in progress. (http://netweb.usc.edu/pim/). [5] A. Ballardie, N. Jain, and S. Reeve. Core Based Trees (CBT) Multi- cast: Protocol Specification; Work in progress, April 1996. [6] W. Fenner. Internet Group Management Protocol, version 2 (IGMPv2), (draft-idmr-igmp-v2-01.txt). Author Information: Tony Ballardie, Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, ENGLAND, U.K. Tel: ++44 (0)71 419 3462 e-mail: A.Ballardie@cs.ucl.ac.uk Expires September, 1996 [Page 8]