idnits 2.17.1 draft-ietf-mboned-mcast-connect-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 40 instances of lines with control characters in the document. ** The abstract seems to contain references ([MSDP], [MBGP], [PIMSM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 233: '...ub domain. This MAY be longer than th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...d is in full ...' == Line 14 has weird spacing: '...), its areas...' == Line 15 has weird spacing: '...ups may also ...' == Line 19 has weird spacing: '... and may be u...' == Line 20 has weird spacing: '...opriate to u...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8827 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BGP' is defined on line 637, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2362 (ref. 'PIMSM') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-05) exists of draft-ietf-idmr-membership-reports-04 -- Possible downref: Normative reference to a draft: ref. 'DWR' -- Possible downref: Non-RFC (?) normative reference: ref. 'AUTORP' ** Downref: Normative reference to an Informational RFC: RFC 2715 (ref. 'INTEROP') == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-09 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'DVMRP') == Outdated reference: A later version (-03) exists of draft-fenner-igmp-proxy-01 ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOSPF') == Outdated reference: A later version (-03) exists of draft-ietf-pim-v2-dm-01 -- Possible downref: Normative reference to a draft: ref. 'PIMDM' ** Downref: Normative reference to an Historic RFC: RFC 1828 (ref. 'BGP') ** Obsolete normative reference: RFC 2283 (ref. 'MBGP') (Obsoleted by RFC 2858) == Outdated reference: A later version (-20) exists of draft-ietf-msdp-spec-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (ref. 'MSDP') ** Obsolete normative reference: RFC 2770 (ref. 'GLOP') (Obsoleted by RFC 3180) == Outdated reference: A later version (-05) exists of draft-ietf-malloc-arch-04 ** Downref: Normative reference to an Historic draft: draft-ietf-malloc-arch (ref. 'MALLOC') == Outdated reference: A later version (-08) exists of draft-ietf-mboned-anycast-rp-05 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-anycast-rp (ref. 'LOGRP') Summary: 18 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group B. Cain 2 INTERNET-DRAFT Nortel Networks 3 Expires August 2000 February 2000 5 Connecting Multicast Domains 6 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 New deployment of multicast routing in Internet Service Provider 32 networks is through the use of the PIM-SM [PIMSM], MSDP [MSDP], and 33 MBGP [MBGP] protocols. This informational document describes 34 several solutions for the connection of different types of multicast 35 routing domains. In particular, the problems and 36 solutions for the connection of a stub intra-domain multicast 37 routing domain to a transit (ISP) PIM-SM domain are addressed. 39 1. Introduction 41 New deployment of multicast routing in Internet Service Provider 42 networks is through the use of the PIM-SM [PIMSM], MSDP [MSDP], and 43 MBGP [MBGP] protocols. This informational document describes 44 several solutions for the connection of different types of multicast 45 routing domains. In particular, it describes the problems (and 46 solutions) for the connection of a stub intra-domain multicast 47 routing domain to a transit (ISP) PIM-SM domain. Because stub 48 domains may use a variety of multicast routing protocols it is 49 important to understand the connection issues between a provider 50 PIM-SM domain and stub domains. 52 In [INTEROP], an interoperability mechanism is described which can 53 be implemented in multicast border routers to route multicast 54 traffic between domains. This is accomplished through a shared 55 multicast forwarding table between two or more multicast routing 56 protocols. [INTEROP] describes the creation of the shared 57 forwarding cache, and thhe details of individual protocols from 58 the perspective of protocol implementors. 60 In this document, multiple scenarios are presented for the actual 61 interconnection of a stub/transit domain connection. We assume 62 that there is a multicast border router (BR) present which is 63 either part of the transit network or part of the stub network 64 which implements the mechanisms described in [INTEROP]. We assume 65 that the BR has two components, one which is the PIM-SM protocol, 66 and one which is the stub domain's intra-domain multicast routing 67 protocol. 69 1.1 Transit Domain (ISP) Configuration 71 In Internet Service Provider networks, PIM-SM has become the 72 de-facto multicast routing protocol, or tree-building protocol. In 73 order to connect PIM-SM domains, the MSDP protocol is used. MSDP is 74 a source distribution protocol, which distributes lists of sources 75 to all PIM-SM Rendenzvous points. To provide for multicast specific 76 routing policies, Multi-protocol BGP is used for multicast specific 77 routes. 79 1.2 Stub Domain Configuration 81 Intra-domain networks may run a variety of multicast routing 82 protocols, such as PIM-DM [PIMDM], PIM-SM [PIMSM], MOSPF [MOSPF], or 83 DVMRP [DVMRP]. These networks use multicast for private specialized 84 applications. In many circumstances, an intra-domain stub domain 85 may wish to receive multicast connectivity from its ISP to receive 86 inter-domain multicast traffic. Many ISPs have been offering access 87 to the legacy DVMRP part of the MBone, but recently, ISPs have 88 begun to offer PIM-SM/MSDP connectivity as well. Because stub 89 domains may run a variety of protocols, confusion exists about the 90 connectivity options when connecting to a PIM-SM provider domain. 92 1.3 General Configuration Issues 94 There are a number of general issues to consider when connecting 95 multicast domains. The following provides a quick summary of the 96 common issues which are not addressed in this document. 98 - Group Scoping: Stub domains may wish to scope certain groups 99 to stay within their domain. This is best accomplished with 100 administratively scoped addresses [ASCOPE]. Administrative 101 scoping ranges are configured on all border routers so as to 102 not forward scoped groups out of the domain. 103 - Special Addresses: Certain multicast addresses are used for 104 protocol purposes which are specific to a domain 105 (e.g. bootstrap messages). These messages should use 106 administratively scoped addresses and therefore should be 107 filtered at domain boundaries. 108 - Group Ownership: If a stub domain wishes to use global 109 addresses for multicast groups, it should use one of the 110 multicast address allocation mechanisms [GLOP, MALLOC] in 111 place to do so. By ignoring the problems of address 112 allocation, a domain may select an address which collides 113 with another which could cause excess traffic and possibly 114 denial of service to other groups. 115 - Multi-homing: Multi-homing multicast is difficult (note: 116 meaining the actual multi-homing of multicast traffic, not 117 unicast multi-homing with multicast enabled). Because 118 multicast routing protocols use RPF checks to prevent packet 119 looping, routing configurations must correctly reflect the 120 actual path of source packets. Mult-homing becomes more 121 difficult when different route distribution protocols are 122 used to distribute routes (e.g. DVMRP and MBGP). It should 123 be noted that a multicast source cannot be "load-balanced" 124 over multiple ingress points. Because packet looping must be 125 prevented, a set of sources must be injected at one point 126 into the network (of course this does not prevent the use 127 of *backup* routes). 129 1.4 Document Organization 131 The following sections describe the methods of connecting multicast 132 domains. Section 2 describes the connection of a stub 133 flood-and-prune domain to a provider domain using PIM-SM. Section 3 134 describes the connection of a stub PIM-SM domain to a provider 135 domain using PIM-SM. Section 4 describes the connection of 136 domains running MOSPF and IGMP-Proxy to a PIM-SM provider domain. 137 Section 5 describes the problems of distributing multicast 138 specific routes between domains. 140 2. Flood and Prune Protocols 142 Many stub or enterprise domains run flood and prune protocols. 143 These protocols, such as DVMRP and PIM-DM, are used because they are 144 simple to deploy and have been available for a long time. This 145 section describes the problems and solutions for connecting a flood 146 and prune stub domain to a transit ISP domain running 147 PIM-SM/MSDP/MBGP. The problems of route distribution are 148 deferred until section 5. 150 2.1 The Problems 152 Flood and prune protocols build multicast trees differently than the 153 explicit join mechanism of the PIM-SM protocol. Flood and prune 154 protocols assume group membership and use prune messages to prune 155 unwanted traffic. This is in contrast to explicit join protocols 156 like PIM-SM in which leaf routers explicitly setup tree branches 157 when an IGMP join is received. 159 In order to connect a flood and prune domain to a shared tree domain, 160 it is necessary to: 162 1. Communicate group membership information between domains 163 2. Bring data from the senders from the flood and prune domain 164 to the RP into the PIM-SM domain and visa-versa. 166 In flood and prune protocols, global group membership is not 167 available to any routers in the domain. This is because of the 168 inherent "dense-mode" philosophy in these protocols in that they 169 assume group membership. This becomes a problem because this 170 information is needed to create branches from the border router to 171 the PIM-SM RP. This is so sources from the shared tree domain can 172 be injected into the flood and prune domain. 174 The opposite problem also exists: how to inject sources from the 175 flood and prune domain into the shared tree domain. This problem 176 can be solved because of the nature of flood and prune protocols. 177 In a flood and prune protocol, every router knows the set of all 178 active sources for every group. Using this information, a BR can 179 act as if it is a directly attached router (to a source) for its 180 shared tree component. 182 The following section presents several solutions for connecting flood 183 and prune protocols in a stub domain to a shared tree protocol in a 184 transit (or ISP) domain. Section 2.3 discusses the problem of 185 injecting sources from stub flood-and-prune domains into transit 186 PIM-SM domains. Sections 2.4.1 through 2.4.4 suggest several 187 possibilities for bringing sources from the PIM-SM domain into the 188 flood-and-prune domain. 190 Note that this document only specifies the *possibilities* in 191 connecting domains. Different vendors may implement different 192 feature sets which include all or part of these solutions. 194 2.3 Stub Sources into Transit Domain 196 This section describes the problem of injecting sources from a 197 stub flood-and-prune domain into a PIM-SM transit domain. 198 Regardless of which solution is chosen for the reverse problem (i.e. 199 injecting sources from the transit to the stub), there is one 200 general solution to this problem which is specified in [PIMSM] and 201 summarized here. 203 BRs will have knowledge of all sources in the flood-and-prune stub 204 domain. In order to inject sources into the transit domain, it will 205 act as a PIM-SM "DR edge router" and use the PIM-SM register 206 protocol. That is, sources from the stub domain will be register 207 encapsulated to the appropriate RP in the PIM-SM domain. Behavior 208 is similar to a PIM-SM DR router encapsulating sources on its local 209 network with one exception. 211 When a PIM-SM DR receives a register stop message, it stops 212 encapsulating the source's data but still periodically sends 213 registers to the RP so that it will know the source is still active. 214 In the case of a DR on a LAN, this is straight-forward because a 215 new packet from the source will trigger an update of soft state on 216 the DR. However, in the case of a BR, it is desirable to prune the 217 source back into the stub domain. The problem arises because the 218 BR is dependent on the re-flood timer in the flood-and-prune 219 protocol as to when its forwarding state will be updated. There 220 are two solutions: 222 1. The transit domain may locate its RP at the BR. In this 223 case, the BR will have knowledge of all groups joined in 224 the transit domain. 225 2. The BR may chose not to prune the source into the stub 226 domain. This allows the BR to refresh its registers with 227 accuracy at the expense of creating a large sink in the 228 network (note: this is how MOSPF works). 229 3. DWRs can be used in the transit domain. If DWRs are 230 available then the BRs will only inject sources from the 231 stub domain which are joined in the transit. 232 4. The BR may send refreshes whenever a source is periodically 233 flooded in the stub domain. This MAY be longer than the 234 RP register state for a source and therefore a significant 235 delay may occur before the source is injected into the 236 transit domain. 237 5. MSDP may be used to report active sources into the transit 238 domain. This would involve a MSDP peering between the BR and 239 another router in the transit domain. 241 2.4 Transit Source into Stub Domain 243 2.4.1 Domain Wide Reports 245 The domain wide report [DWR] protocol allows for complete group 246 membership information for a domain to be obtained by BRs. The DWR 247 protocol works very much like the IGMP protocol except throughout a 248 domain, utilizing domain wide queries and domain wide reports. 249 Routers periodically send reports for all local memberships. These 250 reports can be used by border routers to determine the total group 251 membership of a domain. 253 In using DWRs in the connection of a flood-and-prune stub network to 254 a ISP PIM-SM domain, the following occur: 256 1. The stub domain must support DWR in its routing devices or 257 proxy DWR Reports from each IGMP subnet. 258 2. When a BR receives a domain wide report, it will perform a 259 (*,g) PIM-SM join towards the RP. This will enable sources 260 from the transit domain (and beyond) to be injected into the 261 stub domain. When a DWR membership times out or a group is 262 explicitly left, prunes should be sent for every forwarding 263 entry (i.e. non-pruned) matching the group. 265 DWRs present a "clean" solution to the problem of connecting 266 domains. DWRs may create a small additional overhead in control 267 traffic in the flood-and-prune domain. They also create extra 268 forwarding entries in the flood-and-prune domain because each router 269 which sends a DWR report is itself a multicast source. 271 2.4.2 Receivers are Senders Heuristic 273 Another possibility for transiting traffic between a flood-and-prune 274 domain and a PIM-SM domain is to use the "receivers are senders" 275 heuristic. This heuristic assumes that all receivers in the 276 flood-and-prune domain are also senders and will send traffic 277 to a group (e.g. RTCP). This is true for many-to-many applications 278 or one-to-many applications where receivers send RTCP reports but 279 not in general. Thus this heuristic may not deliver multicast 280 traffic from the PIM-SM domain to all receivers in the flood and 281 prune domain. 283 The "receivers are senders" heuristic works in the following manner: 285 1. BRs have global knowledge of sources in the flood-and-prune 286 domain by virtue of the protocol itself. These are either 287 forwarding or prune entries for all active internal sources 288 in all groups. 289 2. For every group for which there is a forwarding entry, a 290 (*,g) join is sent in the PIM-SM domain. This will pull 291 traffic from the PIM-SM domain into the flood-and-prune 292 domain. 294 The problems with this approach is that it may deny forwarding 295 multicast traffic to valid receivers. This would likely occur in 296 one-to-many applications which do not multicast their RTCP or RTCP 297 like reports. Another problem results if the aggregate reporting 298 interval for the stub domain is greater than the source timeout 299 for the forwarding entries in the BR. 301 2.4.3 (*,*,RP) 303 The PIM-SM specification [PIMSM] specifies that (*,*,RP) state can 304 be used for interconnection of multicast routing domains. These 305 (*,*,RP) tree branches are built from multicast border routers to 306 RPs in the PIM-SM domain. (*,*,RP) branches carry traffic from all 307 sources to all groups. (*,*,RP) solves the interconnection problem 308 by pulling all traffic from RPs to the BRs where it can then be 309 injected into an adjacent domain (in our case a flood-and-prune 310 domain). After it is flooded into the domain, it may be pruned back 311 to the BR where the BR may then initiate PIM-SM prunes back to the 312 RP. 314 In summary, (*,*,RP) works in the following way: 316 1. BRs initiate (*,*,RP) branches to all RPs (all routers in 317 the path will have (*,*,RP) forwarding entries). BRs simply 318 use the RP-set from the RP-set distribution mechanism 319 [PIMSM, AUTORP]. 320 2. When source traffic arrives at an RP, it will be forwarded 321 down the (*,*,RP) branch (as well as other outgoing 322 interfaces). 323 3. When traffic is received at the BR from the (*,*,RP) branch, 324 it is injected into the flood-and-prune domain. If there 325 are no receivers, it will be pruned back to the BR. 326 4. If the BR receives prunes for the injected source, it will 327 then prune the source back into the PIM-SM domain by issuing 328 (s,g) prunes towards the RP. 330 The problems with this approach are that some providers may be 331 reluctant to have (*,*,RP) state in their networks, particularly if 332 they have a large number of customers with flood-and-prune domains. 333 This would result in (*,*,RP) in many parts of the network, 334 effectively turning the PIM-SM domain into a flood-and-prune domain. 336 2.4.4 Running MSDP on BR 338 Another possibility for connection is through the use of the MSDP 339 protocol. In this scenario, MSDP is run on the BR with a peering 340 connection to any other MSDP speaker in the transit domain. MSDP is 341 used to learn about all sources in the PIM-SM domain (and beyond). 342 Once these sources are learned, they can be joined directly and 343 injected into the flood-and-prune domain. This functions in a 344 similar way to (*,*,RP) except that MSDP is used to discover the 345 sources, and must more state is used. 347 In summary, using MSDP to connect flood-and-prune domains works in 348 the following way: 350 1. MSDP is run on the BR. A MSDP peering is configured with 351 a MSDP speaker in the transit domain. 352 2. When a new source is learned through MSDP, the BR will send 353 a PIM-SM (s,g) join towards the source. 354 3. When data from the new source is received, the BR will 355 inject the source into the stub domain to be flooded. 356 4. If there are no receivers (or all receivers leave the 357 group), the source will be pruned back to the BR; the BR 358 will then send a (s,g) prune towards the source in the 359 PIM-SM domain. 361 Running MSDP on the BR provides a reasonable alternative without 362 DWRs. The only possible drawback is the growth of a providers MSDP 363 mesh as each customer will have a MSDP peering. However, this may 364 actually benefit a provider in that provisioning configurations are 365 are similar to inter-provider configurations. 367 3. Explicit Join Shared Tree Protocols 369 Stub domains may run shared tree protocols like PIM-SM. In cases 370 where a stub domain requires multicast transit service from an ISP 371 (also running PIM-SM), several options exist for configuration. 372 Route distribution is deferred until section 5. 374 This section presents the possibilities for connecting a stub 375 shared tree protocol domain (e.g. customer) to a transit PIM-SM 376 domain (e.g. provider). We assume that PIM-SM is the protocol 377 being run in both domains. (NOTE: although other shared-tree 378 protocols exist, PIM-SM is the only one which has currently 379 experienced "real-world" deployment. It is for this reason that 380 only PIM-SM to PIM-SM interconnection is addressed) 382 When an stub domain wishes to receive multicast connectivity from 383 a provider, a decision must be made as to which RPs the stub domain 384 will use. We present two scenarios: the first when the stub PIM 385 domain uses the ISP RPs and the second when a stub domain uses 386 its own RPS. 388 3.1 Using ISP RPs 390 A singly-homed stub domain (if allowed) may use its ISP RPs. In 391 many cases, the stub domain will need to run the same RP-set 392 distribution mechanism [PIMSM, AUTORP] that its ISP does and must 393 not filter any groups used for these protocols. It may be possible 394 for the BR to proxy messages from one RP-set distribution mechanism 395 into another if supported in a BR implemenation. In both cases, the 396 ISP's RP-set will be distributed into the stub domain. In this 397 way, the stub domain is an extension of the ISPs PIM-SM domain. 399 The disadvantage of this configuration is that all traffic must go 400 to the ISPs RPs. As an optimization, an ISP may use multiple RPs 401 with anycast [LOGRP], and may locate an RP at the POP where the 402 customer connects. This allows sources in the stub to be relatively 403 close to their RP. This configuration is best when the stub domain 404 is primarily going to receive traffic sourced outside its domain. 405 The advantage of this scheme is that it is easy to provision and 406 configure for the ISP. However, a potential disadvantage is that 407 routers may become state burdened if a stub domain has many 408 intra-domain groups and the link between the domains may be 409 burdened with traffic. 411 Another potential problem is in the allocation of administratively 412 scoped addresses. One possibility is for the ISP to divide its 413 administratively scoped address space between its customers. 414 Another possibility is for the stub domain to have its own RP but 415 only for administratively scoped groups. In this scenario, a 416 filtering mechanism would have to be in place at the BR to block 417 administratively scoped addresses across the boundary in the RP-set 418 protocol. However, global multicast group trees would still be 419 constructed across the domain boundary (i.e. using the ISP RPs for 420 global groups). 422 In summary, this solution works when a domain uses administratively 423 scoped addresses for its intra-domain groups (and uses its own RP 424 for these groups). It does not require MSDP configuration and 425 therefore does not grow the provider's MSDP mesh. 427 3.2 Private RPs with MSDP 429 When a domain has many multicast sources which will be destined 430 only within its domain, it is best to configure a separate PIM-SM 431 domain for the stub domain. In this configuration, the stub domain 432 runs MSDP to its provider. The border router between the PIM-SM 433 domains must: 435 - Block RP-set information between the domains 436 - Only allow (s,g) joins/prunes between domains (follows from 437 above) 438 - Configure boundaries for administratively scoped addresses 439 between domains. 441 Sources flow between transit and stub in the same way that ISP 442 PIM-SM/MSDP peering works. MSDP distributes source information to 443 RPs who directly join towards the sources. The sources are then 444 sent down the shared tree to receivers (last hop routers may then 445 make a decision about switching to an SPT tree following the 446 standard PIM protocol). When a RP learns a new source in its domain 447 it sends a source-active message in MSDP to all peers. 449 A domain may wish to configure a RP for private addresses 450 (administratively scoped) and one for global addresses. In this 451 case, the "global address" RP only needs MSDP (to peer with 452 transit). 454 4. Connections with other Protocols 456 4.1 MOSPF 458 MOSPF [MOSPF] is a unique protocol which makes use of the OSPF link 459 state database to compute source-based multicast trees. MOSPF has 460 several properties which make it particularly easy to connect to 461 other multicast routing domains: 463 - MOSPF floods group membership information using a Group 464 Membership LSA. Each DR will flood group membership 465 information for its attached subnet. Group LSAs are flooded 466 into the OSPF backbone; therefore, all OSPF backbone routers 467 have total group membership for the entire domain. 468 - MOSPF ABR and ASBRs are "wildcard" receivers. This router 469 will receive all traffic sourced in the domain. These 470 routers therefore have total source knowledge within a domain. 472 Both [MOSPF] and [INTEROP] describe the interoperability between 473 MOSPF and other protocols. The following section gives a quick 474 overview of the issues with repect to MOSPF. 476 4.1.1 Traffic from PIM-SM to MOSPF 478 In order to pull sources from a PIM-SM transit domain into a MOSPF 479 stub domain, the PIM-SM/MOSPF BR should send (*,g) joins into the 480 PIM-SM domain for every group for which a group membership LSA 481 exists in the OSPF LSDB. If all hosts leave the group, the group 482 membership LSAs will be flushed and the BR will send a (*,g) prune. 483 BRs may also monitor source rates and join to source trees if 484 necessary. 486 4.1.2 Traffic from MOSPF to PIM-SM 488 In order to pull sources from a flood-and-prune stub domain into a 489 PIM-SM transit domain, the PIM-SM/MOSPF BR will act as a PIM-SM DR 490 edge router and encapsulate all MOSPF sources in PIM-SM registers. 491 The multicast BR should be configured as a OSPF ASBR in order that 492 the wildcard receiver bit is enabled in the LSAs originated from the 493 router. As mentioned above, part of the MOSPF protocol requires 494 that ASBRs act as wildcard receivers. 496 4.2 IGMP-Proxy 498 IGMP-proxy [PROXY] is a name used to describe a proxy of the 499 IGMP protocol. A router or other device proxies IGMP reports from 500 some interfaces (downstream) to other (upstream) interfaces. The 501 downstream interfaces are typically connected to either dial-in 502 lines or LANS. The upstream interfaces are connected to one or 503 more multicast routers. In the following section, the term BR is 504 used to describe the upstream multicast routers of an IGMP-proxy. 506 A small domain or dial-in user may use IGMP-Proxy within a small 507 network for multicast connectivity. The most critical part of a 508 connection with IGMP-Proxy is that the transit domain have the 509 correct routing information for RPF checks for the stub domain. 511 In order to inject sources from the transit domain to the IGMP-relay 512 domain, a BR is configured with a PIM-SM component (on the provider 513 network), and a regular multicast enabled interface on the stub 514 domain side. To the BR, the IGMP-Proxy domain will look like a 515 single host. Devices will proxy IGMP reports towards the router 516 which will then perform the standard PIM-SM joining procedure. 518 In order to inject sources from the IGMP-Proxy domain into the PIM-SM 519 transit domain, the BR must be configured with the correct routing 520 information for the PIM-SM RPF checks to pass. In the simplest case, 521 the router has route (pointing towards the stub) for all 522 subnets which are multicast capable. The proxy will relay all 523 sources towards the BR which will then be injected into the domain. 525 It is expected that multi-homed domains will be running a multicast 526 routing protocol as opposed to IGMP-Proxy. In the case that a 527 multi-homed stub uses IGMP-Proxy, it must ensure that the sources are 528 relayed to the correct RPF router in the multi-homed configuration 529 (see section 5). 531 5. Exchanging Multicast Specific Routes 533 Some multicast routing protocols in use today perform Reverse Path 534 Forwarding (RPF) checks on packets to verify they were received on 535 the "correct" (i.e. shortest to source or RP) interface. These RPF 536 checks are used to prevent multicast packet looping. 538 When multiple multicast domains transit multicast packets, it is 539 important that routes exchanged between the domains allow for RPF 540 checks to be performed correctly. Problems can occur when domains 541 use different protocols for route selection (e.g. with PIM-SM). 542 Problems can also occur in situations where there are load 543 balancing/backup route schemes in use for unicast routing and the 544 multicast tree building protocol is using those routes for RPF checks. 546 This section presents several route distribution scenarios and 547 attempts to present some of the problems specific to multicast. Many 548 scenarios are covered briefly because they are well-known 549 configurations for unicast routing. 551 5.1 MBGP Peering 553 A provider may choose to MBGP peer with a stub domain in order 554 to learn multicast specific routes from the stub domain. The 555 specifics of MBGP peering are similar to unicast BGP peering. 557 If a stub domain is multi-homed, then MBGP is important for 558 learning the correct ingress for sources. However, unless these 559 routes are injected into the IGP (for multicast), they are not 560 useful. MBGP peering is most useful for providers to learn the 561 the correct ingress for a source. 563 Dependant on the IGP (being used for multicast), multicast specific 564 routes may be injected from MBGP. In most cases, a stub domain 565 will inject a default route from the BR that is connected with 566 the provider network. The following sections discuss injecting 567 default routes into multicast IGPs. In many cases the MBGP peer 568 in the stub domain is the multicast BR. 570 5.2 DVMRP Route Injection 572 If a stub domain is using DVMRP as its multicast IGP, then a 573 default route may be injected from a the multicast BR. This 574 route may be injected dependent on either BGP or MBGP routes 575 being learned. 577 Some implementations of PIM support using DVMRP as a route 578 distribution protocol. PIM can be configured to use DVMRP routes 579 for RPF checking. In this case, a different multicast default 580 route (i.e. from the unicast default) can be injected into a 581 stub domain using DVMRP. 583 (note: only some implementations of DVMRP *truly* support use 584 of a default route. later versions of the spec explicity state 585 the prune and graft rules when a default route is used) 587 5.3 MOSPF Route Injection 589 If a stub domain uses MOSPF as its multicast IGP then multicast 590 specific routes must be injected into OSPF. In most cases, a 591 domain will want to use a default route for external multicast 592 sources. A default route tagged with the "multicast" bit in the 593 OSPF can be used for this. 595 5.4 Different Multicast/Unicast Defaults 597 If a stub domain wishes to configure separate multicast and unicast 598 default routes then it is currently limited in the type of 599 configurations that can be used (this will change as multicast 600 specific metrics are added into unicast IGPs). Three options are 601 to: 602 1. Use DVMRP (strictly as a route propagation protocol) to 603 propagate the multicast specific route. 604 2. Use MOSPF with OSPF multicast tagged route 605 3. MBGP peering for all multicast routers 607 6. References 609 [PIMSM] Estrin, D.,et al., "Protocol Independent Multicast-Sparse Mode 610 (PIM-SM): Protocol Specification," RFC 2362, June 1998. 612 [DWR] Fenner, W., "Domain Wide Multicast Group Membership Reports," 613 draft-ietf-idmr-membership-reports-04.txt, August 1999. 615 [AUTORP] Farinacci, D., Wei, L., "Auto-RP: Automatic discovery of 616 Group-to-RP mappings for IP multicast," 617 ftp://ftpeng.cisco.com/ipmulticast/pim-autorp-spec01.txt, 618 September 1998. 620 [INTEROP] Thaler, D., "Interoperability Rules for Multicast 621 Routing Protocols," RFC 2715, October 1999. 623 [DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol," 624 draft-ietf-idmr-dvmrp-v3-09.txt, September 1999. 626 [PROXY] Fenner, W., "IGMP-based Multicast Forwarding 627 (``IGMP Proxying'')," draft-fenner-igmp-proxy-01.txt, 628 June 1999. 630 [MOSPF] Moy, J., "Multicast Extensions to OSPF," 631 RFC 1584, March 1994. 633 [PIMDM] Deering, S., et al., "Protocol Independent Multicast 634 Version 2 Dense Mode Specification," 635 draft-ietf-pim-v2-dm-01.txt, November 1998. 637 [BGP] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)," 638 RFC 1828, March 1995. 640 [MBGP] Bates, T., et al., "Multiprotocol Extensions for BGP-4," 641 RFC 2283, February 1998. 643 [MSDP] Farinacci, D., "Multicast Source Discovery Protocol (MSDP)," 644 draft-ietf-msdp-spec-05.txt, February 2000. 646 [ASCOPE] Meyer, D., "Administratively Scoped IP Multicast," 647 RFC 2365, July 1998. 649 [GLOP] Meyer, D., Lothberg, P., "GLOP Addressing in 233/8," 650 RFC 2770, February 2000. 652 [MALLOC] Thaler, D., Handley, M., Estrin, D., "The Internet 653 Multicast Address Allocation Architecture," 654 draft-ietf-malloc-arch-04.txt, January 2000. 656 [LOGRP] Kim, D., et al., "Anycast RP mechanism using PIM and MSDP," 657 draft-ietf-mboned-anycast-rp-05.txt, January 2000. 659 7. Author's Address 661 Brad Cain 662 Nortel Networks 663 600 Technology Park 664 Billerica, MA 01821 665 1-978-288-1316 666 bcain@nortelnetworks.com