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 <core, group> 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 <core, group> 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.
<to be completed>
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]
