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/mbgp_configuration_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.