Core-Based Trees¶

A historic shared-tree IP-multicast routing architecture in which group receivers join toward a configured core router and traffic follows the resulting bidirectional distribution tree.

Version: v3 · 2026-09-19 · History
Domain-specific #: 1564
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Computer Networking → Computer Science & Software Engineering
Aliases: CBT, CBTv2, Core Based Tree multicast

Core Idea¶

Core-Based Trees (CBT) is a historic IP-multicast routing architecture that builds one shared bidirectional distribution tree per multicast group around a configured core router. A receiver-side router sends a join toward the core; routers along the path create group state and the branch attaches when it reaches the existing tree. Senders can inject traffic at an on-tree router, and packets follow the shared tree to receivers.^[1]

The recognition invariant is multicast group + selected core/rendezvous router + receiver-initiated joins + shared bidirectional tree + per-group on-tree state + protocol maintenance. RFC 2189 was Experimental and is now Historic; retention describes an important design identity, not a recommendation for contemporary deployment.

How would you explain it like I'm…

One Shared Message Tree

Imagine sending one message to lots of friends at once. Everyone agrees on one central meeting spot. Friends who want the messages make a path to that spot, and all the paths join into one big shared tree. Messages travel along the tree's branches to everyone who joined.

One Shared Group Tree

Core-Based Trees is an old way of sending internet messages to a whole group at once, called multicast. For each group, one special router is picked as the 'core,' like the trunk of a tree. When someone wants to receive the group's messages, their nearby router sends a 'join' message toward the core, and each router along the way remembers that it's part of the tree. The new branch stops as soon as it reaches a part of the tree that already exists. Anyone sending to the group puts the message onto the tree, and it flows along the branches in both directions to all the receivers. It's no longer recommended for use today but was an important design idea.

Shared Bidirectional Multicast Tree

Core-Based Trees (CBT) is a historic routing architecture for IP multicast, where one packet is delivered to every member of a group. Instead of building a separate tree from each sender, CBT builds one shared, bidirectional tree per group, centered on a configured core router. Receivers' routers send join requests toward the core; each router on the path records state for the group, and the new branch attaches when it hits the existing tree. A sender injects traffic at a router on the tree, and packets travel along the shared tree in both directions to reach receivers. Routers must keep per-group state and run protocol maintenance to keep the tree intact. The specification, RFC 2189, was Experimental and is now classified as Historic, so CBT matters as a design model rather than something to deploy now.

Core-Based Trees (CBT) is a historic IP-multicast routing architecture that constructs a single shared, bidirectional distribution tree per multicast group, rooted around a configured core (rendezvous) router. Tree construction is receiver-initiated: a receiver-side router sends a join toward the core, routers along the path instantiate per-group forwarding state, and the branch is grafted once the join reaches a router already on the tree. Senders inject packets at an on-tree router and traffic flows along the shared tree toward all receivers in both directions, rather than along per-source shortest-path trees. Its recognition invariant is the combination of a multicast group, a selected core router, receiver-initiated joins, a shared bidirectional tree, per-group on-tree state, and protocol maintenance of that tree. RFC 2189 specified it as Experimental and it is now Historic; its significance is as a design identity for shared-tree multicast, not a recommendation for contemporary deployment.

Structural Signature¶

IP multicast group and one active core for its shared tree.
Routers classified as on-tree or off-tree for that group.
Unicast routing information used to send control toward the core.
Receiver-driven JOIN_REQUEST and acknowledged branch formation.
Upstream direction toward the core and downstream away from it.
Shared bidirectional tree carrying traffic from multiple senders.
Per-group forwarding state on tree routers.
Parent/child interface relationships and loop-prevention checks.
QUIT, flush, echo/keepalive, and failure-recovery behavior.
Core discovery/bootstrap as an architectural dependency.
Scaling tradeoff: shared state versus potentially non-shortest paths.
Security/trust issues around control packets and core configuration.
Version/status boundary separating CBTv2 from other shared-tree protocols.

What It Is Not¶

CBT is not a B-tree or abstract graph-tree data structure. It is not source-specific shortest-path multicast, where every sender induces its own distribution tree. It is not simply “a network with a central server”: the core is a routing rendezvous and tree root, not necessarily the traffic source or application controller.

It is not PIM Sparse Mode, although both use shared-tree/rendezvous concepts. Their messages, state machines, switching behavior, and specifications differ. Nor should the term imply current standards-track status; the RFC Editor classifies RFC 2189 as Historic.^[1]

Scope of Application¶

CBT addressed scalable inter-domain or wide-area many-to-many multicast where source-specific state would grow poorly. Its shared tree made router state depend more on groups than on source–group pairs, at the cost of core dependence and paths that could be longer than source-rooted alternatives.^[2]

