INTERNET-DRAFT
Network Working Group                                          T. Maufer
Expire in six months
Internet-Draft                                                C. Semeria
Category: Informational                                 3Com Corporation
                                                              March
Expire in six months                                           July 1997

                   Introduction to IP Multicast Routing

            <draft-ietf-mboned-intro-multicast-02.txt>
                 <draft-ietf-mboned-intro-multicast-03.txt>

Status of this Memo

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups.  Note that other groups may also distribute working
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."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the internet-drafts Shadow
Directories on:

    ftp.is.co.za                (Africa)
    nic.nordu.net               (Europe)
    ds.internic.net      (US East Coast)
    ftp.isi.edu          (US West Coast)
    munnari.oz.au          (Pacific Rim)

ABSTRACT

The first part of this paper describes the benefits of multicasting,
the MBone, Class D addressing, and the operation of the Internet Group
Management Protocol (IGMP).  The second section explores a number of
different techniques that may potentially be employed by multicast
routing protocols:

    o  Flooding
    o  Spanning Trees
    o  Reverse Path Broadcasting (RPB)
    o  Truncated Reverse Path Broadcasting (TRPB)
    o  Reverse Path Multicasting (RPM)
    o  ''Shared-Tree'' Techniques

The third part contains the main body of the paper.  It describes how
the previous techniques are implemented in multicast routing protocols
available today (or under development).

    o  Distance Vector Multicast Routing Protocol (DVMRP)
    o  Multicast Extensions to OSPF (MOSPF)
    o  Protocol-Independent Multicast - Dense Mode (PIM-DM)
    o  Protocol-Independent Multicast - Sparse Mode (PIM-SM)
    o  Core-Based Trees (CBT)

FOREWORD

This document is introductory in nature.  We have not attempted to
describe every detail of each protocol, rather to give a concise
overview in all cases, with enough specifics to allow a reader to grasp
the essential details and operation of protocols related to multicast
IP.  Every effort has been made to ensure the accurate representation of
any cited works, especially any works-in-progress.  For the complete
details, we refer you to the relevant specification(s).

If internet-drafts are were cited in this document, it is only because they
are
were the only sources of certain technical information at the time of
this writing.  We expect that many of the internet-drafts which we have

cited will eventually become RFCs.  See the IETF's internet-drafts
shadow directories above for the status of any of these drafts, their follow-on follow-
on drafts, or possibly the resulting RFCs.

ABSTRACT

The first part of this paper describes the benefits of multicasting,
the MBone, Class D addressing, and the operation of the Internet

                          TABLE OF CONTENTS
Section

1  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  INTRODUCTION
1.1  . . . . . . . . . . . . . . . . . . . . . . . . .  Multicast Groups
1.2  . . . . . . . . . . . . . . . . . . . . . Group
Management Protocol (IGMP).  The second section explores a number of
different techniques that may potentially be employed by multicast
routing protocols:

    o  Flooding
    o  Spanning Trees
    o  Reverse Path Broadcasting (RPB)
    o  Truncated Reverse Path Broadcasting (TRPB)
    o  Reverse Path Multicasting (RPM)
    o  "Shared-Tree" Techniques

The third part contains the main body of the paper.  It describes how
the previous techniques are implemented in multicast routing protocols
available today (or under development).

    o  Distance Vector Multicast Routing Protocol (DVMRP)
    o  Multicast Extensions to OSPF (MOSPF)
    o  Protocol-Independent Multicast - Dense Mode (PIM-DM)
    o  Protocol-Independent Multicast - Sparse Mode (PIM-SM)
    o  Core-Based Trees (CBT)

                          Table of Contents
Section

1  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  INTRODUCTION
1.1  . . . . . . . . . . . . . . . . . . . . . . . . .  Multicast Groups
1.2  . . . . . . . . . . . . . . . . . . . . . Group Membership Membership Protocol
1.3  . . . . . . . . . . . . . . . . . . . . Multicast Routing Protocols
1.3.1  . . . . . . . . . . .  Multicast Routing vs. Multicast Forwarding
2  . . . . . . . .  MULTICAST SUPPORT FOR EMERGING INTERNET APPLICATIONS
2.1  . . . . . . . . . . . . . . . . . . . . . . . Reducing Network Load
2.2  . . . . . . . . . . . . . . . . . . . . . . . .  Resource Discovery
2.3  . . . . . . . . . . . . . . .  Support for Datacasting Applications
3  . . . . . . . . . . . . . . THE INTERNET'S MULTICAST BACKBONE (MBone)
4  . . . . . . . . . . . . . . . . . . . . .  . . . MULTICAST ADDRESSING
4.1  . . . . . . . . . . . . . . . . . . . . . .  . .  Class D Addresses
4.2  . . . . . . .  Mapping a Class D Address to an IEEE-802 MAC Address
4.3  . . . . . . . . .  Transmission and Delivery of Multicast Datagrams
5  . . . . . . . . . . . . . . INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
5.1  . . . . . . . . . . . . . . . . . . . . . . . . . .  IGMP Version 1
5.2  . . . . . . . . . . . . . . . . . . . . . . . . . .  IGMP Version 2
5.3  . . . . . . . . . . . . . . . . . . . . . . . . . . IGMP Version 3 (Future)
6  . . . . . . . . . . . . . . . . . . . MULTICAST FORWARDING TECHNIQUES
6.1  . . . . . . . . . . . . . . . . . . . . . "Simpleminded" Techniques
6.1.1  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  Flooding
6.1.2  . . . . . . . . . . . . . . . . . . . . . . . . . .  Multicast Extensions to MAC-layer Spanning Tree Trees
6.2  . . . . . . . . . . . . . . . . . . .  Source-Based Tree Techniques
6.2.1  . . . . . . . . . . . . . . . . . Reverse Path Broadcasting (RPB)
6.2.1.1  . . . . . . . . . . . . .  Reverse Path Broadcasting: Operation
6.2.1.2  . . . . . . . . . . . . . . . . . RPB: Benefits and Limitations
6.2.2  . . . . . . . . . . .  Truncated Reverse Path Broadcasting (TRPB)
6.2.3  . . . . . . . . . . . . . . . . . Reverse Path Multicasting (RPM)
6.2.3.1  . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation
6.2.3.2  . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations
6.3  . . . . . . . . . . . . . . . . . . . . . .  Shared Tree Techniques
6.3.1  . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation
6.3.2  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  Benefits
6.3.3  . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations
7  . . . . . . . . . . . . . . . . . . .  "DENSE MODE" ROUTING PROTOCOLS
7.1  . . . . . . . .  Distance Vector Multicast Routing Protocol (DVMRP)
7.1.1  . . . . . . . . . . . . . . . . .  Physical and Tunnel Interfaces
7.1.2  . . . . . . . . . . . . . . . . . . . . . . . . . Basic Operation
7.1.3  . . . . . . . . . . . . . . . . . . . . .  DVMRP Router Functions
7.1.4  . . . . . . . . . . . . . . . . . . . . . . . DVMRP Routing Table
7.1.5  . . . . . . . . . . . . . . . . . . . . .  DVMRP Forwarding Table
7.1.6  . . . . . . . . . . .  DVMRP Tree Building and Forwarding Summary

7.2  . . . . . . . . . . . . . . .  Multicast Extensions to OSPF (MOSPF)
7.2.1  . . . . . . . . . . . . . . . . . . Intra-Area Routing with MOSPF
7.2.1.1  . . . . . . . . . . . . . . . . . . . . .  Local Group Database
7.2.1.2  . . . . . . . . . . . . . . . . . Datagram's Shortest Path Tree
7.2.1.3  . . . . . . . . . . . . . . . . . . . . . . .  Forwarding Cache
7.2.2  . . . . . . . . . . . . . . . . . . Mixing MOSPF and OSPF Routers
7.2.3  . . . . . . . . . . . . . . . . . . Inter-Area Routing with MOSPF
7.2.3.1  . . . . . . . . . . . . . . . . Inter-Area Multicast Forwarders
7.2.3.2  . . . . . . . . . . .  Inter-Area Datagram's Shortest Path Tree
7.2.4  . . . . . . . . . Inter-Autonomous System Multicasting with MOSPF
7.2.5  . . . . . . . . . . .  MOSPF Tree Building and Forwarding Summary
7.3  . . . . . . . . . . . . . . .  Protocol-Independent Multicast (PIM)
7.3.1  . . . . . . . . . . . . . . . . . . . . PIM - Dense Mode (PIM-DM)
7.3.1.1  . . . . . . . . . . PIM-DM Tree Building and Forwarding Summary
8  . . . . . . . . . . . . . . . . . . . "SPARSE MODE" ROUTING PROTOCOLS
8.1  . . . . . . . Protocol-Independent Multicast - Sparse Mode (PIM-SM)
8.1.1  . . . . . . . . . . . . . .  Directly Attached Host Joins a Group
8.1.2  . . . . . . . . . . . . Directly Attached Source Sends to a Group
8.1.3  . . . . . . .  Shared Tree (RP-Tree) or Shortest Path Tree (SPT)?
8.1.4  . . . . . . . . . . . . . . . . . . . . . . .   Unresolved Issues PIM-SM Tree Building and Forwarding Summary
8.2  . . . . . . . . . . . . . . . . . . . . . .  Core Based Trees (CBT)
8.2.1  . . . . . . . . . . . . . . . . . . Joining a Group's Shared Tree
8.2.2  . . . . . . . . . . . . . . . . . . . . .  Data Packet Forwarding
8.2.3  . . . . . . . . . . . . . . . . . . . . . . .  Non-Member Sending
8.2.4  . . . . . . . . . . . .  CBT Tree Building and Forwarding Summary
8.2.5  . . . . . . . . . . . . . . . . .  CBT Multicast Interoperability
9  . . . . . .  INTEROPERABILITY FRAMEWORK FOR . . . . . . . . . . MULTICAST BORDER ROUTERS IP ROUTING:  RELATED TOPICS
9.1  . . . . . . Interoperability Framework For Multicast Border Routers
9.1.1  . . . . . . . . . . . . Requirements for Multicast Border Routers
9.2  . . . . . . . . . . . . . . . . Issues with Expanding-Ring Searches
10  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REFERENCES
10.1  . . . . . . . . . . . . . . . . . . . Requests for Comments (RFCs)
10.2  . . . . . . . . . . . . . . . . . . . . . . . . .  Internet-Drafts
10.3  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  Textbooks
10.4  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  Other
11  . . . . . . . . . . . . . . . . . . . . . .  SECURITY CONSIDERATIONS
12  . . . . . . . . . . . . . . . . . . . . . . . . . . ACKNOWLEDGEMENTS
13  . . . . . . . . . . . . . . . . . . . . . . . . . AUTHORS' ADDRESSES

[This space was intentionally left blank.]

1. INTRODUCTION

There are three fundamental types of IPv4 addresses:  unicast,
broadcast, and multicast.  A unicast address is used to transmit a
packet to a single destination.  A broadcast address is used to send a
datagram to an entire subnetwork.  A multicast address is designed to
enable the delivery of datagrams to a set of hosts that have been
configured as members of a multicast group across various
subnetworks.

Multicasting is not connection-oriented.  A multicast datagram is
delivered to destination group members with the same "best-effort"
reliability as a standard unicast IP datagram.  This means that
multicast datagrams are not guaranteed to reach all members of a group,
nor to arrive in the same order in which they were transmitted.

The only difference between a multicast IP packet and a unicast IP
packet is the presence of a 'group address' in the Destination Address
field of the IP header.  Instead of a Class A, B, or C IP destination
address, multicasting employs a Class D address format, which ranges
from 224.0.0.0 to 239.255.255.255.

1.1 Multicast Groups

Individual hosts are free to join or leave a multicast group at any
time.  There are no restrictions on the physical location or the number
of members in a multicast group.  A host may be a member of more than
one multicast group at any given time and does not have to belong to a
group to send packets to members of a group.

1.2 Group Membership Protocol

A group membership protocol is employed by routers to learn about the
presence of group members on their directly attached subnetworks.  When
a host joins a multicast group, it transmits a group membership protocol
message for the group(s) that it wishes to receive, and sets its IP
process and network interface card to receive frames addressed to the
multicast group.  This receiver-initiated join process has excellent
scaling properties since, as the multicast group increases in size, it
becomes ever more likely that a new group member will be able to locate
a nearby branch of the multicast delivery tree.

[This space was intentionally left blank.]

========================================================================
                            _    _    _    _
                           |_|  |_|  |_|  |_|
                           '-'  '-'  '-'  '-'
                            |    |    |    |
                          <- - - - - - - - - ->
                                   |
                                   |
                                   v
                                Router
                                   ^
                                /     \
         _  ^                 +         +              ^  _
        |_|-|               /            \             |-|_|
        '_' |             +                +           | '_'
         _  |          v                     v         |  _
        |_|-|- - >|Router| <- + - + - + -> |Router|<- -|-|_|
        '_' |                                          | '_'
         _  |                                          |  _
        |_|-|                                          |-|_|
        '_' |                                          | '_'
            v                                          v

LEGEND

<- - - -> Group Membership Protocol
<-+-+-+-> Multicast Routing Protocol

Figure 1: Multicast IP Delivery Service
=======================================================================

1.3 Multicast Routing Protocols

Multicast routers execute a multicast routing protocol to define
delivery paths that enable the forwarding of multicast datagrams
across an internetwork.

1.3.1  Multicast Routing vs. Multicast Forwarding

Multicast routing protocols establish or help establish the distribution
tree for a given group, which enables multicast forwarding of packets
addressed to the group.  In the case of unicast, routing protocols are
also used to build a forwarding table (commonly called a routing table).

Unicast destinations are entered in the routing table, and associated
with a metric and a next-hop router toward the destination.  The key
difference between unicast forwarding and multicast forwarding is that
multicast packets must be forwarded away from their source.  If a packet
is ever forwarded back toward its source, a forwarding loop could have
formed, possibly leading to a multicast "storm."

Each routing protocol constructs a forwarding table

========================================================================
                           _    _    _    _
                          |_|  |_|  |_|  |_|
                          '-'  '-'  '-'  '-'
                           |    |    |    |
                         <- - - - - - - - - ->
                                  |
                                  |
                                  v
                               Router
                                ^  ^
                               /    \
                              +      +
         _  |                /        \               |  _
        |_|-|               +          +              |-|_|
        '_' |              /            \             | '_'
         _  |             v              v            |  _
        |_|-| - - ->|Router| <-+-+-+-> |Router|<- - - |-|_|
        '_' |                                         | '_'
         _  |                                         |  _
        |_|-|                                         |-|_|
        '_' |                                         | '_'
            |                                         |

LEGEND

<- - - -> Group Membership Protocol
<-+-+-+-> Multicast Routing Protocol

Figure 1: Multicast IP Delivery Service
=======================================================================

multicast packets must be forwarded away from their source.  If a packet
is ever forwarded back toward its source, a forwarding loop could have
formed, possibly leading to a multicast "storm."

