Core Based Trees (CBT) Multicast Routing Architecture
RFC 2201
|
Document |
Type |
|
RFC - Historic
(September 1997; No errata)
|
|
Author |
|
Anthony Ballardie
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2201 (Historic)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group A. Ballardie
Request for Comments: 2201 Consultant
Category: Experimental September 1997
Core Based Trees (CBT) Multicast Routing Architecture
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
CBT is a multicast routing architecture that builds a single delivery
tree per group which is shared by all of the group's senders and
receivers. Most multicast algorithms build one multicast tree per
sender (subnetwork), the tree being rooted at the sender's
subnetwork. The primary advantage of the shared tree approach is
that it typically offers more favourable scaling characteristics than
all other multicast algorithms.
The CBT protocol [1] is a network layer multicast routing protocol
that builds and maintains a shared delivery tree for a multicast
group. The sending and receiving of multicast data by hosts on a
subnetwork conforms to the traditional IP multicast service model
[2].
CBT is progressing through the IDMR working group of the IETF. The
CBT protocol is described in an accompanying document [1]. For this,
and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr
TABLE OF CONTENTS
1. Background................................................... 2
2. Introduction................................................. 2
3. Source Based Tree Algorithms................................. 3
3.1 Distance-Vector Multicast Algorithm...................... 4
3.2 Link State Multicast Algorithm........................... 5
3.3 The Motivation for Shared Trees.......................... 5
4. CBT - The New Architecture................................... 7
4.1 Design Requirements...................................... 7
4.2 Components & Functions................................... 8
4.2.1 CBT Control Message Retransmission Strategy........ 10
4.2.2 Non-Member Sending................................. 11
5. Interoperability with Other Multicast Routing Protocols ..... 11
Ballardie Experimental [Page 1]
RFC 2201 CBT Multicast Routing Architecture September 1997
6. Core Router Discovery........................................ 11
6.1 Bootstrap Mechanism Overview............................. 12
7. Summary ..................................................... 13
8. Security Considerations...................................... 13
Acknowledgements ............................................... 14
References ..................................................... 14
Author Information.............................................. 15
1. Background
Shared trees were first described by Wall in his investigation into
low-delay approaches to broadcast and selective broadcast [3]. Wall
concluded that delay will not be minimal, as with shortest-path
trees, but the delay can be kept within bounds that may be
acceptable. Back then, the benefits and uses of multicast were not
fully understood, and it wasn't until much later that the IP
multicast address space was defined (class D space [4]). Deering's
work [2] in the late 1980's was pioneering in that he defined the IP
multicast service model, and invented algorithms which allow hosts to
arbitrarily join and leave a multicast group. All of Deering's
multicast algorithms build source-rooted delivery trees, with one
delivery tree per sender subnetwork. These algorithms are documented
in [2].
After several years practical experience with multicast, we see a
diversity of multicast applications and correspondingly, a wide
variety of multicast application requirements. For example,
distributed interactive simulation (DIS) applications have strict
requirements in terms of join latency, group membership dynamics,
group sender populations, far exceeding the requirements of many
other multicast applications.
The multicast-capable part of the Internet, the MBONE, continues to
expand rapidly. The obvious popularity and growth of multicast means
that the scaling aspects of wide-area multicasting cannot be
overlooked; some predictions talk of thousands of groups being
present at any one time in the Internet.
We evaluate scalability in terms of network state maintenance,
bandwidth efficiency, and protocol overhead. Other factors that can
affect these parameters include sender set size, and wide-area
distribution of group members.
2. Introduction
Multicasting on the local subnetwork does not require either the
presence of a multicast router or the implementation of a multicast
Show full document text