idnits 2.17.1 draft-thaler-multicast-interop-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 923 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages -- Found 21 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (31 July 1998) is 9394 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '3') ** Obsolete normative reference: RFC 2362 (ref. '4') (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Historic RFC: RFC 2189 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Multicast Routing (IDMR) D. Thaler 3 Internet Engineering Task Force Microsoft 4 INTERNET-DRAFT 31 July 1998 5 draft-thaler-multicast-interop-03.txt Expires: January, 1999 7 Interoperability Rules for Multicast Routing Protocols 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 The rules described in this document will allow efficient interoperation 32 among multiple independent multicast routing domains. Specific 33 instantiations of these rules are given for the DVMRP, MOSPF, PIM-DM, 34 PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only 35 links. Future versions of these protocols, and any other multicast 36 routing protocols, may describe their interoperability procedure by 37 stating how the rules described herein apply to them. 39 Copyright Notice Copyright (C) The Internet Society (1998). All Rights 40 Reserved. 42 1. Introduction 44 To allow sources and receivers inside multiple autonomous multicast 45 routing domains (or "regions") to communicate, the domains must be 46 connected by multicast border routers (MBRs). To prevent black holes or 47 routing loops among domains, we assume that these domains are organized 48 into one of the following topologies: 50 o A tree (or star) topology (figure 1) with a backbone domain at the 51 root, stub domains at the leaves, and possibly "transit" domains as 52 branches between the root and the leaves. Each pair of adjacent 53 domains is connected by one or more MBRs. The root of each subtree 54 of domains receives all globally-scoped traffic originated anywhere 55 within the subtree, and forwards traffic to its parent and children 56 where needed. Each parent domain's MBR injects a default route 57 into its child domains, while child domains' MBRs inject actual 58 (but potentially aggregated) routes into parent domains. Thus, the 59 arrows in the figure indicate both the direction in which the 60 default route points, as well as the direction in which all 61 globally-scoped traffic is sent. 63 +--------+ 64 +----| |----+ 65 +---+ +---+ | ===> <=== | 66 | | | | +----| # |----+ 67 | | | # | +-----#------+ 68 | # | +---#-------| v |-----------+ 69 +--#----| v | | |-----+ 70 | v ===> ===> Backbone <=== <=== | 71 +-------| ^ | | ^ |-----+ 72 +---#-------| ^ |-----#-----+ 73 | # | +-----#------+ | # |-----+ 74 | | | # | | <=== | 75 +---+ +---| | | |-----+ 76 | ===> | +--------+ 77 +---+--------+ 79 Figure 1: Tree Topology of Domains 81 o An arbitrary topology, in which a higher level (inter-domain) 82 routing protocol, such as HDVMRP [1] or BGMP [9], is used to 83 calculate paths among domains. Each pair of adjacent domains is 84 connected by one or more MBRs. 86 Section 2 describes rules allowing interoperability between existing 87 multicast routing protocols [2,3,4,5,6], and reduces the 88 interoperability problem from O(N^2) potential protocol interactions, to 89 just N (1 per protocol) instantiations of the same set of invariant 90 rules. This document specifically applies to Multicast Border Routers 91 (MBRs) which meet the following assumptions: 93 o The MBR consists of two or more active multicast routing 94 components, each running an instance of some multicast routing 95 protocol. No assumption is made about the type of multicast 96 routing protocol (e.g., broadcast-and-prune vs. explicit-join) any 97 component runs, or the nature of a "component". Multiple 98 components running the same protocol are allowed. 100 o The router is configured to forward packets between two or more 101 independent domains. The router has one or more active interfaces 102 in each domain, and one component per domain. The router also has 103 an inter-component "alert dispatcher", which we cover in Section 3. 105 o Only one multicast routing protocol is active per interface (we do 106 not consider mixed multicast protocol LANs). Each interface on 107 which multicast is enabled is thus "owned" by exactly one of the 108 components. 110 o All components share a common forwarding cache of (S,G) entries, 111 which are created when data packets are received, and can be 112 deleted at any time. Only the component owning an interface may 113 change information about that interface in the forwarding cache. 114 Each forwarding cache entry has a single incoming interface (iif) 115 and a list of outgoing interfaces (oiflist). Each component 116 typically keeps a separate multicast routing table with any type of 117 entries. 119 Note that the guidelines in this document are implementation- 120 independent. The same rules given in Section 2 apply in some form, 121 regardless of the implementation. For example, they apply to each of 122 the following architectural models: 124 o Single process (e.g., GateD): Several routing components in the 125 same user-space process, running on top of a multicast-capable 126 kernel. 128 o Multiple peer processes: Several routing components, each as a 129 separate user-space process, all sitting on top of a multicast- 130 capable kernel, with N*(N-1) interaction channels. 132 o Multiple processes with arbiter: Multiple independent peer routing 133 component processes which interact with each other and with the 134 kernel solely through an independent arbitration daemon. 136 o Monolith: Several routing components which are part of the "kernel" 137 itself. 139 We describe all interactions between components in terms of "alerts". 140 The nature of an alert is implementation-dependent (e.g., it may consist 141 of a simple function call, writing to shared memory, use of IPC, or some 142 other method) but alerts of some form exist in every model. Similarly, 143 the originator of an alert is also implementation-dependent; for 144 example, alerts may be originated by a component effecting a change, by 145 an independent arbiter, or by the kernel. 147 1.1. Specification Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119. 153 2. Requirements 155 To insure that a MBR fitting the above assumptions exhibits correct 156 interdomain routing behavior, each MBR component MUST adhere to the 157 following rules: 159 Rule 1: All components must agree on which component owns the incoming 160 interface (iif) for a forwarding cache entry. This component, 161 which we call the "iif owner" is determined by the dispatcher 162 (see Section 3). The incoming component may select ANY 163 interface it owns as the iif according to its own rules. 165 When a routing change occurs which causes the iif to change to an 166 interface owned by a different component, both the component previously 167 owning the entry's iif and the component afterwards owning the entry's 168 iif MUST notice the change (so the first can prune upstream and the 169 second can join/graft upstream, for example). Typically, noticing such 170 changes will happen as a result of normal protocol behavior. 172 Rule 2: The component owning an interface specifies the criteria for 173 which packets received on that interface are to be accepted or 174 dropped (e.g., whether to perform an RPF check, and what scoped 175 boundaries exist on that interface). Once a packet is accepted, 176 however, it is processed according to the forwarding rules of 177 all components. 179 Furthermore, some multicast routing protocols (e.g. PIM) also require 180 the ability to react to packets received on the "wrong" interface. To 181 support these protocols, an MBR must allow a component to place any of 182 its interfaces in "WrongIf Alert Mode". If a packet arrives on such an 183 interface, and is not accepted according to Rule 2, then the component 184 owning the interface MUST be alerted [(S,G) WrongIf alert]. Typically, 185 WrongIf alerts must be rate-limited. 187 Rule 3: Whenever a new (S,G) forwarding cache entry is to be created 188 (e.g., upon accepting a packet destined to a non-local group), all 189 components MUST be alerted [(S,G) Creation alert] so that they can set 190 the forwarding state on their own outgoing interfaces (oifs) before the 191 packet is forwarded. 193 Note that (S,G) Creation alerts are not necessarily generated by one of 194 the protocol components themselves. 196 Rule 4: When a component removes the last oif from an (S,G) forwarding 197 cache entry whose iif is owned by another component, or when 198 such an (S,G) forwarding cache entry is created with an empty 199 oif list, the component owning the iif MUST be alerted [(S,G) 200 Prune alert] (so it can send a prune, for example). 202 Rule 5: When the first oif is added to an (S,G) forwarding cache entry 203 whose iif is owned by another component, the component owning 204 the iif MUST be alerted [(S,G) Join alert] (so it can send a 205 join or graft, for example). 207 The oif list in rules 4 and 5 must also logically include any virtual 208 encapsulation interfaces such as those used for tunneling or for sending 209 encapsulated packets to an RP/core. 211 Rule 6: Unless a component reports the aggregate group membership in the 212 direction of its interfaces, it MUST be a "wildcard receiver" 213 for all sources whose RPF interface is owned by another 214 component ("externally-reached" sources). In addition, a 215 component MUST be a "wildcard receiver" for all sources whose 216 RPF interface is owned by that component ("internally-reached" 217 sources) if any other component of the MBR is a wildcard 218 receiver for externally-reached sources; this will happen 219 naturally as a result of Rule 5 when it receives a (*,*) Join 220 alert. 222 For example, if the backbone does not keep global membership 223 information, all MBR components in the backbone in a tree topology of 224 domains, as well as all components owning the RPF interface towards the 225 backbone are wildcard receivers for externally-reached sources. 227 MBRs need not be wildcard receivers (for internally- or externally- 228 reached sources) if a higher-level routing protocol, such as BGMP, is 229 used for routing between domains. 231 2.1. Deleting Forwarding Cache Entries 233 Special care must be taken to follow Rules 4 and 5 when forwarding cache 234 entries can be deleted at will. Specifically, a component must be able 235 to determine when the combined oiflist for (S,G) goes from null to non- 236 null, and vice versa. 238 This can be done in any implementation-specific manner, including, but 239 not limited to, the following possibilities: 241 o Whenever a component would modify the oiflist of a single 242 forwarding cache entry if one existed, one is first created. The 243 oiflist is then modified and Rules 4 and 5 applied after an (S,G) 244 Creation alert is sent to all components and all components have 245 updated the oiflist. OR, 247 o When a forwarding cache entry is to be deleted, a new alert [(S,G) 248 Deletion alert] is sent to all components, and the entry is only 249 deleted if all components then grant permission. Each component 250 could then grant permission only if it had no (S,G) route table 251 entry. 253 2.2. Additional Recommendation 255 Using (*,G) Join alerts and (*,G) Prune alerts can reduce bandwidth 256 usage by avoiding broadcast-and-prune behavior among domains when it is 257 unnecessary. This optimization requires that each component be able to 258 determine which other components are interested in any given group. 260 Although this may be done in any implementation-dependent method, one 261 example would be to maintain a common table (which we call the 262 Component-Group Table) indexed by group-prefix, listing which components 263 are interested in each group(prefix). Thus, any components which are 264 wildcard receivers for externally-reached sources (i.e., those whose RPF 265 interface is owned by another component) would be listed in all entries 266 of this table, including a default entry. This table is thus loosely 267 analogous to a forwarding cache of (*,G) entries, except that no 268 distinction is made between incoming and outgoing interfaces. 270 3. Alert Dispatchers 272 We assume that each MBR has an "alert dispatcher". The dispatcher is 273 responsible for selecting, for each (S,G) entry in the shared forwarding 274 cache, the component owning the iif. It is also responsible for 275 selecting to which component(s) a given alert should be sent. 277 3.1. The "Interop" Dispatcher 279 We describe here rules that may be used in the absence of any inter- 280 domain multicast routing protocol, to enable interoperability in a tree 281 topology of domains. If an inter-domain multicast routing protocol is 282 in use, another dispatcher should be used instead. The Interop 283 dispatcher does not own any interfaces. 285 To select the iif of an (S,G) entry, the iif owner is the component 286 owning the next-hop interface towards S in the multicast RIB. 288 The "iif owner" of (*,G) and (*,*) entries is the Interop dispatcher 289 itself. This allows the Interop dispatcher to receive relevant alerts 290 without owning any interfaces. 292 3.1.1. Processing Alerts 294 If the Interop dispatcher receives an (S,G) Creation alert, it adds no 295 interfaces to the entry's oif list, since it owns none. 297 When the Interop dispatcher receives a (*,G) Prune alert, the following 298 actions are taken, depending on the number of components N which want to 299 receive data for G. If N has just changed from 2 to 1, a (*,G) Prune 300 alert is sent to the remaining component. If N has just changed from 1 301 to 0, a (*,G) Prune alert is sent to ALL components other than the 1. 303 When the Interop dispatcher receives a (*,G) Join alert, the following 304 actions are taken, depending on the number of components N which want to 305 receive data for G. If N has just changed from 0 to 1, a (*,G) Join 306 alert is sent to ALL components other than the 1. If N has just changed 307 from 1 to 2, a (*,G) Join alert is sent to the original (1) component. 309 3.2. "BGMP" Dispatcher 311 This dispatcher can be used with an inter-domain multicast routing 312 protocol (such as BGMP) which allows global (S,G) and (*,G) trees. 314 The iif owner of an (S,G) entry is the component owning the next-hop 315 interface towards S in the multicast RIB. 317 The iif owner of a (*,G) entry is the component owning the next-hop 318 interface towards G in the multicast RIB. 320 3.2.1. Processing Alerts 322 This dispatcher simply forwards all (S,G) and (*,G) alerts to the iif 323 owner of the associated entry. 325 4. Multicast Routing Protocol Components 327 In this section, we describe how the rules in section 2 apply to current 328 versions of various protocols. Future versions, and additional 329 protocols, should describe how these rules apply in a separate document. 331 4.1. DVMRP 333 In this section we describe how the rules in section 2 apply to DVMRP. 334 We assume that the reader is familiar with normal DVMRP behavior as 335 specified in [2]. 337 As with all broadcast-and-prune protocols, DVMRP components are 338 automatically wildcard receivers for internally-reached sources. Unless 339 some form of Domain-Wide-Reports (DWRs) [10] (synonymous with Regional- 340 Membership-Reports as described in [1]) are added to DVMRP in the 341 future, all DVMRP components also act as wildcard receivers for 342 externally-reached sources. If DWRs are available for the domain, then 343 a DVMRP component acts as a wildcard receiver for externally-reached 344 sources only if internally-reached domains exist which do not support 345 some form of DWRs. 347 One simple heuristic to approximate DWRs is to assume that if there are 348 any internally-reached members, then at least one of them is a sender. 349 With this heuristic, the presense of any (S,G) state for internally- 350 reached sources can be used instead. Sending a data packet to a group 351 is then equivalent to sending a DWR for the group. 353 4.1.1. Generating Alerts 355 A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., 356 the Interop dispatcher) when the first component becomes a wildcard 357 receiver for external sources. This may occur when a DVMRP component 358 starts up which does not support some form of DWRs. 360 A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., 361 the Interop dispatcher) when all components are no longer wildcard 362 receivers for external sources. This may occur when a DVMRP component 363 which does not support some form of DWRs shuts down. 365 An (S,G) Prune alert is sent to the component owning the iif for a 366 forwarding cache entry whenever the last oif is removed from the entry, 367 and the iif is owned by another component. In DVMRP, this may happen 368 when: 369 o A DVMRP (S,G) Prune message is received on the logical interface. 371 An (S,G) Join alert is sent to the component owning the iif for a 372 forwarding cache entry whenever the first logical oif is added to an 373 entry, and the iif is owned by another component. In DVMRP, this may 374 happen when any of the following occur: 375 o The oif's prune timer expires, or 376 o A DVMRP (S,G) Graft message is received on the logical interface, 377 or 378 o IGMP [7] notifies DVMRP that directly-connected members of G now 379 exist on the interface. 381 When it is known, for a group G, that there are no longer any members in 382 the DVMRP domain which receive data for externally-reached sources from 383 the local router, a (*,G) Prune alert is sent to the "iif owner" for 384 (*,G) according to the dispatcher. In DVMRP, this may happen when: 385 o The DWR for G times out, or 386 o The members-are-senders approximation is being used and the last 387 (S,G) entry for G is timed out. 389 When it is first known that there are members of a group G in the DVMRP 390 domain, a (*,G) Join alert is sent to the "iif owner" of (*,G). In 391 DVMRP, this may happen when either of the following occurs: 392 o A DWR is received for G, or 393 o The members-are-senders approximation is being used and a data 394 packet for G is received on one of the component's interfaces. 396 4.1.2. Processing Alerts 398 When a DVMRP component receives an (S,G) Creation alert, it adds all the 399 component's interfaces to the entry's oif list (according to normal 400 DVMRP behavior) EXCEPT: 401 o the iif, 402 o interfaces without local members of the entry's group, and for 403 which DVMRP (S,G) Prune messages have been received from all 404 downstream dependent neighbors. 405 o interfaces for which the router is not the designated forwarder for 406 S, 407 o and interfaces with scoped boundaries covering the group. 409 When a DVMRP component receives an (S,G) Prune alert, and the forwarding 410 cache entry's oiflist is empty, it sends a DVMRP (S,G) Prune message to 411 the upstream neighbor according to normal DVMRP behavior. 413 When a DVMRP component receives a (*,G) or (*,*) Prune alert, it is 414 treated as if an (S,G) Prune alert were received for every existing 415 DVMRP (S,G) entry covered. In addition, if DWRs are being used, a DWR 416 Leave message is sent within its domain. 418 When a DVMRP component receives an (S,G) Join alert, and a prune was 419 previously sent upstream, it sends a DVMRP (S,G) Graft message to the 420 upstream neighbor according to normal DVMRP behavior. 422 When a DVMRP component receives a (*,G) or (*,*) Join alert, it is 423 treated as if an (S,G) Join alert were received for every existing DVMRP 424 (S,G) entry covered. In addition, if DWRs are being used, the component 425 sends a DWR Join message within its domain. 427 4.2. MOSPF 429 In this section we describe how the rules in section 2 apply to MOSPF. 430 We assume that the reader is familiar with normal MOSPF behavior as 431 specified in [3]. We note that MOSPF allows joining and pruning entire 432 groups, but not individual sources within groups. 434 Although interoperability between MOSPF and dense-mode protocols (such 435 as DVMRP) is specified in [3], we describe here how an MOSPF 436 implementation may interoperate with all other multicast routing 437 protocols. 439 An MOSPF component acts as a wildcard receiver for internally-reached 440 sources if and only if any other component is a wildcard receiver for 441 externally-reached sources. An MOSPF component acts as a wildcard 442 receiver for externally-reached sources only if internally-reached 443 domains exist which do not support some form of Domain-Wide-Reports 444 (DWRs) [10]. Since MOSPF floods membership information throughout the 445 domain, MOSPF itself is considered to support a form of DWRs natively. 447 4.2.1. Generating Alerts 449 A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., 450 the Interop dispatcher) when the first component becomes a wildcard 451 receiver for external sources. This may occur when an MOSPF component 452 starts up and decides to act in this role. 454 A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., 455 the Interop dispatcher) when all components are no longer wildcard 456 receivers for external sources. This may occur when an MOSPF component 457 which was acting in this role shuts down. 459 When it is known that there are no longer any members of a group G in 460 the MOSPF domain, a (*,G) Prune alert is sent to the "iif owner" for 461 (*,G) according to the dispatcher. In MOSPF, this may happen when 462 either: 463 o IGMP notifies MOSPF that there are no longer any directly-connected 464 group members on an interface, or 465 o Any router's group-membership-LSA for G is aged out. 467 When it is first known that there are members of a group G in the MOSPF 468 domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), 469 according to the dispatcher. In MOSPF, this may happen when any of the 470 following occur: 471 o IGMP notifies MOSPF that directly-connected group members now exist 472 on the interface, or 473 o A group-membership-LSA is received for G. 475 4.2.2. Processing Alerts 477 When an MOSPF component receives an (S,G) Creation alert, it calculates 478 the shortest path tree for the MOSPF domain, and adds the downstream 479 interfaces to the entry's oif list according to normal MOSPF behavior. 481 When an MOSPF component receives an (S,G) Prune alert, the alert is 482 ignored, since MOSPF can only prune entire groups at a time. 484 When an MOSPF component receives a (*,G) Prune alert, and there are no 485 directly-connected members on any MOSPF interface, the router 486 "prematurely ages" out its group-membership-LSA for G in the MOSPF 487 domain according to normal MOSPF behavior. 489 When an MOSPF component receives either an (S,G) Join alert or a (*,G) 490 Join alert, and G was not previously included in the router's group- 491 membership-LSA (and the component is not a wildcard multicast receiver), 492 it originates a group-membership-LSA in the MOSPF domain according to 493 normal MOSPF behavior. 495 When an MOSPF component receives a (*,*) Prune alert, it ceases to be a 496 wildcard multicast receiver in its domain. 498 When an MOSPF component receives a (*,*) Join alert, it becomes a 499 wildcard multicast receiver in its domain. 501 4.3. PIM-DM 503 In this section we describe how the rules in section 2 apply to Dense- 504 mode PIM. We assume that the reader is familiar with normal PIM-DM 505 behavior as specified in [6]. 507 As with all broadcast-and-prune protocols, PIM-DM components are 508 automatically wildcard receivers for internally-reached sources. Unless 509 some form of Domain-Wide-Reports (DWRs) [10] are added to PIM-DM in the 510 future, all PIM-DM components also act as wildcard receivers for 511 externally-reached sources. If DWRs are available for the domain, then 512 a PIM-DM component acts as a wildcard receiver for externally-reached 513 sources only if internally-reached domains exist which do not support 514 some form of DWRs. 516 One simple heuristic to approximate DWRs is to assume that if there are 517 any internally-reached members, then at least one of them is a sender. 518 With this heuristic, the presense of any (S,G) state for internally- 519 reached sources can be used instead. Sending a data packet to a group 520 is then equivalent to sending a DWR for the group. 522 4.3.1. Generating Alerts 524 A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., 525 the Interop dispatcher) when the first component becomes a wildcard 526 receiver for external sources. This may occur when a PIM-DM component 527 starts up which does not support some form of DWRs. 529 A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., 530 the Interop dispatcher) when all components are no longer wildcard 531 receivers for external sources. This may occur when a PIM-DM component 532 which does not support some form of DWRs shuts down. 534 A (S,G) Prune alert is sent to the component owning the iif for a 535 forwarding cache entry whenever the last oif is removed from the 536 forwarding cache entry, and the iif is owned by another component. In 537 PIM-DM, this may happen when: 538 o A PIM (S,G) Join/Prune message with S in the prune list is received 539 on a point-to-point interface. 540 o The Oif-Timer in an (S,G) route table entry expires. 541 o A PIM (S,G) Assert message from a preferred neighbor is received on 542 the interface. 544 A (S,G) Join alert is sent to the component owning the iif for a 545 forwarding cache entry whenever the first oif is added to an entry, and 546 the iif is owned by another component. In PIM-DM, this may happen when 547 any of the following occur: 548 o The oif's prune timer expires, or 549 o A PIM-DM (S,G) Graft message is received on the interface, or 550 o IGMP notifies PIM-DM that directly-connected group members now 551 exist on the interface. 553 When it is known that there are no longer any members of a group G in 554 the PIM-DM domain which receive data for externally-reached sources from 555 the local router, a (*,G) Prune alert is sent to the "iif owner" for 556 (*,G) according to the dispatcher. In PIM-DM, this may happen when: 557 o The DWR for G times out. 558 o The members-are-senders approximation is being used and PIM-DM's 559 last (S,G) entry for G is timed out. 561 When it is first known that there are members of a group G in the PIM-DM 562 domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), 563 according to the dispatcher. In PIM-DM, this may happen when either of 564 the following occurs: 565 o A DWR is received for G. 566 o The members-are-senders approximation is being used and a data 567 packet for G is received on one of the component's interfaces. 569 4.3.2. Processing Alerts 570 When a PIM-DM component receives an (S,G) Creation alert, it adds the 571 component's interfaces to the entry's oif list (according to normal 572 PIM-DM behavior) EXCEPT: 573 o the iif, 574 o leaf networks without local members of the entry's group, 575 o and interfaces with scoped boundaries covering the group. 577 When a PIM-DM component receives an (S,G) Prune alert, and the 578 forwarding cache entry's oiflist is empty, it sends a PIM-DM (S,G) Prune 579 message to the upstream neighbor according to normal PIM-DM behavior. 581 When a PIM-DM component receives a (*,G) or (*,*) Prune alert, it is 582 treated as if an (S,G) Prune alert were received for every matching 583 (S,G) entry. 585 When a PIM-DM component receives an (S,G) Join alert, and an (S,G) prune 586 was previously sent upstream, it sends a PIM-DM (S,G) Graft message to 587 the upstream neighbor according to normal PIM-DM behavior. 589 When a PIM-DM component receives a (*,G) or (*,*) Join alert, then for 590 each matching (S,G) entry in the PIM-DM routing table for which a prune 591 was previously sent upstream, it sends a PIM-DM (S,G) Graft message to 592 the upstream neighbor according to normal PIM-DM behavior. In addition, 593 if DWR's are being used, the component sends a DWR Join message within 594 its domain. 596 4.4. PIM-SM 598 In this section we describe how the rules in section 2 apply to Sparse- 599 mode PIM. We assume that the reader is familiar with normal PIM-SM 600 behavior, as specified in [4]. 602 To achieve correct PIM-SM behavior within the domain, the PIM-SM domain 603 MUST be convex so that Bootstrap messages reach all routers in the 604 domain. That is, the shortest-path route from any internal router to 605 any other internal router must lie entirely within the PIM domain. 607 Unless some form of Domain-Wide-Reports (DWRs) [10] are added to PIM-SM 608 in the future, all PIM-SM components act as wildcard receivers for 609 externally-reached sources. If DWRs are available for the domain, then 610 a PIM-SM component acts as a wildcard receiver for externally-reached 611 sources only if internally-reached domains exist which do not support 612 some form of DWRs. 614 A PIM-SM component acts as a wildcard receiver for internally-reached 615 sources if and only if any other component is a wildcard receiver for 616 externally-reached sources. It does this by periodically sending 617 (*,*,RP) Joins to all RPs for non-local groups (for example, 239.x.x.x 618 is considered locally-scoped, and PIM-SM components do not send (*,*,RP) 619 Joins to RPs supporting only that portion of the address space). The 620 period is set according to standard PIM-SM rules for periodic Join/Prune 621 messages. 623 To properly instantiate Rule 1, whenever PIM creates a PIM (S,G) entry 624 for an externally-reached source, and the next hop towards S is reached 625 via an interface owned by another component, the iif should always point 626 towards S and not towards the RP for G. In addition, the Border-bit is 627 set in all PIM Register messages for this entry. 629 Finally, the PIM-SM component acts as a DR for externally-reached 630 receivers in terms of being able to switch to the shortest-path tree for 631 internally-reached sources. 633 4.4.1. Generating Alerts 635 A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., 636 the Interop dispatcher) when the first component becomes a wildcard 637 receiver for external sources. This may occur when a PIM-SM component 638 starts up and decides to act in this role. 640 A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., 641 the Interop dispatcher) when all components are no longer wildcard 642 receivers for external sources. This may occur when a PIM-SM component 643 which was acting in this role shuts down. 645 A (S,G) Prune alert is sent to the component owning the iif for a 646 forwarding cache entry whenever the last oif is removed from the entry 647 and the iif is owned by another component. In PIM-SM, this may happen 648 when: 649 o A PIM (S,G) Join/Prune message with S in the prune list is received 650 on a point-to-point interface, or 651 o A PIM (S,G) Assert from a preferred neighbor was received on the 652 interface, or 653 o A PIM Register-Stop message is received for (S,G), or 654 o The interface's Oif-Timer for PIM's (S,G) route table entry 655 expires. 656 o The Entry-Timer for PIM's (S,G) route table entry expires. 658 When it is known that there are no longer any members of a group G in 659 the PIM-SM domain which receive data for externally-reached sources from 660 the local router, a (*,G) Prune alert is sent to the "iif owner" for 661 (*,G) according to the dispatcher. In PIM-SM, this may happen when: 662 o A PIM (*,G) Join/Prune message with G in the prune list is received 663 on a point-to-point interface, or 664 o A PIM (*,G) Assert from a preferred neighbor was received on the 665 interface, or 666 o IGMP notifies PIM-SM that directly-connected members no longer 667 exist on the interface. 668 o The Entry-Timer for PIM's (*,G) route table entry expires. 670 A (S,G) Join alert is sent to the component owning the iif for a 671 forwarding cache entry whenever the first logical oif is added to an 672 entry and the iif is owned by another component. In PIM-SM, this may 673 happen when any of the following occur: 674 o A PIM (S,G) Join/Prune message is received on the interface, or 675 o The Register-Suppression-Timer for (S,G) expires, or 676 o The Entry-Timer for an (S,G) negative-cache state route table entry 677 expires. 679 When it is first known that there are members of a group G in the PIM-SM 680 domain, a (*,G) Join alert is sent to the "iif owner" of (*,G), 681 according to the dispatcher. In PIM-SM, this may happen when any of the 682 following occur: 683 o A PIM (*,G) Join/Prune message is received on the interface, or 684 o A PIM (*,*,RP) Join/Prune message is received on the interface, or 685 o (*,G) negative cache state expires, or 686 o IGMP notifies PIM that directly-connected group members now exist 687 on the interface. 689 4.4.2. Processing Alerts 691 When a PIM-SM component receives an (S,G) Creation alert, it does a 692 longest match search ((S,G), then (*,G), then (*,*,RP)) in its multicast 693 routing table. All outgoing interfaces of that entry are then added to 694 the forwarding cache entry. Unless the PIM-SM component owns the iif, 695 the oiflist is also modified to support sending PIM Registers with the 696 Border-bit set to the corresponding RP. 698 When a PIM-SM component receives an (S,G) Prune alert, and the 699 forwarding cache entry's oiflist is empty, then for each PIM (S,G) state 700 entry covered, it sends an (S,G) Join/Prune message with S in the prune 701 list to the upstream neighbor according to normal PIM-SM behavior. 703 When a PIM-SM component receives a (*,G) Prune alert, it sends a (*,G) 704 Join/Prune message with G in the prune list to the upstream neighbor 705 towards the RP for G, according to normal PIM-SM behavior. 707 When a PIM-SM component receives an (S,G) Join alert, it sends an (S,G) 708 Join/Prune message to the next-hop neighbor towards S, and resets the 709 (S,G) Entry-timer, according to normal PIM-SM behavior. 711 When a PIM-SM component receives a (*,G) Join alert, then it sends a 712 (*,G) Join/Prune message to the next-hop neighbor towards the RP for G, 713 and resets the (*,G) Entry-timer, according to normal PIM-SM behavior. 715 When a PIM-SM component receives a (*,*) Join alert, then it sends 716 (*,*,RP) Join/Prune messages towards each RP. 718 When a PIM-SM component receives a (*,*) Prune alert, then it sends a 719 (*,*,RP) Prune towards each RP. 721 7. CBTv2 723 In this section we describe how the rules in section 2 apply to CBTv2. 724 We assume that the reader is familiar with normal CBTv2 behavior as 725 specified in [5]. We note that, like MOSPF, CBTv2 allows joining and 726 pruning entire groups, but not individual sources within groups. 728 Interoperability between a single CBTv2 stub domain and a DVMRP backbone 729 is outlined in [8]. Briefly, CBTv2 MBR components are statically 730 configured such that, whenever an external route exists between two or 731 more MBRs, one is designated as the primary, and the others act as non- 732 forwarding (to prevent duplicate packets) backups. Thus, a CBTv2 733 domain must not serve as transit between two domains if another route 734 between them exists. 736 We now describe how a CBTv2 implementation may extend this to 737 interoperate with all other multicast routing protocols. A CBTv2 738 component acts as a wildcard receiver for internally-reached sources if 739 and only if any other component is a wildcard receiver for externally- 740 reached sources. It does this by sending JOIN-REQUESTs for all non- 741 local group ranges to all known cores, as described in [8]. 743 Unless some form of Domain-Wide-Reports (DWRs) [10] are added to CBTv2 744 in the future, all CBTv2 components act as wildcard receivers for 745 externally-reached sources. If DWRs are available for the domain, then 746 a CBTv2 component acts as a wildcard receiver for externally-reached 747 sources only if internally-reached domains exist which do not support 748 some form of DWRs. 750 7.1. Generating Alerts 752 A (*,*) Join alert is sent to the iif owner of the (*,*) entry (e.g., 753 the Interop dispatcher) when the first component becomes a wildcard 754 receiver for external sources. This may occur when a PIM-SM component 755 starts up and decides to act in this role. 757 A (*,*) Prune alert is sent to the iif owner of the (*,*) entry (e.g., 758 the Interop dispatcher) when all components are no longer wildcard 759 receivers for external sources. This may occur when a PIM-SM component 760 which was acting in this role shuts down. 762 When the last oif is removed from the core tree for G, a (*,G) Prune 763 alert is sent to the "iif owner" for (*,G) according to the dispatcher. 764 Since CBTv2 always sends all data to the core, the only time this can 765 occur after the entry is created is when the MBR is the core. In this 766 case, the last oif is removed from the entry when: 767 o A QUIT-REQUEST is received on the logical interface, and there are 768 no directly-connected members present on the interface, or 769 o IGMP notifies CBT that there are no longer directly-connected 770 members present on the interface, and the interface is not a CBT 771 child interface for group G. 773 When the first CBT outgoing interface is added to an existing core tree, 774 a (*,G) Join alert is sent to the "iif owner" of (*,G) according to the 775 dispatcher. Since CBTv2 always sends all data to the core, the only 776 time these can occur, other than when the entry is created, is when the 777 MBR is the core. In this case, the first logical oif is added to an 778 entry when: 779 o A JOIN-REQUEST for G is received on the interface, or 780 o IGMP notifies CBT that directly-connected group members now exist 781 on the interface. 783 7.2. Processing Alerts 785 When a CBTv2 component receives an (S,G) Creation alert, and the router 786 is functioning as the designated BR, any CBT interfaces which are on the 787 tree for G are added to the forwarding cache entry's oif list (according 788 to normal CBTv2 behavior). 790 When a CBTv2 component receives an (S,G) Prune alert, the alert is 791 ignored, since CBTv2 cannot prune specific sources. Thus, it will 792 continue to receive packets from S since it must receive packets from 793 other sources in group G. 795 When a CBTv2 component receives a (*,G) Prune alert, and the router is 796 not the primary core for G, and the only CBT on-tree interface is the 797 interface towards the core, it sends a QUIT-REQUEST to the next-hop 798 neighbor towards the core, according to normal CBTv2 behavior. 800 When a CBTv2 component receives either an (S,G) Join alert or a (*,G) 801 Join alert, and the router is not the primary core for G, and the router 802 is not already on the core-tree for G, it sends a CBT (*,G) JOIN-REQUEST 803 to the next-hop neighbor towards the core, according to normal CBTv2 804 behavior. 806 4.5. IGMP-only links 808 In this section we describe how the rules in section 2 apply to a link 809 which is not within any routing domain, and hence no routing protocol 810 messages are exchanged and the interface is not owned by any multicast 811 routing protocol component. We assume that the reader is familiar with 812 normal IGMP behavior as specified in [7]. We note that IGMPv2 allows 813 joining and pruning entire groups, but not individual sources within 814 groups. 816 An IGMP-only "component" may only own a single interface; hence an 817 IGMP-only domain only consists of a single link. Since an IGMP-only 818 component can only act as a wildcard receiver for internally-reached 819 sources if all internally-reached sources are directly-connected, then 820 either the IGMP-only domain (link) must be a stub domain, or else there 821 must be no other components which are wildcard receivers for 822 externally-reached sources. 824 4.5.1. Generating Alerts 826 When it is known that there are no longer any directly-connected members 827 of a group G on the IGMP-only interface, a (*,G) Prune alert is sent to 828 the "iif owner" for (*,G) according to the dispatcher. In IGMP, this 829 may happen when: 830 o The group membership times out. 832 When it is first known that there are directly-connected members of a 833 group G on the interface, a (*,G) Join alert is sent to the "iif owner" 834 of (*,G), according to the dispatcher. In IGMP, this may happen when 835 any of the following occur: 836 o A Membership Report is received for G. 838 4.5.2. Processing Alerts 840 When an IGMP-only component receives an (S,G) Creation alert, and there 841 are directly-connected members of G present on its interface, it adds 842 the interface to the entry's oif list. 844 When an IGMP-only component receives an (S,G) Prune alert, the alert is 845 ignored, since IGMP can only prune entire groups at a time. 847 When an IGMP-only component receives a (*,G) Prune alert, the router 848 leaves the group G, sending an IGMP Leave message if it was the last 849 reporter, according to normal IGMPv2 behavior. 851 When an IGMP-only component receives a (*,*) Prune alert, it leaves 852 promiscuous multicast mode. 854 When an IGMP-only component receives either an (S,G) Join alert or a 855 (*,G) Join alert, and the component was not previously a member of G on 856 the IGMP-only interface (and the component is not a wildcard receiver 857 for internally reached sources), it joins the group on the interface, 858 causing it to send an unsolicited Membership Report according to normal 859 IGMP behavior. 861 When an IGMP-only component receives a (*,*) Join alert, it enters 862 promiscuous multicast mode. 864 5. Security Considerations 866 All operations described herein are internal to multicast border 867 routers. The rules described herein do not change the security issues 868 underlying individual multicast routing protcols. Allowing different 869 protocols to interact, however, means that security weaknesses of any 870 particular protocol may also apply to the other protocols as a result. 872 6. References 874 [1] Ajit S. Thyagarajan and Stephen E. Deering. Hierarchical 875 distance-vector multicast routing for the MBone. In "Proceedings 876 of the ACM SIGCOMM", pages 60--66, October 1995. 878 [2] T. Pusateri. Distance vector multicast routing protocol. Internet 879 Draft, March 1998. Available from ftp://ds.internic.net/internet- 880 drafts/draft-ietf-idmr-dvmrp-v3-06.ps. 882 [3] J. Moy. Multicast extensions to OSPF. RFC 1584, July 1993. 884 [4] Estrin, Farinacci, Helmy, Thaler, Deering, Handley, Jacobson, Liu, 885 Sharma, and Wei. Protocol independent multicast-sparse mode (PIM- 886 SM): Protocol specification. RFC 2362, June 1998. 888 [5] A. Ballardie. Core based trees (CBT version 2) multicast routing: 889 Protocol specification. RFC 2189, September 1997. 891 [6] Estrin, Farinacci, Helmy, Jacobson, and Wei. Protocol independent 892 multicast (PIM), dense mode protocol specification. Internet 893 Draft, May 1997. Available from ftp://ds.internic.net/internet- 894 drafts/draft-ietf-idmr-pim-dm-spec-05.ps. 896 [7] W. Fenner. Internet Group Management Protocol, Version 2. RFC 897 2236, November 1997. 899 [8] A. J. Ballardie. Core Based Tree (CBT) Multicast Border Router 900 Specification. Internet Draft, November 1997. Available from 901 ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-br-spec- 903 01.txt. 904 [9] D. Thaler, D. Estrin, and D. Meyer. Border Gateway Multicast 905 Protocol (BGMP): Protocol Specification. Internet Draft, October 906 1997. Available from ftp://ds.internic.net/internet-drafts/draft- 907 ietf-idmr-gum-01.txt. 909 [10] W. Fenner. Domain Wide Multicast Group Membership Reports, 910 Internet Draft, November 1997. Available from 911 ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-membership- 912 reports-00.txt. 914 7. Address of Author 916 Dave Thaler 917 Microsoft 918 One Microsoft Way 919 Redmond, WA 98052 920 Phone: (425) 703-8835 921 Email: thalerd@eecs.umich.edu 922 8. Full Copyright Statement 923 Copyright (C) The Internet Society (1998). All Rights Reserved. 924 This document and translations of it may be copied and furnished to 925 others, and derivative works that comment on or otherwise explain it or 926 assist in its implmentation may be prepared, copied, published and 927 distributed, in whole or in part, without restriction of any kind, 928 provided that the above copyright notice and this paragraph are included 929 on all such copies and derivative works. However, this document itself 930 may not be modified in any way, such as by removing the copyright notice 931 or references to the Internet Society or other Internet organizations, 932 except as needed for the purpose of developing Internet standards in 933 which case the procedures for copyrights defined in the Internet 934 Standards process must be followed, or as required to translate it into 935 languages other than English. 936 The limited permissions granted above are perpetual and will not be 937 revoked by the Internet Society or its successors or assigns. 938 This document and the information contained herein is provided on an "AS 939 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 940 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 941 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 942 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 943 FITNESS FOR A PARTICULAR PURPOSE."