Each routing protocol constructs a forwarding table in its own way; the way.  The
forwarding table tells may tell each router that for a certain source, or for
a given source sending to a certain group (called a (a (source, group) pair), or
for any source sending to some group, how to forward such packets.  This
may take the form of rules expecting certain packets are expected to arrive on a certain some
"inbound" or "upstream"
interface "upstream"interface, and must be copied to certain the (set of) "outbound" or "downstream" or
"outbound" interface(s) in order required to reach all known subnetworks with
group members.  Not all multicast routing protocols use the same style
forwarding state, and some use techniques not mentioned here.

2. MULTICAST SUPPORT FOR EMERGING INTERNET APPLICATIONS

Today, the majority of Internet applications rely on point-to-point
transmission.  The utilization of point-to-multipoint transmission has
traditionally been limited to local area network applications.  Over the
past few years the Internet has seen a rise in the number of new
applications that rely on multicast transmission.  Multicast IP
conserves bandwidth by forcing the network to do packet replication only
when necessary, and offers an attractive alternative to unicast
transmission for the delivery of network ticker tapes, live stock
quotes, multiparty videoconferencing, and shared whiteboard applications
(among others). It is important to note that the applications for IP
Multicast are not solely limited to the Internet.  Multicast IP can also
play an important role in large commercial internetworks.

2.1 Reducing Network Load

Assume that a stock ticker application is required to transmit packets
to 100 stations within an organization's network.  Unicast transmission
to this set of stations will require the periodic transmission of 100
packets where many packets may in fact be traversing the same link(s).
Multicast transmission is the ideal solution for this type of
application since it requires only a single packet stream to be
transmitted by the source which is replicated at forks in the multicast
delivery tree.

Broadcast transmission is not an effective solution for this type of
application since it affects the CPU performance of each and every
station that sees the packet.  Besides, it wastes bandwidth.

2.2 Resource Discovery

Some applications utilize multicast instead of broadcast transmission
to transmit packets to group members residing on the same subnetwork.
However, there is no reason to limit the extent of a multicast
transmission to a single LAN.  The time-to-live (TTL) field in the IP
header can be used to limit the range (or "scope") of a multicast
transmission.  "Expanding ring searches" are one often-cited generic
multicast application, and they will be discussed in detail once the
mechanisms used by each multicast routing protocol have been described.

2.3 Support for Datacasting Applications

Since 1992, the IETF has conducted a series of "audiocast" experiments
in which live audio and video were multicast from the IETF meeting site
to destinations around the world.  In this case, "datacasting" takes
compressed audio and video signals from the source station and transmits
them as a sequence of UDP packets to a group address.  Multicast
delivery today is not limited to audio and video.  Stock quote systems
are one example of a (connectionless) data-oriented multicast

application.  Someday reliable multicast transport protocols may
facilitate efficient inter-computer communication.  Reliable multicast
transport protocols are currently an active area of research and
development.

3. THE INTERNET'S MULTICAST BACKBONE (MBone)

The Internet Multicast Backbone (MBone) is an interconnected set of
subnetworks and routers that support the delivery of IP multicast
traffic.  The goal of the MBone is to construct a semipermanent IP
multicast testbed to enable the deployment of multicast applications
without waiting for the ubiquitous deployment of multicast-capable
routers in the Internet.

The MBone has grown from 40 subnets in four different countries in 1992,
to more than 3400 4300 subnets in over 25 countries worldwide by   March July 1997.  With new multicast
applications and multicast-based services appearing, it seems likely
that the use of multicast technology in the Internet will keep growing
at an ever-increasing rate.

The MBone is a virtual network that is layered on top of sections of the
physical Internet.  It is composed of islands of multicast routing
capability connected to other islands islands, or "regions," by virtual point-to-point point-
to-point links called "tunnels."  The tunnels allow multicast traffic to
pass through the non-multicast-capable parts of the Internet.  Tunneled
IP multicast packets are encapsulated as IP-over-IP (i.e., the protocol
number is set to 4) so they look like normal are seen as regular unicast packets to the
intervening routers.  The encapsulation encapsulating IP header is added on entry to a
tunnel and stripped off on exit
from a tunnel. exit.  This set of multicast routers, their
directly-connected subnetworks, and the interconnecting tunnels comprise
the MBone.

Since the MBone and the Internet have different topologies, multicast
routers execute a separate routing protocol to decide how to forward
multicast packets.  The majority of the MBone routers currently use the
Distance Vector Multicast Routing Protocol (DVMRP), although  In some
portions cases, this means that they include their
own internal unicast routing protocol, but in other cases the multicast
routing protocol relies on the routing table provided by the underlying
unicast routing protocols.

The majority of the MBone regions are currently interconnected by the
Distance Vector Multicast Routing Protocol (DVMRP).  Internally, the
regions may execute either any routing protocol they choose, i.e., Multicast
extensions to OSPF (MOSPF) (MOSPF), or the Protocol-Independent Multicast (PIM)
routing protocols.  The operation protocol(s), or the DVMRP.

As multicast routing software features become more widely available on
the routers of each the Internet, providers may gradually decide to use
"native" multicast as an alternative to using lots of these protocols is discussed later in this paper. tunnels.  "Native"
multicast happens when a region of routers (or set of regions) operates

========================================================================

                              +++++++
                           / |Island
                            /|Region | \
                         /T/ |
                          /T/|   A   | \T\
                        /U/   +++++++    \U\
                      /N/        |         \N\
                    /N/          |           \N\
                  /E/            |             \E\
                /L/              |               \L\
         ++++++++             +++++++             ++++++++            ++++++++
        | Region | Island           | Region | Island| ---------| Island Region |
        |    B   |           |   C    |   Tunnel |   D    |
         ++++++++\            ++++++++             +++++++  --------- ++++++++
               \ \               |
                \T\              |
                  \U\            |
                    \N\          |
                     \N\     +++++++
                        \E\  |Island         |
                       \E\   ++++++++
                         \L\| Region |
                           \|   E    |
                            \ +++++++
                             ++++++++

Figure 2: Internet Multicast Backbone (MBone)

========================================================================

As multicast routing software features become more widely available on
the routers

without tunnels.  All subnetworks are connected by at least one router
which is capable of the Internet, providers may gradually decide to use
"native" forwarding their multicast packets as an alternative to using lots of tunnels. required.  In
this case, tunnels are not required:  Multicast packets just flow where
they need to.

The MBone carries audio and video multicasts of Internet Engineering
Task Force (IETF) meetings, NASA Space Shuttle Missions, US House and
Senate sessions, and live satellite weather photos. other content.  There are public and private
sessions on the MBone.  Sessions that are menat meant for public
viewing or participation consumption
are announced via the session directory (SDR) tool.  A user  Users of this tool can
see a list of current and future public
sessions sessions, provided the user is they are
within the administrative scope of the
sender. sender's "scope."

4. MULTICAST ADDRESSING

A multicast address is assigned to a set of receivers defining Internet hosts comprising a
multicast group.  Senders use the multicast address as the destination
IP address of a packet that is to be transmitted to all group members.

4.1 Class D Addresses

An IP multicast group is identified by a Class D address.  Class D
addresses have their high-order four bits set to "1110" followed by
a 28-bit multicast group ID.  Expressed in standard "dotted-decimal"
notation, multicast group addresses range from 224.0.0.0 to
239.255.255.255 (shorthand:  224.0.0.0/4).

Figure 3 shows the format of a 32-bit Class D address. address:

========================================================================

      0 1 2 3                                                      31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|1|1|0|                   Multicast Group ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |------------------------28 bits------------------------|

Figure 3: Class D Multicast Address Format
========================================================================

The Internet Assigned Numbers Authority (IANA) maintains a list of
registered IP multicast groups.  The base address 224.0.0.0 is reserved
and cannot be assigned to any group.  The block of multicast addresses
ranging from 224.0.0.1 to 224.0.0.255 is reserved for permanent
assignment to various uses, including routing protocols and other
protocols that require a well-known permanent address.  Multicast
routers should not forward any multicast datagram with destination
addresses in this range, (regardless of the packet's TTL).

Some of the well-known groups include:

    "all systems on this subnet"       224.0.0.1
    "all routers on this subnet"       224.0.0.2
    "all DVMRP routers"                224.0.0.4
    "all OSPF routers"                 224.0.0.5
    "all OSPF designated routers"      224.0.0.6
    "all RIP2 routers"                 224.0.0.9
    "all PIM routers"                  224.0.0.13
    "all CBT routers"                  224.0.0.15

The remaining groups ranging from 224.0.1.0 to 239.255.255.255 are
either permanently assigned to various multicast applications or remain unassigned. are
available for dynamic assignment (via SDR or other methods).  From this
range, the addresses from 239.0.0.0 to 239.255.255.255 are being reserved for
various "administratively scoped" applications, within private networks,
not necessarily Internet-wide applications.

The complete list may be found in the Assigned Numbers RFC (RFC 1700 or
its successor) or at the assignments page of the IANA Web Site:

<URL:http://www.isi.edu/div7/iana/assignments.html>

    <URL:http://www.iana.org/iana/assignments.html>

4.2 Mapping a Class D Address to an IEEE-802 MAC Address

The IANA has been allocated a reserved portion of the IEEE-802 MAC-layer
multicast address space.  All of the addresses in IANA's reserved block
begin with 01-00-5E (hex); to be clear, the range from 01-00-5E-00-00-00
to 01-00-5E-FF-FF-FF is reserved used for IP multicast groups.

A simple procedure was developed to map Class D addresses to this
reserved MAC-layer multicast address block.  This allows IP multicasting
to easily take advantage of the hardware-level multicasting supported by
network interface cards.

The mapping between a Class D IP address and an IEEE-802 (e.g., FDDI,
Ethernet) MAC-layer multicast address is obtained by placing the low-
order 23 bits of the Class D address into the low-order 23 bits of
IANA's reserved MAC-layer multicast address block.  This simple
procedure removes the need for an explicit protocol for multicast
address resolution on LANs akin to ARP for unicast.  All LAN stations
know this simple transformation, and can easily send any IP multicast
over any IEEE-802-based LAN.

Figure 4 illustrates how the multicast group address 234.138.8.5
(or EA-8A-08-05 expressed in hex) is mapped into an IEEE-802 multicast
address.  Note that the high-order nine bits of the IP address are not
mapped into the MAC-layer multicast address.

The mapping in Figure 4 places the low-order 23 bits of the IP multicast
group ID into the low order 23 bits of the IEEE-802 multicast address.
Note that
Because the mapping may place up to multiple IP class D space has more groups into (2^28) than the same
IEEE-802 address because IETF's OUI may
contain at the upper five bits of the IP class D address
are not used.  Thus, there is a 32-to-1 ratio of IP MAC layer (2^23), multiple group addresses map to each
IEEE-802 address.  To be precise, 32 class D addresses map to
valid MAC-layer each MAC-
layer multicast addresses.  In practice, there is a small
chance of collisions, should multiple  If two or more groups happen to pick on a LAN have, by some
astronomical coincidence, chosen class D addresses that which map to the same
MAC-layer multicast address.  However,
chances are that higher-layer protocols will let address, then the member hosts will receive traffic
for all those groups.  It will then be up to their IP-layer software to
interpret which packets are for them (i.e., the chances of two different groups picking
the same class D address and the same set of UDP ports is extremely
unlikely).  For example, the group(s) to which they really belong.
The class D addresses 224.10.8.5 (E0-0A-08-05) and 225.138.8.5 (E1-8A-08-05) (E1-8A-
08-05) are shown to map to the same IEEE-802 MAC-layer multicast address (01-00-5E-0A-08-05) used in this example.
(01-00-5E-0A-08-05).

4.3 Transmission and Delivery of Multicast Datagrams

When the sender and receivers are members of the same (LAN) subnetwork,
the transmission and reception of multicast frames is a straightforward
process.  The source station simply addresses the IP packet to the
multicast group, the network interface card maps the Class D address to

========================================================================

  Class D Address: Addresses:

  234.138.8.5 (EA-8A-08-05)  1110 1010  1000 1010  0000 1000  0000 0101
  224.10.8.5  (E0-0A-08-05)  1110 0000  0000 1010  0000 1000  0000 0101
  225.138.8.5 (E1-8A-08-05)  1110 0001  1000 1010  0000 1000  0000 0101
                             **** ''''  '^^^ ^^^^  ^^^^ ^^^^  ^^^^ ^^^^

                                |    E      A   |   8
                  Class-D IP    |_______ _______|__ _ _ _
                     Address    |-+-+-+-+-+-+-+-|-+ - - -
                                |1 1 1 0 1 0 1 0|1
                                |-+-+-+-+-+-+-+-|-+ - - -
                                ...................
IEEE-802                           ....not.........
MAC-Layer                            ..............
Multicast                              ....mapped..
Address                                 ...........
|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+ - - -
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|0 1 0 1 1 1 1 0|0
|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+ - - -
|_______ _______|_______ _______|_______ _______|_______
|   0       1   |   0       0   |   5       E   |   0

                       [Address mapping below continued from half above]

         |   8       A   |   0       8   |   0      5    |
         |_______ _______|_______ _______|_______ _______|    Class-D IP
  - - - -|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    Address
         |  0 0 0 1 0 1 0|0 0 0 0 1 0 0 0|0 0 0 0 0 1 0 1|
  - - - -|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|
            \____________           ____________________/
                         \___   ___/
                             \ /
                              |
                   23 low-order bits mapped
                              |
                              v

  - - - -|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    IEEE-802
         |  0 0 0 1 0 1 0|0 0 0 0 1 0 0 0|0 0 0 0 0 1 0 1|    MAC-Layer
  - - - -|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    Multicast
         |_______ _______|_______ _______|_______ _______|    Address
         |   0       A   |   0       8   |   0       5   |

Figure 4: Mapping between Class D and IEEE-802 Multicast Addresses
========================================================================

4.3 Transmission and Delivery of Multicast Datagrams

When the sender and receivers are members of the same (LAN) subnetwork,
the transmission and reception of multicast frames is a straightforward
process.  The source station simply addresses the IP packet to the
multicast group, the network interface card maps the Class D address to

the corresponding IEEE-802 multicast address, and the frame is sent.
Receivers
Internet hosts that wish need to capture receive selected multicast frames, whether
because a user has executed a multicast application, or because the frame notify their MAC and
host's IP layers
that they want stack is required to receive datagrams addressed to certain groups (e.g., 224.0.0.1,
the group.

Things become somewhat more "all-hosts" group), notify their driver software of which group
addresses to filter.

Things become somewhat more complex when the sender is attached to one
subnetwork and receivers reside on different subnetworks.  In this case,
the routers must implement a multicast routing protocol that permits the
construction of multicast delivery trees and supports multicast packet
forwarding.  In addition, each router needs to implement a group
membership protocol that allows it to learn about the existence of group
members on its directly attached subnetworks.

5. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)

The Internet Group Management Protocol (IGMP) runs between hosts and
their immediately-neighboring multicast routers.  The mechanisms of the
protocol allow a host to inform its local router that it wishes to
receive transmissions addressed to a specific multicast group.  Also,
routers periodically query the LAN to determine if any group members are
still active.  If there is more than one IP multicast router on the LAN,
one of the routers is elected "querier" and assumes the responsibility of
querying the LAN for the presence of any group members.

Based on the group membership information learned from the IGMP, a
router is able to determine which (if any) multicast traffic needs to be
forwarded to each of its "leaf" subnetworks.  "Leaf" subnetworks are
those that have no further downstream routers; they either contain
receivers for some set of groups, or they do not.  Multicast routers use this
information, in conjunction
the information derived from IGMP, along with a multicast routing
protocol, to support IP multicasting across the Internet. MBone.

5.1 IGMP Version 1

IGMP Version 1 was specified in RFC-1112.  According to the
specification, multicast routers periodically transmit Host Membership
Query messages to determine which host groups have members on their
directly-attached networks.  IGMP Query messages are addressed to the
all-hosts group (224.0.0.1) and have an IP TTL = 1.  This means that
Query messages sourced from a router are transmitted onto the
directly-attached subnetwork directly-
attached subnetwork, but are not forwarded by any other multicast
routers.

When a host receives an IGMP Query message, it responds with a Host
Membership Report for each group to which it belongs, sent to each group
to which it belongs.  (This is an important point:  While  IGMP Queries are

sent to the "all hosts on this subnet" class D address (224.0.0.1), but
IGMP Reports are sent to the group(s) to which the host(s) belong.  IGMP
Reports, like Queries, are sent with the IP TTL = 1, and thus are not
forwarded beyond the local subnetwork.)

========================================================================

         Group 1                                   _____________________                                   ____________________
           ____            ____                   |  multicast         |
          |    |          |    |                  |            router  |
          |_H2_|          |_H4_|                  |_____________________|                  |____________________|
           ----            ----                      +-----+ |
             |               |                 <-----|Query| |
             |               |                       +-----+ |
             |               |                               |
|---+----+-------+-------+--------+-----------------------+----|
    |-----+--+---------+-----+----------+--------------------+----|
          |            |                |
          |            |                |
        ____         ____              ____
       |    |       |    |            |    |
       |_H1_|       |_H3_|            |_H5_|
        ----         ----              ----
       Group 2      Group 1           Group 1
                    Group 2

Figure 5: Internet Group Management Protocol-Query Protocol - Query Message
========================================================================

are sent to the "all hosts on this subnet" class D address (224.0.0.1),
IGMP Reports are sent to the group(s) to which the host(s) belong.
IGMP Reports, like Queries, are sent with the IP TTL = 1, and thus are
not forwarded beyond the local subnetwork.)

In order to avoid a flurry of Reports, each host starts a randomly-
chosen Report delay timer for each of its group memberships.  If, during
the delay period, another Report is heard for the same group, every
other host in that group must reset its timer to a new random value.
This procedure spreads Reports out over a period of time and thus
minimizes Report traffic for each group that has at least one member on
a given subnetwork.

It should be noted that multicast routers do not need to be directly
addressed since their interfaces are required to promiscuously receive
all multicast IP traffic.  Also, a router does not need to maintain a
detailed list of which hosts belong to each multicast group; the router
only needs to know that at least one group member is present on a given
network interface.

Multicast routers periodically transmit IGMP Queries to update their
knowledge of the group members present on each network interface.  If
the router does not receive a Report from any members of a particular
group after a number of Queries, the router assumes that group members

are no longer present on an interface.  Assuming this is a leaf subnet
(i.e., a subnet with group members but no multicast routers connecting
to additional group members further downstream), this interface is
removed from the delivery tree(s) for this group.  Multicasts will
continue to be sent on this interface only if the router can tell (via
multicast routing protocols) that there are additional group members
further downstream reachable via this interface.

When a host first joins a group, it immediately transmits an IGMP Report
for the group rather than waiting for a router's IGMP Query.  This
reduces the "join latency" for the first host to join a given group on
a particular subnetwork.  "Join latency" is measured from the time when
a host's first IGMP Report is sent, until the transmission of the first packet for that
group onto arrives on that host's subnetwork.  Of course, if the group is
already active, the join latency is precisely zero. negligible.

5.2 IGMP Version 2

IGMP version 2 was distributed as part of the Distance Vector Multicast
Routing Protocol (DVMRP) implementation ("mrouted") source code, from
version 3.3 through 3.8.  Initially, there was no detailed specification
for IGMP version 2 other than this source code.  However, the complete
specification has recently been published in <draft-ietf-idmr-igmp-
v2-06.txt>
v2-06.txt>, a work-in-progress which will update the specification
contained in the first appendix of RFC-1112.  IGMP version 2 extends
IGMP version 1 while maintaining backward compatibility with version 1
hosts.

IGMP version 2 defines a procedure for the election of the multicast
querier for each LAN.  In IGMP version 2, the multicast router with the
lowest IP address on the LAN is elected the multicast querier.  In IGMP
version 1, the querier election was determined by the multicast routing
protocol.

IGMP version 2 defines a new type of Query message:  the Group-Specific
Query.  Group-Specific Query messages allow a router to transmit a Query
to a specific multicast group rather than all groups residing on a
directly attached subnetwork.

Finally, IGMP version 2 defines a Leave Group message to lower IGMP's
"leave latency."  When the last host to respond to a Query with a Report host wishes to leave that specific group, the
host transmits a Leave Group an IGMPv2 "Leave Group" message to the all-routers group (224.0.0.2)
(224.0.0.2), with the group field set to the group being left.  In response to  After
receiving a Leave Group message, the router
begins IGMPv2-elected querier must find
out if this was the transmission last member of this group on this subnetwork.  To do
this, the router begins transmitting Group-Specific Query messages on
the interface that received the Leave Group message.  If there are it hears no

Reports in response to the Group-Specific Query messages, then (if this
is a leaf subnet) this interface is removed from the delivery tree(s)
for this group (as was the case of IGMP version 1).  Again,  Even if there are

no group members on this subnetwork, multicasts
will must continue to be sent on this interface
onto it if the router can tell (via
multicast routing protocols) that there are additional group members are further downstream
away from the source (i.e., "downstream") that are reachable via other
routers attached to this interface. subnetwork.

"Leave latency" is measured from a router's perspective.  In version 1
of IGMP, leave latency was the time from a router's hearing the last
Report for a given group, until the router aged out that interface from
the delivery tree for that group (assuming this is a leaf subnet, of
course).  Note that the only way for the router to tell that this was
the LAST group member is that no reports are heard in some multiple of
the Query Interval (this is on the order of minutes).  IGMP version 2,
with the addition of the Leave Group message, allows a group member to
more quickly inform the router that it is done receiving traffic for a
group.  The router then must determine if this host was the last member
of this group on this subnetwork.  To do this, the router quickly
queries the subnetwork for other group members via the Group-Specific
Query message.  If no members send reports after several of these Group-
Specific Queries, the router can infer that the last member of that
group has, indeed, left the subnetwork.

The benefit of lowering the leave latency is that prune messages can be sent as soon as possible
after the last member host drops out of router can quickly
use its multicast routing protocol to inform its "upstream" neighbors
("upstream" is the group, instead direction that a router considers to be toward a
source), allowing the delivery tree for this group to quickly adapt to
the new shape of the group (without this subnetwork and the branch that
lead to it).  The alternative was having to wait for several minutes worth rounds of Query intervals
unanswered Queries to pass. pass (on the order of minutes).  If a group
was experiencing high traffic levels, it can be very beneficial to stop
transmitting data for this group as soon as possible.

5.3 IGMP Version 3 (Future)

IGMP version 3 is a preliminary draft specification work-in-progress published in
<draft-cain-igmp-00.txt>. <draft-
cain-igmp-00.txt>.  IGMP version 3 introduces as it is currently defined will
introduce support for Group-
Source Group-Source Report messages so that a host can may
elect to receive traffic only from specific sources of a multicast within a group. An
Inclusion Group-Source Report message allows will allow a host to specify the
IP addresses address(es) of the specific sources it wants to receive.  An receive, and an
Exclusion Group-Source Report message
allows will allow a host to explicitly identify the sources
ask that it does not want
to receive. traffic from some (list of) sources be blocked.  With IGMP version
versions 1 and version 2, if a host wants to receive any traffic for a group, the
then traffic from all sources for the
group must group's sources will be forwarded onto the
host's subnetwork.

IGMP version 3 will help conserve bandwidth by allowing a host to select
only the specific sources from which it wants to receive traffic.  Also,
multicast routing protocols will be able to make use this information to help
conserve bandwidth when constructing the branches of their multicast
delivery trees.

Finally, support for Leave Group messages messages, first introduced in IGMP
version 2 IGMPv2,
has been enhanced to support Group-Source Leave messages.  This feature allows
will allow a host to leave an entire group group, or to specify the specific
IP address(es) of the (source, group) pair(s) that it wishes to leave.
Note that at this time, not all existing multicast routing protocols have mechanisms to can
support such requests from group members. requests.  This is one issue that will needs to be addressed
during the development of IGMP version 3.

6. MULTICAST FORWARDING TECHNIQUES

IGMP provides the final step in a multicast packet delivery service
since it is only concerned with the forwarding of multicast traffic from
a router to group members on its directly-attached subnetworks.  IGMP is
not concerned with the delivery of multicast packets between neighboring
routers or across an internetwork.

To provide an internetwork delivery service, it is necessary to define
multicast routing protocols.  A multicast routing protocol is
responsible for the construction of multicast delivery trees and
enabling multicast packet forwarding.  This section explores a number of
different techniques that may potentially be employed by multicast
routing protocols:

    o "Simpleminded" Techniques
       - Flooding
       - Multicast Extensions to MAC-layer Spanning Trees

    o  Source-Based Tree (SBT) Techniques
       - Reverse Path Broadcasting (RPB)
       - Truncated Reverse Path Broadcasting (TRPB)
       - Reverse Path Multicasting (RPM)

    o "Shared-Tree" Techniques

Later sections will describe how these algorithms are implemented in the
most prevalent multicast routing protocols in the Internet today  (e.g.,
Distance Vector Multicast Routing Protocol (DVMRP), Multicast extensions
to OSPF (MOSPF), Protocol-Independent Multicast (PIM), and Core-Based
Trees (CBT).

6.1 "Simpleminded" Techniques

Flooding and Multicast Extensions to MAC-layer Spanning Trees are two
algorithms that can could be used to build primitive multicast routing
protocols.  The techniques are primitive due
to the fact that because they tend to waste
bandwidth or require a large amount of computational resources within
the participating multicast routers involved. routers.  Also, protocols built on these
techniques may work for small networks with few senders, groups, and
routers, but do not scale well to larger numbers of senders, groups, or

routers.  Also,  Finally, the ability to handle arbitrary topologies may not be present
absent, or may only be present in limited ways.

6.1.1 Flooding

The simplest technique for delivering multicast datagrams to all routers
in an internetwork is to implement a flooding algorithm. The flooding
procedure begins when a router receives a packet that is addressed to a
multicast group.  The router employs a protocol mechanism to determine
whether or not it has seen this particular packet before.  If it is the
first reception of the packet, the packet is forwarded on all interfaces
(except the one on which it arrived) guaranteeing that the multicast
packet reaches all routers in the internetwork.  If the router has seen
the packet before, then the packet is discarded.

A flooding algorithm is very simple to implement since a router does not
have to maintain a routing table and only needs to keep track of the
most recently seen packets.  However, flooding does not scale for
Internet-wide applications since it generates a large number of
duplicate packets and uses all available paths across the internetwork
instead of just a limited number.  Also, the flooding algorithm makes
inefficient use of router memory resources since each router is required
to maintain a distinct table entry for each recently seen packet.

6.1.2 Multicast Extensions to MAC-layer Spanning Tree Trees

A more effective solution than flooding would be to select a subset of
the internetwork topology which forms a spanning tree.  The spanning
tree defines a structure in which only one active path connects any two
routers of the internetwork.  Figure 6 shows an internetwork and a
spanning tree rooted at router RR.

Once the spanning tree has been built, a multicast router simply
forwards each multicast packet to all interfaces that are part of the
spanning tree except the one on which the packet originally arrived.
Forwarding along the branches of a spanning tree guarantees that the
multicast packet will not loop and that it will eventually reach all
routers in the internetwork.

A spanning tree solution is powerful and would be relatively easy to
implement since there is a great deal of experience with spanning tree
protocols in the Internet community.  However, a spanning tree solution
can centralize traffic on a small number of links, and may not provide
the most efficient path between the source subnetwork and group members.
Also, it is computationally difficult to compute a spanning tree in
large, complex topologies.

6.2 Source-Based Tree Techniques

The following techniques all generate a source-based tree by various
means.  The techniques differ in the efficiency of the tree building
process, and the bandwidth and router resources (i.e., state tables)
used to build a source-based tree.

6.2.1 Reverse Path Broadcasting (RPB)

A more efficient solution than building a single spanning tree for the
entire internetwork would be to build a spanning tree for each potential
source [subnetwork].  These spanning trees would result in source-based
delivery trees emanating from the subnetworks directly connected to the

========================================================================

[This space was intentionally left blank.]

========================================================================

A Sample Internetwork Internetwork:

                     #----------------#
                   / |\              / \
                  |  | \           /    \
                  |  |   \       /       \
                  |  |    \    /          \
                  |  |      \ /            \
                  |  |       #------#       \
                  |  |      /       | \      \
                  |  |     /        |  \      \
                  |   \   /         |   \-------#
                  |    \ /          |     -----/|
                  |     #-----------#----/      |
                  |    /|\---    --/|    \      |
                  |   / |    \  /    \    \     |
                  |  /   \    /\     |     \   /
                  | /      \ /   \   |      \ /
                  #---------#--   \  |   ----#
                               \   \ |  /
                                \--- #-/

A

One Possible Spanning Tree for this Sample Internetwork Internetwork:

                     #                #
                      \              /
                       \           /
                         \       /
                          \    /
                            \ /
                             #------RR
                                    | \
                                    |  \
                                    |   \-------#
                                    |
                        #-----------#----
                       /|           |    \
                      / |            \    \
                     /   \           |     \
                    /      \         |      \
                   #        #        |       #
                                     |
                                     #
LEGEND

#   Router
RR  Root Router

Figure 6: Spanning Tree
========================================================================

6.2 Source-Based Tree Techniques

The following techniques all generate a source-based tree by various
means.  The techniques differ in the efficiency of the tree building
process, and the bandwidth and router resources (i.e., state tables)
used to build a source-based tree.

6.2.1 Reverse Path Broadcasting (RPB)

A more efficient solution than building a single spanning tree for the
entire internetwork would be to build a spanning tree for each potential
source [subnetwork].  These spanning trees would result in source-based
delivery trees emanating from the subnetworks directly connected to the
source stations.  Since there are many potential sources for a group, a
different delivery tree is constructed rooted at each active source.

6.2.1.1 Reverse Path Broadcasting: Operation

The fundamental algorithm to construct these source-based trees is
referred to as Reverse Path Broadcasting (RPB).  The RPB algorithm is
actually quite simple.  For each source, if a packet arrives on a link
that the local router believes to be on the shortest path back toward
the packet's source, then the router forwards the packet on all
interfaces except the incoming interface.  If the packet does not
arrive on the interface that is on the shortest path back toward the
source, then the packet is discarded.  The interface over which the
router expects to receive multicast packets from a particular source is
referred to as the "parent" link.  The outbound links over which the
router forwards the multicast packet are called "child" links for this
source.

This basic algorithm can be enhanced to reduce unnecessary packet
duplication.  If the local router making the forwarding decision can
determine whether a neighboring router on a child link is "downstream,"
then the packet is multicast toward the neighbor.  (A "downstream"
neighbor is a neighboring router which considers the local router to be
on the shortest path back toward a given source.)  Otherwise, the packet
is not forwarded on the potential child link since the local router
knows that the neighboring router will just discard the packet (since it
will arrive on a non-parent link for the source, relative to that
downstream router).

========================================================================

                                 Source
                                    |   ^
                                    |   :    shortest path back to the
                                    |   :     source for THIS router
                                    |   :
                               "parent link"
                                    _
                            ______|!2|_____
                           |               |
                --"child -|!1|           |!3| - "child --
                    link"  |    ROUTER     |      link"
                           |_______________|

Figure 7: Reverse Path Broadcasting - Forwarding Algorithm
========================================================================

The information to make this "downstream" decision is relatively easy to
derive from a link-state routing protocol since each router maintains a
topological database for the entire routing domain.  If a distance-
vector routing protocol is employed, a neighbor can either advertise its
previous hop for the source as part of its routing update messages or
"poison reverse" the route toward a source if it is not on the
distribution delivery
tree for that source.  Either of these techniques allows an upstream
router to determine if a downstream neighboring router is on an active
branch of the delivery distribution tree for a certain source.

Please refer to Figure 8 for a discussion describing the basic operation
of the enhanced RPB algorithm.

========================================================================

                                 Source Station------>O
                                    A #
                                     +|+
                                    +
                                    | +
                                   +  O  +
                                  +       +
                                 1         2
                                +           +
                               +             +
                              +               +
                          B  +                 +  C
                          O-#- - - - -3- - - - -#-O
                           +|+                 -|+
                          +   ^
                                    | +               -   :    shortest path back to the
                                    | +
                         +  O  +             -  O  +
                        +       +           -       +
                       +         +   :     source for THIS router
                                    |   :
                               "parent link"
                                    _
                            ______|!2|_____
                           |               |
                --"child -|!1|           |!3| -         +
                      4           5       6           7
                     +             + "child --
                    link"  |    ROUTER     |      link"
                           |_______________|

Figure 7: Reverse Path Broadcasting -             +
                    +               + E -               +
                   +                 + -                 +
                D #- - - - -8- - - - -#- - - - -9- - - - -# F
                  |                   |                   |
                  O                   O                   O

LEGEND

O   Leaf
+ + Shortest-path
- - Branch
#   Router

Figure 8: Reverse Path Broadcasting - Example Forwarding Algorithm
========================================================================

Note that the source station (S) is attached to a leaf subnetwork
directly connected to Router A.  For this example, we will look at the
RPB algorithm from Router B's perspective. Router B receives the
multicast packet from Router A on link 1.  Since Router B considers link
1 to be the parent link for the (source, group) pair, it forwards the
packet on link 4, link 5, and the local leaf subnetworks if they contain
group members.  Router B does not forward the packet on link 3 because
it knows from routing protocol exchanges that Router C considers link 2
as its parent link for the source.  Router B knows that if it were to
forward the packet on link 3, it would be discarded by Router C since
the packet would not be arriving on Router C's parent link for this
source.

Figure 8 illustrates the preceding discussion of the enhanced RPB
algorithm's basic operation.

6.2.1.2 RPB: Benefits and Limitations

The key benefit to reverse path broadcasting is that it is reasonably
efficient and easy to implement.  It does not require that the router
know about the entire spanning tree, nor does it require a special
mechanism to stop the forwarding process (as flooding does).  In
addition, it guarantees efficient delivery since multicast packets
always follow the "shortest" path from the source station to the
destination group.  Finally, the packets are distributed over multiple
links, resulting in better network utilization since a different tree is
computed for each source.

One of the major limitations of the RPB algorithm is that it does not
take into account multicast group membership when building the delivery

tree for a source.  As a result, extraneous datagrams may be unnecessarily forwarded
onto subnetworks that have no members in a destination group. group members.

========================================================================

                 Source Station------>O
                                    A #
                                     +|+
                                    + | +
                                   +  O  +
                                  +       +
                                 1         2
                                +           +
                               +             +
                              +               +
                          B  +                 +  C
                          O-#- - - - -3- - - - -#-O
                           +|+                 -|+
                          + | +               - | +
                         +  O  +             -  O  +
                        +       +           -       +
                       +         +         -         +
                      4           5       6           7
                     +             +     -             +
                    +               + E -               +
                   +                 + -                 +
                D #- - - - -8- - - - -#- - - - -9- - - - -# F
                  |                   |                   |
                  O                   O                   O
LEGEND

O   Leaf
+ + Shortest-path
- - Branch
#   Router

Figure 8: Reverse Path Broadcasting - Example
========================================================================

6.2.2 Truncated Reverse Path Broadcasting (TRPB)

Truncated Reverse Path Broadcasting (TRPB) was developed to overcome the
limitations of Reverse Path Broadcasting.  With information provided by
IGMP, multicast routers determine the group memberships on each leaf
subnetwork and avoid forwarding datagrams onto a leaf subnetwork if it
does not contain at least one member of a given destination group.  Thus,
the delivery tree is "truncated" by the router if a leaf subnetwork has
no group members.

Figure 9 illustrates the operation of TRPB algorithm.  In this example
the router receives a multicast packet on its parent link for the
Source.  The router forwards the datagram on interface 1 since that
interface has at least one member of G1.  The router does not forward
the datagram to interface 3 since this interface has no members in the
destination group.  The datagram is forwarded on interface 4 if and only
if a downstream router considers this subnetwork to be part of its
"parent link" for the Source.

======================================================================

                            Source
                                |   :
                                    :
                                |   :     (Source, G1)
                                    v
                                |
                           "parent link"
                                |
              "child link"     ___
          G1            _______|2|_____
           \           |               |
         G3\\ _____   ___    ROUTER   ___      ______ / G2
            \| hub |--|1|             |3|-----|switch|/
            /|_____|  ^--     ___     --^     |______|\
            /        ^ |______|4|_____|  ^            \
          G1        ^       .^---         ^            G3
                   ^      .^   |           ^
                  ^     .^  "child link"    ^
                 Forward       |             Truncate

Figure 9: Truncated Reverse Path Broadcasting - (TRPB)
======================================================================

TRPB removes some limitations of RPB but it solves only part of the
problem.  It eliminates unnecessary extraneous traffic on leaf subnetworks subnetworks, but it
does not consider group memberships when building the branches of the
delivery tree.

6.2.3 Reverse Path Multicasting (RPM)

Reverse Path Multicasting (RPM) is an enhancement to Reverse Path
Broadcasting and Truncated Reverse Path Broadcasting.

RPM creates a delivery tree that spans only:

    o  Subnetworks only 1) subnetworks with group
members, and

    o  Routers 2) routers and subnetworks along the shortest path to subnetworks with group members. those
subnetworks.  RPM allows the source-based "shortest-path" tree to be pruned
"pruned" so that datagrams are only forwarded along branches that lead
to active members of the destination group.

6.2.3.1 Operation

When a multicast router receives a packet for a (source, group) pair,
the first packet is forwarded following the TRPB algorithm across all
routers in the internetwork.  Routers on the edge of the network (which
have only leaf subnetworks) are called leaf routers.  The TRPB algorithm
guarantees that each leaf router will receive at least the first
multicast packet.  If there is a group member on one of its leaf
subnetworks, a leaf router forwards the packet based on this group
membership information.

========================================================================

                   Source
                      | :
                      | : (Source, G)
                      | v :
                      | v
                      |
                    o-#-G
                    , |**********
                    ^ |         *
                    , |         *
                    ^ |         *  o
                    , |         * /
                    o-#-o       #***********      ,#***********
                    ^ |\      ^ |\         *
                    ^ | o     ^ | G        *
                    , | o     , | G        *
                    ^ |       ^ |          *
                    , |       , |          *
                    ^,|       ^,|          *
                      #         #          #
                     /|\       /|\        /|\
                    o o o     o o o      G o G
LEGEND

 #    Router
 o    Leaf without group member
 G    Leaf with group member
***   Active Branch
---   Pruned Branch
,>,   Prune Message (direction of flow -->

Figure 10: Reverse Path Multicasting  (RPM)
========================================================================

If none of the subnetworks connected to the leaf router contain group
members, the leaf router may transmit a "prune" message on its parent
link, informing the upstream router that it should not forward packets

for this particular (source, group) pair on the child interface on which
it received the prune message.  Prune messages are sent just one hop
back toward the source.

An upstream router receiving a prune message is required to store the
prune information in memory.  If the upstream router has no recipients
on local leaf subnetworks and has received prune messages from each
downstream neighbor on each of the child interfaces for this (source,
group) pair, then the upstream router does not need to receive
additional any more
packets for the this (source, group) pair.  This implies that  Therefore, the upstream router
can also generate a prune message of its own, one hop further back
toward the source.  This cascade of prune messages results in an active
multicast delivery tree, consisting exclusively of "live" branches
(i.e., branches that lead to active receivers).

Since both the group membership and internetwork topology can change
dynamically, the pruned state of the multicast delivery tree must be
refreshed periodically.  At regular intervals, the prune information
expires from the memory of all routers and the next packet for the
(source, group) pair is forwarded toward all downstream routers.  This
allows "stale state" (prune state for groups that are no longer active)
to be reclaimed by the multicast routers.

6.2.3.2 Limitations

Despite the improvements offered by the RPM algorithm, there are still
several scaling issues that need to be addressed when attempting to
develop an Internet-wide delivery service.  The first limitation is that
multicast packets must be periodically flooded broadcast across every router in
the internetwork, onto every leaf subnetwork.  This flooding "broadcasting" is
wasteful of bandwidth (until the updated prune state is constructed).

This "flood "broadcast and prune" paradigm is very powerful, but it wastes
bandwidth and does not scale well, especially if there are receivers at
the edge of the delivery tree which are connected via low-speed
technologies (e.g., ISDN or modem).  Also, note that every router
participating in the RPM algorithm must either have a forwarding table
entry for a (source, group) pair, or have prune state information for
that (source, group) pair.

It is clearly wasteful (especially as the number of active sources and
groups increase) to place such a burden on routers that are not on every
(or perhaps any) active delivery tree.  Shared tree techniques are an
attempt to address these scaling issues, which become quite acute when
most groups' senders and receivers are sparsely distributed across the
internetwork.

6.3 Shared Tree Techniques

The most recent additions to the set of multicast forwarding techniques
are based on a shared delivery tree.  Unlike shortest-path tree

algorithms which build a source-based tree for each source, or each
(source, group) pair, shared tree algorithms construct a single delivery
tree that is shared by all members of a group.  The shared tree approach
is quite similar to the spanning tree algorithm except it allows the
definition of a different shared tree for each group.  Stations wishing
to receive traffic for a multicast group must explicitly join the shared
delivery tree.  Multicast traffic for each group is sent and received
over the same delivery tree, regardless of the source.

6.3.1 Operation

A shared tree may involve a single router, or set of routers, which
comprise(s) the "core" of a multicast delivery tree.  Figure 11
illustrates how a single multicast delivery tree is shared by all
sources and receivers for a multicast group.

========================================================================

               Source        Source        Source
                  |             |             |
                  |             |             |
                  v             v             v

                 [#] * * * * * [#] * * * * * [#]
                                *
                  ^             *             ^
                  |             *             |
             join |             *             | join
                  |            [#]            |
                 [x]                         [x]
                  :                           :
                member                      member
                 host                        host

LEGEND

[#]  Shared Tree "Core" Routers
* *  Shared Tree Backbone
[x]  Member-hosts' directly-attached routers

Figure 11: Shared Multicast Delivery Tree

========================================================================

Similar to other multicast forwarding algorithms, shared tree algorithms
do not require that the source of a multicast packet be a member of a
destination group in order to send to a group.

6.3.2 Benefits

In terms of scalability, shared tree techniques have several advantages
over source-based trees.  Shared tree algorithms make efficient use of
router resources since they only require a router to maintain state
information for each group, not for each source, or for each (source,
group) pair. (Remember that source-based tree techniques required all
routers in an internetwork to either a) be on the delivery tree for a
given source or (source, group) pair, or b) to have prune state for
that source or (source, group) pair:  So the entire internetwork must
participate in the source-based tree protocol.)  This improves the
scalability of applications with many active senders since the number of
source stations is no longer a scaling issue.  Also, shared tree
algorithms conserve network bandwidth since they do not require that
multicast packets be periodically flooded across all multicast routers
in the internetwork onto every leaf subnetwork.  This can offer
significant bandwidth savings, especially across low-bandwidth WAN
links, and when receivers sparsely populate the domain of operation.
Finally, since receivers are required to explicitly join the shared
delivery tree, data only ever flows over those links that lead to active
receivers.

6.3.3 Limitations

Despite these benefits, there are still several limitations to protocols
that are based on a shared tree algorithm.  Shared trees may result in
traffic concentration and bottlenecks near core routers since traffic
from all sources traverses the same set of links as it approaches the
core.  In addition, a single shared delivery tree may create suboptimal
routes (a shortest path between the source and the shared tree, a
suboptimal path across the shared tree, a shortest path between the
egress
group's core router and the receiver's directly attached router) directly-attached router),
resulting in increased delay which may be a critical issue for some
multimedia applications.  (Simulations indicate that latency over a
shared tree may be approximately 10% larger than source-based trees in
many cases, but by the same token, this may be negligible for many
applications.)

Finally, expanding-ring searches are will probably not supported work as expected
inside shared-tree domains.

7. "DENSE MODE" ROUTING PROTOCOLS

Certain multicast routing protocols are designed to  The searching host's increasing TTL will
cause the packets to work their way up the shared tree, and while a
desired resource may still be found, it may not be as topologically
close as one would expect.

7. "DENSE MODE" ROUTING PROTOCOLS

Certain multicast routing protocols are designed to work well in
environments that have plentiful bandwidth and where it is reasonable
to assume that receivers are rather densely distributed.  In such
scenarios, it is very reasonable to use periodic flooding, or other

bandwidth-intensive techniques that would not necessarily be very
scalable over a wide-area network.  In section 8, we will examine
different protocols that are specifically geared toward efficient WAN
operation, especially for groups that have widely dispersed (i.e.,
sparse) membership.

These

So-called "dense"-mode routing protocols include:

o  the Distance Vector Multicast Routing Protocol (DVMRP),

o  Multicast Extensions to Open Shortest Path First (MOSPF), and

o  Protocol Independent Multicast - Dense Mode (PIM-DM).

These protocols' underlying designs assume that the amount of protocol
overhead (in terms of the amount of state that must be maintained by
each router, the number of router CPU cycles required, and the amount of
bandwidth consumed by protocol operation) is appropriate since receivers
densely populate the area of operation.

7.1. Distance Vector Multicast Routing Protocol (DVMRP)

The Distance Vector Multicast Routing Protocol (DVMRP) is a distance-
vector routing protocol designed to support the forwarding of multicast
datagrams through an internetwork.  DVMRP constructs source-based
multicast delivery trees using the Reverse Path Multicasting (RPM)
algorithm.  Originally, the entire MBone ran only DVMRP.  Today, over
half of the MBone routers still run some version of DVMRP.

DVMRP was first defined in RFC-1075.  The original specification was
derived from the Routing Information Protocol (RIP) and employed the
Truncated Reverse Path Broadcasting (TRPB) technique. The major
difference between RIP and DVMRP is that RIP calculates the next-hop
toward a destination, while DVMRP computes the previous-hop back toward
a source.  Since mrouted 3.0, DVMRP has employed the Reverse Path
Multicasting (RPM) algorithm.  Thus, the latest implementations of DVMRP
are quite different from the original RFC specification in many regards.
There is an active effort within the IETF Inter-Domain Multicast Routing
(IDMR) working group to specify DVMRP version 3 in a standard well-documented
form.

The current DVMRP v3 Internet-Draft Internet-Draft, representing a snapshot of a work-
in-progress, is:

<draft-ietf-idmr-dvmrp-v3-04.txt>, or <draft-ietf-idmr-dvmrp-v3-04.ps>

7.1.1 Physical and Tunnel Interfaces

The ports interfaces of a DVMRP router may be either a physical interface to
a directly-attached subnetwork or a tunnel interface (a.k.a virtual
interface) to another multicast-
capable island. multicast-capable region.  All interfaces are

configured with a metric specifying
cost for the given port, their individual costs, and a TTL
threshold that limits the scope of a which any multicast transmission. packets must exceed in order to cross this
interface.  In addition, each tunnel interface must be explicitly
configured with two additional parameters:  The IP address of the local
router's tunnel interface and the IP address of the remote router's interface.
interface address.

========================================================================

      TTL                            Scope
   Threshold
________________________________________________________________________
   _____________________________________________________________________
       0                             Restricted to the same host
       1                             Restricted to the same subnetwork
      15                             Restricted to the same site
      63                             Restricted to the same region
     127                             Worldwide
     191                             Worldwide; limited bandwidth
     255                             Unrestricted in scope

Table 1:   TTL Scope Control Values
========================================================================

A multicast router will only forward a multicast datagram across an
interface if the TTL field in the IP header is greater than the TTL
threshold assigned to the interface.  Table 1 lists the conventional
TTL values that are used to restrict the scope of an IP multicast.  For
example, a multicast datagram with a TTL of less than 16 is restricted
to the same site and should not be forwarded across an interface to
other sites in the same region.

TTL-based scoping is not always sufficient for all applications.
Conflicts arise when trying to simultaneously enforce limits on
topology, geography, and bandwidth.  In particular, TTL-based scoping
cannot handle overlapping regions, which is a necessary characteristic
of administrative regions.  In light of these issues, "administrative"
scoping was created in 1994, to provide a way to do scoping based on
multicast address.  Certain addresses would be usable within a given
administrative scope (e.g., a corporate internetwork) but would not be
forwarded onto the global MBone.  This allows for privacy, and address
reuse within the class D address space.  The range from 239.0.0.0 to
239.255.255.255 has been reserved for administrative scoping.  While
administrative scoping has been in limited use since 1994 or so, it has
yet to be widely deployed.  The IETF MBoneD working group is working on
the deployment of administrative scoping.  For additional information,
please see <draft-ietf-mboned-admin-ip-space-01.txt> <draft-ietf-mboned-admin-ip-space-03.txt> or its successor, the successor to
this work-in-progress, entitled "Administratively Scoped IP Multicast."

7.1.2 Basic Operation

DVMRP implements the Reverse Path Multicasting (RPM) algorithm.
According to RPM, the first datagram for any (source, group) pair is
forwarded across the entire internetwork (providing the packet's TTL and
router interface thresholds permit this).  Upon receiving this traffic,
leaf routers may transmit prune messages back toward the source if there
are no group members on their directly-attached leaf subnetworks.  The
prune messages remove all branches that do not lead to group members
from the tree, leaving a source-based shortest path tree.

After a period of time, the prune state for each (source, group) pair
expires to reclaim stale router memory that is being used to store prune
state (from pertaining to groups that are no longer in
use). active.  If those groups are actually
happen to still in use, a subsequent datagram for the (source, group)
pair will be flooded broadcast across all downstream routers.  This flooding will result
in a new set of prune messages, serving to regenerate the source-based shortest-path tree for this (source,
group) pair.  In current pair's source-based shortest-path tree.  Current implementations
of RPM (notably
DVMRP), DVMRP) do not transmit prune messages are not reliably transmitted, reliably, so the
prune lifetime must be kept short to compensate for potential lost
prune messages.  (The internet-draft of DVMRP 3.0 incorporates a
mechanism to make prunes reliable.)

DVMRP also implements a mechanism to quickly "graft" back a previously
pruned branch of a group's delivery tree.  If a router that had sent a
prune message for a (source, group) pair discovers new group members on
a leaf network, it sends a graft message to the previous-hop router for
this source.  When an upstream router receives a graft message, it
cancels out the previously-received prune message.  Graft messages
cascade (reliably) hop-by-hop back toward the source until they reach
the nearest "live" branch point on the delivery tree.  In this way,
previously-pruned branches are quickly restored to a given delivery
tree.

7.1.3 DVMRP Router Functions

In  Figure 13, 12, Router C is downstream and may potentially receive
datagrams from the source subnetwork from Router A or Router B.  If
Router A's metric to the source subnetwork is less than Router B's
metric, then Router A is dominant over Router B for this source.

This means that Router A will forward any traffic from the source
subnetwork and Router B will discard traffic received from that source.
However, if Router A's metric is equal to Router B's metric, then the
router with the lower IP address on its downstream interface (child
link) becomes the Dominant Router for this source.  Note that on a
subnetwork with multiple routers forwarding to groups with multiple
sources, different routers may be dominant for each source.

7.1.4 DVMRP Routing Table

The DVMRP process periodically exchanges routing table updates with its
DVMRP neighbors.  These updates are logically independent of those generated by
any unicast Interior Gateway Protocol.

Since the DVMRP was developed to route multicast and not unicast
traffic, a router will probably run multiple routing processes in
practice:  One to support the forwarding of unicast traffic and another
to support the forwarding of multicast traffic. (This can be convenient:
A router can be configured to only route multicast IP, with no unicast

========================================================================

                                   To
              .-<-<-<-<-<-<-Source Subnetwork->->->->->->->->--.
              v                                                v
              |                                                |
          parent link                                      parent link
              |                                                |
        _____________                                    _____________
       | Router A    |                                  | Router B    |
       |             |                                  |             |
        -------------                                    -------------
              |                                                |
         child link                                       child link
              |                                                |
 ---------------------------------------------------------------------
                                       |
                                  parent link
                                       |
                                 _____________
                                | Router C    |
                                |             |
                                 -------------
                                       |
                                  child link
                                       |

Figure 12. DVMRP Dominant Router in a Redundant Topology
========================================================================

IP routing.  This may be a useful capability in firewalled
environments.)

Again, consider Figure 12:  There are two types of routers in this
figure:  dominant figure 12:
Dominant and subordinate; assume Subordinate.  Assume in this example that Router B is
dominant, Router A is subordinate, and Router C is part of the
downstream distribution tree.  In general, which routers are dominant

or subordinate may be different for each source!  A subordinate router
is one that is NOT on the shortest path tree back toward a source.  The
dominant router can tell this because the subordinate router will
'poison-reverse' the route for this source in its routing updates which
are sent on the common LAN (i.e., Router A sets the metric for this
source to 'infinity').  The dominant router keeps track of subordinate
routers on a per-source basis...it never needs or expects to receive a
prune message from a subordinate router.  Only routers that are truly on
the downstream distribution tree will ever need to send prunes to the
dominant router.  If a dominant router on a LAN has received either a
poison-reversed route for a source, or prunes for all groups emanating
from that source subnetwork, then it may itself send a prune upstream
toward the source (assuming also that IGMP has told it that there are no
local receivers for any group from this source).

A sample routing table for a DVMRP router is shown in Figure 13.  Unlike

========================================================================

    Source     Subnet       From          Metric   Status   TTL
     Prefix     Mask         Gateway

    128.1.0.0  255.255.0.0  128.7.5.2       3        Up     200
    128.2.0.0  255.255.0.0  128.7.5.2       5        Up     150
    128.3.0.0  255.255.0.0  128.6.3.1       2        Up     150
    128.3.0.0  255.255.0.0  128.6.3.1       4        Up     200

Figure 13: DVMRP Routing Table
========================================================================

A sample routing table for a DVMRP router is shown in Figure 13.  Unlike
the table that would be created by a unicast routing protocol such as
the RIP, OSPF, or the BGP, the DVMRP routing table contains Source
Prefixes and From-Gateways instead of Destination Prefixes and Next-Hop
Gateways.

The routing table represents the shortest path (source-based) spanning
tree to every possible source prefix in the internetwork--the Reverse
Path Broadcasting (RPB) tree.  The DVMRP routing table does not
represent group membership or received prune messages.

The key elements in DVMRP routing table include the following items:

Source Prefix          A subnetwork which is a potential or actual
                       source of multicast datagrams.

Subnet Mask            The subnet mask associated with the Source
                       Prefix.  Note that the DVMRP provides the subnet
                       mask for each source subnetwork (in other words,
                       the DVMRP is classless).

From-Gateway           The previous-hop router leading back toward a
                       particular Source Prefix.

TTL                    The time-to-live is used for table management
                       and indicates the number of seconds before an
                       entry is removed from the routing table.  This
                       TTL has nothing at all to do with the TTL used
                       in TTL-based scoping.

7.1.5 DVMRP Forwarding Table

Since the DVMRP routing table is not aware of group membership, the
DVMRP process builds a forwarding table based on a combination of the
information contained in the multicast routing table, known groups, and
received prune messages.  The forwarding table represents the local
router's understanding of the shortest path source-based delivery tree
for each (source, group) pair--the Reverse Path Multicasting (RPM) tree.

========================================================================

     Source     Multicast     TTL   InIntf    OutIntf(s)
      Prefix     Group

     128.1.0.0  224.1.1.1     200    1 Pr      2p3p
                224.2.2.2     100    1         2p3
                224.3.3.3     250    1         2
     128.2.0.0  224.1.1.1     150    2         2p3

Figure 14: DVMRP Forwarding Table
========================================================================

The forwarding table for a sample DVMRP router is shown in Figure 14.
The elements in this display include the following items:

Source Prefix           The subnetwork sending multicast datagrams
                        to the specified groups (one group per row).

Multicast Group         The Class D IP address to which multicast
                        datagrams are addressed.  Note that a given
                        Source Prefix may contain sources for several
                        Multicast Groups.

InIntf                  The parent interface for the (source, group)
                        pair.  A 'Pr' in this column indicates that a
                        prune message has been sent to the upstream
                        router (the From-Gateway for this Source Prefix
                        in the DVMRP routing table).

OutIntf(s)              The child interfaces over which multicast
                        datagrams for this (source, group) pair are
                        forwarded.  A 'p' in this column indicates
                        that the router has received a prune message(s)
                        from a (all) downstream router(s) on this port.

7.2. Multicast Extensions

7.1.6 DVMRP Tree Building and Forwarding Summary

As we have seen, DVMRP enables packets to OSPF (MOSPF)

Version 2 of be forwarded away from a
multicast source along the Open Shortest Reverse Path First (OSPF) routing protocol Multicasting (RPM) tree.  The
general name for this technique is
defined in RFC-1583.  OSPF Reverse Path Forwarding, and it is an Interior Gateway Protocol (IGP) that
distributes unicast topology information among routers belonging to
used in some other multicast routing protocols, as we shall see later.

Reverse Path Forwarding was described in Steve Deering's Ph.D. thesis,
and was a
single OSPF "Autonomous System."  OSPF is based refinement of early work on link-state algorithms
which permit rapid route calculation with a minimum of routing protocol
traffic.  In addition to efficient route calculation, OSPF is an open
standard that supports hierarchical routing, load balancing, Reverse Path Broadcasting done by
Dalal and the
import Metcalfe in 1978.  In our discussion of external routing information.

The Multicast Extensions to OSPF (MOSPF) are defined RPB, we saw that it
was wasteful in RFC-1584.  MOSPF
routers maintain a current image its excessive usage of the network topology through resources, because all
nodes received a (single) copy of each packet.  No effort was made in
RPB to prune the
unicast OSPF link-state routing protocol.  The tree to only include branches leading to active
receivers.  After all, RPB was a broadcast technique, not a multicast extensions
technique.

Truncated RPB added a small optimization so that IGMP was used to
OSPF are built tell
if there were listeners on top the LANs at the edge of OSPF Version 2 so that a multicast routing
capability can be incrementally introduced into an OSPF Version 2
routing domain.  Routers running MOSPF will interoperate with non-MOSPF the RPB tree; if
there were no listeners, the packets were stopped at the leaf routers when forwarding unicast IP data traffic.  MOSPF does
and not support
tunnels.

7.2.1 Intra-Area Routing with MOSPF

Intra-Area Routing describes forwarded onto the basic routing algorithm employed by
MOSPF.  This elementary algorithm runs inside edge LANs.  Despite the savings of LAN
bandwidth, TRPB still sends a single OSPF area copy of each packet to every router in the
topology.

Reverse Path Multicasting, used in DVMRP, takes the group membership
information derived from IGMP and
supports multicast forwarding when a sends control messages upstream (i.e.,
toward the source and all destination group
members reside subnetwork) in order to prune the same OSPF area, or when distribution tree.
This technique trades off some memory in the entire OSPF Autonomous
System is a single area (and participating routers (to
store the source is inside that area...).  The
following discussion assumes prune information) in order to gain back the wasted bandwidth
on branches that do not lead to interested receivers.

In DVMRP, the reader RPM distribution tree is familiar with OSPF.

7.2.1.1 Local Group Database

Similar created on demand to all other multicast routing protocols, MOSPF routers use describe the
Internet Group Management Protocol (IGMP)
forwarding table for a given source sending to monitor multicast group
membership on directly-attached subnetworks.  MOSPF routers maintain a
"local group database" which lists directly-attached groups group.  As described in
section 7.1.5, the forwarding table indicates the expected inbound
interface for packets from this source, and
determines the local router's responsibility expected outbound
interface(s) for delivering multicast
datagrams distribution to these groups.

On any given subnetwork, the transmission rest of IGMP Host Membership
Queries is performed solely by the Designated Router (DR).  However, the responsibility of listening group.  Forwarding table
entries are created when packets to IGMP Host Membership Reports is
performed by not only the Designated Router (DR) but also the Backup
Designated Router (BDR).  Therefore, in a mixed LAN containing both
MOSPF "new" (source, group) pair arrive
at a DVMRP router.  As each packet is received, its source and OSPF routers, an MOSPF router must be elected group are
matched against the DR for appropriate row of the
subnetwork.  This can be achieved by setting forwarding table.  If the OSPF RouterPriority to
zero in each non-MOSPF router to prevent them from becoming
packet was received on the (B)DR.

The DR correct inbound interface, it is responsible for communicating group membership information to forwarded
downstream on the appropriate outbound interfaces for this group.

DVMRP's tree-building protocol is often called "broadcast-and-prune"
because the first time a packet for a new (source, group) pair arrives,
it is transmitted towards all other routers in the OSPF area by flooding Group-Membership LSAs.
Similar to Router-LSAs and Network-LSAs, Group-Membership LSAs internetwork.  Then the
edge routers initiate prunes.  Unnecessary delivery branches are only
flooded pruned

within a single area.

7.2.1.2 Datagram's Shortest Path Tree

The datagram's shortest path tree describes the path taken by a
multicast datagram as it travels through the area round-trip time from the source
subnetwork top of a branch to each the furthest leaf
router, typically on the order tens of milliseconds or less, thus, the group members' subnetworks.  The shortest
path
distribution tree for each this new (source, group) pair is built "on demand" quickly trimmed
to serve only active receivers.

The check DVMRP routers do when a
router receives the first multicast datagram for a particular (source,
group) pair.

When the initial datagram arrives, packet arrives at the source subnetwork router is located in called
the MOSPF link state database. "reverse-path check."  The MOSPF link state database is simply
the standard OSPF link state database with the addition first thing a router must do upon receipt
of Group-
Membership LSAs.  Based a multicast packet is determine that it arrived on the Router- and Network-LSAs in the OSPF
link state database, "correct"
inbound interface.  For packets matching (source, group) pairs that this
router has already seen, there will already be a source-based shortest-path tree is constructed
using Dijkstra's algorithm.  After forwarding table entry
indicating the tree expected incoming interface.  For "new" packets, DVMRP's
routing table is built, Group-Membership
LSAs are used to prune compare the tree such actual receiving interface with the
one that is considered by the only remaining branches
lead router to be on the shortest path back to subnetworks containing members of this group.  The output of
these algorithms is a pruned source-based tree rooted at
the datagram's source.

========================================================================

                      S
                      |
                      |
                   A  #
                     / \
                    /   \
                   1     2
                  /       \
               B #         # C
                / \         \
               /   \         \
              3     4         5
             /       \         \
          D #         # E       # F
                     / \         \
                    /   \         \
                   6     7         8
                  /       \         \
               G #         # H       # I

LEGEND

 #   Router

Figure 15. Shortest Path Tree for a (S, G) pair
========================================================================

To forward multicast datagrams  If the reverse-path check succeeds, the packet is forwarded
only on those interfaces that the router considers "child" interfaces
(with respect to downstream members the source of the packet); there may be some interfaces
that, for a group, each given source, are neither child nor incoming interfaces.
Child interfaces attach to subnetworks which use this router must determine its position in as their
previous-hop on the datagram's shortest path tree.
Assume that Figure 15 illustrates toward the shortest path tree for source (router addresses on
this subnetwork are used as a given
(source, group) pair.  Router E's upstream node tie-breaker when there is Router B more than one
such router).

Once the incoming interface and there
are two valid downstream interfaces:  one connecting child interfaces for
this (source, group) are determined, a forwarding table entry is created
to Subnetwork 6 and
another connecting enable quick forwarding of future packets for this (source, group)
pair.  A multicast packet must never be forwarded back toward its source:
This would result in a forwarding loop.

7.2. Multicast Extensions to Subnetwork 7.

Note the following properties OSPF (MOSPF)

Version 2 of the basic MOSPF routing algorithm:

    o  For a given multicast datagram, all routers within Open Shortest Path First (OSPF) routing protocol is
defined in RFC-1583.  OSPF is an Interior Gateway Protocol (IGP) that
distributes unicast topology information among routers belonging to a
single OSPF
       area calculate the same source-based shortest path delivery
       tree.  Tie-breakers have been defined "Autonomous System."  OSPF is based on link-state algorithms
which permit rapid route calculation with a minimum of routing protocol
traffic.  In addition to guarantee efficient route calculation, OSPF is an open
standard that if
       several equal-cost paths exist, all supports hierarchical routing, load balancing, and the
import of external routing information.

The Multicast Extensions to OSPF (MOSPF) are defined in RFC-1584.  MOSPF
routers agree on maintain a single
       path current image of the network topology through the area.  Unlike
unicast OSPF, OSPF link-state routing protocol.  The multicast extensions to
OSPF are built on top of OSPF Version 2 so that a multicast routing
capability can be incrementally introduced into an OSPF Version 2
routing domain.  Routers running MOSPF will interoperate with non-MOSPF
routers when forwarding unicast IP data traffic.  MOSPF does not support the concept of equal-cost multipath routing.

    o  Synchronized link state databases containing Group-Membership
       LSAs allow an
tunnels.

7.2.1 Intra-Area Routing with MOSPF router to build a source-based shortest-
       path tree in memory, working forward from

Intra-Area Routing describes the basic routing algorithm employed by
MOSPF.  This elementary algorithm runs inside a single OSPF area and
supports multicast forwarding when a source to the and all destination group member(s).  Unlike
members reside in the DVMRP, this means that same OSPF area, or when the first
       datagram of entire OSPF Autonomous
System is a new transmission does not have to be flooded single area (and the source is inside that area...).  The
following discussion assumes that the reader is familiar with OSPF.

7.2.1.1 Local Group Database

Similar to all other multicast routing protocols, MOSPF routers in an area.

    o  The "on demand" construction of the source-based delivery tree
       has the benefit of spreading calculations over time, resulting
       in a lesser impact for participating routers.  Of course, this
       may strain the CPU(s) in a router if many new (source, group)
       pairs appear at about use the same time, or if there are
Internet Group Management Protocol (IGMP) to monitor multicast group
membership on directly-attached subnetworks.  MOSPF routers maintain a lot of
       events
"local group database" which force the MOSPF process to flush lists directly-attached groups and rebuild its
       forwarding cache.  In a stable topology with long-lived
determines the local router's responsibility for delivering multicast sessions,
datagrams to these effects should be minimal.

7.2.1.3 Forwarding Cache

Each MOSPF router makes its forwarding decision based on groups.

On any given subnetwork, the contents transmission of
its forwarding cache.  Contrary IGMP Host Membership
Queries is performed solely by the Designated Router (DR).  However,
the responsibility of listening to DVMRP, MOSPF forwarding IGMP Host Membership Reports is
performed by not RPF-
based.  The forwarding cache is built from the source-based shortest-
path tree for each (source, group) pair, and only the router's local group
database.  After Designated Router (DR) but also the router discovers its position Backup
Designated Router (BDR).  Therefore, in the shortest path
tree, a forwarding cache entry is created mixed LAN containing the (source, group)
pair, its expected upstream interface, both
MOSPF and OSPF routers, an MOSPF router must be elected the necessary downstream
interface(s). DR for the
subnetwork.  This can be achieved by setting the OSPF RouterPriority to
zero in each non-MOSPF router to prevent them from becoming the (B)DR.

The forwarding cache entry DR is now used responsible for communicating group membership information to quickly
forward
all subsequent datagrams from this source other routers in the OSPF area by flooding Group-Membership LSAs.
Similar to this group.  If Router-LSAs and Network-LSAs, Group-Membership LSAs are only
flooded within a new single area.

7.2.1.2 Datagram's Shortest Path Tree

The datagram's shortest path tree describes the path taken by a
multicast datagram as it travels through the area from the source begins sending
subnetwork to a new group, MOSPF must first calculate each of the distribution group members' subnetworks.  The shortest
path tree so that it may create for each (source, group) pair is built "on demand" when a cache entry that can be
used to forward the packet.

Figure 16 displays
router receives the forwarding cache first multicast datagram for an example a particular (source,
group) pair.

When the initial datagram arrives, the source subnetwork is located in
the MOSPF router. link state database.  The elements MOSPF link state database is simply
the standard OSPF link state database with the addition of Group-
Membership LSAs.  Based on the Router- and Network-LSAs in the display include OSPF
link state database, a source-based shortest-path tree is constructed
using Dijkstra's algorithm.  After the following items:

Dest. Group            A known destination group address to which
                       datagrams tree is built, Group-Membership
LSAs are currently being forwarded, or used to
                       which traffic was sent "recently" (i.e., since prune the last topology or group membership or other
                       event which (re-)initialized MOSPF's forwarding
                       cache.

Source tree such that the only remaining branches
lead to subnetworks containing members of this group.  The output of
these algorithms is a pruned source-based tree rooted at the datagram's
source host address.  Each (Dest.
                       Group, Source) pair uniquely identifies (Figure 15).

To forward multicast datagrams to downstream members of a
                       separate forwarding cache entry. group, each
router must determine its position in the datagram's shortest path tree.

========================================================================

    Dest. Group     Source       Upstream     Downstream   TTL

    224.1.1.1       128.1.0.2      11          12   13      5
    224.1.1.1       128.4.1.2      11          12   13

                      S
                      |
                    A #
                     / \
                    1   2
    224.1.1.1       128.5.2.2      11          12   13
                   /     \
                B #       # C
                 / \       \
                3
    224.2.2.2       128.2.0.3      12          11   4       5
               /     \       \
            D #       # E     # F                 LEGEND
                     / \       \
                    6   7       8                  #   Router
                   /     \       \
                G #       # H     # I

Figure 16: MOSPF Forwarding Cache
========================================================================

Upstream               Datagrams matching this row's Dest. Group and
                       Source must be received on this interface.

Downstream             If 15. Shortest Path Tree for a datagram matching this row's Dest. Group
                       and Source is received on the correct Upstream
                       interface, then it is forwarded across (S, G) pair
========================================================================

Assume that Figure 15 illustrates the listed
                       Downstream interfaces.

TTL                    The minimum number of hops shortest path tree for a datagram must cross given
(source, group) pair.  Router E's upstream node is Router B and there
are two downstream interfaces:  one connecting to reach any Subnetwork 6 and
another connecting to Subnetwork 7.

Note the following properties of the Dest. Group's members.  An basic MOSPF router may discard a datagram if it can see
                       that the datagram has insufficient TTL to reach
                       even the closest group member.

The information in the forwarding cache is not aged or periodically
refreshed:  It is maintained as long as there are system resources
available (e.g., memory) or until the next topology change.  The
contents of the forwarding cache will change when: routing algorithm:

    o  The topology of the OSPF internetwork changes, forcing  For a given multicast datagram, all of routers within an OSPF
       area calculate the same source-based shortest path trees to be recalculated.  (Once the cache
       has delivery
       tree.  Tie-breakers have been flushed, entries are not rebuilt.  If another packet
       for one of the previous (Dest. Group, Source) pairs is
       received, then a "new" cache entry for defined to guarantee that pair will be
       created then.)

    o  There is if
       several equal-cost paths exist, all routers agree on a change in the Group-Membership LSAs indicating that single
       path through the distribution of individual group members has changed.

7.2.2 Mixing MOSPF and OSPF Routers area.  Unlike unicast OSPF, MOSPF routers can be combined with non-multicast OSPF routers. This
permits does not
       support the gradual deployment concept of MOSPF and allows experimentation with
multicast routing on a limited scale.

It is important to note that equal-cost multipath routing.

    o  Synchronized link state databases containing Group-Membership
       LSAs allow an MOSPF router is required to eliminate
all non-multicast OSPF routers when it builds its build a source-based shortest-
       path delivery tree.  (An MOSPF router can determine tree in memory, working forward from the multicast
capability of any other router based on source to the setting of
       group member(s).  Unlike the multicast-
capable bit (MC-bit) in DVMRP, this means that the Options field of each router's link state
advertisements.)  The omission of non-multicast routers may create a
number first
       datagram of potential problems when forwarding multicast traffic:

    o  The Designated Router for a multi-access network must new transmission does not have to be flooded to
       all routers in an
       MOSPF router.  If a non-multicast OSPF router is elected area.

    o  The "on demand" construction of the
       DR, source-based delivery tree
       has the subnetwork will not be selected to forward multicast
       datagrams since benefit of spreading calculations over time, resulting
       in a non-multicast DR cannot generate Group-
       Membership LSAs lesser impact for its subnetwork (because it is not running
       IGMP, so it won't hear IGMP Host Membership Reports).

    o  Even though there participating routers.  Of course, this
       may be unicast connectivity to strain the CPU(s) in a destination,
       there may not be multicast connectivity.  For example, router if many new (source, group)
       pairs appear at about the only
       path between two points could require traversal of same time, or if there are a non-
       multicast-capable OSPF router.

    o  The forwarding lot of multicast
       events which force the MOSPF process to flush and unicast datagrams between two
       points may follow different paths, making some routing problems rebuild its
       forwarding cache.  In a bit more challenging to solve.

7.2.3 Inter-Area Routing stable topology with long-lived
       multicast sessions, these effects should be minimal.

7.2.1.3 Forwarding Cache

Each MOSPF

Inter-area routing involves router makes its forwarding decision based on the case where a datagram's source and some contents of
its destination group members reside in different OSPF areas.  It
should be noted that the forwarding of multicast datagrams continues cache.  Contrary to
be determined by the contents of the DVMRP, MOSPF forwarding is not RPF-
based.  The forwarding cache which is still built from the local group database and the datagram source-based trees.
The major differences are related to shortest-
path tree for each (source, group) pair, and the way that router's local group membership
information is propagated and
database.  After the way that router discovers its position in the inter-area source-based
tree is constructed.

7.2.3.1 Inter-Area Multicast Forwarders

In MOSPF, shortest path
tree, a subset of an area's Area Border Routers (ABRs) function as
"inter-area multicast forwarders."  An inter-area multicast forwarder forwarding cache entry is
responsible for created containing the forwarding of group membership information (source, group)
pair, its expected "upstream" incoming interface, and
multicast the necessary
"downstream" outgoing interface(s).  The forwarding cache entry is then
used to quickly forward all subsequent datagrams between areas.  Configuration parameters determine
whether or not from this source to
this group.  If a particular ABR also functions as an inter-area
multicast forwarder.

Inter-area multicast forwarders summarize their attached areas' group
membership information new source begins sending to the backbone by originating a new Group-
Membership LSAs into group, MOSPF must
first calculate the backbone area.  Note distribution tree so that the summarization of
group membership in MOSPF is asymmetric.  This means it may create a cache
entry that while group
membership information from non-backbone areas is flooded into the
backbone, but group membership from can be used to forward the backbone (or from any other
non-backbone areas) is not flooded into any non-backbone area(s).

To permit packet.

Figure 16 displays the forwarding of multicast traffic between areas, MOSPF
introduces the concept of a "wild-card multicast receiver."  A wild-card
multicast receiver is a router that receives all multicast traffic
generated in cache for an area.  In non-backbone areas, all inter-area multicast
forwarders operate as wild-card multicast receivers.  This guarantees
that all multicast traffic originating example MOSPF router.
The elements in any non-backbone area is
delivered to its inter-area multicast forwarder, and then if necessary
into the backbone area.  Since display include the backbone knows following items:

Dest. Group            A known destination group membership for
all areas, the datagram can be forwarded address to which
                       datagrams are currently being forwarded, or to
                       which traffic was sent "recently" (i.e., since
                       the appropriate location(s)
in last topology or group membership or other
                       event which (re-)initialized MOSPF's forwarding
                       cache.

Source                 The datagram's source host address.  Each (Dest.
                       Group, Source) pair uniquely identifies a
                       separate forwarding cache entry.

========================================================================

    Dest. Group     Source       Upstream     Downstream   TTL

    224.1.1.1       128.1.0.2      11          12   13      5
    224.1.1.1       128.4.1.2      11          12   13      2
    224.1.1.1       128.5.2.2      11          12   13      3
    224.2.2.2       128.2.0.3      12          11           7

Figure 16: MOSPF Forwarding Cache
========================================================================

Upstream               Datagrams matching this row's Dest. Group and
                       Source must be received on this interface.

Downstream             If a datagram matching this row's Dest. Group
                       and Source is received on the OSPF autonomous system, if only correct Upstream
                       interface, then it is forwarded into the backbone
by the source area's multicast ABR.

7.2.3.2 Inter-Area Datagram's Shortest-Path Tree

In across the case listed
                       Downstream interfaces.

TTL                    The minimum number of inter-area multicast routing, it is usually impossible to
build a complete shortest-path delivery tree.  Incomplete trees are hops a
fact of life because each OSPF area's complete topological and group
membership information is not distributed between OSPF areas.
Topological estimates are made through the use datagram must cross
                       to reach any of wild-card receivers
and OSPF Summary-Links LSAs.

If the source of Dest. Group's members.  An
                       MOSPF router may discard a multicast datagram resides in the same area as the
router performing the calculation, the pruning process must be careful
to ensure if it can see
                       that branches leading the datagram has insufficient TTL to other areas are not removed from reach
                       even the
tree.  Only those branches having no closest group members nor wild-card
multicast receivers are pruned.  Branches containing wild-card multicast
receivers must be retained since member.

The information in the local routers do forwarding cache is not know whether aged or periodically
refreshed:  It is maintained as long as there are any group members residing in other areas.

If system resources
available (e.g., memory) or until the source next topology change.  The
contents of a multicast datagram resides in a different area than
the router performing the calculation, forwarding cache will change when:

    o  The topology of the details describing OSPF internetwork changes, forcing all of
       the local
topology surrounding shortest path trees to be recalculated.  (Once the source station cache
       has been flushed, entries are not known.  However, this
information can be estimated using information provided by Summary-Links
LSAs rebuilt.  If another packet
       for the source subnetwork.  In this case, the base one of the tree

begins with branches directly connecting previous (Dest. Group, Source) pairs is
       received, then a "new" cache entry for that pair will be
       created then.)

    o  There is a change in the source subnetwork to each
of the local area's inter-area multicast forwarders.  Datagrams sourced
from outside the local area will enter Group-Membership LSAs indicating that
       the area via one distribution of its inter-
area multicast forwarders, so they all must individual group members has changed.

7.2.2 Mixing MOSPF and OSPF Routers

MOSPF routers can be part of combined with non-multicast OSPF routers. This
permits the candidate
distribution tree.

Since each inter-area gradual deployment of MOSPF and allows experimentation with
multicast forwarder routing on a limited scale.

It is also important to note that an ABR, it must
maintain a separate link state database for each attached area.  Thus
each inter-area multicast forwarder MOSPF router is required to calculate a separate
forwarding tree for each of eliminate
all non-multicast OSPF routers when it builds its attached areas.

7.2.4 Inter-Autonomous System Multicasting with source-based shortest-
path delivery tree.  (An MOSPF

Inter-Autonomous System multicasting involves router can determine the situation where a
datagram's source or some multicast
capability of its destination group members are in
different OSPF Autonomous Systems.  In OSPF terminology, "inter-AS"
communication also refers to connectivity between an OSPF domain and
another routing domain which could be within the same Autonomous System
from any other router based on the perspective setting of an Exterior Gateway Protocol.

To facilitate inter-AS multicast routing, selected Autonomous System
Boundary Routers (ASBRs) are configured as "inter-AS multicast
forwarders."  MOSPF makes the assumption that each inter-AS multicast
forwarder executes an inter-AS multicast routing protocol which forwards
multicast datagrams multicast-
capable bit (MC-bit) in a reverse path forwarding (RPF) manner.  Since the publication Options field of the MOSPF RFC, a term has been defined for such a
router:  Multicast Border Router.  See section 9 each router's link state
advertisements.)  The omission of non-multicast routers may create a
number of potential problems when forwarding multicast traffic:

    o  The Designated Router for a multi-access network must be an overview of
       MOSPF router.  If a non-multicast OSPF router is elected the
MBR concepts.  Each inter-AS
       DR, the subnetwork will not be selected to forward multicast forwarder
       datagrams since a non-multicast DR cannot generate Group-
       Membership LSAs for its subnetwork (because it is not running
       IGMP, so it won't hear IGMP Host Membership Reports).

    o  Even though there may be unicast connectivity to a wildcard destination,
       there may not be multicast
receiver in each connectivity.  For example, the only
       path between two points could require traversal of its attached areas.  This guarantees that each
inter-AS multicast forwarder remains on all pruned shortest-path trees
and receives all multicast datagrams. a non-
       multicast-capable OSPF router.

    o  The details of inter-AS forwarding are very similar of multicast and unicast datagrams between two
       points may follow different paths, making some routing problems
       a bit more challenging to inter-area
forwarding.  On solve.

7.2.3 Inter-Area Routing with MOSPF

Inter-area routing involves the "inside" case where a datagram's source and some
of the its destination group members reside in different OSPF domain, areas.  It
should be noted that the forwarding of multicast ASBR
must conform datagrams continues to all
be determined by the requirements contents of intra-area and inter-area
forwarding.  Within the OSPF domain, group members are reached by forwarding cache which is still
built from the
usual forward path computations, local group database and paths to external sources are
approximated by a reverse-path the datagram source-based tree, with the multicast
ASBR standing in for the actual source.  When trees.
The major differences are related to the source way that group membership
information is within the
OSPF AS, propagated and there are external group members, it falls to the inter-
AS multicast forwarders, in their role as wildcard receivers, to make
sure way that the data gets out inter-area source-based
tree is constructed.

7.2.3.1 Inter-Area Multicast Forwarders

In MOSPF, a subset of an area's Area Border Routers (ABRs) function as
"inter-area multicast forwarders."  An inter-area multicast forwarder is
responsible for the OSPF domain forwarding of group membership information and sent off in
multicast datagrams between areas.  Configuration parameters determine
whether or not a particular ABR also functions as an inter-area
multicast forwarder.

Inter-area multicast forwarders summarize their attached areas' group
membership information to the
correct direction.

7.3 Protocol-Independent Multicast (PIM)

The Protocol Independent Multicast (PIM) routing protocols have been
developed backbone by originating new Group-
Membership LSAs into the Inter-Domain Multicast Routing (IDMR) working group of backbone area.  Note that the IETF.  The objective summarization of the IDMR working
group membership in MOSPF is to develop one--or
possibly more than one--standards-track multicast routing protocol(s) asymmetric.  This means that can provide scaleable multicast routing across the Internet.

PIM while group
membership information from non-backbone areas is actually two protocols:  PIM - Dense Mode (PIM-DM) and PIM -
Sparse Mode (PIM-SM).  In flooded into the remainder of this introduction, any
references to "PIM" apply equally well to either of
backbone, but group membership from the two protocols...
there is no intention to imply that there is only one PIM protocol.
While PIM-DM and PIM-SM share part of their names, and they do have
related control messages, they are actually two completely independent
protocols.

PIM receives its name because it backbone (or from any other
non-backbone areas) is not dependent on the mechanisms
provided by any particular unicast routing protocol.  However, flooded into any
implementation supporting PIM requires non-backbone area(s).

To permit the presence forwarding of a unicast routing
protocol to provide routing table information and to adapt to topology
changes.

PIM makes a clear distinction multicast traffic between areas, MOSPF
introduces the concept of a "wild-card multicast routing protocol that
is designed for dense environments and one that receiver."  A wild-card
multicast receiver is designed for sparse
environments.  Dense-mode refers to a protocol router that is designed to
operate receives all multicast traffic
generated in an environment where group members are relatively densely
packed area.  In non-backbone areas, all inter-area multicast
forwarders operate as wild-card multicast receivers.  This guarantees
that all multicast traffic originating in any non-backbone area is
delivered to its inter-area multicast forwarder, and bandwidth then if necessary
into the backbone area.  Since the backbone knows group membership for
all areas, the datagram can be forwarded to the appropriate location(s)
in the OSPF autonomous system, if only it is plentiful.  Sparse-mode refers forwarded into the backbone
by the source area's multicast ABR.

7.2.3.2 Inter-Area Datagram's Shortest-Path Tree

In the case of inter-area multicast routing, it is usually impossible to
build a protocol
that is optimized for environments where group members complete shortest-path delivery tree.  Incomplete trees are distributed
across many regions a
fact of the Internet life because each OSPF area's complete topological and bandwidth group
membership information is not necessarily
widely available.  It is important to note that sparse-mode does not
imply that the group has a few members, just that they distributed between OSPF areas.

Topological estimates are widely
dispersed across made through the Internet.

The designers use of PIM-SM argue that DVMRP and MOSPF were developed for
environments where group members are densely distributed, wild-card receivers
and bandwidth
is relatively plentiful.  They emphasize OSPF Summary-Links LSAs.

If the source of a multicast datagram resides in the same area as the
router performing the calculation, the pruning process must be careful
to ensure that when group members and
senders branches leading to other areas are sparsely distributed across a wide area, DVMRP and MOSPF
do not provide removed from the most efficient
tree.  Only those branches having no group members nor wild-card
multicast delivery service.  The
DVMRP periodically sends receivers are pruned.  Branches containing wild-card multicast packets over many links that
receivers must be retained since the local routers do not
lead to know whether
there are any group members, while MOSPF members residing in other areas.

If the source of a multicast datagram resides in a different area than
the router performing the calculation, the details describing the local
topology surrounding the source station are not known.  However, this
information can send group membership be estimated using information over links that do not lead to senders or receivers.

7.3.1 PIM - Dense Mode (PIM-DM)

While the PIM architecture was driven provided by Summary-Links
LSAs for the need to provide scaleable
sparse-mode delivery trees, PIM also defines a new dense-mode protocol
instead source subnetwork.  In this case, the base of relying on existing dense-mode protocols such as DVMRP and
MOSPF.  It is envisioned that PIM-DM would be deployed in resource rich
environments, such as a campus LAN where group membership is relatively
dense and bandwidth is likely to be readily available.  PIM-DM's control
messages are similar to PIM-SM's by design.

[This space was intentionally left blank.]

PIM - Dense Mode (PIM-DM) is similar to DVMRP in that it employs the
Reverse Path Multicasting (RPM) algorithm.  However, there are several
important differences between PIM-DM and DVMRP:

    o  To find routes back tree
begins with branches directly connecting the source subnetwork to sources, PIM-DM relies on each
of the presence local area's inter-area multicast forwarders.  Datagrams sourced
from outside the local area will enter the area via one of an existing unicast routing table.  PIM-DM is independent its inter-
area multicast forwarders, so they all must be part of the mechanisms of any specific unicast routing protocol.  In
       contrast, DVMRP contains candidate
distribution tree.

Since each inter-area multicast forwarder is also an integrated routing protocol that
       makes use of its own RIP-like exchanges to build its own unicast
       routing table (so ABR, it must
maintain a router may orient itself with respect to
       active source(s)).  MOSPF augments the information in the OSPF separate link state database, thus MOSPF must run in conjunction with
       OSPF.

    o  Unlike the DVMRP which calculates a set of child interfaces database for each (source, group) pair, PIM-DM simply forwards attached area.  Thus
each inter-area multicast
       traffic on all downstream interfaces until explicit prune
       messages are received.  PIM-DM forwarder is willing to accept packet
       duplication to eliminate routing protocol dependencies and required to avoid the overhead inherent in determining calculate a separate
forwarding tree for each of its attached areas.

7.2.4 Inter-Autonomous System Multicasting with MOSPF

Inter-Autonomous System multicasting involves the parent/child
       relationships.

For those cases situation where group members suddenly appear on a pruned branch
datagram's source or some of the delivery tree, PIM-DM, like DVMRP, employs graft messages to
re-attach the previously pruned branch its destination group members are in
different OSPF Autonomous Systems.  In OSPF terminology, "inter-AS"
communication also refers to connectivity between an OSPF domain and
another routing domain which could be within the delivery tree.

8. "SPARSE MODE" ROUTING PROTOCOLS

The most recent additions to same Autonomous System
from the set perspective of an Exterior Gateway Protocol.

To facilitate inter-AS multicast routing protocols are
called "sparse mode" protocols.  They routing, selected Autonomous System
Boundary Routers (ASBRs) are designed from a different
perspective than configured as "inter-AS multicast
forwarders."  MOSPF makes the "dense mode" protocols assumption that we have already
examined.  Often, they are not data-driven, each inter-AS multicast
forwarder executes an inter-AS multicast routing protocol which forwards
multicast datagrams in the sense that a reverse path forwarding
state is set up in advance, and they trade off using bandwidth liberally
(which is (RPF) manner.  Since
the publication of the MOSPF RFC, a valid thing to do in term has been defined for such a campus LAN environment)
router:  Multicast Border Router.  See section 9 for other
techniques that are much more suited to scaling over large WANs, where
bandwidth an overview of the
MBR concepts.  Each inter-AS multicast forwarder is scarce and expensive.

These emerging routing protocols include:

    o  Protocol Independent Multicast - Sparse Mode (PIM-SM), and

    o  Core-Based Trees (CBT).

While these routing protocols a wildcard multicast
receiver in each of its attached areas.  This guarantees that each
inter-AS multicast forwarder remains on all pruned shortest-path trees
and receives all multicast datagrams.

The details of inter-AS forwarding are designed very similar to operate efficiently over a
wide area network where bandwidth is scarce inter-area
forwarding.  On the "inside" of the OSPF domain, the multicast ASBR
must conform to all the requirements of intra-area and inter-area

forwarding.  Within the OSPF domain, group members may be
quite sparsely distributed, this is not are reached by the
usual forward path computations, and paths to imply that they external sources are only
suitable
approximated by a reverse-path source-based tree, with the multicast
ASBR standing in for small groups.  Sparse doesn't mean small, rather it the actual source.  When the source is
meant to convey that within the groups are widely dispersed,
OSPF AS, and thus there are external group members, it is
wasteful falls to (for instance) flood the inter-
AS multicast forwarders, in their role as wildcard receivers, to make
sure that the data periodically across gets out of the
entire internetwork.

8.1  Protocol-Independent Multicast - Sparse Mode (PIM-SM)

As described previously, PIM also defines OSPF domain and sent off in the
correct direction.

7.2.5 MOSPF Tree Building and Forwarding Summary

MOSPF builds a "dense-mode" or source-based separate tree variant.  Again, for each (source, group) combination.  The
tree is rooted at the two protocols are quite unique, source, and other than
control messages, they have very little in common.  Note that while PIM
integrates control message processing and data packet forwarding among
PIM-Sparse and -Dense Modes, PIM-SM and PIM-DM must run in separate
regions.  All groups includes each of the group members as
leaves.  If the (M)OSPF domain is divided into multiple areas, the tree
is built in pieces, one area at a region time.  These pieces are either sparse-mode or dense-mode.

PIM-Sparse Mode (PIM-SM) has been developed to provide a multicast
routing protocol that provides efficient communication between members
of sparsely distributed groups--the type then glued
together at the area border routers which connect the various areas.

Sometimes group membership of groups that are likely certain areas (or other ASes) is unknown.
MOSPF forces the tree to
be common in wide-area internetworks.  PIM's designers observed that
several hosts wishing extend to these areas and/or ASes by adding
their area border routers/AS boundary routers to participate in a multicast conference do not
justify flooding the entire internetwork periodically with the group's tree as "wildcard
multicast traffic.

Noting today's existing MBone scaling problems, and extrapolating to a
future receivers".

Construction of ubiquitous multicast (overlaid with perhaps thousands the tree within a given area depends on the location of
small, widely dispersed groups), it
the source.  If the source is not hard to imagine within the area, "forward" costs are used,
and the path within the area follows the "forward path" , that existing
multicast routing protocols will experience scaling problems.  To
eliminate these potential scaling issues, PIM-SM is designed to limit
multicast traffic so is, the
same route that only those routers interested in receiving
traffic for a particular group "see" it.

PIM-SM differs unicast packets would take from existing dense-mode protocols in two key ways:

    o  Routers with adjacent or downstream members are required source to
       explicitly join a sparse mode delivery tree by transmitting
       join messages. group member.
If a router does not join the pre-defined
       delivery tree, it will not receive multicast traffic addressed source belongs to the group.

       In contrast, dense-mode protocols assume downstream group
       membership and forward multicast traffic on downstream links
       until explicit prune messages a different area, or a different AS, "reverse
costs" are received.  Thus, used, resulting in reverse path forwarding through the default area.
(Reverse path forwarding action of dense-mode routing protocols is less preferred, but is forced because OSPF
Summary LSAs and AS-External LSAs only advertise costs in the reverse
direction).

MOSPF's tree-building process is data-driven.  Despite having Group LSAs
present in each area's link state database, no trees are built unless
multicast data is seen from a source to forward
       all traffic, while a group (of course, if the default action of Link
State Database indicates no Group LSAs for this group, then no tree is
built since there must be no group members present in this area).  So,
despite MOSPF being a sparse-mode protocol "Dense-mode" routing protocol, it is to block traffic unless not based on
broadcast-and-prune, but rather it is a so-called "explicit-join"
protocol.

If a packet arrives for a (source, group) pair which has not been explicitly requested.

    o  PIM-SM evolved from seen
by this router before, the Core-Based Trees (CBT) approach router executes the Dijkstra algorithm over
the relevant links in the Link State Database.  The Dijkstra algorithm
outputs the "source-rooted" shortest-path tree for this (source, group),
as described earlier.  The router examines its position in the tree,
caching the expected inbound interface for packets from this source, and
listing the outbound interface(s) that
       it employs lead to active downstream
receivers.  Subsequent traffic is examined against this cached data.
The traffic from the concept source must arrive on the correct interface to be
processed further.

7.3 Protocol-Independent Multicast (PIM)

The Protocol Independent Multicast (PIM) routing protocols have been
developed by the Inter-Domain Multicast Routing (IDMR) working group of a "core" (or rendezvous point (RP) in
       PIM-SM terminology) where receivers "meet" sources.

[This space was intentionally left blank.]

========================================================================

                    S1                                      S2
                   ___|___                                 ___|___
                        |                                   |
                        |                                   |
                        #                                   #
                         \                                 /
                          \                               /
                           \_____________RP______________/
                                       ./|\.
                      ________________// | \\_______________
                     /         _______/  |  \______         \
                     #         #         #         #         #
                  ___|___   ___|___   ___|___   ___|___   ___|___
                        |     |   |        |     |            |
                        R     R   R        R     R            R
LEGEND

   #   PIM Router
   R   Multicast Receiver

Figure 17: Rendezvous Point
========================================================================

When joining a group, each receiver uses IGMP to notify its directly-
attached router, which in turn joins the multicast delivery tree by
sending an explicit PIM-Join message hop-by-hop toward
the group's
RP.  A source uses IETF.  The objective of the RP to announce its presence, and act as a conduit IDMR working group is to members develop one--or
possibly more than one--standards-track multicast routing protocol(s)
that have joined can provide scalable multicast routing across the group.  This model requires sparse-mode
routers Internet.

PIM is actually two protocols:  PIM - Dense Mode (PIM-DM) and PIM -
Sparse Mode (PIM-SM).  In the remainder of this introduction, any
references to maintain a bit "PIM" apply equally well to either of state (the RP-set for the sparse-mode
region) prior two protocols...
there is no intention to the arrival imply that there is only one PIM protocol.
While PIM-DM and PIM-SM share part of data.  In contrast, because dense-mode
protocols are data-driven, their names, and they do not store any state for a group until
the arrival of have
related control messages, they are really two independent protocols.

PIM receives its first data packet.

There name because it is only one RP-set per sparse-mode domain, not per group.
Moreover, dependent on the creator of a group is not involved in RP selection.  Also,
there is no such concept as a "primary" RP.  Each group has precisely
one RP at mechanisms
provided by any given time.  In the event of particular unicast routing protocol.  However, any
implementation supporting PIM requires the failure presence of an RP, a new
RP-set is distributed which does not include the failed RP.

8.1.1 Directly Attached Host Joins a Group

When there is more than one PIM router connected unicast routing
protocol to provide routing table information and to adapt to topology
changes.

PIM makes a multi-access LAN,
the router with the highest IP address clear distinction between a multicast routing protocol that
is selected to function as the
Designated Router (DR) for the LAN.  The DR may or may not be
responsible designed for the transmission of IGMP Host Membership Query messages,
but does send Join/Prune messages toward the RP, dense environments and maintains the
status of the active RP one that is designed for local senders sparse
environments.  Dense-mode refers to multicast groups.

When the DR receives an IGMP Report message for a new group, the DR
determines if the group protocol that is RP-based or not by examining the designed to
operate in an environment where group
address.  If the address indicates members are relatively densely
packed and bandwidth is plentiful.  Sparse-mode refers to a SM protocol
that is optimized for environments where group (by virtue members are distributed
across many regions of the group-
specific state Internet and bandwidth is not necessarily
widely available.  It is important to note that sparse-mode does not
imply that even inactive groups have stored in all PIM
routers), the DR performs group has a deterministic hash function few members, just that they are widely
dispersed across the Internet.

The designers of PIM-SM argue that DVMRP and MOSPF were developed for
environments where group members are densely distributed, and bandwidth
is relatively plentiful.  They emphasize that when group members and
senders are sparsely distributed across a wide area, DVMRP and MOSPF
exhibit inefficiencies (but both are efficient in delivering packets).
The DVMRP periodically sends multicast packets over many links that do
not lead to group members, while MOSPF propagates group membership
information across links that may not lead to senders or receivers.

7.3.1 PIM - Dense Mode (PIM-DM)

While the PIM architecture was driven by the need to provide scalable
sparse-mode region's RP-set delivery trees, PIM also defines a new dense-mode protocol
instead of relying on existing dense-mode protocols such as DVMRP and
MOSPF.  It is envisioned that PIM-DM would be deployed in resource rich
environments, such as a campus LAN where group membership is relatively
dense and bandwidth is likely to be readily available.  PIM-DM's control
messages are similar to PIM-SM's by design.

PIM - Dense Mode (PIM-DM) is similar to DVMRP in that it employs the
Reverse Path Multicasting (RPM) algorithm.  However, there are several
important differences between PIM-DM and the DVMRP:

    o  To find routes back to sources, PIM-DM relies on the presence
       of an existing unicast routing table.  PIM-DM is independent of
       the mechanisms of any specific unicast routing protocol.  In
       contrast, DVMRP contains an integrated routing protocol that
       makes use of its own RIP-like exchanges to build its own unicast
       routing table (so a router may orient itself with respect to
       active source(s)).

    o  Unlike the DVMRP, which calculates a set of child interfaces for
       each (source, group) pair, PIM-DM simply forwards multicast
       traffic on all downstream interfaces until explicit prune
       messages are received.  PIM-DM is willing to accept packet
       duplication to eliminate routing protocol dependencies and
       to avoid the overhead inherent in determining the parent/child
       relationships.

For those cases where group members suddenly appear on a pruned branch
of the delivery tree, PIM-DM--like DVMRP--employs graft messages to re-
attach the previously pruned branch to the delivery tree.

7.3.1.1 PIM-DM Tree Building and Forwarding Summary

Dense-mode PIM builds source-based trees by default.  It uses the RPM
algorithm, which is what DVMRP uses:  Thus, PIM-DM is a data-driven
protocol that floods packets to the edges of the PIM-DM domain, and
expects prunes to be returned on inactive branches.  A minor difference
from DVMRP is that PIM-DM floods packets for new (source, group) pairs
on all non-incoming interfaces.  PIM-DM trades off a bit of extra
flooding traffic for a simpler protocol design.

Pruning in PIM-DM only happens via explicit Prune messages, which are
multicast on broadcast links (if there are other routers present which
hear a prune, and they still wish to receive traffic for this group to
support active receivers that are downstream of them, then these other
routers must multicast PIM-Join packets to ensure they remain attached
to the distribution tree).  Finally, PIM-DM uses a reliable graft
mechanism to enable previously-sent prunes to be "erased" when new
downstream group members appear after a prune had been sent.

Since PIM-DM uses RPM, it implements a reverse-path check on all packets
which it receives.  Again, this check verifies that received packets
arrive on the interface that the router would use if it needed to
send a packet toward the source's prefix.  Since PIM-DM does not have
its own routing protocol (as DVMRP does), it uses the existing unicast
routing protocol to locate itself with respect to the source(s) of
multicast packets it has seen.

8. "SPARSE MODE" ROUTING PROTOCOLS

The most recent additions to the set of multicast routing protocols are
called "sparse mode" protocols.  They are designed from a different
perspective than the "dense mode" protocols that we have already
examined.  Often, they are not data-driven, in the sense that forwarding
state is set up in advance, and they trade off using bandwidth liberally
(which is a valid thing to do in a campus LAN environment) for other
techniques that are much more suited to scaling over large WANs, where
bandwidth is scarce and expensive.

These emerging routing protocols include:

    o  Protocol Independent Multicast - Sparse Mode (PIM-SM), and

    o  Core-Based Trees (CBT).

While these routing protocols are designed to operate efficiently over a
wide area network where bandwidth is scarce and group members may be
quite sparsely distributed, this is not to imply that they are only
suitable for small groups.  Sparse doesn't mean small, rather it is
meant to convey that the groups are widely dispersed, and thus it is
wasteful to (for instance) flood their data periodically across the
entire internetwork.

CBT and PIM-Sparse Mode (PIM-SM) have been designed to provide highly
efficient communication between members of sparsely distributed groups--
the type of groups that are likely to be prevalent in wide-area
internetworks.  The designers of these sparse-mode protocols' have
observed that several hosts participating in a multicast session do not
require periodically broadcasting their traffic across the entire
internetwork.

Noting today's existing MBone scaling problems, and extrapolating to a
future of ubiquitous multicast (overlaid with perhaps thousands of
widely scattered groups), it is not hard to imagine that existing
multicast routing protocols will experience scaling problems.  To
mitigate these potential scaling issues, PIM-SM and CBT are designed
to ensure that multicast traffic only crosses routers that have
explicitly joined a shared tree on behalf of group members.

8.1  Protocol-Independent Multicast - Sparse Mode (PIM-SM)

As described previously, PIM also defines a "dense-mode" or source-based
tree variant.  Again, the two protocols are quite unique, and other than
control messages, they have very little in common.  Note that although
PIM integrates control message processing and data packet forwarding
among PIM-Sparse and -Dense Modes, PIM-SM and PIM-DM must never run in
the same region at the same time.  Essentially, a region is a set of
routers which are executing a common multicast routing protocol.

PIM-SM differs from existing dense-mode protocols in two key ways:

    o  Routers with adjacent or downstream members are required to
       explicitly join a sparse mode delivery tree by transmitting
       join messages.  If a router does not join the pre-defined
       delivery tree, it will not receive multicast traffic addressed
       to the group.

       In contrast, dense-mode protocols assume downstream group
       membership and forward multicast traffic on downstream links
       until explicit prune messages are received.  Thus, the default
       forwarding action of dense-mode routing protocols is to forward
       all traffic, while the default action of a sparse-mode protocol
       is to block traffic unless it has been explicitly requested.

    o  PIM-SM evolved from the Core-Based Trees (CBT) approach in that
       it employs the concept of a "core" (or rendezvous point (RP) in
       PIM-SM terminology) where receivers "meet" sources.

========================================================================

                      S1                                     S2
                    ___|___                               ___|___
                         |                                 |
                         |                                 |
                         #                                 #
                          \                               /
                           \_____________RP______________/
                                       ./|\.
                      ________________// | \\_______________
                     /         _______/  |  \______         \
                     #         #         #         #         #
                  ___|___   ___|___   ___|___   ___|___   ___|___
                        |     |   |        |     |            |
                        R     R   R        R     R            R
LEGEND

   #   PIM Router
   R   Multicast Receiver

Figure 17: Rendezvous Point
========================================================================

When joining a group, each receiver uses IGMP to notify its directly-
attached router, which in turn joins the multicast delivery tree by
sending an explicit PIM-Join message hop-by-hop toward the group's RP.
A source uses the RP to announce its presence, and act as a conduit to
members that have joined the group.  This model requires sparse-mode

routers to maintain a small amount of state (the RP-set for the sparse-
mode region) prior to the arrival of data.

There is only one RP-set per sparse-mode domain.  By using a hash
function, each PIM-SM router can map a group address uniquely to one of
the members of the RP-set (to determine the group's RP).  At any given
time, each group has precisely one RP.  In the event of the failure of
an RP, a new RP-set is distributed which does not include the failed RP.

8.1.1 Directly Attached Host Joins a Group

When there is more than one PIM router connected to a multi-access LAN,
the router with the highest IP address is selected to function as the
Designated Router (DR) for the LAN.  The DR sends Join/Prune messages
toward the RP.

When the DR receives an IGMP Report message for a new group, it performs
a deterministic hash function over the sparse-mode region's RP-set to
uniquely determine the RP for the group.

========================================================================

                                      Source (S)
                                      _|_____
                                         |
                                         |
                                         #
                                        / \
                                       /   \
                                      /     \
                                     #       #
                |                   /         \
                |                  /           \
       Host     |                 /             \
           -----|- DR - - - - - -#- - - - - - - -RPg
     (receiver) |  ----Join-->  ----Join-->

LEGEND

   #   PIM Router                 RPg  Rendezvous Point for group g

Figure 18: Host Joins a Multicast Group
========================================================================

After performing the lookup, the DR creates a multicast forwarding entry
for the (*, group) pair and transmits a unicast PIM-Join message toward
the RP for this specific group.  The (*, group) notation indicates an
(any source, group) pair.  The intermediate routers forward the unicast
PIM-Join message, creating a forwarding entry for the (*, group) pair

only if such a forwarding entry does not yet exist.  Intermediate
routers must create a forwarding entry so that they will be able to
forward future traffic downstream toward the DR which originated the
PIM-Join message.

8.1.2 Directly Attached Source Sends to a Group

When a source first transmits a multicast packet to a group, its DR
forwards the datagram to the RP for subsequent distribution along the
group's delivery tree.  The DR encapsulates the initial multicast
packets in PIM-SM-Register packets and unicasts them toward the group's
RP.  The PIM-SM-Register packets inform the RP of a new source.  The RP
may then elect to transmit PIM-Join messages back toward the source's DR
to join this source's shortest-path tree, which will allow future
unencapsulated packets to flow from this source's DR to the group's RP.

========================================================================

                                Source (S)
                                 _|____
                                    |
                                    |
                                    DR v
                                   / ^\ v
                                  /  ^ \ v
                                 /    ^ \ v
                                #      ^ # v
                               /        ^ \ v
                              /          ^ \ v
Host        |                /            ^ \ v            |       Host
      ------|- # - - - - - -#- - - - - - - - RP - - - # - -|-----
(receiver)  |   < ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~  ~ ~ ~ ~ ~ > | (receiver)

LEGEND

   #   PIM Router                  v v v  PIM-SM-Register
   RP  Rendezvous Point            ^ ^ ^  PIM-Join
                                   ~ ~ ~  Resend to group members

Figure 19: Source sends to a Multicast Group
========================================================================

Unless the RP decides to join the source's SPT, rooted at the source's
DR, the (source, group) state is not created in all the routers between
source's DR and the RP, and the DR must continue to send the source's
multicast IP packets to the RP as unicast packets encapsulated within
unicast PIM-SM-Register packets.  The DR may stop forwarding multicast

packets encapsulated in this manner once it has received a PIM-Register-
Stop message from the group's RP.  The RP may send PIM-Register-Stop
messages if there are no downstream receivers for a group, or if the RP
has successfully joined the source's shortest-path tree (SPT).

8.1.3 Shared Tree (RP-Tree) or Shortest Path Tree (SPT)?

The RP-tree provides connectivity for group members but does not
optimize the delivery path through the internetwork.  PIM-SM allows
routers to either a) continue to receive multicast traffic over the
shared RP-tree, or b) subsequently create a source-based shortest-path
tree on behalf of their attached receiver(s).  Besides reducing the
delay between this router and the source (beneficial to its attached
receivers), the shared tree also reduces traffic concentration effects
on the RP-tree.

A PIM-SM router with local receivers has the option of switching to the
source's shortest-path tree (i.e., source-based tree) once it starts
receiving data packets from the source.  The change-over may be
triggered if the data rate from the source exceeds a predefined
threshold.  The local receiver's last-hop router does this by sending a
PIM-Join message toward the active source.  After the source-based SPT
is active, protocol mechanisms allow a Prune message for that source to
be transmitted to the group's RP, thus removing this router from the
this source's shared RP-tree.  Alternatively, the DR may be configured
to never switch over to the source-based SPT, or some other metric might
be used to control when to switch to a source-based SPT.

========================================================================

LEGEND                                  Source
                                          (S)
  #   PIM Router                          _|____
  RP  Rendezvous Point                       |
 ` `  RP-Tree (Shared)                       |
 % %  Shortest-Path Tree                   % # `
      (Source-based)                      % / \ `
                                         % /   \ `
                                        % /     \ `
                   Designated          % #       # `
                     Router           % /         \ `
                                     % /           \ `
           Host      |  <-% % % % % % /             \ `
                -----|-#-------------#---------------RP
          (receiver) | <-` ` ` ` ` ` ` ` ` ` ` ` ` ` `
                     |

Figure 20: Shared RP-Tree and Shortest Path Tree (SPT)
========================================================================

Besides a last-hop router being able to switch to a source-based tree,
there is also the capability of the RP for a group to transition to a
source's shortest-path tree.  Similar controls (bandwidth threshold,
administrative metrics, etc.) may be used at an RP to influence these
decisions.  The RP only joins the source's DR's SPT if local policy
controls permit this.

8.1.4  PIM-SM Tree Building and Forwarding Summary

PIM-SM can use both source-based and shared trees.  In fact, a given
group may have some routers on its shared tree, and others on source-
based trees, simultaneously.  By default, PIM-SM uses shared trees
rooted at the Rendezvous Point, but regardless of which tree type is in
use, there is no broadcasting of any traffic.  Interested receivers use
IGMP to uniquely determine the RP for inform their local PIM-SM router(s), then the
group.

========================================================================

                                      Source (S)
                                      _|____
                                         |
                                         |
                                         #
                                        / \
                                       /   \
                                      /     \
                                     #       #
                                    /         \ subnetwork's PIM-
SM Designated      /           \
       Host      | Router         /             \  Rendezvous Point
            -----|- # - - - - - -#- - - - - - - -RP   for group G
      (receiver) |  ----Join-->  ----Join-->
                 |

LEGEND

   #   PIM Router                 RP  Rendezvous Point

Figure 18: Host Joins a Multicast Group
========================================================================

After performing then issues PIM-Join messages (on behalf of the lookup,
receivers) toward the DR creates a multicast group's RP.  These join messages establish
forwarding entry
for the (*, group) pair and transmits a unicast PIM-Join message toward state in the primary RP for this specific group.  The (*, group) notation
indicates an (any source, group) pair.  The intermediate routers forward which is used in the unicast PIM-Join message, creating a future
to make  forwarding entry for the
(*, group) pair only if such decisions.  If a packet is received which has no
pre-established forwarding entry does not yet exist.
Intermediate routers state, it is dropped.

As each packet is received, it must create match a pre-existing forwarding entry so that they will be
able to forward future traffic downstream toward the DR
cache entry.  If it does, then you know which interface on which originated
the PIM-Join message.

8.1.2 Directly Attached Source Sends to a Group

When a source first transmits a multicast packet to do
the a group, its DR
forwards reverse-path check.  This is consistent with the datagram forwarding
technique used by PIM-DM, and similar to the primary RP for subsequent distribution
along the group's delivery tree. that used by DVMRP.  The DR encapsulates
unicast routing table provides the initial

multicast packets in a PIM-SM-Register packet and unicasts them necessary information to determine
the best route toward the primary RP for group's RP; the group.  The PIM-SM-Register packet informs the
RP of a new source which causes must have arrived on
the active RP interface this router would use to transmit PIM-Join
messages back send traffic toward the source's DR.  The routers between group's
RP.  Note that the RP and forwarding state which is created by PIM-SM is uni-
directional (it allows traffic to flow from the source's DR use the received PIM-Join messages (from toward the RP)
RP, not away from it).

8.2 Core Based Trees (CBT)

Core Based Trees is another multicast architecture that is based on a
shared delivery tree.  It is specifically intended to
create forwarding state for address the new (source, group) pair.  Now all
routers from
important issue of scalability when supporting multicast applications
across the active RP public Internet, and is also suitable for this sparse-mode group use within private
intranetworks.

Similar to PIM-SM, CBT is protocol-independent.  CBT employs the source's DR
will
information contained in the unicast routing table to build its shared
delivery tree.  It does not care how the unicast routing table is
derived, only that a unicast routing table is present.  This feature
allows CBT to be able deployed without requiring the presence of any specific
unicast routing protocol.

"Protocol independence" doesn't necessarily have to forward future unencapsulated mean that multicast packets from
this source subnetwork
paths are the same set of routers and links used by unicast routing,
though it is easy to make this assumption (it may indeed hold true in

some cases).  An underlying routing protocol could collect both unicast-
and multicast- related information, so that unicast routes could be
calculated based on the RP.  Until unicast information, and multicast routes based
on the (source, group) state has
been created in all multicast information.  If the path (set of intervening routers between the RP
and source's DR, the DR
must continue to send links) used between any two network nodes is the source's same for multicast IP packets to
and for unicast, then it can be said that the RP as unicast packets encapsulated within and multicast
topologies overlap (for that set of paths).

Where multicast and unicast PIM-Register packets.  The
DR may stop forwarding topologies do happen to overlap, multicast packets encapsulated in this manner
once it has received a PIM-Register-Stop message
and unicast paths could be calculated from the active RP for
this group.  The RP may send PIM-Register-Stop messages if there are no
downstream receivers for a group, or if the RP has successfully joined
the (source, group) tree (which originates at the source's DR).

========================================================================

                                Source (S)
                                _|____
                                   |
                                   |
                                   # v
                                  /.\ ,
                                 /  ^\ v
                                /    .\ ,
                               #      ^# v
                              /        .\ ,
             Designated      /          ^\ v
 Host      | Router         /            .\ ,             |       Host
      -----|-#- - - - - - -#- - - - - - - -RP- - - # - - -|-----
(receiver) |  <~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~   ~ ~ ~ ~ ~>   | (receiver)

LEGEND

   #   PIM Router
   RP  Rendezvous Point
> , >  PIM-Register
< . <  PIM-Join
~ ~ ~  Resend to group members

Figure 19: Source sends to a Multicast Group
========================================================================

8.1.3 Shared Tree (RP-Tree) or Shortest Path Tree (SPT)?

The RP-tree provides connectivity for group members but does not
optimize the delivery path through one set of information
(i.e., unicast).  However, if the internetwork.  PIM-SM allows set of routers to either a) continue to receive and links between two
network nodes differs for multicast traffic over and unicast traffic, then the
shared RP-tree, or b) subsequently create
unicast and multicast topologies are incongruent for that network path.
It's a source-based shortest-path
tree on behalf matter of their attached receiver(s).  Besides reducing the
delay between this router policy whether unicast and multicast topologies are
aligned for any set of network links.

The current version of the source (beneficial CBT specification has adopted a similar
"bootstrap" mechanism to its attached
receivers), the shared tree also reduces traffic concentration effects
on that defined in the RP-tree.

A PIM-SM router with local receivers has the option specification.  It
is an implementation choice whether a dynamic or static mechanism is
used for discovering how groups map to cores.  This process of switching
discovering which core serves which group(s) is what is referred to as
bootstrapping.

Each group has only one core, but one core might serve multiple groups.
Use of the
source's shortest-path tree (i.e., source-based tree) once it starts
receiving data packets from dynamic bootstrap mechanism is only applicable within a
multicast region, not between regions.  The advantage of the source. dynamic
approach is that a region's CBT routers need less configuration.  The change-over may
disadvantage is that core placement could be
triggered particularly sub-optimal
for some set of receivers.  Manual placement means that each group's
core can be "better" positioned relative to a group's members.  CBT's
modular design allows other core discovery mechanisms to be used if such
mechanisms are considered more beneficial to CBT's requirements.  For
inter-domain RP/Core discovery, efforts are underway to standardize (or
at least separately specify) a common mechanism, the data rate intent being that
any shared tree protocol could implement this common interdomain
discovery architecture using its own protocol message types.

In a significant departure from PIM-SM, CBT has decided to maintain its
scaling characteristics by not offering the source exceeds option of optimizing delay
by shifting from a predefined
threshold. Shared Tree (e.g., PIM-SM's RP-Tree) to a Shortest
Path Tree (SPT).  The local receiver's last-hop router does designers of CBT believe that this by sending a
Join message toward the active source.  After the source-based SPT is
active, protocol mechanisms allow a Prune message for critical
decision since when multicasting becomes widely deployed, the same source
to be transmitted need for
routers to maintain large amounts of state information will become the active RP, thus removing this router from
overpowering scaling factor.  Thus CBT's state information (i.e., its
forwarding cache) consists of: (group, incoming interface, {outgoing
interface list}).  Forwarding decisions are made by using the
shared RP-tree.  Alternatively, group's
destination address as the DR may be configured to continue
using search key into the forwarding cache.

Finally, unlike PIM-SM's shared RP-tree and never switch over to the source-based SPT,
or a router could perhaps use a different administrative metric to
decide if and when to switch to tree state, CBT state is bi-directional.
Data may therefore flow in either direction along a source-based tree.

========================================================================

                                          Source (S)
                                          _|____
                                             |
                                            %|
                                           % #
                                          % / \*
                                         % /   \*
                                        % /     \*
                    Designated         % #       #*
                     Router           % /         \*
                                     % /           \*
           Host      |  <-% % % % % % /             \v
                -----|-#- - - - - - -#- - - - - - - -RP
          (receiver) | <* * * * * * * * * * * * * * *
                     |
LEGEND

  #   PIM Router
  RP  Rendezvous Point
 * *  RP-Tree (Shared)
 % %  Shortest-Path Tree (Source-based)

Figure 20: branch.  Thus, data

from a source which is directly attached to an existing tree branch need
not be encapsulated.

8.2.1 Joining a Group's Shared RP-Tree and Shortest Path Tree (SPT)
========================================================================

Besides

A host that wants to join a last-hop router being able multicast group issues an IGMP host
membership report.  This message informs its local CBT-aware router(s)
that it wishes to switch receive traffic addressed to the multicast group. Upon
receipt of an IGMP host membership report for a source-based tree,
there new group, the local CBT
router issues a JOIN_REQUEST which is also processed hop-by-hop, creating
transient join state (incoming interface, outgoing interface) in each
router traversed.

If the capability of JOIN_REQUEST encounters a router that is already on the RP group's
shared tree before it reaches the core router, then that router issues a
JOIN_ACK hop-by-hop back toward the sending router.  If the JOIN_REQUEST
does not encounter an on-tree CBT router along its path towards the
core, then the core router is responsible for responding with a group to transition
JOIN_ACK.  In either case, each intermediate router that forwards the
JOIN_REQUEST towards the core is required to create a
source's shortest-path tree.  Similar controls (bandwidth threshhold,
administrative weights, etc.) can be used at transient "join
state."  This transient "join state" includes the multicast group, and
the JOIN_REQUEST's incoming and outgoing interfaces.  This information
allows an RP intermediate router to influence these
decisions.

8.2 Core Based Trees (CBT)

Core Based Trees is another multicast architecture forward returning JOIN_ACKs along the
exact reverse path to the CBT router which initiated the JOIN_REQUEST.

As the JOIN_ACK travels towards the CBT router that issued the
JOIN_REQUEST, each intermediate router creates new "active state" for
this group.  New branches are established by having the intermediate
routers remember which interface is based on upstream, and which interface(s)
is(are) downstream.  Once a
shared delivery tree.  It new branch is specifically intended to address created, each child router
monitors the
important issue status of scalability when supporting multicast applications
across its parent router with a keepalive mechanism,
the public Internet.

Similar to PIM-SM, CBT "Echo" protocol.  A child router periodically unicasts a
ECHO_REQUEST to its parent router, which is protocol-independent.  CBT employs the
information contained in the unicast routing table then required to build respond
with a unicast ECHO_REPLY message.

If, for any reason, the link between an on-tree router and its shared
delivery tree.  It does not care how parent
should fail, or if the unicast routing table parent router is
derived, only that otherwise unreachable, the
on-tree router transmits a unicast routing table FLUSH_TREE message on its child interface(s)
which begins tearing down all the downstream branches for this group.
Each leaf router is present.  This feature
allows CBT then responsible for re-attaching itself to be deployed without requiring the presence of any specific
unicast routing protocol.

Another similarity to PIM-SM is that CBT has adopted
group's core, thus rebuilding the core discovery
mechanism ("bootstrap" ) defined in shared delivery tree.  Leaf routers
only re-join the PIM-SM specification.  For
inter-domain discovery, efforts are underway to standardize (or shared tree if they have at least
separately specify) a common RP/Core discovery mechanism. one directly-
attached group member.

The intent is
that any shared tree protocol could implement this common discovery
mechanism using its own protocol message types.

In a significant departure from PIM-SM, CBT has decided to maintain it's
scaling characteristics Designated Router (DR) for a given broadcast-capable subnetwork is
elected by CBT's "Hello" protocol.  It functions as the only upstream
router for all groups using that link.  The DR is not offering necessarily the option of shifting from a
Shared Tree (e.g., PIM-SM's RP-Tree) to a Shortest Path Tree (SPT)
best next-hop router to
optimize delay. every core for every multicast group.  The designers of CBT believe
implication is that this it is possible for the DR to receive a critical
decision since when multicasting becomes widely deployed, JOIN_REQUEST
over a LAN, but the DR may need for
routers to maintain large amounts of state information will become redirect the JOIN_REQUEST back across

========================================================================

                                            #- - - -#- - - - -#
                                                    |          \
                                                    |           #
                                                    |
                                                    # - - - - #
      member  |                                     |
       host --|                                     |
              |     --Join-->  --Join-->  --Join--> |
              |- [DR] - - - [:] - - - -[:] - - - - [@]
              |     <--ACK--   <--ACK--   <--ACK--

LEGEND

  [DR]  Local CBT Designated Router
   [:]  CBT Router
   [@]  Core Router
    #   CBT Router that is already on the
overpowering scaling factor.

Finally, unlike PIM-SM's shared tree state,

Figure 21: CBT state Tree Joining Process
========================================================================

the same link to the best next-hop router toward a given group's core.
Data traffic is bi-directional. never duplicated across a link, only JOIN_REQUESTs,
which should be an inconsequential volume of traffic.

8.2.2 Data may therefore flow in Packet Forwarding

When a JOIN_ACK is received by an intermediate router, it either direction along adds
the interface over which the JOIN_ACK was received to an existing
group's forwarding cache entry, or creates a new entry for the multicast
group if one does not already exist.  When a branch.  Thus, data
from CBT router receives a source which is directly attached data
packet addressed to an existing tree branch need any multicast group, it simply forwards the packet
over the outgoing interfaces specified by the group's forwarding cache
entry.

8.2.3 Non-Member Sending

Similar to other multicast routing protocols, CBT does not be encapsulated.

8.2.1 Joining a Group's Shared Tree

A host require that wants to join
the source of a multicast group issues an IGMP host
membership report.  This message informs its local CBT-aware router(s)
that it wishes to receive traffic addressed to packet be a member of the multicast group.
Upon receipt of an IGMP host membership report
However, for a new multicast data packet to reach the active core for the
group, at least one CBT-capable router must be present on the non-member
sender's subnetwork.  The local CBT CBT-capable router issues a JOIN_REQUEST hop-by-hop toward employs IP-in-IP
encapsulation and unicasts the group's data packet to the active core router.

If for
delivery to the JOIN_REQUEST encounters a rest of the multicast group.  Thus, every CBT-capable
router that is already in each CBT region needs a list of corresponding <core, group>
mappings

8.2.4 CBT Tree Building and Forwarding Summary

CBT trees are constructed based on forward paths from the group's
shared tree before it reaches source(s) to
the core router, then core.  Any group only has exactly one active core, as you recall.
As CBT is an explicit-join protocol, no routers forward traffic to a
group unless there are pre-established active receivers for that router issues group
within the CBT domain.

Trees are built using each CBT router's unicast routing table, by
forwarding JOIN_REQUESTs toward a group's core.  The resulting non-
source-specific state is bi-directional, a
JOIN_ACK hop-by-hop back toward the sending router.  If the JOIN_REQUEST
does not encounter an on-tree feature unique to CBT router along its path towards the
core, then trees.
If any group member needs to send to the core router group, zero extra forwarding
state needs to be established...every possible receiver is responsible for responding with already also
a
JOIN_ACK.  In either case, each intermediate router that forwards potential sender, with no penalty of extra state (in the
JOIN_REQUEST towards form of
(source, group) state), in the core routers.

8.2.5 CBT Multicast Interoperability

Multicast interoperability is required to create a transient "join
state."  This transient "join state" includes currently being defined.  Work is underway
in the multicast group, and IDMR working group to describe the JOIN_REQUEST's incoming attachment of stub-CBT and outgoing interfaces.  This information
allows an intermediate router
stub-PIM domains to forward returning JOIN_ACKs along the
exact reverse path a DVMRP backbone.  Future work will focus on
developing methods of connecting non-DVMRP transit domains to the a DVMRP
backbone.

CBT router which initiated interoperability will be achieved through the JOIN_REQUEST.

As deployment of domain
border routers (BRs) which enable the JOIN_ACK travels towards forwarding of multicast traffic
between the CBT router that issued the
JOIN_REQUEST, each intermediate router creates new "active state" and DVMRP domains.  The BR implements DVMRP and CBT on
different interfaces and is responsible for
this group.  New branches are established by having forwarding data across the intermediate
routers remember which interface is upstream, and which interface(s)
is(are) downstream.  Once a new branch
domain boundary.

The BR is created, each child router
monitors also responsible for exporting selected routes out of the CBT
domain into the DVMRP domain.  While the CBT stub domain never needs to
import routes, the status DVMRP backbone needs to import routes to any sources
of its parent router with a keepalive mechanism, traffic which are inside the CBT "Echo" protocol.  A child router periodically unicasts a
CBT_ECHO_REQUEST to domain.  The routes must be imported
so that DVMRP can perform its parent router, which is then required to respond
with a unicast CBT_ECHO_REPLY message. reverse-path check.

========================================================================

                                            #-

         / - - - - -#- - - - -#
                                                    | \              /----------------\
         |           #                              |
                                                    # - - - - #
      member                |
               DVMRP     |
       host --|    +----+    |      CBT       |     --Join-->  --Join-->  --Join-->
         |
              |- [DR] - - - [:] -                ----| BR |----|                |
              Backbone   |    +----+    |     Domain     |
         |                              |                |
         \- - - -[:] - - - - [@]
              |     <--ACK--   <--ACK--   <--ACK--
              |

LEGEND

  [DR]  CBT Designated Router
   [:]  CBT Router
   [@]  Target Core Router
    #   CBT -/              \----------------/

Figure 22: Domain Border Router that
========================================================================

9. MULTICAST IP ROUTING:  RELATED TOPICS

To close this overview of multicast IP routing technology, we first
examine multicast routing protocol interoperability, then turn to
expanding-ring searches, which may not be equally-effective depending
on which multicast routing protocol is already being used.

9.1 Interoperability Framework for Multicast Border Routers

In late 1996, the IETF IDMR working group began discussing a formal
structure that would describe the way different multicast routing
protocols should interact inside a multicast border router (MBR).  The
work-in-progress can be found in the following internet draft:  <draft-
thaler-interop-00.ps>, or its successor.  The draft covers explicit
rules for the major multicast routing protocols that existed at the end
of 1996:  DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT, but applies to any
potential future multicast routing protocol(s) as well.

The IDMR standards work will focus on this generic inter-protocol MBR
scheme, rather than having to write 25 documents, 20 detailing how each
of those 5 protocols must interwork with the shared tree

Figure 21: CBT Tree Joining Process
========================================================================

If, for any reason, 4 others, plus 5 detailing
how two disjoint regions running the link between same protocol must interwork.

9.1.1 Requirements for Multicast Border Routers

In order to ensure reliable multicast delivery across a network with an on-tree router and its parent
should fail,
arbitrary mixture of multicast routing protocols, some constraints are
imposed to limit the scope of the problem space.

Each multicast routing domain, or if region, may be connected in a "tree
of regions" topology.  If more arbitrary inter-regional topologies are
desired, a hierarchical multicast routing protocol (such as, H-DVMRP)
must be employed, because it carries topology information about how the parent router
regions are interconnected.  Until this information is otherwise unreachable, available, we
must consider the
on-tree router transmits case of a FLUSH_TREE message on its child interface(s)
which initiates the tearing down tree of all downstream branches for the
multicast group. regions with one centrally-placed
"backbone" region.  Each downstream router pair of regions is interconnected one or more
MBR(s).

A MBR is then responsible for
re-attaching itself (provided it has injecting a directly attached group member)
to the group's shared delivery tree.

The Designated Router (DR) is elected by CBT's "Hello" protocol default route into its "child
regions," and
functions as THE single upstream router for all groups also injecting subnetwork reachability information into
its "parent region," optionally using that link. aggregation techniques to reduce
the volume of the information while preserving its meaning.  MBRs which
comply with <draft-thaler-interop-00.ps> have other characteristics and
duties, including:

o  The DR MBR consists at least two active routing components, each
   an instance of some multicast routing protocol.  No assumption is not necessarily
   made about the best next-hop router to every core type of routing protocol (e.g., broadcast-and-prune
   or explicit-join; distance-vector or link-state; etc.) any component
   runs, or the nature of a "component".  Multiple components running
   the same protocol are allowed.

o  A MBR forwards packets between two or more independent regions, with
   one or more active interfaces per region, but only one component per
   region.

o  Each interface for
every which multicast group.  The implication is that it enabled is possible for a
JOIN_REQUEST to be redirected "owned" by exactly
   one of the DR across components at a link to the best
next-hop router providing access time.

o  All components share a given group's core.  Note that common forwarding cache of (S,G) entries,
   which are created when data
traffic is never duplicated across a link, only JOIN_REQUESTs, packets are received, and the
volume of this JOIN_REQUEST traffic should can be negligible.

8.2.2 Data Packet Forwarding

When a JOIN_ACK is received by
   deleted at any time.  The component owning an intermediate router, it either adds
the interface over which is the JOIN_ACK was received to an existing only
   component that may change forwarding cache entry, or creates a new entry if one does not already
exist for the multicast group.  When a CBT router receives a data packet
addressed entries pertaining to the multicast group, it simply forwards the packet over all
outgoing interfaces as specified by the
   that interface.  Each forwarding cache entry for the
group.

8.2.3 Non-Member Sending

Similar has a single incoming
   interface (iif) and a list of outgoing interfaces (oiflist).

9.2. ISSUES WITH EXPANDING-RING SEARCHES

Expanding-ring searches may be used when an end-station wishes to other multicast routing protocols, CBT does not require that find
the source closest example of a multicast packet be a member certain kind of server.  One key assumption is
that each of these servers is equivalent in the multicast group.
However, for service provided:  Ask
any of them a multicast data packet question pertinent to reach the active core for that service and you should get the
group, at least one CBT-capable router must be present on
same answer.  For example, such a service is the non-member
source station's subnetwork. DNS.  The local CBT-capable router employs
IP-in-IP encapsulation and unicasts the data searching
client sends a query packet to with the active core
for delivery IP header's TTL field set to 1.
This packet will only reach its local subnetwork.  If a response is not
heard within some timeout interval, a second query is emitted, this time
with the rest TTL set to 2.  This process of sending and waiting for a
response, while incrementing the multicast group.

8.2.4 CBT Multicast Interoperability

Multicast interoperability TTL, is currently being defined.  Work what an expanding-ring search
is, fundamentally.  Expanding-ring searches can facilitate resource-
discovery or auto-configuration protocols.

Another key assumption is underway
in that the IDMR working group to describe multicast infrastructure provides the attachment of stub-CBT and
stub-PIM domains
ability to broadcast from a DVMRP backbone.  Future work will focus on
developing methods of connecting non-DVMRP transit domains to source equally well in all directions.  This
usually implies that, at a DVMRP
backbone.

CBT interoperability will be achieved through the deployment of domain
border minimum, all routers (BRs) which enable the forwarding of in an internetwork
support a multicast traffic
between the CBT routing protocol.

There are two classes of routing protocols to consider when discussing
expanding-ring searches:  DVMRP, MOSPF, and PIM-DM make up one class,
while PIM-SM and CBT comprise the other.

DVMRP domains. supports expanding-ring searches fairly well for a reasonable
number of sources.  The BR implements downside of using DVMRP and CBT on
different interfaces and is responsible for forwarding data that there is source-
specific state kept across the
domain boundary.

========================================================================

         /---------------\        /---------------\
         |               |        |                |
         |               |        |                |
         | entire DVMRP      |--[BR]--|  CBT Domain    |
         |   Backbone    |        |                |
         |               |        |                |
         \---------------/        \---------------/

Figure 22: Domain Border Routers (BRs)
========================================================================

The BR is also responsible for exporting selected routes out of the CBT
domain into internetwork.  As the DVMRP domain.  While number
of sources increases, the CBT stub domain never needs amount of state increases linearly.  Due to
import routes,
DVMRP's broadcast-and-prune nature, the DVMRP backbone needs tree for each source will
quickly converge to import routes reach all receivers for a given group (limited to any sources
of traffic which are inside
receivers within the CBT domain.  The routes must be imported
so packet's TTL).  If we assume that DVMRP can perform its RPF check.

9. INTEROPERABILITY FRAMEWORK FOR MULTICAST BORDER ROUTERS

In late 1996, all routers in
your internetwork speak DVMRP, these TTL-scoped searches will have the IETF IDMR working group began discussing a formal
structure that would describe
desired result:  As the way different multicast routing
protocols should interact inside a multicast border router (MBR).  The
work can be found in TTL is incremented, the following internet draft:  <draft-thaler-
interop-00.ps>, or its successor.  The draft covers explicit rules for packets will cross
successively further routers, radiating away from the major multicast routing protocols that existed at source subnetwork.

MOSPF supports expanding-ring searches particularly well.  It also keeps
source-specific state, so has the end of 1996:
DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT, but applies to any potential
multicast routing protocol same scaling issues as well.

The IDMR standards work will focus on this generic inter-protocol MBR
scheme, rather than having DVMRP with

respect to write 25 documents, 20 detailing how each
of those 5 protocols must interwork state (forwarding cache) increasing linearly with the 4 others, plus 5 detailing
how two disjoint regions running number
of sources.  MOSPF's unique capability is that it knows the same protocol must interwork.

9.1  Requirements topology of
its local area.  One by-product of this knowledge is that for Multicast Border Routers

In order to ensure reliable multicast delivery across a network with an
arbitrary mixture of multicast routing protocols, some constraints are
imposed given
(source, group) pair, each MOSPF router knows the minimum TTL needed to limit
reach the scope closest group member.  If a packet's TTL is not at least this
large, it need not be forwarded.  This conserves bandwidth that would
otherwise be wasted by several iterations of the problem space.

Each multicast routing domain, or region, may successively larger TTLs.
However, since MOSPF is an explicit-join protocol, any servers wishing
to be connected found must join the search group in a "tree advance.  Otherwise, MOSPF's
trees will not include these subnetworks.

PIM-DM is very similar to DVMRP in the context of regions" topology. expanding-ring
searches.  If more arbitrary inter-regional topologies are
desired, we continue to assume that all routers in a hierarchical given
internetwork support the multicast routing protocol (such as, H-DVMRP)
must be employed, because it carries topology information about how protocol, then RPM (used by
PIM-DM and the
regions are interconnected.  Until this information DVMRP) will ensure that sources' traffic is available, we
must consider broadcast
across the entire internetwork (limited only by the packet's initial
TTL), with no forwarding loops.

Shared-tree protocols do not have properties that necessarily lend
themselves to supporting expanding-ring searches.  PIM-SM, by default,
does not build source-based trees.  Consider the case of a tree of regions sender on
a leaf subnet in a PIM-SM domain.  Multicast packets sent with one centrally-placed

"backbone" region.  Each pair of regions is interconnected one or more
MBR(s).

A MBR is responsible TTL=1
will only reach end-stations on the local subnetwork, but TTL=2 packets
will be tunneled inside PIM-SM-Register packets destined for injecting a default route into its "child
regions," and also injecting subnetwork reachability information into
its "parent region," optionally using aggregation techniques to reduce the volume of RP.
Once at the information while preserving its meaning.  MBRs RP, the PIM-SM-Register wrapper is removed, exposing the
multicast packet, which
comply with <draft-thaler-interop-00.ps> should now have other characteristics and
duties, including:

o TTL=1 (the DR should have
decremented the TTL before forwarding the packet).  The MBR consists at least two active routing components, each
   an instance of some multicast routing protocol.  No assumption RP can now
forward the original packet over its attached downstream interfaces for
this group.  Since the TTL=1, this is
   made about as far as they will go.  Future
packets, with incrementally-higher TTLs, will radiate outward from the type of routing protocol (e.g., broadcast-and-prune
   or explicit-join; distance-vector or link-state; etc.)
RP along any component
   runs, or the nature of a "component".  Multiple components running downstream branches for this group.  Thus, the same protocol search will
locate resources that are allowed.

o  An MBR forwards closest to the RP, not the source (unless the
RP and the source happen to be very close together).

CBT does not really have this problem, at least in the latest version,
since it does not need to encapsulate packets between two or more independent regions, to get them to the group's
core.  Also, CBT's state is bi-directional, so any receiver can also be
a sender with
   one no tree-setup penalty.  CBT, because it is a shared-tree
protocol, isn't as good as DVMRP, MOSPF, or more active interfaces per region, but only one component per
   region.

o  Each interface PIM-DM for which multicast expanding-ring
searches, but it is enabled better than PIM-SM:  CBT tends to have more
symmetric distances, and "closer" on the core-based tree is "owned" by exactly
   one more
correlated with "closer" in terms of network hops.  However, CBT is not
perfect for these searches.  The effectiveness of the components at a time.

o  All components share a common forwarding cache CBT search depends
on the density of (S,G) entries,
   which are created when data packets branch points of the group's distribution tree in the
immediate vicinity of the source.  If we assume that all routers are received, and
also CBT routers, then the search can be
   deleted at any time.  The component owning an interface is the only
   component that may change forwarding cache entries pertaining to
   that interface.  Each forwarding cache entry has a single incoming
   interface (iif) and a list of outgoing interfaces (oiflist).

[This space was intentionally left blank.] quite effective.

10. REFERENCES

10.1 Requests for Comments (RFCs)

    1075   "Distance Vector Multicast Routing Protocol," D. Waitzman,
            C. Partridge, and S. Deering, November 1988.

    1112   "Host Extensions for IP Multicasting," Steve Deering,
            August 1989.

    1583   "OSPF Version 2," John Moy, March 1994.

    1584   "Multicast Extensions to OSPF," John Moy, March 1994.

    1585   "MOSPF: Analysis and Experience," John Moy, March 1994.

    1700   "Assigned Numbers," J. Reynolds and J. Postel, October
            1994. (STD 2)

    1812   "Requirements for IP version 4 Routers," Fred Baker,
            Editor, June 1995

    2000   "Internet Official

    2117   "Protocol Independent Multicast-Sparse Mode (PIM-SM):
            Protocol Standards," Jon Postel,
            Editor, February Specification," D. Estrin, D. Farinacci, A. Helmy,
            D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu,
            P. Sharma, and L. Wei, July 1997.

10.2 Internet-Drafts

    2189   "Core Based Trees (CBT) Multicast: Architectural Overview,"
    <draft-ietf-idmr-cbt-arch-04.txt>, (CBT version 2) Multicast Routing,"
            A. J. Ballardie, March September 1997.

    2200   "Internet Official Protocol Standards," Jon Postel, Editor,
            June 1997. (STD 1)

    2201   "Core Based Trees (CBT) Multicast: Protocol Specification," <draft-
    ietf-idmr-cbt-spec-07.txt>, Multicast Routing Architecture,"
            A. J. Ballardie, March September 1997.

10.2 Internet-Drafts

   "Core Based Tree (CBT) Multicast Border Router Specification for
    Connecting a CBT Stub Region to a DVMRP Backbone," <draft-ietf-
    idmr-cbt-dvmrp-00.txt>, A. J. Ballardie, March 1997.

   "Distance Vector Multicast Routing Protocol," <draft-ietf-idmr-
    dvmrp-v3-04.ps>, T. Pusateri, February 19, 1997.

   "Internet Group Management Protocol, Version 2," <draft-ietf-
    idmr-igmp-v2-06.txt>, William Fenner, January 22, 1997.

   "Internet Group Management Protocol, Version 3," <draft-cain-
    igmp-00.txt>, Brad Cain, Ajit Thyagarajan, and Steve Deering,
    Expired.

   "Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol
    Specification," <draft-ietf-idmr-pim-dm-spec-04.ps>, D. Estrin,
    D. Farinacci, A. Helmy, V. Jacobson, and L. Wei, September 12, 1996.

   "Protocol Independent Multicast-Sparse Multicast Version 2, Dense Mode (PIM-SM): Motivation
    and Architecture," <draft-ietf-idmr-pim-arch-04.ps>, Specification,"
    <draft-ietf-idmr-pim-dm-spec-05.ps>, S. Deering, D. Estrin,
    D. Farinacci, V. Jacobson, C. Liu, A. Helmy, and L. Wei,
    November 19, 1996. May 21, 1997.

   "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
    Specification," <draft-ietf-idmr-pim-sm-spec-09.ps>, Motivation
    and Architecture," <draft-ietf-idmr-pim-arch-04.ps>, S. Deering,
    D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei, October 9,
    November 19, 1996.

   (Note:  Results of IESG review were announced on December 23, 1996:
    This internet-draft is to be published as an Experimental RFC.)

   "PIM Multicast Border Router (PMBR) specification for connecting
    PIM-SM domains to a DVMRP Backbone," <draft-ietf-mboned-pmbr-
    spec-00.txt>, D. Estrin, A. Helmy, D. Thaler, Febraury February 3, 1997.

   "Administratively Scoped IP Multicast," <draft-ietf-mboned-admin-ip-
    space-01.txt>,
    space-03.txt>, D. Meyer, December 23, 1996. June 10, 1997.

   "Interoperability Rules for Multicast Routing Protocols," <draft-
    thaler-interop-00.txt>, D. Thaler, November 7, 1996.

    See the IDMR home pages for an archive of specifications:

    <URL:http://www.cs.ucl.ac.uk/ietf/public_idmr/>
    <URL:http://www.ietf.org/html.charters/idmr-charter.html>

10.3 Textbooks

    Comer, Douglas E. Internetworking with TCP/IP Volume 1 Principles,
    Protocols, and Architecture Second Edition, Prentice Hall, Inc.
    Englewood Cliffs, New Jersey, 1991

    Huitema, Christian. Routing in the Internet, Prentice Hall, Inc.
    Englewood Cliffs, New Jersey, 1995

    Stevens, W. Richard. TCP/IP Illustrated: Volume 1 The Protocols,
    Addison Wesley Publishing Company, Reading MA, 1994

    Wright, Gary and W. Richard Stevens. TCP/IP Illustrated: Volume 2
    The Implementation, Addison Wesley Publishing Company, Reading MA,
    1995

10.4 Other

    Dalal, Y. K., and Metcalfe, R. M., "Reverse Path Forwarding of
    Broadcast Packets", Communications of the ACM, 21(12):1040-1048,
    December 1978.

    Deering, Steven E. "Multicast Routing in a Datagram
    Internetwork," Ph.D. Thesis, Stanford University, December 1991.

    Ballardie, Anthony J. "A New Approach to Multicast Communication
    in a Datagram Internetwork," Ph.D. Thesis, University of London,
    May 1995.

   "Hierarchical Distance Vector Multicast Routing for the MBone,"
    Ajit Thyagarajan and Steve Deering, July Proceedings of the ACM SIGCOMM,
    pages 60-66, October, 1995.

11. SECURITY CONSIDERATIONS

As with unicast routing, the integrity and accuracy of the multicast
routing information is important to the correct operation of the
multicast segments of the Internet.  Lack of authentication of routing
protocol updates can permit an adversary to inject incorrect routing
data and cause multicast routing to break or flow in unintended
directions.  Some existing multicast routing protocols (e.g., MOSPF) do
support cryptographic authentication of their protocol exchanges.  More
detailed discussion of multicast routing protocol security is left to
the specifications of those routing protocols.

Lack of authentication of IGMP can permit an adversary to inject false
IGMP messages on a directly attached subnet.  Such messages could cause
unnecessary traffic to be transmitted to that subnet (e.g., via a forged
JOIN) or could cause desired traffic to not be transmitted to that
subnet (e.g., via a forged LEAVE).  If this is considered to be an
issue, one could use the IP Authentication Header [RFC-1825, RFC-1826]
to provide cryptographic authentication of the IGMP messages.  The
reader should consult the IGMPv2 specification for additional
information on this topic.

Security issues are not discussed in multicast data traffic are beyond the scope of this memo.
document.

12. ACKNOWLEDGEMENTS

This RFC would not have been possible without the encouragement of Mike
O'Dell and the support of Joel Halpern and David Meyer. Meyer and Joel Halpern.  Also invaluable
was the feedback and comments of from the IETF MBoneD and IDMR working
groups.
Certain  A number of people spent considerable time commenting on and
discussing this paper with the authors, and deserve to be mentioned by
name:  Kevin Almeroth, Ran Atkinson, Tony Ballardie, Steve Casner, Jon
Crowcroft, Steve Deering, Bill Fenner, Hugh Holbrook, Cyndi Jung, John
Moy, Shuching Shieh, Dave Thaler, and Nair Venugopal.
Our apologies to anyone  If we unintentionally neglected
to list here. mention anyone here, please accept our sincerest apologies.

13. AUTHORS' ADDRESSES

    Tom Maufer                             Chuck Semeria

      3Com Corporation                       3Com Corporation
      5400 Bayfront Plaza                    5400 Bayfront Plaza
        Mailstop 5247                          Mailstop 2218
      P.O. Box 58145                         P.O. Box 58145
      Santa Clara, CA 95052-8145

      Phone:  +1 408 764-8814
      Email:  <maufer@3Com.com>

    Chuck Semeria
      3Com Corporation
      5400 Bayfront Plaza
      P.O. Box 58145             Santa Clara, CA 95052-8145

      Phone:  +1 408 764-8814                Phone:  +1 408 764-7201
      Email:  <maufer@3Com.com>              Email:  <semeria@3Com.com>