[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00                                                            
MBONED Working Group                                            B. Cain
INTERNET-DRAFT                                          Nortel Networks
Expires August 2000                                       February 2000

                      Connecting Multicast Domains


 This document is an Internet-Draft and is in  full  conformance  with
 all provisions of Section 10 of RFC2026.

 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-

 Internet-Drafts are draft documents valid for a maximum of six months
 and  may be updated, replaced, or obsoleted by other documents at any
 time.  It is inappropriate  to  use  Internet-  Drafts  as  reference
 material or to cite them other than as work in progress.

 The  list   of   current   Internet-Drafts   can   be   accessed   at

 The list of Internet-Draft Shadow  Directories  can  be  accessed  at


   New deployment of multicast routing in Internet Service Provider
   networks is through the use of the PIM-SM [PIMSM], MSDP [MSDP], and
   MBGP [MBGP] protocols.  This informational document describes
   several solutions for the connection of different types of multicast
   routing domains.  In particular, the problems and
   solutions for the connection of a stub intra-domain multicast
   routing domain to a transit (ISP) PIM-SM domain are addressed.

Expires August 2000                                          [Page 1]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

1. Introduction

   New deployment of multicast routing in Internet Service Provider
   networks is through the use of the PIM-SM [PIMSM], MSDP [MSDP], and
   MBGP [MBGP] protocols.  This informational document describes
   several solutions for the connection of different types of multicast
   routing domains.  In particular, it describes the problems (and
   solutions) for the connection of a stub intra-domain multicast
   routing domain to a transit (ISP) PIM-SM domain.  Because stub
   domains may use a variety of multicast routing protocols it is
   important to understand the connection issues between a provider
   PIM-SM domain and stub domains.

   In [INTEROP], an interoperability mechanism is described which can
   be implemented in multicast border routers to route multicast
   traffic between domains.  This is accomplished through a shared
   multicast forwarding table between two or more multicast routing
   protocols.  [INTEROP] describes the creation of the shared
   forwarding cache, and thhe details of individual protocols from
   the perspective of protocol implementors.

   In this document, multiple scenarios are presented for the actual
   interconnection of a stub/transit domain connection.  We assume
   that there is a multicast border router (BR) present which is
   either part of the transit network or part of the stub network
   which implements the mechanisms described in [INTEROP].  We assume
   that the BR has two components, one which is the PIM-SM protocol,
   and one which is the stub domain's intra-domain multicast routing

1.1 Transit Domain (ISP) Configuration

   In Internet Service Provider networks, PIM-SM has become the
   de-facto multicast routing protocol, or tree-building protocol.  In
   order to connect PIM-SM domains, the MSDP protocol is used.  MSDP is
   a source distribution protocol, which distributes lists of sources
   to all PIM-SM Rendenzvous points.  To provide for multicast specific
   routing policies, Multi-protocol BGP is used for multicast specific

1.2 Stub Domain Configuration

   Intra-domain networks may run a variety of multicast routing
   protocols, such as PIM-DM [PIMDM], PIM-SM [PIMSM], MOSPF [MOSPF], or
   DVMRP [DVMRP].  These networks use multicast for private specialized
   applications.  In many circumstances, an intra-domain stub domain
   may wish to receive multicast connectivity from its ISP to receive
   inter-domain multicast traffic.  Many ISPs have been offering access
   to the legacy DVMRP part of the MBone, but recently, ISPs have
   begun to offer PIM-SM/MSDP connectivity as well.  Because stub

Expires August 2000                                          [Page 2]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

   domains may run a variety of protocols, confusion exists about the
   connectivity options when connecting to a PIM-SM provider domain.

1.3 General Configuration Issues

   There are a number of general issues to consider when connecting
   multicast domains.  The following provides a quick summary of the
   common issues which are not addressed in this document.

        - Group Scoping: Stub domains may wish to scope certain groups
          to stay within their domain.  This is best accomplished with
          administratively scoped addresses [ASCOPE].  Administrative
          scoping ranges are configured on all border routers so as to
          not forward scoped groups out of the domain.
        - Special Addresses: Certain multicast addresses are used for
          protocol purposes which are specific to a domain
          (e.g. bootstrap messages).  These messages should use
          administratively scoped addresses and therefore should be
          filtered at domain boundaries.
        - Group Ownership: If a stub domain wishes to use global
          addresses for multicast groups, it should use one of the
          multicast address allocation mechanisms [GLOP, MALLOC] in
          place to do so.  By ignoring the problems of address
          allocation, a domain may select an address which collides
          with another which could cause excess traffic and possibly
          denial of service to other groups.
        - Multi-homing: Multi-homing multicast is difficult (note:
          meaining the actual multi-homing of multicast traffic, not
          unicast multi-homing with multicast enabled).  Because
          multicast routing protocols use RPF checks to prevent packet
          looping, routing configurations must correctly reflect the
          actual path of source packets.  Mult-homing becomes more
          difficult when different route distribution protocols are
          used to distribute routes (e.g. DVMRP and MBGP).  It should
          be noted that a multicast source cannot be "load-balanced"
          over multiple ingress points.  Because packet looping must be
          prevented, a set of sources must be injected at one point
          into the network (of course this does not prevent the use
          of  *backup* routes).

1.4 Document Organization

   The following sections describe the methods of connecting multicast
   domains.  Section 2 describes the connection of a stub
   flood-and-prune domain to a provider domain using PIM-SM.  Section 3
   describes the connection of a stub PIM-SM domain to a provider
   domain using PIM-SM.  Section 4 describes the connection of
   domains running MOSPF and IGMP-Proxy to a PIM-SM provider domain.
   Section 5 describes the problems of distributing multicast
   specific routes between domains.

Expires August 2000                                          [Page 3]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

2. Flood and Prune Protocols

   Many stub or enterprise domains run flood and prune protocols.
   These protocols, such as DVMRP and PIM-DM, are used because they are
   simple to deploy and have been available for a long time.  This
   section describes the problems and solutions for connecting a flood
   and prune stub domain to a transit ISP domain running
   PIM-SM/MSDP/MBGP.  The problems of route distribution are
   deferred until section 5.

2.1 The Problems

   Flood and prune protocols build multicast trees differently than the
   explicit join mechanism of the PIM-SM protocol.  Flood and prune
   protocols assume group membership and use prune messages to prune
   unwanted traffic.  This is in contrast to explicit join protocols
   like PIM-SM in which leaf routers explicitly setup tree branches
   when an IGMP join is received.

   In order to connect a flood and prune domain to a shared tree domain,
   it is necessary to:

        1. Communicate group membership information between domains
        2. Bring data from the senders from the flood and prune domain
           to the RP into the PIM-SM domain and visa-versa.

   In flood and prune protocols, global group membership is not
   available to any routers in the domain.  This is because of the
   inherent "dense-mode" philosophy in these protocols in that they
   assume group membership.  This becomes a problem because this
   information is needed to create branches from the border router to
   the PIM-SM RP.  This is so sources from the shared tree domain can
   be injected into the flood and prune domain.

   The opposite problem also exists: how to inject sources from the
   flood and prune domain into the shared tree domain.  This problem
   can be solved because of the nature of flood and prune protocols.
   In a flood and prune protocol, every router knows the set of all
   active sources for every group.  Using this information, a BR can
   act as if it is a directly attached router (to a source) for its
   shared tree component.

   The following section presents several solutions for connecting flood
   and prune protocols in a stub domain to a shared tree protocol in a
   transit (or ISP) domain.  Section 2.3 discusses the problem of
   injecting sources from stub flood-and-prune domains into transit
   PIM-SM domains.  Sections 2.4.1 through 2.4.4 suggest several
   possibilities for bringing sources from the PIM-SM domain into the
   flood-and-prune domain.

   Note that this document only specifies the *possibilities* in

Expires August 2000                                          [Page 4]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

   connecting domains.  Different vendors may implement different
   feature sets which include all or part of these solutions.

2.3 Stub Sources into Transit Domain

   This section describes the problem of injecting sources from a
   stub flood-and-prune domain into a PIM-SM transit domain.
   Regardless of which solution is chosen for the reverse problem (i.e.
   injecting sources from the transit to the stub), there is one
   general solution to this problem which is specified in [PIMSM] and
   summarized here.

   BRs will have knowledge of all sources in the flood-and-prune stub
   domain.  In order to inject sources into the transit domain, it will
   act as a PIM-SM "DR edge router" and use the PIM-SM register
   protocol.  That is, sources from the stub domain will be register
   encapsulated to the appropriate RP in the PIM-SM domain.  Behavior
   is similar to a PIM-SM DR router encapsulating sources on its local
   network with one exception.

   When a PIM-SM DR receives a register stop message, it stops
   encapsulating the source's data but still periodically sends
   registers to the RP so that it will know the source is still active.
   In the case of a DR on a LAN, this is straight-forward because a
   new packet from the source will trigger an update of soft state on
   the DR.  However, in the case of a BR, it is desirable to prune the
   source back into the stub domain.  The problem arises because the
   BR is dependent on the re-flood timer in the flood-and-prune
   protocol as to when its forwarding state will be updated.  There
   are two solutions:

        1. The transit domain may locate its RP at the BR.  In this
           case, the BR will have knowledge of all groups joined in
           the transit domain.
        2. The BR may chose not to prune the source into the stub
           domain.  This allows the BR to refresh its registers with
           accuracy at the expense of creating a large sink in the
           network (note: this is how MOSPF works).
        3. DWRs can be used in the transit domain.  If DWRs are
           available then the BRs will only inject sources from the
           stub domain which are joined in the transit.
        4. The BR may send refreshes whenever a source is periodically
           flooded in the stub domain.  This MAY be longer than the
           RP register state for a source and therefore a significant
           delay may occur before the source is injected into the
           transit domain.
        5. MSDP may be used to report active sources into the transit
           domain.  This would involve a MSDP peering between the BR and
           another router in the transit domain.

Expires August 2000                                          [Page 5]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

2.4 Transit Source into Stub Domain

2.4.1 Domain Wide Reports

   The domain wide report [DWR] protocol allows for complete group
   membership information for a domain to be obtained by BRs.  The DWR
   protocol works very much like the IGMP protocol except throughout a
   domain, utilizing domain wide queries and domain wide reports.
   Routers periodically send reports for all local memberships.  These
   reports can be used by border routers to determine the total group
   membership of a domain.

   In using DWRs in the connection of a flood-and-prune stub network to
   a ISP PIM-SM domain, the following occur:

        1. The stub domain must support DWR in its routing devices or
           proxy DWR Reports from each IGMP subnet.
        2. When a BR receives a domain wide report, it will perform a
           (*,g) PIM-SM join towards the RP.  This will enable sources
           from the transit domain (and beyond) to be injected into the
           stub domain.  When a DWR membership times out or a group is
           explicitly left, prunes should be sent for every forwarding
           entry (i.e. non-pruned) matching the group.

   DWRs present a "clean" solution to the problem of connecting
   domains.  DWRs may create a small additional overhead in control
   traffic in the flood-and-prune domain.  They also create extra
   forwarding entries in the flood-and-prune domain because each router
   which sends a DWR report is itself a multicast source.

2.4.2 Receivers are Senders Heuristic

   Another possibility for transiting traffic between a flood-and-prune
   domain and a PIM-SM domain is to use the "receivers are senders"
   heuristic.  This heuristic assumes that all receivers in the
   flood-and-prune domain are also senders and will send traffic
   to a group (e.g. RTCP).  This is true for many-to-many applications
   or one-to-many applications where receivers send RTCP reports but
   not in general.  Thus this heuristic may not deliver multicast
   traffic from the PIM-SM domain to all receivers in the flood and
   prune domain.

   The "receivers are senders" heuristic works in the following manner:

        1. BRs have global knowledge of sources in the flood-and-prune
           domain by virtue of the protocol itself.  These are either
           forwarding or prune entries for all active internal sources
           in all groups.
        2. For every group for which there is a forwarding entry, a
           (*,g) join is sent in the PIM-SM domain.  This will pull
           traffic from the PIM-SM domain into the flood-and-prune

Expires August 2000                                          [Page 6]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

   The problems with this approach is that it may deny forwarding
   multicast traffic to valid receivers.  This would likely occur in
   one-to-many applications which do not multicast their RTCP or RTCP
   like reports.  Another problem results if the aggregate reporting
   interval for the stub domain is greater than the source timeout
   for the forwarding entries in the BR.

2.4.3 (*,*,RP)

   The PIM-SM specification [PIMSM] specifies that (*,*,RP) state can
   be used for interconnection of multicast routing domains.  These
   (*,*,RP) tree branches are built from multicast border routers to
   RPs in the PIM-SM domain.  (*,*,RP) branches carry traffic from all
   sources to all groups.  (*,*,RP) solves the interconnection problem
   by pulling all traffic from RPs to the BRs where it can then be
   injected into an adjacent domain (in our case a flood-and-prune
   domain).  After it is flooded into the domain, it may be pruned back
   to the BR where the BR may then initiate PIM-SM prunes back to the

   In summary, (*,*,RP) works in the following way:

        1. BRs initiate (*,*,RP) branches to all RPs (all routers in
           the path will have (*,*,RP) forwarding entries).  BRs simply
           use the RP-set from the RP-set distribution mechanism
           [PIMSM, AUTORP].
        2. When source traffic arrives at an RP, it will be forwarded
           down the (*,*,RP) branch (as well as other outgoing
        3. When traffic is received at the BR from the (*,*,RP) branch,
           it is injected into the flood-and-prune domain.  If there
           are no receivers, it will be pruned back to the BR.
        4. If the BR receives prunes for the injected source, it will
           then prune the source back into the PIM-SM domain by issuing
           (s,g) prunes towards the RP.

   The problems with this approach are that some providers may be
   reluctant to have (*,*,RP) state in their networks, particularly if
   they have a large number of customers with flood-and-prune domains.
   This would result in (*,*,RP) in many parts of the network,
   effectively turning the PIM-SM domain into a flood-and-prune domain.

2.4.4 Running MSDP on BR

   Another possibility for connection is through the use of the MSDP
   protocol.  In this scenario, MSDP is run on the BR with a peering
   connection to any other MSDP speaker in the transit domain.  MSDP is
   used to learn about all sources in the PIM-SM domain (and beyond).
   Once these sources are learned, they can be joined directly and
   injected into the flood-and-prune domain.  This functions in a

Expires August 2000                                          [Page 7]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

   similar way to (*,*,RP) except that MSDP is used to discover the
   sources, and must more state is used.

   In summary, using MSDP to connect flood-and-prune domains works in
   the following way:

        1. MSDP is run on the BR.  A MSDP peering is configured with
           a MSDP speaker in the transit domain.
        2. When a new source is learned through MSDP, the BR will send
           a PIM-SM (s,g) join towards the source.
        3. When data from the new source is received, the BR will
           inject the source into the stub domain to be flooded.
        4. If there are no receivers (or all receivers leave the
           group), the source will be pruned back to the BR; the BR
           will then send a (s,g) prune towards the source in the
           PIM-SM domain.

   Running MSDP on the BR provides a reasonable alternative without
   DWRs.  The only possible drawback is the growth of a providers MSDP
   mesh as each customer will have a MSDP peering.  However, this may
   actually benefit a provider in that provisioning configurations are
   are similar to inter-provider configurations.

3. Explicit Join Shared Tree Protocols

   Stub domains may run shared tree protocols like PIM-SM.  In cases
   where a stub domain requires multicast transit service from an ISP
   (also running PIM-SM), several options exist for configuration.
   Route distribution is deferred until section 5.

   This section presents the possibilities for connecting a stub
   shared tree protocol domain (e.g. customer) to a transit PIM-SM
   domain (e.g.  provider).  We assume that PIM-SM is the protocol
   being run in both domains.  (NOTE: although other shared-tree
   protocols exist, PIM-SM is the only one which has currently
   experienced "real-world" deployment.  It is for this reason that
   only PIM-SM to PIM-SM interconnection is addressed)

   When an stub domain wishes to receive multicast connectivity from
   a provider, a decision must be made as to which RPs the stub domain
   will use.  We present two scenarios: the first when the stub PIM
   domain uses the ISP RPs and the second when a stub domain uses
   its own RPS.

3.1 Using ISP RPs

   A singly-homed stub domain (if allowed) may use its ISP RPs.  In
   many cases, the stub domain will need to run the same RP-set
   distribution mechanism [PIMSM, AUTORP] that its ISP does and must

Expires August 2000                                          [Page 8]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

   not filter any groups used for these protocols.  It may be possible
   for the BR to proxy messages from one RP-set distribution mechanism
   into another if supported in a BR implemenation.  In both cases, the
   ISP's RP-set will be distributed into the stub domain.  In this
   way, the stub domain is an extension of the ISPs PIM-SM domain.

   The disadvantage of this configuration is that all traffic must go
   to the ISPs RPs.  As an optimization, an ISP may use multiple RPs
   with anycast [LOGRP], and may locate an RP at the POP where the
   customer connects.  This allows sources in the stub to be relatively
   close to their RP.  This configuration is best when the stub domain
   is primarily going to receive traffic sourced outside its domain.
   The advantage of this scheme is that it is easy to provision and
   configure for the ISP.  However, a potential disadvantage is that
   routers may become state burdened if a stub domain has many
   intra-domain groups and the link between the domains may be
   burdened with traffic.

   Another potential problem is in the allocation of administratively
   scoped addresses.  One possibility is for the ISP to divide its
   administratively scoped address space between its customers.
   Another possibility is for the stub domain to have its own RP but
   only for administratively scoped groups.  In this scenario, a
   filtering mechanism would have to be in place at the BR to block
   administratively scoped addresses across the boundary in the RP-set
   protocol.  However, global multicast group trees would still be
   constructed across the domain boundary (i.e. using the ISP RPs for
   global groups).

   In summary, this solution works when a domain uses administratively
   scoped addresses for its intra-domain groups (and uses its own RP
   for these groups).  It does not require MSDP configuration and
   therefore does not grow the provider's MSDP mesh.

3.2 Private RPs with MSDP

   When a domain has many multicast sources which will be destined
   only within its domain, it is best to configure a separate PIM-SM
   domain for the stub domain.  In this configuration, the stub domain
   runs MSDP to its provider.  The border router between the PIM-SM
   domains must:

        - Block RP-set information between the domains
        - Only allow (s,g) joins/prunes between domains (follows from
        - Configure boundaries for administratively scoped addresses
          between domains.

   Sources flow between transit and stub in the same way that ISP
   PIM-SM/MSDP peering works.  MSDP distributes source information to
   RPs who directly join towards the sources.  The sources are then

Expires August 2000                                          [Page 9]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

   sent down the shared tree to receivers (last hop routers may then
   make a decision about switching to an SPT tree following the
   standard PIM protocol).  When a RP learns a new source in its domain
   it sends a source-active message in MSDP to all peers.

   A domain may wish to configure a RP for private addresses
   (administratively scoped) and one for global addresses.  In this
   case, the "global address" RP only needs MSDP (to peer with

4. Connections with other Protocols


   MOSPF [MOSPF] is a unique protocol which makes use of the OSPF link
   state database to compute source-based multicast trees.  MOSPF has
   several properties which make it particularly easy to connect to
   other multicast routing domains:

        - MOSPF floods group membership information using a Group
          Membership LSA.  Each DR will flood group membership
          information for its attached subnet.  Group LSAs are flooded
          into the OSPF backbone; therefore, all OSPF backbone routers
          have total group membership for the entire domain.
        - MOSPF ABR and ASBRs are "wildcard" receivers.  This router
          will receive all traffic sourced in the domain.  These
          routers therefore have total source knowledge within a domain.

   Both [MOSPF] and [INTEROP] describe the interoperability between
   MOSPF and other protocols.  The following section gives a quick
   overview of the issues with repect to MOSPF.

4.1.1 Traffic from PIM-SM to MOSPF

   In order to pull sources from a PIM-SM transit domain into a MOSPF
   stub domain, the PIM-SM/MOSPF BR should send (*,g) joins into the
   PIM-SM domain for every group for which a group membership LSA
   exists in the OSPF LSDB.  If all hosts leave the group, the group
   membership LSAs will be flushed and the BR will send a (*,g) prune.
   BRs may also monitor source rates and join to source trees if

4.1.2 Traffic from MOSPF to PIM-SM

   In order to pull sources from a flood-and-prune stub domain into a
   PIM-SM transit domain, the PIM-SM/MOSPF BR will act as a PIM-SM DR
   edge router and encapsulate all MOSPF sources in PIM-SM registers.
   The multicast BR should be configured as a OSPF ASBR in order that

Expires August 2000                                          [Page 10]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

   the wildcard receiver bit is enabled in the LSAs originated from the
   router.  As mentioned above, part of the MOSPF protocol requires
   that ASBRs act as wildcard receivers.

4.2 IGMP-Proxy

  IGMP-proxy [PROXY] is a name used to describe a proxy of the
  IGMP protocol.  A router or other device proxies IGMP reports from
  some interfaces (downstream) to other (upstream) interfaces.  The
  downstream interfaces are typically connected to either dial-in
  lines or LANS.  The upstream interfaces are connected to one or
  more multicast routers.  In the following section, the term BR is
  used to describe the upstream multicast routers of an IGMP-proxy.

  A small domain or dial-in user may use IGMP-Proxy within a small
  network for multicast connectivity.  The most critical part of a
  connection with IGMP-Proxy is that the transit domain have the
  correct routing information for RPF checks for the stub domain.

  In order to inject sources from the transit domain to the IGMP-relay
  domain, a BR is configured with a PIM-SM component (on the provider
  network), and a regular multicast enabled interface on the stub
  domain side.  To the BR, the IGMP-Proxy domain will look like a
  single host.  Devices will proxy IGMP reports towards the router
  which will then perform the standard PIM-SM joining procedure.

  In order to inject sources from the IGMP-Proxy domain into the PIM-SM
  transit domain, the BR must be configured with the correct routing
  information for the PIM-SM RPF checks to pass.  In the simplest case,
  the router has route (pointing towards the stub) for all
  subnets which are multicast capable.  The proxy will relay all
  sources towards the BR which will then be injected into the domain.

  It is expected that multi-homed domains will be running a multicast
  routing protocol as opposed to IGMP-Proxy.  In the case that a
  multi-homed stub uses IGMP-Proxy, it must ensure that the sources are
  relayed to the correct RPF router in the multi-homed configuration
  (see section 5).

5. Exchanging Multicast Specific Routes

  Some multicast routing protocols in use today perform Reverse Path
  Forwarding (RPF) checks on packets to verify they were received on
  the "correct" (i.e. shortest to source or RP) interface.  These RPF
  checks are used to prevent multicast packet looping.

  When multiple multicast domains transit multicast packets, it is
  important that routes exchanged between the domains allow for RPF
  checks to be performed correctly.  Problems can occur when domains

Expires August 2000                                          [Page 11]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

  use different protocols for route selection (e.g. with PIM-SM).
  Problems can also occur in situations where there are load
  balancing/backup route schemes in use for unicast routing and the
  multicast tree building protocol is using those routes for RPF checks.

  This section presents several route distribution scenarios and
  attempts to present some of the problems specific to multicast.  Many
  scenarios are covered briefly because they are well-known
  configurations for unicast routing.

5.1 MBGP Peering

  A provider may choose to MBGP peer with a stub domain in order
  to learn multicast specific routes from the stub domain.  The
  specifics of MBGP peering are similar to unicast BGP peering.

  If a stub domain is multi-homed, then MBGP is important for
  learning the correct ingress for sources.  However, unless these
  routes are injected into the IGP (for multicast), they are not
  useful.  MBGP peering is most useful for providers to learn the
  the correct ingress for a source.

  Dependant on the IGP (being used for multicast),  multicast specific
  routes may be injected from MBGP.  In most cases, a stub domain
  will inject a default route from the BR that is connected with
  the provider network.  The following sections discuss injecting
  default routes into multicast IGPs.  In many cases the MBGP peer
  in the stub domain is the multicast BR.

5.2 DVMRP Route Injection

  If a stub domain is using DVMRP as its multicast IGP, then a
  default route may be injected from a the multicast BR.  This
  route may be injected dependent on either BGP or MBGP routes
  being learned.

  Some implementations of PIM support using DVMRP as a route
  distribution protocol.  PIM can be configured to use DVMRP routes
  for RPF checking.  In this case, a different multicast default
  route (i.e. from the unicast default) can be injected into a
  stub domain using DVMRP.

  (note: only some implementations of DVMRP *truly* support use
   of a default route.  later versions of the spec explicity state
   the prune and graft rules when a default route is used)

5.3 MOSPF Route Injection

  If a stub domain uses MOSPF as its multicast IGP then multicast

Expires August 2000                                          [Page 12]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

  specific routes must be injected into OSPF.  In most cases, a
  domain will want to use a default route for external multicast
  sources.  A default route tagged with the "multicast" bit in the
  OSPF can be used for this.

5.4 Different Multicast/Unicast Defaults

  If a stub domain wishes to configure separate multicast and unicast
  default routes then it is currently limited in the type of
  configurations that can be used (this will change as multicast
  specific metrics are added into unicast IGPs).  Three options are
        1. Use DVMRP (strictly as a route propagation protocol) to
           propagate the multicast specific route.
        2. Use MOSPF with OSPF multicast tagged route
        3. MBGP peering for all multicast routers

6. References

  [PIMSM] Estrin, D.,et al., "Protocol Independent Multicast-Sparse Mode
         (PIM-SM): Protocol Specification," RFC 2362, June 1998.

  [DWR] Fenner, W., "Domain Wide Multicast Group Membership Reports,"
        draft-ietf-idmr-membership-reports-04.txt, August 1999.

  [AUTORP] Farinacci, D., Wei, L., "Auto-RP: Automatic discovery of
           Group-to-RP mappings for IP multicast,"
           September 1998.

  [INTEROP] Thaler, D., "Interoperability Rules for Multicast
            Routing Protocols," RFC 2715, October 1999.

  [DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol,"
          draft-ietf-idmr-dvmrp-v3-09.txt, September 1999.

  [PROXY] Fenner, W., "IGMP-based Multicast Forwarding
          (``IGMP Proxying'')," draft-fenner-igmp-proxy-01.txt,
          June 1999.

  [MOSPF] Moy, J., "Multicast Extensions to OSPF,"
          RFC 1584, March 1994.

  [PIMDM] Deering, S., et al., "Protocol Independent Multicast
          Version 2 Dense Mode Specification,"
          draft-ietf-pim-v2-dm-01.txt, November 1998.

  [BGP] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4),"
        RFC 1828, March 1995.

Expires August 2000                                          [Page 13]

INTERNET-DRAFT        Connecting Multicast Domains       February 2000

  [MBGP] Bates, T., et al., "Multiprotocol Extensions for BGP-4,"
         RFC 2283, February 1998.

  [MSDP] Farinacci, D., "Multicast Source Discovery Protocol (MSDP),"
         draft-ietf-msdp-spec-05.txt, February 2000.

  [ASCOPE] Meyer, D., "Administratively Scoped IP Multicast,"
           RFC 2365, July 1998.

  [GLOP] Meyer, D., Lothberg, P., "GLOP Addressing in 233/8,"
         RFC 2770, February 2000.

  [MALLOC] Thaler, D., Handley, M., Estrin, D., "The Internet
           Multicast Address Allocation Architecture,"
           draft-ietf-malloc-arch-04.txt, January 2000.

  [LOGRP] Kim, D., et al., "Anycast RP mechanism using PIM and MSDP,"
          draft-ietf-mboned-anycast-rp-05.txt, January 2000.

7. Author's Address

  Brad Cain
  Nortel Networks
  600 Technology Park
  Billerica, MA 01821

Expires August 2000                                          [Page 14]