idnits 2.17.1 draft-ietf-idmr-cbt-spec-07.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 (2024-04-26) 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 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. ** Expected the document's filename to be given on the first page, but didn't find any == 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 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 45 instances of lines with control characters in the document. ** The abstract seems to contain references ([1,5,, 6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 271 has weird spacing: '...ency of paren...' == Line 611 has weird spacing: '...ding of its o...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 1997) is 9904 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' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Experimental RFC: RFC 1949 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 5 March 1997 7 Core Based Trees (CBT) Multicast Routing 9 -- Protocol Specification -- 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working doc- 14 uments of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute work- 16 ing documents as Internet Drafts). 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any other 26 Internet Draft. 28 Abstract 30 This document describes the Core Based Tree (CBT) network layer mul- 31 ticast routing protocol. CBT builds a shared multicast distribution 32 tree per group, and is suited to inter- and intra-domain multicast 33 routing. 35 CBT is protocol independent in that it makes use of unicast routing 36 to establish paths between senders and receivers. The CBT architec- 37 ture is described in [1]. 39 This document is progressing through the IDMR working group of the 40 IETF. CBT related documents include [1, 5, 6]. For all IDMR-related 41 documents, see http://www.cs.ucl.ac.uk/ietf/idmr. 43 TABLE OF CONTENTS 45 1. Changes Since Previous Revision............................ 3 47 2. Introduction & Terminology................................. 4 49 3. CBT Functional Overview.................................... 5 51 4. CBT Protocol Specificiation Details........................ 8 53 4.1 CBT HELLO Protocol..................................... 8 55 4.1.1 Sending HELLOs................................... 9 57 4.1.2 Receiving HELLOs................................. 9 59 4.2 JOIN_REQUEST Processing................................ 10 61 4.2.1 Sending JOIN_REQUESTs............................ 10 63 4.2.2 Receiving JOIN_REQUESTs.......................... 10 65 4.3 JOIN_ACK Processing.................................... 11 67 4.3.1 Sending JOIN_ACKs................................ 11 69 4.3.2 Receiving JOIN_ACKs.............................. 12 71 4.4 QUIT_NOTIFICATION Processing........................... 12 73 4.4.1 Sending QUIT_NOTIFICATIONs....................... 12 75 4.4.2 Receiving QUIT_NOTIFICATIONs..................... 13 77 4.5 CBT ECHO_REQUEST Processing............................ 14 79 4.5.1 Sending ECHO_REQUESTs............................ 14 81 4.5.2 Receiving ECHO_REQUESTs.......................... 14 83 4.6 ECHO_REPLY Processing.................................. 15 85 4.6.1 Sending ECHO_REPLYs.............................. 15 87 4.6.2 Receiving ECHO_REPLYs............................ 15 89 4.7 FLUSH_TREE Processing.................................. 16 91 4.7.1 Sending FLUSH_TREE Messages...................... 16 93 4.7.2 Receiving FLUSH_TREE Messages.................... 16 95 5. Timers and Default Values.................................. 16 97 6. CBT Packet Formats and Message Types....................... 17 99 6.1 CBT Common Control Packet Header....................... 18 101 6.2 HELLO Packet Format.................................... 19 103 6.3 JOIN_REQUEST Packet Format............................. 19 105 6.4 JOIN_ACK Packet Format................................. 20 107 6.5 QUIT_NOTIFICATION Packet Format........................ 21 109 6.6 ECHO_REQUEST Packet Format............................. 21 111 6.7 ECHO_REPLY Packet Format............................... 22 113 6.8 FLUSH_TREE Packet Format............................... 23 115 7. Core Router Discovery...................................... 23 117 7.1 Bootstrap Message Format.............................. 25 119 7.2 Candidate Core Advertisement Message Format........... 25 121 8. Interoperability Issues.................................... 25 123 Acknowledgements.............................................. 26 125 References.................................................... 26 127 Author Information............................................ 27 129 1. Changes since Previous Revision (05) 131 This revision of the CBT protocol specification differs significantly 132 from the previously released revision (05). Consequently, this revi- 133 sion represents version 2 of the CBT protocol. CBT version 2 is not, 134 and was not, intended to be backwards compatible with version 1; we 135 do not expect this to cause extensive compatibility problems because 136 we do not believe CBT is at all widely deployed at this stage. How- 137 ever, any future versions of CBT can be expected to be backwards com- 138 patible with this version. 140 The most significant changes to version 2 compared to version 1 141 include: 143 +o new LAN mechanisms, including the incorporation of an HELLO pro- 144 tocol. 146 +o new simplified packet formats, with the definition of a common 147 CBT control packet header. 149 +o a generic intra-domain core discovery ("bootstrap") mechanism, 150 to be specified separately, and published soon. 152 This specification revision is a complete re-write of the previous 153 revision. 155 2. Introduction & Terminology 157 In CBT, a "core router" (or just "core") is a router which configured 158 to act as a "meeting point" between a sender and group receivers. The 159 term "rendezvous point (RP)" is used equivalently in some contexts 160 [2]. Each core router is configured to know it is a core router. 162 A router that is part of a CBT distribution tree is known as an "on- 163 tree" router. An on-tree router maintains active state for the group. 165 We refer to a broadcast interface as any interface that supports mul- 166 ticast transmission. 168 An "upstream" interface (or router) is one which is on the path 169 towards the group's core router with respect to this router. A "down- 170 stream" interface (or router) is one which is on the path away from 171 the group's core router with respect to this router. 173 Other terminology is introduced in its context throughout the text. 175 3. CBT Functional Overview 177 The CBT protocol is designed to build and maintain a shared multicast 178 distribution tree that spans only those networks and links leading to 179 interested receivers. 181 To achieve this, a host first expresses its interest in joining a 182 group by multicasting an IGMP host membership report [3] across its 183 attached link. On receiving this report, a local CBT aware router 184 invokes the tree joining process (unless it has already) by generat- 185 ing a JOIN_REQUEST message, which is sent to the next hop on the path 186 towards the group's core router (how the local router discovers which 187 core to join is discussed in section 7). This join message must be 188 explicitly acknowledged (JOIN_ACK) either by the core router itself, 189 or by another router that is on the unicast path between the sending 190 router and the core, which itself has already successfully joined the 191 tree. 193 The join message sets up transient join state in the routers it tra- 194 verses, and this state consists of . "Incoming interface" and "outgoing interface" may be 196 "previous hop" and "next hop", respectively, if the corresponding 197 links do not support multicast transmission. "Previous hop" is taken 198 from the incoming control packet's IP source address, and "next hop" 199 is gleaned from the routing table - the next hop to the specified 200 core address. This transient state eventually times out unless it is 201 "confirmed" with a join acknowledgement (JOIN_ACK) from upstream. The 202 JOIN_ACK traverses the reverse path of the corresponding join mes- 203 sage, which is possible due to the presence of the transient join 204 state. Once the acknowledgement reaches the router that originated 205 the join message, the new receiver can receive traffic sent to the 206 group. 208 Loops cannot be created in a CBT tree because a) there is only one 209 active core per group, and b) tree building/maintenance scenarios 210 which may lead to the creation of tree loops are avoided. For exam- 211 ple, if a router's upstream neighbour becomes unreachable, the router 212 immediately "flushes" all of its downstream branches, allowing them 213 to individually rejoin if necessary. Transient unicast loops do not 214 pose a threat because a new join message that loops back on itself 215 will never get acknowledged, and thus eventually times out. 217 The state created in routers by the sending or receiving of a 218 JOIN_ACK is bi-directional - data can flow either way along a tree 219 "branch", and the state is group specific - it consists of the group 220 address and a list of local interfaces over which join messages for 221 the group have previously been acknowledged. There is no concept of 222 "incoming" or "outgoing" interfaces, though it is necessary to be 223 able to distinguish the upstream interface from any downstream inter- 224 faces. In CBT, these interfaces are known as the "parent" and "child" 225 interfaces, respectively. We recommend the parent be distinguished as 226 such by a single bit in each multicast forwarding cache entry. 228 With regards to the information contained in the multicast forwarding 229 cache, on link types not supporting native multicast transmission an 230 on-tree router must store the address of a parent and any children. 231 On links supporting multicast however, parent and any child informa- 232 tion is represented with local interface addresses (or similar iden- 233 tifying information, such as an interface "index") over which the 234 parent or child is reachable. 236 When a multicast data packet arrives at a router, the router uses the 237 group address as an index into the multicast forwarding cache. A copy 238 of the incoming multicast data packet is forwarded over each inter- 239 face (or to each address) listed in the entry except the incoming 240 interface. 242 Each router that comprises a CBT multicast tree, except the core 243 router, is responsible for maintaining its upstream link, provided it 244 has interested downstream receivers, i.e. the child interface list is 245 non-NULL. A child interface is one over which a member host is 246 directly attached, or one over which a downstream on-tree router is 247 attached. This "tree maintenance" is achieved by each downstream 248 router periodically sending a CBT "keepalive" message (ECHO_REQUEST) 249 to its upstream neighbour, i.e. its parent router on the tree. One 250 keepalive message is sent to represent entries with the same parent, 251 thereby improving scalability on links which are shared by many 252 groups. On multicast capable links, a keepalive is multicast to the 253 "all-cbt-routers" group (IANA assigned as 224.0.0.15); this has a 254 suppressing effect on any other router for which the link is its par- 255 ent link. If a parent link does not support multicast transmission, 256 keepalives are unicast. 258 The receipt of a keepalive message over a valid child interface imme- 259 diately prompts a response (ECHO_REPLY), which is either unicast or 260 multicast, as appropriate. 262 The ECHO_REQUEST does not contain any group information; the 263 ECHO_REPLY does, but only periodically. To maintain consistent infor- 264 mation between parent and child, 265 the parent periodically reports, in an ECHO_REPLY, all groups for 266 which it has state, over each of its child interfaces for those 267 groups. This group-carrying echo reply is not prompted explicitly by 268 the receipt of an echo request message. A child is notified of the 269 time to expect the next echo reply message containing group informa- 270 tion in an echo reply prompted by a child's echo request. The fre- 271 quency of parent group reporting is at the granularity of minutes. 273 It cannot be assumed all of the routers on a multi-access link have a 274 uniform view of unicast routing; this is particularly the case when a 275 multi-access link spans two or more unicast routing domains. This 276 could lead to multiple upstream tree branches being formed (an error 277 condition) unless steps are taken to ensure all routers on the link 278 agree which is the upstream router for a particular group. CBT 279 routers attached to a multi-access link participate in an explicit 280 election mechanism that elects a single router, the designated router 281 (DR), as the link's upstream router for all groups. Since the DR 282 might not be the link's best next-hop for a particular core router, 283 this may result in join messages being re-directed back across a 284 multi-access link. If this happens, the re-directed join message is 285 unicast across the link by the DR to the best next-hop, thereby pre- 286 venting a looping scenario. This re-direction only ever applies to 287 join messages. Whilst this is suboptimal for join messages, which 288 are generated infrequently, multicast data never traverses a link 289 more than once (either natively, or encapsulated). 291 In all but the exception case described above, all CBT control mes- 292 sages are multicast over multicast supporting links to the "all-cbt- 293 routers" group, with IP TTL 1. The IP source address of CBT control 294 messages is the outgoing interface of the sending router. The IP des- 295 tination address of CBT control messages is either the "all-cbt- 296 routers" group address, or the IP address of a router reachable over 297 one of the sending router's interfaces, depending on whether the 298 sender's outgoing link supports multicast transmission. All the nec- 299 essary addressing information is obtained as part of tree set up. 301 If CBT is implemented over a tunnelled topology, when sending a CBT 302 control packet over a tunnel interface, the sending router uses as 303 the packet's IP source address the local tunnel end point address, 304 and the remote tunnel end point address as the packet's IP destina- 305 tion address. 307 4. Protocol Specification Details 309 Details of the CBT protocol are presented in the context of a single 310 router implementation. 312 4.1. CBT HELLO Protocol 314 The HELLO protocol is used to elect a designated router (DR) on 315 broadcast-type links. It is also used to elect a designated border 316 router (BR) when interconnecting a CBT domain with other domains (see 317 [5]). 319 A router represents its status as a link's DR by setting the DR-flag 320 on that interface; a DR flag is associated with each of a router's 321 broadcast interfaces. This flag can only assume one of two values: 322 TRUE or FALSE. By default, this flag is FALSE. 324 HELLO messages are multicast periodically to the all-cbt-routers 325 group, 224.0.0.15, using IP TTL 1. The advertisement period is 326 [HELLO_TIMER] seconds. [HELLO_TIMER] comprises a configured 327 [HELLO_INTERVAL], to which is added [RND_RSP] seconds - a random 328 response interval. This random response additive is required to 329 avoid the potential problem of synchronisation between HELLO adver- 330 tisements (or other control messages) from different routers. The 331 HELLO protocol's convergence time is set at [HELLO_CONV] seconds - 332 the time after which no further HELLOs are expected in any one round 333 of the protocol. 335 Each HELLO advertising router includes the upper bound of its 336 [RND_RSP] timer in its HELLO advertisements. This is necessary so 337 that all routers attached to the link can agree on a common HELLO 338 convergence time [HELLO_CONV]; in any one round of the HELLO proto- 339 col, a router assumes the minimum of the upper bound of its config- 340 ured [RND_RSP] and that of any received advertisement's. The minimum 341 upper bound is then used as this router's [RND_RSP] upper bound in 342 the next round of the protocol. [HELLO_CONV] is set to this minimum 343 upper bound + 2 seconds (the 2 seconds being a response "safety mar- 344 gin") for the next round of the protocol. 346 A network manager can preference a router's DR eligibility by option- 347 ally configuring a HELLO preference. Valid configuration values range 348 from 1 to 254 (decimal), 1 representing the "most eligible" value. In 349 the absence of explicit configuration, a router assumes the default 350 HELLO preference value of 255. The elected DR uses HELLO preference 351 zero (0) in HELLO advertisements, irrespective of any configured 352 preference. The DR continues to use preference zero for as long as 353 it is running. 355 The DR election winner is that which advertises the lowest HELLO 356 preference, or the lowest-addressed in the event of a tie. 358 The situation where two or more routers attached to the same broad- 359 cast link are advertising HELLO preference 0 should never arise. How- 360 ever, should this situation arise, all but the lowest addressed zero- 361 advertising router relinquishes its claim as DR immediately by unset- 362 ting the DR flag on the corresponding interface. The relinquishing 363 router(s) subsequently advertise their previously used preference 364 value in HELLO advertisements. 366 4.1.1. Sending HELLOs 368 When a router starts up, it multicasts two HELLO messages over each 369 of its broadcast interfaces in successsion. The DR flag is initially 370 unset (FALSE) on each broadcast interface. 372 A router sends a HELLO message whenever its [HELLO_TIMER] expires. 374 Whenever a router sends a HELLO message, it resets its [HELLO_TIMER]. 376 4.1.2. Receiving HELLOs 378 On receipt of any HELLO message, a router adjusts its [RND_RSP] upper 379 bound to the minimum of this router's configured [RND_RSP] upper 380 bound and that received in the received HELLO. The router also 381 adjusts its [HELLO_CONV] as described above. 383 A router need not respond to a HELLO message if the received HELLO is 384 "better" than its own. Thus, in steady state, the HELLO protocol 385 incurs very little traffic overhead. 387 If the received HELLO message is "better" (lower preferenced, or 388 equally preferenced but lower addressed) than it would send itself, 389 it immediately unsets its DR flag on the arriving interface if the DR 390 flag is set on that interface. It also resets its [HELLO_TIMER]. 392 If the received HELLO message is not "better" than this router would 393 send itself, it sets its [RND_RSP] random response timer; on expiry, 394 the router responds with its own HELLO message . If no "better" HELLO 395 message is received within the current [HELLO_CONV], the router sets 396 the DR flag on the corresponding interface. 398 4.2. JOIN_REQUEST Processing 400 A JOIN_REQUEST is the CBT control message used to register a member 401 host's interest in joining the distribution tree for the group. 403 4.2.1. Sending JOIN_REQUESTs 405 A JOIN_REQUEST can only ever be originated by a leaf router, i.e. a 406 router with directly attached member hosts. This join message is sent 407 hop-by-hop towards the core router for the group (see section 7). 408 The originating router caches state 409 for each join it originates. This state is known as "transient join 410 state". The absence of a "downstream interface" (NULL) indicates 411 that this router is the join message originator, and is therefore 412 responsible for any retransmissions of this message if a response is 413 not received within [JOIN_RTX_INTERVAL]. It is an error if no 414 response is received after [JOIN_TIMEOUT] seconds. If this error 415 condition occurs, the joining process may be re-invoked by the 416 receipt of the next IGMP host membership report from a locally 417 attached member host. 419 Note that if the interface over which a JOIN_REQUEST is to be sent 420 supports multicast, the JOIN_REQUEST is multicast to the all-cbt- 421 routers group, using IP TTL 1. If the link does not support multi- 422 cast, the JOIN_REQUEST is unicast to the next hop on the unicast path 423 to the group's core. 425 4.2.2. Receiving JOIN_REQUESTs 427 On broadcast links, JOIN_REQUESTs which are multicast may only be 428 forwarded by the link's DR. Other routers attached to the link may 429 process the join (see below). JOIN_REQUESTs which are multicast over 430 a point-to-point link are only processed by the router on the link 431 which does not have a local interface corresponding to the join's 432 network layer (IP) source address. Unicast JOIN_REQUESTs may only be 433 processed by the router which has a local interface corresponding to 434 the join's network layer (IP) destination address. 436 With regard to forwarding a received JOIN_REQUEST, if the receiving 437 router is not on-tree for the group, and is not the group's core 438 router, the join is forwarded to the next hop on the path towards the 439 core. The join is multicast, or unicast, according to whether the 440 outgoing interface supports multicast. The router caches the follow- 441 ing information with respect to the forwarded join: . 444 If this transient join state is not "confirmed" with a join acknowl- 445 edgement (JOIN_ACK) message from upstream, the state is timed out 446 after 1.5 times [JOIN_RTX_INTERVAL]. 448 If the receiving router is the group's core router, the join is "ter- 449 minated" and acknowledged by means of a JOIN_ACK. Similarly, if the 450 router is on-tree and the JOIN_REQUEST arrives over an interface that 451 is not the upstream interface for the group, the join is acknowl- 452 edged. 454 If [RND_RSP] pertaining to a JOIN_REQUEST is active (i.e. running), 455 if a JOIN_REQUEST is received for the same group over that group's 456 parent interface, cancel [RND_RSP] for the impending JOIN_REQUEST. 458 If this router has a cache-deletion-timer [CACHE_DEL_TIMER] running 459 on the arrival interface for the group specified in a multicast join, 460 the timer is cancelled. 462 If a multicast JOIN_REQUEST is received and the QUIT_TIME bit (see 463 section 4.4.1) is set on the arrival interface for the specified 464 group, unset the QUIT_TIME bit. 466 4.3. JOIN_ACK Processing 468 A JOIN_ACK is the mechanism by which an interface is added to a 469 router's multicast forwarding cache; thus, the interface becomes part 470 of the group distribution tree. 472 4.3.1. Sending JOIN_ACKs 474 The JOIN_ACK is sent over the same interface as the corresponding 475 JOIN_REQUEST was received. The sending of the acknowledgement causes 476 the router to add the interface to its child interface list in its 477 forwarding cache for the group, if it is not already. If the router 478 does not yet have active state for this group, this router must be 479 the core router for the group; the core creates a forwarding cache 480 entry and includes the interface in its child interface list, and 481 sends the JOIN_ACK downstream. 483 A JOIN_ACK is multicast or unicast, according to whether the outgoing 484 interface supports multicast transmission or not. 486 4.3.2. Receiving JOIN_ACKs 488 The group and arrival interface must be matched to a from the router's cached transient state. If no 490 match is found, the JOIN_ACK is discarded. If a match is found, a 491 CBT forwarding cache entry for the group is created, with "upstream 492 interface" marked as the group's parent interface. 494 If "downstream interface" in the cached transient state is NULL, the 495 JOIN_ACK has reached the originator of the corresponding 496 JOIN_REQUEST; the JOIN_ACK is not forwarded downstream. If "down- 497 stream interface" is non-NULL, a JOIN_ACK for the group is sent over 498 the "downstream interface" (multicast or unicast, accordingly). This 499 interface is installed in the child interface list of the group's 500 forwarding cache entry. 502 Once transient state has been confirmed by transferring it to the 503 forwarding cache, the transient state is deleted. 505 4.4. QUIT_NOTIFICATION Processing 507 A CBT tree is "pruned" in the direction downstream-to-upstream when- 508 ever a CBT router's child interface list for a group becomes NULL. 510 4.4.1. Sending QUIT_NOTIFICATIONs 512 A QUIT_NOTIFICATION is sent to a router's parent router on the tree 513 whenever the router's child interface list becomes NULL. 515 A QUIT_NOTIFICATION is not acknowledged; once sent, all information 516 pertaining to the group it represents is deleted from the forwarding 517 cache after a short interval. 519 To ensure consistency between a child and parent router given the 520 potential for loss of a QUIT_NOTIFICATION, there is a QUIT_TIME bit 521 associated with the parent of each group entry; whenever a 522 QUIT_NOTIFICATION is sent for a group, the QUIT_TIME bit for that 523 group entry is set for a maximum of [QUIT_TIME] seconds before the 524 entry is deleted and the QUIT_TIME bit unset. By default, this bit is 525 unset. 527 When the QUIT_TIME bit is set, if the router detects multicast traf- 528 fic for the group arriving over a to-be-deleted parent interface (one 529 over which a quit has recently been sent), the router sends another 530 QUIT_NOTIFICATION over that interface. This is multicast, or unicast, 531 as appropriate for the outgoing link. It continues to do so at 532 [QUIT_RATE] second intervals so long as data continues to arrive, and 533 provided [QUIT_TIME] has not yet expired. 535 If, after sending a QUIT_NOTIFICATION a multicast JOIN_REQUEST for 536 the specified group arrives over the interface the quit was sent, the 537 QUIT_TIME bit is immediately unset if it is set (any traffic arriving 538 over the interface will be for/from another child router attached to 539 the same link). 541 4.4.2. Receiving QUIT_NOTIFICATIONs 543 The group reported in the QUIT_NOTIFICATION must be matched with a 544 forwarding cache entry. If no match is found, the QUIT_NOTIFICATION 545 is ignored and discarded. If a match is found, if the arrival inter- 546 face is a valid child interface in the group entry, how the router 547 proceeds depends on whether the QUIT_NOTIFICATION was multicast or 548 unicast. 550 If the QUIT_NOTIFICATION was unicast, the corresponding child inter- 551 face is deleted from the group's forwarding cache entry, and no fur- 552 ther processing is required. 554 If the QUIT_NOTIFICATION was multicast, and the arrival interface is 555 a valid child interface for the specified group, the router sets a 556 cache-deletion-timer [CACHE_DEL_TIMER]. 558 Because this router might be acting as a parent router for multiple 559 downstream routers attached to the arrival link, [CACHE_DEL_TIMER] 560 interval gives those routers that did not send the 561 QUIT_NOTIFICATION, but received it over their parent interface, the 562 opportunity to ensure that the parent router does not remove the link 563 from its child interface list. 565 Therefore, on receipt of a multicast QUIT_NOTIFICATION over a parent 566 interface, a receiving router starts a random response interval timer 567 which is set to [RND_RSP] seconds. 569 If a multicast JOIN_REQUEST is received over the same interface (par- 570 ent) for the same group before this router's [RND_RSP] timer expires, 571 it suppresses the multicasting of its own similar JOIN_REQUEST. 573 If a multicast JOIN_REQUEST is not received via the router's parent 574 link before [RND_RSP] expires, a JOIN_REQUEST is multicast over the 575 link for the previously quit group, with IP TTL 1. 577 4.5. ECHO_REQUEST Processing 579 The ECHO_REQUEST message allows a child to monitor reachability to 580 its parent router for a group (or range of groups if the parent 581 router is the parent for multiple groups). Group information is not 582 carried in ECHO_REQUEST messages. 584 4.5.1. Sending ECHO_REQUESTs 586 Whenever a router creates a forwarding cache entry due to the receipt 587 of a JOIN_ACK, the router begins the periodic sending of ECHO_REQUEST 588 messages over its parent interface. The ECHO_REQUEST is multicast to 589 the "all-cbt-routers" group over multicast-capable interfaces, and 590 unicast to the parent router otherwise. 592 ECHO_REQUEST messages are sent at [ECHO_INTERVAL] second intervals. 593 Whenever an ECHO_REQUEST is sent, [ECHO_INTERVAL] is reset. 595 If, for any echo-request sent to a parent, the expected response 596 (ECHO_REPLY) is not forthcoming within [ECHO_RTX_INTERVAL], the echo 597 request message is retransmitted. If no response is forthcoming 598 within [ECHO_TIMEOUT] seconds, the router sends a FLUSH_TREE message 599 over each of its child interfaces for the group, then removes all 600 forwarding cache state for the group. 602 4.5.2. Receiving ECHO_REQUESTs 604 If a ECHO_REQUEST is received over any valid child interface, the 605 receiving router responds with an ECHO_REPLY message over the same 606 interface. This message is multicast to the "all-cbt-routers" group 607 over multicast-capable interfaces, and unicast otherwise. 609 If a multicast ECHO_REQUEST message arrives via any valid parent 610 interface, the router resets its [ECHO_INTERVAL] timer for that 611 upstream interface, thereby suppressing the sending of its own 612 ECHO_REQUEST over that upstream interface. 614 4.6. ECHO_REPLY Processing 616 ECHO_REPLY messages allow a child to monitor the reachability of its 617 parent, and ensure the group state information is consistent between 618 them. 620 4.6.1. Sending ECHO_REPLY messages 622 An ECHO_REPLY message is sent in direct response to receiving an 623 ECHO_REQUEST message, provided the ECHO_REQUEST is received over any 624 one of this router's valid child interfaces. Additionally, an 625 ECHO_REPLY is sent periodically by a parent router over each of its 626 child links, reporting all groups for which the link is its child. 628 ECHO_REPLY messages are unicast or multicast, as appropriate. 630 4.6.2. Receiving ECHO_REPLY messages 632 An ECHO_REPLY message must be received via a valid parent interface. 633 When received, the child router resets its [ECHO_INTERVAL] timer for 634 this upstream interface. The child router also caches the reported 635 "group report interval" (seconds) - the time at which the next group 636 carrying ECHO_REPLY will be sent by the parent router. Like 637 [ECHO_INTERVAL], this is cached per upstream interface. If the group 638 carrying ECHO_REPLY does not arrive shortly after "group report 639 interval" has expired, a QUIT_NOTIFICATION is sent for each group for 640 which the non-reporting router is the parent. 642 If this echo reply carries a list of groups, the child router must 643 match all those of its forwarding cache entries for which the arrival 644 interface is the upstream interface. If the parent router does not 645 consider itself the parent router for group(s) which the child thinks 646 is its parent, the child sends a FLUSH_TREE message downstream for 647 each such group. If this router has directly attached members for any 648 of the flushed groups, the receipt of an IGMP host membership report 649 for any of those groups will prompt this router to rejoin the corre- 650 sponding tree(s). 652 If the upstream router considers itself the parent for more groups 653 than does the receiving router, this router sends a QUIT_NOTIFICATION 654 for each of those groups for which the QUIT_TIME bit is set in the 655 forwarding cache. Otherwise, the router takes no action. 657 4.7. FLUSH_TREE Processing 659 The FLUSH_TREE (flush) message is the mechanism by which a router 660 invokes the tearing down of all its downstream branches for a partic- 661 ular group. The flush message is multicast to the "all-cbt-routers" 662 group when sent over multicast-capable interfaces, and unicast other- 663 wise. 665 4.7.1. Sending FLUSH_TREE messages 667 A FLUSH_TREE message is sent over each downstream (child) interface 668 when a router has lost reachability with its parent router for the 669 group (detected via ECHO_REQUEST and ECHO_REPLY messages). All group 670 state is removed from an interface over which a flush message is 671 sent. 673 4.7.2. Receiving FLUSH_TREE messages 675 A FLUSH_TREE message must be received over the parent interface for 676 the specified group, otherwise the message is discarded. 678 The flush message must be forwarded over each child interface for the 679 specified group. 681 Once the flush message has been forwarded, all state for the group is 682 removed from the router's forwarding cache. 684 5. Timers and Default Values 686 This section provides a summary of the timers described above, 687 together with their default values. 689 +o [HELLO_INTERVAL]: a base value making up the bulk of the inter- 690 val between sending a HELLO message. Default: 60 seconds. 692 +o [RND_RSP]: router's random response interval. Default: 2 sec- 693 onds. 695 +o [HELLO_TIMER]: (variable) interval between sending HELLO mes- 696 sages. [HELLO_TIMER] = [HELLO_INTERVAL + RND_RSP] 698 +o [HELLO_CONV]: convergence time of one round of the HELLO proto- 699 col. [HELLO_CONV] = [min(RND_RSP) + 2 seconds]. 701 +o [JOIN_RTX_INTERVAL]: retransmission time for JOIN_REQUESTs. 702 Default: 5 seconds. 704 +o [JOIN_TIMEOUT]: time to raise exception due to tree join fail- 705 ure. Default: 3.5 times [JOIN_RTX_INTERVAL]. 707 +o [CACHE_DEL_TIMER]: time to remove child interface from forward- 708 ing cache. Default: 2 seconds. 710 +o [QUIT_TIME]: time to remove parent interface from forwarding 711 cache entry. Unset QUIT_TIME bit. Default: 60 seconds. 713 +o [QUIT_RATE]: period for sending QUIT_NOTIFICATION if traffic 714 persists. Default: 15 seconds. 716 +o [ECHO_INTERVAL]: interval between sending ECHO_REQUEST to parent 717 routers. Default: 60 seconds. 719 +o [ECHO_RTX_INTERVAL]: retransmission time for ECHO_REQUESTs. 720 Default 2 seconds. 722 +o [ECHO_TIMEOUT]: time to consider parent unreachable. Default: 723 3.5 times [ECHO_RTX_INTERVAL]. 725 6. CBT Packet Formats and Message Types 727 CBT control packets are encapsulated in IP. CBT has been assigned IP 728 protocol number 7 by IANA [4]. 730 6.1. CBT Common Control Packet Header 732 All CBT control messages have a common fixed length header. 734 0 1 2 3 735 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | vers | type | addr len | checksum | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Figure 1. CBT Common Control Packet Header 742 This CBT specification is version 2. 744 CBT packet types are: 746 +o type 0: HELLO 748 +o type 1: JOIN_REQUEST 750 +o type 2: JOIN_ACK 752 +o type 3: QUIT_NOTIFICATION 754 +o type 4: ECHO_REQUEST 756 +o type 5: ECHO_REPLY 758 +o type 6: FLUSH_TREE 760 +o type 7: Bootstrap Message 762 +o type 8: Candidate Core Advertisement 764 +o Addr Length: address length in bytes of unicast or multicast 765 addresses carried in the control packet. 767 +o Checksum: the 16-bit one's complement of the one's complement 768 sum of the entire CBT control packet. 770 6.2. HELLO Packet Format 772 0 1 2 3 773 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | CBT Control Packet Header | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | rnd response | Preference | reserved | option type | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | option len | option value | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Figure 2. HELLO Packet Format 784 HELLO Packet Field Definitions: 786 +o rnd response: random response interval in seconds. 788 +o preference: sender's HELLO preference. 790 +o option type: the type of option present in the "option value" 791 field. One option type is currently defined: option type 0 792 (zero) = BR_HELLO; option value 0 (zero); option length 0 793 (zero). This option type is used with HELLO messages sent by a 794 border router (BR) as part of designated BR election (see [5]). 796 +o option len: length of the "option value" field in bytes. 798 +o option value: variable length field carrying the option value. 800 6.3. JOIN_REQUEST Packet Format 802 JOIN_REQUEST Field Definitions 804 +o group address: multicast group address of the group being 805 joined. For a "wildcard" join (see [5]), this field contains 806 the value of INADDR_ANY. 808 +o originating router: router that originated this JOIN_REQUEST. 810 0 1 2 3 811 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | CBT Control Packet Header | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | group address | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | originating router | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | target router | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | option type | option len | option value | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 Figure 3. JOIN_REQUEST Packet Format 825 +o target router: target (core) router for the group. 827 +o option type: allows the specification of a variety of 828 JOIN_REQUEST options. One option is currently defined: option 829 type 0 (zero) = BR_JOIN; option length 0 (zero); option value 0 830 (zero). This option is used by a CBT domain border router to 831 join an internal core for all groups that map to that core. The 832 state instantiated by a JOIN_REQUEST with this option set is 833 represents (*, core). For further details, see [5]. 835 6.4. JOIN_ACK Packet Format 837 0 1 2 3 838 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | CBT Control Packet Header | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | group address | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | target router | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | option type | option len | option value | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Figure 4. JOIN_ACK Packet Format 851 JOIN_ACK Field Definitions 853 +o group address: multicast group address of the group being 854 joined. 856 +o target router: router (DR) that originated the corresponding 857 JOIN_REQUEST. 859 6.5. QUIT_NOTIFICATION Packet Format 861 0 1 2 3 862 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | CBT Control Packet Header | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | group address | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | originating child router | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Figure 5. QUIT_NOTIFICATION Packet Format 873 QUIT_NOTIFICATION Field Definitions 875 +o group address: multicast group address of the group being 876 joined. 878 +o originating child router: address of the router that originates 879 the QUIT_NOTIFICATION. 881 6.6. ECHO_REQUEST Packet Format 883 ECHO_REQUEST Field Definitions 885 +o originating child router: address of the router that originates 886 the ECHO_REQUEST. 888 0 1 2 3 889 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | CBT Control Packet Header | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | originating child router | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Figure 6. ECHO_REQUEST Packet Format 897 6.7. ECHO_REPLY Packet Format 899 0 1 2 3 900 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | CBT Control Packet Header | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | originating parent router | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | group report interval | num groups | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | group address #1 | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | group address #2 | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | ...... | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | group address #n | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 Figure 7. ECHO_REPLY Packet Format 919 ECHO_REPLY Field Definitions 921 +o oringinating parent router: address of the router originating 922 this ECHO_REPLY. 924 +o group report interval: number of seconds until the sending 925 router will send its next ECHO_REPLY containing a list of group 926 addresses. 928 +o num groups: the number of groups being reported by this 929 ECHO_REPLY. 931 +o group address: a list of multicast group addresses for which 932 this router considers itself a parent router w.r.t. the link 933 over which this message is sent. 935 6.8. FLUSH_TREE Packet Format 937 0 1 2 3 938 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | CBT Control Packet Header | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | group address | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 Figure 8. FLUSH_TREE Packet Format 947 FLUSH_TREE Field Definitions 949 +o group address: multicast group address of the group being 950 "flushed". 952 7. Core Router Discovery 954 For intra-domain core discovery, CBT has decided to adopt the "boot- 955 strap" mechanism currently specified with the PIM sparse mode proto- 956 col [2]. This bootstrap mechanism is scalable, robust, and does not 957 rely on underlying multicast routing support to deliver core router 958 information; this information is distributed via traditional unicast 959 hop-by-hop forwarding. 961 It is expected that the bootstrap mechanism will be specified inde- 962 pendently as a "generic" RP/Core discovery mechanism in its own sepa- 963 rate document. It is unlikely at this stage that the bootstrap mecha- 964 nism will be appended to a well-known network layer protocol, such as 965 IGMP [3], though this would facilitate its ubiquitous (intra-domain) 966 deployment. Therefore, each multicast routing protocol requiring the 967 bootstrap mechanism must implement it as part of the multicast rout- 968 ing protocol itself. 970 A summary of the operation of the bootstrap mechanism follows 971 (details are provided in [7]). It is assumed that all routers within 972 the domain implement the "bootstrap" protocol, or at least forward 973 bootstrap protocol messages. 975 A subset of the domain's routers are configured to be CBT candidate 976 core routers. Each candidate core router periodically (default every 977 60 secs) advertises itself to the domain's Bootstrap Router (BSR), 978 using "Core Advertisement" messages. The BSR is itself elected 979 dynamically from all (or participating) routers in the domain. The 980 domain's elected BSR collects "Core Advertisement" messages from can- 981 didate core routers and periodically advertises a candidate core set 982 (CC-set) to each other router in the domain, using traditional hop- 983 by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to 984 advertise the CC-set. Together, "Core Advertisements" and "Bootstrap 985 Messages" comprise the "bootstrap" protocol. 987 When a router receives an IGMP host membership report from one of its 988 directly attached hosts, the local router uses a hash function on the 989 reported group address, the result of which is used as an index into 990 the CC-set. This is how local routers discover which core to use for 991 a particular group. 993 Note the hash function is specifically tailored such that a small 994 number of consecutive groups always hash to the same core. Further- 995 more, bootstrap messages can carry a "group mask", potentially limit- 996 ing a CC-set to a particular range of groups. This can help reduce 997 traffic concentration at the core. 999 If a BSR detects a particular core as being unreachable (it has not 1000 announced its availability within some period), it deletes the rele- 1001 vant core from the CC-set sent in its next bootstrap message. This is 1002 how a local router discovers a group's core is unreachable; the 1003 router must re-hash for each affected group and join the new core 1004 after removing the old state. The removal of the "old" state follows 1005 the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message 1006 downstream. 1008 7.1. Bootstrap Message Format 1010 0 1 2 3 1011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | CBT common control packet header | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | For full Bootstrap Message specification, see [7] | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 Figure 9. Bootstrap Message Format 1020 7.2. Candidate Core Advertisement Message Format 1022 0 1 2 3 1023 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | CBT common control packet header | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | For full Candidate Core Adv. Message specification, see [7] | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 Figure 10. Candidate Core Advertisement Message Format 1032 8. Interoperability Issues 1034 Interoperability between CBT and DVMRP is specified in [5]. 1036 Interoperability with other multicast protocols will be fully speci- 1037 fied as the need arises. 1039 Acknowledgements 1041 Special thanks goes to Paul Francis, NTT Japan, for the original 1042 brainstorming sessions that brought about this work. 1044 Others that have contributed to the progress of CBT include Ken Carl- 1045 berg, Eric Crawley, Nitin Jain, Steven Ostrowsksi, Radia Perlman, 1046 Scott Reeve, Clay Shields, Sue Thompson, Paul White. 1048 The participants of the IETF IDMR working group have provided useful 1049 feedback since the inception of CBT. 1051 References 1053 [1] Core Based Trees (CBT) Multicast Routing Architecture; 1054 A. Ballardie; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr- 1055 cbt-arch-**.txt. Working draft, 1997. 1057 [2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D. 1058 Estrin et al; ftp://netweb.usc.edu/pim Working drafts, 1996. 1060 [3] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner; 1061 ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-v2-**.txt. 1062 Working draft, 1996. 1064 [4] Assigned Numbers; J. Reynolds and J. Postel; RFC 1700, October 1065 1994. 1067 [5] CBT Border Router Specification for Interconnecting a CBT Stub 1068 Region to a DVMRP Backbone; A. Ballardie; 1069 ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt- 1070 dvmrp-**.txt. Working draft, March 1997. 1072 [6] Scalable Multicast Key Distribution; A. Ballardie; RFC 1949, July 1073 1996. 1075 [7] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Rout- 1076 ing; D. Estrin et al.; Technical Report; ftp://catarina.usc.edu/pim 1078 Author Information: 1080 Tony Ballardie, 1081 Research Consultant, 1083 e-mail: ABallardie@acm.org