Interdomain Multicast Routing:
Use of MGBP to provide Scaleable, Policy Based
Interdomain Multicast Exchange
Last updated June 3, 1998
Background:
----------
Initial deployment of multicast throughout the Internet
has been based on the use of the Distance Vector Multicast
Routing Protocol routing independently from the underlying
unicast routing protocols of the Internet. This routing
topology is flat, all global participants exchanging multicast
based on DVMRP are sharing a single DVMRP routing table.
While this approach was extremely useful in demonstrating
the viability of multicast over the Internet, it retains all
the inherent disadvantageous of running a distance vector
protocol over the Internet
- poor scalability (currently under strain at ~6000 routes)
- poor convergence
- limited policy control (resulting in limited acceptance
in production ISP environments)
- waste of bandwidth based on periodic routing updates in
both directions of a link (i.e. poison-reverse).
In addition, much of the existing multicast backbone (MBone)
utilizes tunnels among non-production routing platforms and
is administered outside of the operational network engineering
and ops support groups (eg via R&D, sysadmin, etc).
Current Motivation for Internet Multicast:
-----------------------------------------
Despite these limitations, the interest in multicast
continues to rise. The use of streaming multimedia and
multi-destination apps has increased significantly in the
Internet and has pushed the demand for multicast in two ways:
1) in order to reduce bandwidth consumption from a network
design perspective
2) in order to provide effective multipoint distribution from
an applications perspective
3) in order to provide effective scalable distribution from
large-scale applicastions perspective.
Move toward Production Multicast:
-------------------------------------
Now more and more networks are running production multicast
co-resident on their production unicast routing infrastructure
and utilizing the underlying unicast routing protocols for
multicast forwarding decisions.
One stark exception to this is at the interdomain routing space.
In order to address the demand for scalable, production multicast
most ISPs have stated that they require an effective interdomain
routing solution. This has two parts:
1) a multicast EGP which provides scalability and policy control
analogous to BGP. This will be discussed here.
2) a method of establishing multicast forwarding trees across
interdomain space, and which avoids extensive dependency
on third parties (eg other ISPs). Possible solutions to
this component being discussed by the IETF include BGMP/
MASC. This is not covered in this draft.
Multicast BGP:
-------------
Multicast Border Gateway Protocol (MBGP) offers a method
for providers to distinguish which prefixes they will use
for performing multicast reverse path forwarding (RPF)checks.
Recall the RPF check is fundamental in establishing
multicast forwarding trees and moving multicast content
successfully from source to receiver(s).
MBGP is based on RFC 2283, Multiprotocol Extensions for BGP-4.
This brings along all of the administrative machinery that
providers (and customers for that matter) like in their
inter-domain routing environment. Examples include all of the AS
machinery, and the tools to operate on it (e.g., route maps).
Therefore, by using MBGP, any network utilizing internal or
external BGP can apply the multiple policy control knobs
familiar in BGP to specify routing (and therefore forwarding)
policy for multicast.
Two path attributes, MP_REACH_NLRI and MP_UNREACH_NLRI,
are introduced to yield BGP4+ as described in Internet Draft
draft-ietf-idr-bgp4-multiprotocol-01.txt.
MBGP is a simple way to carry two sets of routes. One set for
unicast routing and one set for multicast routing. The routes
associated with multicast routing are used by the multicast
routing protocols to build data distribution trees.
Advantages:
o An internet can support non-congruent unicast and multicast
topologies.
o An internet, when the unicast and multicast topologies are
congruent, can support differing policies.
Disadvantages:
o Multiple sets of routes for the same prefixes are carried in
BGP and stored in routers.
Deployment challenges for MBGP:
-----------------------------------------------
As will be the case with many newly emerging internetwork
protocols, one of the deployment challenges will be to
gracefully migrate the new protocol onto an existing
production routing infrastructure. Unlike HTTP/Web services
which could be deployed and propagated without alteration
of the routing infrastructure, multicast and in particular,
MBGP require that production BGP peering routers get upgraded
to new images supporting MBGP, and that routing policy be
changed and reflected by updating router configs. This is
a fairly large risk for most ISPs for several reasons:
- most of the routers to run MBGP are critical production
routers, usually already under heavy unicast load
- images supporting MBGP do not have significant uptime
compared to mainline images and as such have a higher
probability of containing bugs of varying severity
- subtle configurations issues exist regarding how to make
MBGP work (and accurately reflect policy)
- interprovider multicast policy in general is poorly
understood due to limited experience.
These issues must be resolved at least to the degree which
analogous unicast issues have been, such that providers can
confidently deploy MBGP and multicast as a production service.
Multicast over current NAPs:
Multicast BGP peering currently across many popular
NAPs is prohibited by the existing physical architecture
of the NAP. Some NAP switching infrastructures treat multicast
as broadcast, defeating the purpose of the switch and can
creating unwanted redistribution and load on the switch,
and switch<->switch or switch<->router links.
MBGP Deployment:
---------------------
Due to the issues stated, an MBGP deployment effort was
initiated by Cisco, several ISPs, and NAP operators
and focuses on these objectives:
- demonstrate stability and configurability in mbgp code
- develop multicast exchange points which bootstrap deployment
of multicast across exchanges without impacting existing
unicast traffic.
- provide participants with a method of gaining operational
experience with MBGP and policy definition prior to full
scale production deployment, and to feed this information to
multicast operators and multicast-related IETF working groups.
Current MBGP Deployment Status:
------------------------------
Initial MBGP deployment involves several NAPs including
exchanges at Ames Research Center, Palo Alto, Pensauken,
and Stockholm.
At these NAPs, dedicated fddi concentrators are set-up to
provide a non-switched media across which participating
ISPs can peer via multicast nlri. Only multicast is
forwarded across these multicast exchanges, unicast forwarding
still occurs via the existing switched NAP. Since unicast and
multicast peering paths are non-congruent, mbgp is used
to specify different routing information bases (RIBs) for
multicast and unicast forwarding.
Participating ISPs provide a separate fddi interface to
attach to the multicast exchange and run the MBGP code on
their peering routers.
Initial participating providers include various commercial
and federal ISPs, such as NASA Ames Research Center which
participates as both a peering ISP (the NASA Research and
Education Network is currently running a full internal
mbgp mesh), and as an operator of one of the initial
multicast exchange points utilizing mbgp.
Cisco Systems provided the first mbgp code available
for deployment. Configuration examples for participating
in mbgp peerng are avaiable at:
ftp://ftpeng.cisco.com:/ipmulticast/...n_examples.txt
Multicast Forwarding Protocols being used in deployment effort:
--------------------------------------------------------------
A variety of internal multicast forwarding protocols are
run by participating ISPs including PIM-SM, PIM-DM, and
DVMRP.
PIM-SM (or PIM Sparse-Dense-Mode, which is recommended):
For those ISPs running PIM-SM, their internal RP must be
located at the border router, sitting on the multicast
exchange running PIM-DM. This way content can be flooded among RPs
and forwarded to the receivers within their respective domains.
PIM-DM
For ISP's running PIM-DM internally, they simply need to
initiate peering at one of the multicast friendly exchange
points.
DVMRP
For ISPs running DVMRP, Cisco's MBGP implementation supports
two way redistribution of routes between MBGP and DVMRP, such
that the ISP can MBGP peer with its neighbors at the exchange,
and service internal sites running DVMRP.
AS10888:
-------
For ISPs who have positioned their RP at one NAP, and
would like to communicate with ISPs who's RP is at a separate
NAP, it is necessary to get source information among the NAPs.
Initially this is being done via a temporary short-lived backbone
of GRE tunnels (transit provided by various participating ISPs)
running PIM-DM and and an iMBGP mesh using AS10888
(provided by NASA Ames Research Center).
These tunnels (and AS10888) route between dedicated MBGP routers
sitting at each participating NAP. ISPs at each multicast NAP can
then elect to peer with these routers in AS10888 and obtain multicast
connectivity with other Sparse-mode ISPs peering with AS10888.
It is important to note that AS10888 is only intended to facilitate
initial deployment of multicast while ISPs establish early
peering. AS10888 can be disassembled when one of three things
occurs:
1) Participating ISPs provide DM transit between NAPs as part of
their peering agreement. (Only one DM path is necessary between
each NAP, but multiple paths could be provided).
2) Participating ISPs provide BGMP transit between NAPs. This
proposal is still under development within the IETF.
3) A protocol is developed which can distribute information
about sources to all RPs. One such protocol under development
is Multicast Source Distribution Protocol (MSDP).
MSDP:
-----
MSDP is designed to provide a method of distributing
information about active sources within each multicast
routing domain. Top level RPs for each domain pass
source active information to each other, rather than
flooding content, in order to determine the presence
of active sources within the Internet. Once this
information is available, it can be used by receivers
to join the source-based trees across domain boundaries
for a given source.
Deployment of MSDP will rescind the need to flood content
among the participating NAPs, and will allow for
disassembly of the AS10888 backbone.
Summary:
-------
Multicast BGP (MBGP) provides for scalable, policy-
based interdomain routing which can be used to support
non-congruent unicast and multicast forwarding paths.
MBGP is necessary to establish scalable, production multicast
services over the Internet. However, the integration of
MBGP and production multicast into an existing production
unicast infrastructure is problematic. A deployment
effort is underway to help facilitate this integration
and to move multicast toward a ubiquitous Internet
service
mbgp 
