One document matched: draft-cain-mcast-connect-00.txt
INTERNET DRAFT B. Cain
Nortel Networks
October 1999 Expires April 2000
Connecting Multicast Domains
<draft-cain-mcast-connect-00.txt>
STATUS OF THIS MEMO
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
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 April 2000 [Page 1]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
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 multicat routing protocols it is
important to understand the connection issues between an 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
sources 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, but does not address the details of individual
protocols.
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
protocol.
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
routes.
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 MBONE, but recently, ISPs have begun to offer PIM-SM/MSDP
connectivity as well.
Expires April 2000 [Page 2]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
Because stub 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). Domain boundaries routers
(either BRs or MSDP peering routers) should be configured to
filter these special addresses.
- 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 multicast sources 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 use 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
Expires April 2000 [Page 3]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
domains running MOSPF and IGMP-Proxy to a PIM-SM provider domain.
Section 5 describes the problems of distributing multicast
specific routes between domains.
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 multicat 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 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
inherit "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 present 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.2 discusses the problem of
Expires April 2000 [Page 4]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
injecting sources from stub flood-and-prune domains into transit
PIM-SM domains. Sections 2.3 through 2.6 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
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.
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 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 BR may send refreshes as long as it has forwarding state
for a source. This MAY be longer than the source is
actually "alive" as the flood-and-prune timeout on some
protocols is fairly long. This may result in a RP sending a
(s,g) join for a non-active source in the stub 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).
2.2 Domain Wide Reports
The domain wide report [DWR] protocol allows for complete group
Expires April 2000 [Page 5]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
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
use DWR proxies
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 entry
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.3 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 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
domain.
The problems with this approach is that it may deny forwarding
Expires April 2000 [Page 6]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
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 receiver reporting
intervals are greater than the source timeout for the forwarding
entries in the BR.
2.4 (*,*,RP)
The PIM-SM border router specification [PIMBR] 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 RP.
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 protocol [BSR,
AUTORP].
2. When source traffic arrives at an RP, it will be forwarded
down the (*,*,RP) branch (as well as other outgoing
interfaces).
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.5 Running MSDP on BR
Another possibility for connection is through the use of the MSDP
protocol. In this scenario, MSDP is run on BR with a peering
connection to any other MSDP speaker in the transit domain. MSDP is
Expires April 2000 [Page 7]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
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
similar way to (*,*,RP) except that MSDP is used to discover the
sources.
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 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 is a good alternative without DWRs. The
only possible drawback is the growth of a providers MSDP mesh as
each customer will have a MSDP peering.
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.
Expires April 2000 [Page 8]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
3.1 Using ISP RP
A stub domain (if allowed) may use its ISP RPs. In this case, the
stub domain must run the same RP-set distribution protocol
[BSR, AUTORP] that its ISP does and must not filter any groups used
for these protocols. The ISP's RP-set will be distributed into the
stub domain. In this case, 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.
Another potential problem is in the configuration 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 admin scoped groups. In this scenario, a filtering
mechanism would have to be in place at the BR to block
admin scoped addresses across the boundary in the RP-set protocol.
An implementation would also need to
In summary, this solution works well when a domain uses admin
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 (and does not make use of admin scoped
addressing), 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
above)
- Configure boundaries for administratively scoped addresses
between domains.
Expires April 2000 [Page 9]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
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
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
transit).
4. Connections with other Protocols
4.1 MOSPF
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.
We now explain how these properties can be used to pull sources
between multicast domains.
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
necessary.
4.1.2 Traffic from MOSPF to PIM-SM
Expires April 2000 [Page 10]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
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
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.
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 router, 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 a static 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
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.
Expires April 2000 [Page 11]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
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
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 dependant 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 PIM.
(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
Expires April 2000 [Page 12]
^L
INTERNET-DRAFT Connecting Multicast Domains October 1999
If a stub domain uses MOSPF as its multicast IGP then multicast
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
to:
1. Use DVMRP (or DVMRP/PIM hybrid) to propagate the multicast
specific route.
2. Use MOSPF with OSPF multicast tagged route
3. MBGP peering for all multicast routers
6. References
[PIMSM]
[PIMBR]
[DWR]
[BSR]
[AUTORP]
[INTEROP]
[DVMRP]
[PROXY]
[MOSPF]
[MBGP]
[PIMDM]
[BGP]
[MBGP]
[MSDP]
[ASCOPE]
[GLOP]
[MALLOC]
[LOGRP]
7. Author's Address
Brad Cain
Nortel Networks
600 Technology Park
Billerica, MA 01821
1-978-288-1316
bcain@nortelnetworks.com
Expires April 2000 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 22:11:58 |