Browse Prior Art Database

Interoperability Rules for Multicast Routing Protocols (RFC2715)

IP.com Disclosure Number: IPCOM000003310D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 18 page(s) / 46K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Thaler: AUTHOR

Abstract

The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. Specific instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 6% of the total text.

Network Working Group D. Thaler

Request for Comments: 2715 Microsoft

Category: Informational October 1999

Interoperability Rules for Multicast Routing Protocols

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

The rules described in this document will allow efficient

interoperation among multiple independent multicast routing domains.

Specific instantiations of these rules are given for the DVMRP,

MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well

as for IGMP-only links. Future versions of these protocols, and any

other multicast routing protocols, may describe their

interoperability procedure by stating how the rules described herein

apply to them.

1. Introduction

To allow sources and receivers inside multiple autonomous multicast

routing domains (or "regions") to communicate, the domains must be

connected by multicast border routers (MBRs). To prevent black holes

or routing loops among domains, we assume that these domains are

organized into one of the following topologies:

o A tree (or star) topology (figure 1) with a backbone domain at the

root, stub domains at the leaves, and possibly "transit" domains

as branches between the root and the leaves. Each pair of

adjacent domains is connected by one or more MBRs. The root of

each subtree of domains receives all globally-scoped traffic

originated anywhere within the subtree, and forwards traffic to

its parent and children where needed. Each parent domain's MBR

injects a default route into its child domains, while child

domains' MBRs inject actual (but potentially aggregated) routes

into parent domains. Thus, the arrows in the figure indicate both

the direction in which the default route points, as well as the

direction in which all globally-scoped traffic is sent.

+--------+

+----| |----+

+---+ +---+ | ===> <=== |

| | | | +----| # |----+

| | | # | +-----#------+

| # | +---#-------| v |-----------+

+--#----| v | | |-----+

| v ===> ===> Backbone <=== <=== |

+-------| ^ | | ^ |-----+

+---#-------| ^ |-----#-----+

| # | +-----#------+ | # |-----+

| | | # | | <=== |

+---+ +---| | | |-----+

| ===> | +--------+

+---+--------+

...