MBONED Working Group B. Cain INTERNET-DRAFT Nortel Networks Expires August 2000 February 2000 Connecting Multicast Domains 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 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 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 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 domain. 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 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 mechanism [PIMSM, 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.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 above) - 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 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. 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 necessary. 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 to: 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," ftp://ftpeng.cisco.com/ipmulticast/pim-autorp-spec01.txt, 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 1-978-288-1316 bcain@nortelnetworks.com Expires August 2000 [Page 14]