idnits 2.17.00 (12 Aug 2021) /tmp/idnits16141/draft-ietf-idmr-cbt-br-spec-02.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. Expected boilerplate is as follows today (2022-05-14) 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) 2022 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 6 months document validity. ** 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. == 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 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. ** There are 20 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 32 instances of lines with control characters in the document. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '4' is defined on line 452, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-05) exists of draft-ietf-idmr-membership-reports-00 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1771 (ref. '6') (Obsoleted by RFC 4271) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Multicast Routing (IDMR) A. Ballardie 3 INTERNET-DRAFT Consultant 4 B. Cain 5 Bay Networks 6 Z. Zhang 7 Bay Networks 9 March 1998. 11 Core Based Tree (CBT) Multicast Border Router Specification 12 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working doc- 17 uments of the Internet Engineering Task Force (IETF), its Areas, and 18 its Working Groups. Note that other groups may also distribute work- 19 ing documents as Internet Drafts). 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress." 27 Please check the I-D abstract listing contained in each Internet 28 Draft directory to learn the current status of this or any other 29 Internet Draft. 31 Abstract 33 This draft specifies the behaviour of a CBT multicast border router 34 (BR). This specification assumes the use of CBTv3 - the latest CBT 35 protocol version [3]. 37 CBTv3 has capabilities which make CBT equally well suited for use in 38 stub- or transit- domains; this draft describes mechanisms which 39 enable a CBT distribution tree to span only those routers and links 40 leading to interested receivers or receiver-domains. 42 1. Changes from Previous Revision 44 This draft differs significantly from previous revisions, and incor- 45 porates mostly new procedures and mechanisms. 47 2. Interoperability Model 49 The interoperability model follows that described in [2]. Particular 50 attention is drawn to sections 1 and 2 of that document. For brevity, 51 some of the more fundamental aspects of interoperability are listed 52 below: 54 +o logically, a BR has at least two "components", each component being 55 associated with a particular multicast routing protocol. Each com- 56 ponent may have more than one associated interface which is running 57 the particular multicast protocol associated with the component. At 58 least one of these components is a CBT component. Figure 1 provides 59 an example (logical) representation of a border router. 61 +o besides a CBT component owning its own (private) forwarding cache 62 (hereafter referred to as the PFC), all components share a common, 63 protocol independent, multicast forwarding cache (hereafter 64 referred to as the SFC) which supports source specific (i.e (S, 65 G)), and source independent (i.e. (*, G)) entries. The latest CBT 66 specification recommends that all CBT router implementations 67 include support for an SFC, allowing any CBT router to assume the 68 role of Border Router if necessary. 70 A CBT component's PFC must support (*, G), (S, G), and (*, Core) 71 entries; (*, Core) entries are not relevant to the SFC. 73 To ensure that all components have a consistent view of the SFC a 74 BR's components must be able to communicate with each other; how is 75 implementation dependent (guidelines provided in [2]). 77 +o the parent for all PFC entries shall point towards the local domain 78 core for G. There is no notion of "incoming" interface wrt any PFC 79 state. 81 The semantics of the SFC cannot be stated until such time as the 82 inter-domain multicast routing architecture is fully understood. 84 +o It is suggested the SFC is only used on active CBT Border Routers; 85 the PFC is used on all other CBT routers. 87 +o mixed multicast protocol LANs are not permitted. 89 ------------X----------------------X--X-------- 90 | | | | | | X = component 91 | | comp A | | comp B | | interface 92 | ------------- ----------- | 93 | | comp = component 94 | ----------------------------- | 95 | | Shared Multicast | | 96 | | Forwarding Cache (S,G) | | 97 | ----------------------------- | 98 | | 99 | ------------ ---------- | 100 | | comp C | | comp D | | 101 | | | | | | 102 ----------X----X----------------------X-------- 104 Figure 1: Example Representation of a Border Router 106 3. Multicast ASs vs. Multicast Domains/"Regions" 108 It is important to distinguish between a multicast Autonomous System 109 (AS) - an AS whose unicast and multicast routing boundaries are 110 aligned, and a multicast domain (or "region"), whose unicast and mul- 111 ticast routing boundaries are not aligned. 113 In the former case BGP-4 [6] is often deployed as a separator between 114 interior and exterior routing. For multicast ASs BGP-4+ [1] is 115 assumed, which allows a domain to express multicast policy, i.e. 116 "come from" paths, as well as unicast policy, i.e. "go to" paths, for 117 particular network addresses (or prefixes). The advantage of BGP-4+ 118 is highlighted in the case where a multicast AS is multi-homed 119 (multi-homed stub AS, or transit AS) - BGP-4+ has the ability to 120 select a single ingress border router (BR) per external multicast 121 source (network or prefix), thereby avoiding the potential for the 122 very damaging effect of multicast packet duplicates being injected 123 into a domain (or AS). 125 Note that, if BGP-4+ is assumed, it must be deployed on all of an 126 AS's BRs. 128 In circumstances where BGP-4+ cannot be assumed, a single ingress BR 129 for a particular multicast source (network or prefix) must be 130 selected by alternate means. One alternative would be to manually 131 configure a CBT domain's multicast BRs, but this does not scale for 132 large numbers of BRs. We therefore recommend that each of a CBT 133 domain's BRs implement an "arbitration process" on each BR, responsi- 134 ble for dynamically selecting a single ingress BR per multicast 135 source (network or prefix). This scheme arbitrates using (multicast) 136 routing metrics as its BR selection criterium; its goal is to select 137 a single ingress BR per external source, not replace BGP-4+ with its 138 fine-grained policy expression capabilities. 140 The resulting effect of the arbitration process is to allow a CBT 141 component to potentially create/modify/delete a BR shared forwarding 142 cache entry as necessary to prevent the injection of multicast dupli- 143 cates inside the CBT domain. 145 A description of one possible implementation of an "arbitration pro- 146 cess" is provided in the Appendix. 148 Hereafter, the terms "multicast domain" and "multicast AS" will be 149 simply referred to as multicast "domain". 151 4. The Architectural Model 153 This section explains the overall architecture of a CBT multicast 154 domain that attaches to other multicast domain(s). 156 +o a CBT Border Router (BR) which is used to forward traffic towards 157 an external receiver domain can be thought of as a group member wrt 158 the CBT domain. 160 +o Domain Wide Reports (DWRs) (see section 5) are used in a CBT domain 161 so that BRs learn of internal group membership, and downstream 162 domain group membership. 164 DWRs need not necessarily be implemented in singly-homed stub CBT 165 domains, at the potential cost of traffic flowing unnecessarily 166 between the ingress BR and core router(s). 168 +o DWRs are only sent by core routers. They are sent whenever a core 169 router gets its first child, or when a core loses its last child. 171 DWRs are distributed via the "all-cbt-border-routers" (ABR) multi- 172 cast group, administratively scoped as 239.X.X.X. All CBT BRs must 173 join this group at initialization time. 175 +o CBT core routers have authoritative group membership information 176 for the CBT domain for those groups for which they are the core. 177 Hence, DWRs sent by core routers are authoritative - BRs use DWRs 178 to decide whether or not to inject traffic into the CBT domain. 180 +o CBT core routers also have authoritative group membership informa- 181 tion wrt BRs' attached domain(s) - this is reflected in a core 182 router's forwarding cache; BRs not interested in receiving traffic 183 on behalf of a neighbouring domain send a QUIT_NOTIFICATION (prune) 184 of the corresponding granularity towards the core router. Hence, a 185 core router knows whether or not there are interested receivers 186 downstream of it (internal or external). 188 +o CBT BRs may issue (*, Core), (*, G), or (S, G) quits (prunes). In 189 CBT, quits always instantiate uni-directional prune state; by send- 190 ing a quit the BR is electing not to receive traffic via the CBT 191 domain, but may inject externally sourced traffic into the CBT 192 domain. A quit always follows the state that it is pruning - 193 towards the core; if a quit reaches a core router, it is never for- 194 warded beyond the core router. 196 +o A BR may instantiate a priori state between itself and a core 197 router, or that state may be explicitly invoked (see section 4.1 198 below). For the case where no a priori state exists between a BR 199 and core router, if the BR receives externally sourced data and is 200 the ingress BR for that data, if the BR has a cached DWR Join 201 (received recently from a core router) the ingress BR instantiates 202 (*, Core) (uni-directional) state between itself and the core, 203 UNLESS the BR has appropriate pre-existing (*, G) or (S, G) state. 204 This way, externally sourced data traffic can always be injected 205 natively into the CBT domain. 207 +o A join explicitly invoked by another BR component (as opposed to a 208 DWR) - signalling that a neighbouring domain is interested in a 209 group - instantiates bi-directional state between the BR and core 210 (otherwise data would not be "pulled down" to the BR). This state 211 may be (*, Core), (*, G), or (S, G). 213 In each of the following two sections we look at the procedures followed 214 by two different circumstances: firstly, when a BR's neighbouring domain 215 is able to explicitly signal its group membership, and secondly, when a 216 BR's neighbouring domain cannot (or cannot to the same degree compared 217 to the first case) explicitly signal group membership. 219 4.1. A Neighbouring Domain can Explitly Signal Group Membership 221 +o CBT BR's send (*,G), (S,G), or (*, Core) JOIN_REQUESTs towards the 222 relevant core router when a neighbouring domain has group members, 223 i.e. a join-alert is received by the CBT BR component from another 224 BR component. The resulting state is bi-directional. 226 +o CBT BR's send (*,G), (S,G), or (*, Core) QUIT_NOTIFICATIONs towards 227 the relevant core router when the neighbouring domain no longer has 228 group members, i.e. a prune-alert is received by the CBT component 229 from another BR component. 231 +o When a core router gets its first child or loses its last child it 232 issues a DWR of the corresponding granularity. This is received by 233 all BR's; as a result, the BRs know whether or not to inject exter- 234 nally sourced traffic. 236 4.2. A Neighbouring Domain cannot Explitly Signal Group Membership 238 +o CBT BR's instantiate (*,Core) state at initialization time to all 239 core routers in a CBT domain that are associated with inter-domain 240 scoped groups. The resulting state is bi-directional. 242 +o Though a neighbouring BR component might not be explicitly informed 243 of group membership inside its domain, it may still send prune- 244 alerts (e.g. DVMRP) to the CBT component. Upon receiving a prune- 245 alert from another component, the CBT component sends a (*, G), (S, 246 G), or (*, Core) QUIT_NOTIFICATION (prune) towards the relevant 247 core. Since a quit (prune) is always uni-directional, the BR - if 248 ingress for some external sources - is still able to inject exter- 249 nally sourced data into the CBT domain. 251 +o Though a neighbouring BR component might not be explicitly informed 252 of group membership inside its domain, it may still send join- 253 alerts (e.g. DVMRP) to the CBT component. Upon receiving a join- 254 alert from another component, the CBT component sends a (*, G) (or 255 (S, G)) JOIN_REQUEST toward the relevant core, UNLESS there exists 256 appropriate non-pruned less specific state, i.e. (*, Core). The 257 resulting state is bi-directional. 259 4.3. Architectural Summary 261 In the context of multicast domain interconnection, a CBT domain 262 exhibits the following attributes: 264 +o if at least one of a BR's neighbouring domains cannot explicitly 265 signal group membership, the BR must instantiate a priori (*, Core) 266 state (bi-directional) between itself and each domain core. 268 +o if all of a BR's neighbouring domains can explicitly signal group 269 membership, the BR need not instantiate any state between itself 270 and domain cores until group membership is signalled. 272 +o if a BR receives a DWR Join from a domain core, the DWR is cached. 273 If, during the DWR cache lifetime data arrives for a member group 274 and the BR is the ingress BR for that data, the BR instantiates 275 uni-directional (*, Core) state between itself and the core so the 276 data can be injected into the CBT domain natively, UNLESS there 277 exists appropriate (*, G) or (S, G) state. A BR may explicitly 278 tear down (using a quit message) uni-directional (*, Core) state 279 after a suitable data flow idle period, or the state may remain. 281 +o if a BR receives a DWR Leave from a domain core, the DWR is cached. 282 A DWR Leave results in BRs with any (*, G) or (S,G) PFC (bi-direc- 283 tional) states pruning the relevant state by sending a quit mes- 284 sage. The BR also removes the appropriate interface from its SFC 285 entry. An ingress BR which is receiving traffic for the now pruned 286 group (injecting it using (*,Core) state) either tears down the 287 one-way (*, Core) state, or marks its parent PFC as pruned; this is 288 the ONLY instance of a parent interface being pruned. 290 5. Domain Wide Reports (DWRs) 292 Domain Wide Reports (DWRs) are used in a CBT domain to enable BRs to 293 learn - in a dynamic and timely fashion - of internal group member- 294 ship, and downstream domain group membership. Group member- 295 ship/absence is indicated by means of DWR Join and Leave messages, 296 respectively. 298 It is assumed DWRs are refreshed periodically, and cached by receiv- 299 ing BRs for a lifetime of X seconds, after which time they expire in 300 the BR's DWR cache. 302 If DWRs are in use in a CBT domain, they are only ever issued by core 303 routers. DWRs issued by core routers are authoritative. 305 DWRs can be source-group specific (S, G), or source independent (*, 306 G). 308 A DWR represents aggregated state where possible. For example, if a 309 core has only one child for each of its (*, G) and (S, G) states, it 310 generates a (*, G) DWR to cover (*, G) and (S, G). Finer grained 311 aggregates may be represented if DWRs support mask information. 313 The DWR processing rules are as follows: 315 +o whenever a CBT component receives an (S,G) DWR Join message it is 316 only processed by the ingress BR for S. If there exists no (S, G) 317 SFC entry at the ingress BR, an (S, G) SFC entry is created by the 318 CBT component, and an (S, G) Creation-Alert is generated. Then (or 319 if an (S, G) entry already exists) the interface via which the DWR 320 originating core router is reachable is added (or un-pruned) in the 321 entry's child list. If this interface is the only interface in the 322 child list of the entry, the CBT component generates an (S, G) 323 Join-Alert. 325 If the CBT component's PFC does not have equal- or less specific 326 state that includes the same interface, a (*, G) JOIN_REQUEST 327 (including the "uni-directional" join option) is sent over the 328 interface towards the domain core for G. [An (S,G) join is not sent 329 because (S,G) state does not exist between the ingress BR and core 330 router]. 332 +o whenever a CBT component receives an (S,G) DWR Leave message it is 333 processed only by the ingress BR for S. If the ingress BR for S has 334 an equal- or less specific SFC entry that includes a pruned 335 outgoing interface corresponding to that leading to the relevant 336 domain core router, no further action need be taken. 338 Otherwise, an (S, G) SFC entry is created (causing an (S, G) Cre- 339 ation-Alert), and the interface leading to the relevant domain core 340 router is included in the outgoing interface list and marked as 341 pruned. 343 If no further non-pruned children remain in the (S, G) SFC child 344 list, the CBT component sends an (S, G) Prune-Alert to the entry's 345 owner. 347 +o whenever a CBT component receives a (*, G) DWR Join, a (*, G) SFC 348 entry is created (unless it, or a less specific entry, already 349 exists) and the interface leading to the domain core for G is added 350 as a child in the entry. The CBT component's PFC is checked to 351 ensure the same interface belongs to an equal- or less specific 352 entry. If no such entry exists, the CBT component sends a (*, G) 353 JOIN_REQUEST (uni-directional) towards the domain core for G, 354 instantiating (*, G) PFC state. 356 +o When a DWR (*, G) Leave message is received by a CBT component if 357 no (*, G) SFC entry exists one is created, and the interface lead- 358 ing to the relevant domain core router is added as a child and 359 marked as pruned. 361 If no more non-pruned (*, G) SFC children remain, the CBT component 362 sends an (*, G) Prune-Alert to the entry's owner. 364 6. More BR Component Interactions 366 +o upon receipt of an (S,G) Join-Alert (see [2]) by a CBT component, 367 if the interface towards the domain core for G is owned by the CBT 368 component, it adds the interface as the (S, G) SFC entry's incoming 369 interface. 371 If the CBT component's PFC has no equal- or less specific state 372 that includes the same interface, an (S, G) JOIN_REQUEST is sent 373 over the interface towards G. 375 +o the receipt of a (*,G) Join-Alert (see [2]) by a CBT component 376 results in the CBT component including the interface leading to the 377 relevant domain core as the parent in the (*, G) SFC entry. The 378 CBT component's PFC is checked to ensure the same interface belongs 379 to an equal- or less specific entry. If no such entry exists the 380 CBT component sends a (*, G) JOIN_REQUEST towards the domain core 381 for G, instantiating (*, G) PFC state. 383 +o upon receipt of an (S,G) Prune-Alert (see [2]) by a CBT component, 384 if the next-hop interface towards the domain core for G is owned by 385 the CBT component, the CBT component removes the interface from the 386 (S, G) SFC entry, and an (S, G) QUIT_NOTIFICATION is sent towards 387 the domain core for G, instantiating (S, G) PFC prune state. 389 +o the receipt of an (*,G) Prune-Alert (see [2]) by a CBT component 390 causes the CBT component to remove the interface leading to the 391 relevant domain core from the (*, G) SFC entry, then send a (*,G) 392 QUIT_NOTIFICATION over that interface. 394 +o whenever a more specific PFC entry is created and there exists a 395 less specific entry/entries, the child list of the new entry is the 396 union of the less specific entry/entries child list(s). The child 397 list of the new entry must also include the interface over which 398 the triggering control message was received. 400 7. Tunnel Issues 402 IP multicast deployment in the Internet is a slow process. A unicast 403 AS may not have the resources, or it may not be practical, to migrate 404 a complete AS into one that is completely multicast capable (i.e. 405 multicast AS), so multicast "islands" (i.e. multicast domains - see 406 section 3) may be created within the unicast AS infrastructure as 407 part of a longer term migration strategy. 409 A shortage of resources may mean that core routers must be shared 410 between any multicast domains, implying that, from the perspective of 411 the Bootstrap Mechanism [5], multiple multicast domains may be seen 412 as one single domain. Configured (IP-in-IP) tunnels provide multi- 413 cast connectivity between the multicast domain "islands". 415 Under these circumstances the Bootstrap Mechanism operating within 416 each multicast domain must be modified such that, if the core router 417 for some set of groups belongs to another domain, the local domain 418 tunnel end-point advertises ("proxies") itself as the core router for 419 that set of groups. The tunnel end-point (router) simply acts as a 420 "relay" agent for CBT joins, forwarding them to the remote tunnel 421 end-point for onward forwarding. 423 Acknowledgements 425 Special thanks goes to Paul Francis, NTT Japan, for the original 426 brainstorming sessions that led to the development of CBT. 428 Others that have contributed to the progress of CBT include Ken Carl- 429 berg, Eric Crawley, Jon Crowcroft, Bill Fenner, Mark Handley, Ahmed 430 Helmy, Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, 431 Scott Reeve, Benny Rodrig, Clay Shields, Martin Tatham, Dave Thaler, 432 Sue Thompson, Paul White, and other participants of the IETF IDMR 433 working group. 435 Thanks also to 3Com Corporation and British Telecom Plc for assisting 436 with funding this work. 438 References 440 [1] Multiprotocol Extensions to BGP-4; T. Bates et al. 441 ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiproto- 442 col-02.txt 444 [2] Interoperability Rules for Multicast Routing Protocols; D. Thaler; 445 ftp://ds.internic.net/internet-drafts/draft-thaler-multicast- 446 interop-01.txt; Working Draft, March 1997. 448 [3] Core Based Trees (CBTv3) Multicast Routing: Protocol Specifica- 449 tion; A. Ballardie, B. Cain, Z. Zhang; ftp://ds.internic.net/inter- 450 net-drafts/draft-ietf-idmr-cbt-spec-**.txt Working Draft, March 1998. 452 [4] Domain Wide Multicast Group Membership Reports; W. Fenner; draft- 453 ietf-idmr-membership-reports-00.txt; Working Draft, November 1997. 455 [5] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Rout- 456 ing; D. Estrin et al.; Technical Report, available from: 457 http//netweb.usc.edu/pim 459 [6] A Border Gateway Protocol 4 (BGP-4); Y. Rekhter and T. Li; RFC 460 1771, March 1995. ftp://ds.internic.net/rfc/rfc1771.txt 462 APPENDIX 464 The BR "Arbitration Process" 466 The specific details of the arbitration process (AP) are implementa- 467 tion dependent, but we provide an outline of its possible operation 468 for reference. 470 The AP is applicable to any multi-homed (stub or transit) CBT domain 471 whose BRs have not deployed BGP-4+ [1]. The goal of the arbitration 472 process is to allow CBT BRs attached to a CBT domain to select a sin- 473 gle ingress BR per external multicast source in a timely fashion. A 474 diagram showing the arbitration process in a CBT BR component is 475 shown in figure 2. 477 ------------X----------------------X--X-------- 478 | | | | | | X = component 479 | | comp A | | comp B | | interface 480 | ------------- ----------- | 481 | ----------------------------- | 482 | | Shared Multicast | | 483 | | Forwarding Cache | | 484 | ----------------------------- | 485 | comp C _______ | 486 | _______| AP | | 487 | | CBT | | ___________ | 488 | | ----> | | comp D | | 489 | | <---- | | | | 490 ----------X----X----------------------X-------- 492 Figure 5: Logical Representation of the Arbitration Process 494 The arbitration process is only triggered by externally sourced pack- 495 ets, i.e. those passed to a CBT component interface by the BR process 496 that handles SFC forwarding); the AP is not triggered by data packets 497 arriving from inside the CBT domain. 499 All of a CBT domain's BRs are joined to the "all-CBT-border-routers" 500 (ABR) multicast group (see section 4), the group address for which is 501 domain-scoped, 239.X.X.X. This group is used both by the arbitration 502 process, and by CBT transit domains for propogating multicast routing 503 information (in cases where multicast topology discovery is neces- 504 sary). 506 Whenever a CBT component receives an externally sourced data packet 507 for the first time (since some time 't-zero') the CBT component arbi- 508 tration process is invoked. 510 The arbiter queries the BR component owning the interface via which 511 the externally sourced data packet arrived, i.e. the component owning 512 the interface nearest to S, to find out that component's current 513 (multicast) metric for S. The arbiter multicasts an (S, G, metric, 514 protocol component) tuple - where protocol component is DVMRP, PIM- 515 DM, etc. - to the ABR group, and the message is processed by each 516 receiving CBT component arbitration process. The receiving 517 arbiter(s) cache the received tuple. 519 The unsolicited arrival of a triple triggers the receiving arbiter to 520 reply with its own corresponding tuple; those CBT components not 521 receiving the (S,G) multicast data simply reply with a NULL tuple, 522 where "metric" and "protocol component" are both NULL. Failure to 523 receive a reply from each other BR belonging to the ABR group results 524 in the tuple being resent (unicast, unless no reply is forthcoming 525 from any BR) after 3 (??) seconds. 527 The receipt of a non-NULL tuple with a better metric for S than this 528 BR's tuple (for the same protocol), or an equal metric but sent by a 529 lower-addressed BR, causes the arbiter to instigate the removal of 530 the CBT component interface from the relevant SFC entry's child list. 532 The subsequent arrival of data packets from S are injected into the 533 CBT domain via a single BR, with the same packets arriving at any of 534 the other BRs being filtered. The arrival of subsequent data packets 535 does not result in any exchanges between BR arbiters for the lifetime 536 of the relevant cache entry's timeout period, which must be synchro- 537 nised across all of the domain's BRs (recommended lifetime, X secs). 539 Whilst this method does not guarantee against multicast duplicates 540 being injected into the CBT domain, it should ensure that any dupli- 541 cation is short-lived. 543 Author Information: 545 Tony Ballardie, 546 Research Consultant. 548 e-mail: ABallardie@acm.org 550 Brad Cain, 551 Bay Networks Inc., 552 3, Federal Street, 553 Billerica, MA 01821, USA. 554 e-mail: bcain@baynetworks.com 555 voice: +1 978 916 1316 557 Zhaohui "Jeffrey" Zhang, 558 Bay Networks Inc., 559 600 Technology Park Drive, 560 Billerica, MA 01821, USA. 561 Phone: +1 (978) 439 0280 562 Fax: +1 978 670 8760 563 e-mail: zzhang@baynetworks.com