The architecture remains useful in protocol history, comparison of multicast tree designs, rendezvous placement research, routing-state analysis, and failure/security reasoning.

Clarity¶

The “core” is logically central to tree construction but need not be topologically central or aware that it was configured as a core. Version 2 specifies a single active core per group tree, even though broader descriptions sometimes speak loosely of multiple cores or candidate cores.^[1]

Bidirectional means traffic can enter the tree away from the core and traverse tree branches under protocol rules; it does not mean every physical link is simultaneously used in both directions.

Manages Complexity¶

The shared tree compresses many senders’ delivery state into one group structure. Routers need not maintain a separate shortest-path tree for every source, and receivers can attach by following existing unicast reachability toward a common rendezvous.

The compression transfers complexity to core selection, path stretch, single-tree failure consequences, bootstrap, and group-wide control consistency.

Abstract Reasoning¶

Define group, candidate core, active core, and administrative scope.
Trace a receiver’s join toward the core using unicast routing.
Mark where the join first intersects the existing tree.
Construct parent/child interface state along the new branch.
Trace sender traffic entering and traversing the tree.
Test duplicate suppression, loop prevention, and reverse-path conditions.
Analyze core, link, and router failure and state repair.
Compare state scaling and path stretch against source-rooted alternatives.
Preserve protocol-version and Historic-status boundaries.

Knowledge Transfer¶

The portable structure is rendezvous-centered shared traversal: many participants attach toward a common meeting point, and the union of attachment paths becomes the reusable delivery structure. The proposed immediate parent is Network Traversal.

Examples¶

Receiver join. A border router with a newly interested host sends JOIN_REQUEST toward the group core. Each traversed router records state; the first on-tree router returns acknowledgment, completing the branch.

Many senders. Several sources inject packets onto the same group tree, avoiding separate source trees but potentially sending some traffic over longer routes.

Non-example. A unicast spanning tree used only for loop avoidance is not CBT without multicast group joins, a core, and CBT state/messages.

Structural Tensions¶

Shared state economy versus path stretch.
Rendezvous simplicity versus core dependence.
Receiver-driven growth versus sender-independent traffic injection.
Stable group tree versus changing unicast routes.
Protocol history value versus obsolete deployment status.
Distributed routing versus configured core selection.

Structural–Framed Character¶

Rendezvous, join paths, tree state, traversal, and failure repair are structural. IP multicast addresses, CBT messages, router roles, timers, and RFC status are networking frame.

Structural Core vs. Domain Accent¶

The portable core is a shared tree grown by joining participants toward a rendezvous. Multicast groups, routers, unicast next hops, JOIN/QUIT packets, forwarding caches, bootstrap, and protocol status are constitutive domain accent.

This entry is a kind of Network Traversal.

Network Traversal is the broader abstraction this entry instantiates. Tree, Rendezvous, Aggregation, Shared State, Routing, and Failure Domain are related. B-Tree and SPQR Tree share only generic tree vocabulary.

Relationships to Other Abstractions¶

Current abstraction Core-Based Trees Domain-specific

Parents (1) — outgoing typed relations

Core-Based Trees is a kind of Network Traversal Prime

Network Traversal is the broader abstraction this entry instantiates.

Hierarchy path (1) — routes to 1 parentless root

Core-Based Trees → is a kind of Network Traversal → presupposes Network

Neighborhood in Abstraction Space¶

Core-Based Trees sits in a sparse region of the domain-specific corpus (99^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25

Not to Be Confused With¶

B-tree or other data-structure trees.
Source-specific multicast trees.
Protocol Independent Multicast Sparse Mode.
A centralized application server.
The generic graph-theoretic tree abstraction.
Current deployment guidance or a standards-track recommendation.

References¶

[1] Anthony Ballardie, RFC 2189: Core Based Trees (CBT version 2) Multicast Routing—Protocol Specification, Experimental, September 1997; later designated Historic. registry ↩a ↩b ↩c

[2] Anthony Ballardie, RFC 2201: Core Based Trees (CBT) Multicast Routing Architecture, Informational, September 1997. registry ↩

[3] Anthony Ballardie, Paul Francis, and Jon Crowcroft, “Core Based Trees (CBT): An Architecture for Scalable Inter-Domain Multicast Routing,” ACM SIGCOMM Computer Communication Review 23, no. 4 (1993): 85–95, DOI 10.1145/167954.166245. registry ↩

[4] Brian Quinn and Kevin Almeroth, RFC 3170: IP Multicast Applications: Challenges and Solutions, Informational, September 2001. registry ↩