Core Based Trees (CBT) Multicast Routing Architecture
RFC 2201

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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