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: v2 · 2026-09-06 · History
Domain-specific #: 1564
Origin domain: computer science
Subdomain: computer networking
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.

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.

Network Traversal is the proposed immediate parent. Tree, Rendezvous, Aggregation, Shared State, Routing, and Failure Domain are related. B-Tree and SPQR Tree share only generic tree vocabulary.

The prospective queue contains one strict edge to prime:network_traversal. No live DAG mutation is authorized.

Relationships to Other Abstractions¶

Current abstraction Core-Based Trees Domain-specific

Parents (1) — more general patterns this builds on

Core-Based Trees is a kind of Network Traversal Prime

Network Traversal is the proposed immediate parent.

Hierarchy path (1) — routes to 1 parentless root

Core-Based Trees → Network Traversal → Network → Reservoir-Flux Network → Conservation Laws → Invariance

Neighborhood in Abstraction Space¶

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

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

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 ↩