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]
