idnits 2.17.1 draft-ietf-idmr-cbt-spec-v3-01.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-03-28) 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 84 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 50 instances of lines with control characters in the document. ** The abstract seems to contain references (3,, 8], 5,, [1,2,, [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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 280: '... MUST be able to distinguish between...' RFC 2119 keyword, line 354: '... A CBT router MUST implement a multi...' RFC 2119 keyword, line 359: '... implementations SHOULD also implement...' RFC 2119 keyword, line 376: '...erefore, the PFC SHOULD support the in...' RFC 2119 keyword, line 573: '...eighbour, the DR MUST keep transient s...' (4 more instances...) -- The abstract seems to indicate that this document obsoletes RFC2189, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (August 1998) is 9357 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) -- Looks like a reference, but probably isn't: 'HOLDTIME' on line 1100 -- Looks like a reference, but probably isn't: 'HOLD-TIME' on line 1091 ** Downref: Normative reference to an Historic RFC: RFC 2201 (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' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 August 1998 11 Core Based Trees (CBT version 3) Multicast Routing 13 -- Protocol Specification -- 15 Status of this Memo 17 This document is an Internet Draft. Internet Drafts are working doc- 18 uments of the Internet Engineering Task Force (IETF), its Areas, and 19 its Working Groups. Note that other groups may also distribute work- 20 ing documents as Internet Drafts). 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress." 28 Please check the I-D abstract listing contained in each Internet 29 Draft directory to learn the current status of this or any other 30 Internet Draft. 32 Abstract 34 This document describes the Core Based Tree (CBT version 3) network 35 layer multicast routing protocol. CBT builds a shared multicast dis- 36 tribution tree per group, and is suited to inter- and intra-domain 37 multicast routing. 39 CBT may use a separate multicast routing table, or it may use that of 40 underlying unicast routing, to establish paths between senders and 41 receivers. The CBT architecture is described in [1]. 43 This specification supercedes and obsoletes RFC 2189. Changes from 44 RFC 2189 include support for source specific joining and pruning to 45 provide better CBT transit domain capability, new packet formats, and 46 new robustness features. Section 1 documents the primary changes to 47 RFC 2189. 49 This document is progressing through the IDMR working group of the 50 IETF. CBT related documents include [1, 2, 3, 5, 8]. For all IDMR- 51 related documents, see http://www.cs.ucl.ac.uk/ietf/idmr. 53 TABLE OF CONTENTS 55 1. Changes from RFC 2189 .......................................... 4 57 2. Building a CBT Multicast Domain ................................ 5 59 3. Introduction & Terminology ..................................... 5 61 4. CBT Functional Overview ........................................ 6 63 4.1. The First Step: Joining the Tree .......................... 6 65 4.2. Transient State ........................................... 7 67 4.3. Getting on-tree ........................................... 8 69 4.3. Pruning & Prune State ..................................... 8 71 4.4. The Forwarding Cache ...................................... 9 73 4.5. Packet Forwarding ......................................... 11 75 4.7. The "Keepalive" Protocol .................................. 11 77 4.8. Control Message Precedence & Forwarding Criteria .......... 12 79 4.9. Broadcast LANs ............................................ 14 81 4.10. The "all-cbt-routers" Group .............................. 15 83 4.11. Non-Member Sending ....................................... 15 85 5. Protocol Specification Details ................................. 15 87 5.1. CBT HELLO Protocol ........................................ 16 88 5.1.1. Sending HELLOs ..................................... 17 90 5.1.2. Receiving HELLOs ................................... 17 92 5.2. JOIN_REQUEST Processing ................................... 20 94 5.2.1. Sending JOIN_REQUESTs .............................. 20 96 5.2.2. Receiving JOIN_REQUESTs ............................ 20 98 5.2.3. Additional Aspects Related to Receiving Multicast 99 JOIN_REQUESTs ............................................. 21 101 5.3. JOIN_ACK Processing ....................................... 21 103 5.3.1. Sending JOIN_ACKs .................................. 21 105 5.3.2. Receiving JOIN_ACKs ................................ 22 107 5.4. QUIT_NOTIFICATION Processing .............................. 22 109 5.4.1. Sending QUIT_NOTIFICATIONs ......................... 22 111 5.4.2. Receiving QUIT_NOTIFICATIONs ....................... 23 113 5.5. ECHO_REQUEST Processing ................................... 24 115 5.5.1. Sending ECHO_REQUESTs .............................. 24 117 5.5.2. Receiving ECHO_REQUESTs ............................ 24 119 5.6. ECHO_REPLY Processing ..................................... 25 121 5.6.1. Sending ECHO_REPLYs ................................ 25 123 5.6.2. Receiving ECHO_REPLYs .............................. 25 125 5.7. FLUSH_TREE Processing ..................................... 26 127 5.7.1. Sending FLUSH_TREE messages ........................ 26 129 5.7.2. Receiving FLUSH_TREE messages ...................... 26 131 6. Timers and Default Values ...................................... 27 132 7. CBT Packet Formats and Message Types ........................... 28 134 7.1. CBT Common Control Packet Header .......................... 28 136 7.2. Packet Format for CBT Control Packet Types 0 - 6 .......... 29 138 7.2.1. Option Type Definitions ............................ 30 140 7.2.2. Sample Control Packets ............................. 31 142 8. Core Router Discovery .......................................... 33 144 8.1. "Bootstrap" Mechanism Overview ............................ 34 146 8.2. Bootstrap Message Format .................................. 35 148 8.3. Candidate Core Advertisement Message Format ............... 36 150 Acknowledgements .................................................. 36 152 References ........................................................ 37 154 Author Information ................................................ 38 156 1. Changes from RFC 2189 158 +o forwarding cache support for entries of different granularities, 159 i.e. (*, G), (*, Core), or (S, G), and support for S and/or G masks 160 for representing S and/or G aggregates 162 +o included support for joins, quits (prunes), and flushes of differ- 163 ent granularities, i.e. (*, G), (*, Core), or (S, G), where S 164 and/or G can be aggregates 166 +o optional one-way join capability 168 +o improved the LAN HELLO protocol and included a state diagram 170 +o revised packet format, and provided option support for all control 171 packets 173 +o added downstream state timeout to CBT router 175 +o revised the CBT "keepalive" mechanism between adjacent on-tree CBT 176 routers 178 +o overall provided added clarification of protocol events and mecha- 179 nisms 181 Unfortunately, most of these changes are not backwards compatible 182 with RFC 2189, but at the time of writing, these changes remain in 183 advent of any widespread implementation or deployment. 185 2. Building a CBT Multicast Domain 187 When building a CBT multicast domain that attaches to other multicast 188 domains, this document should be used in conjunction with draft-ietf- 189 idmr-cbt-br-spec-**.txt, which describes the CBT Border Router Speci- 190 fication and discusses various issues related to CBT domain intercon- 191 nection. 193 3. Introduction & Terminology 195 In CBT, a "core router" (or just "core") is a router which acts as a 196 "meeting point" between a sender and group receivers. The term "ren- 197 dezvous point (RP)" is used equivalently in some documents [2]. 199 A router that is part of a CBT distribution tree is known as an "on- 200 tree" router. An router which is on-tree for a group is one which has 201 forwarding state for the group. 203 We refer to a broadcast interface as any interface that is multicast 204 capable. 206 An "upstream" interface (or router) is one which is on the path 207 towards the group's core router with respect to this router. A "down- 208 stream" interface (or router) is one which is on the path away from 209 the group's core router with respect to this router. 211 4. CBT Functional Overview 213 The CBT protocol is designed to build and maintain a shared multicast 214 distribution tree that spans only those networks and links leading to 215 interested receivers. 217 4.1. The First Step: Joining the Tree 219 As a first step, a host first expresses its interest in joining a 220 group by multicasting an IGMP host membership report [3] across its 221 attached link. Note that all CBT routers, similar to other multicast 222 protocol routers, are expected to participate in IGMP for the purpose 223 of monitoring directly attached group memberships, and acting as IGMP 224 querier should the need arise. 226 On receiving an IGMP Host Membership Report, a local CBT router 227 invokes the tree joining process (unless it has already) by generat- 228 ing a JOIN_REQUEST message, which is sent to the next hop on the path 229 towards the group's core router (how the local router discovers which 230 core to join is discussed in section 8). This join message must be 231 explicitly acknowledged (JOIN_ACK) either by the core router itself, 232 or by another router that is on the path between the sending router 233 and the core, which itself has already successfully joined the tree. 235 By default, joins/join-acks create bi-directional forwarding state, 236 i.e. data can flow in the direction downstream -> upstream, or 237 upstream -> downstream. In some circumstances a join/join-ack may 238 include an option which instantiates uni-directional forwarding 239 state; an interface over which a uni-directional join-ack is for- 240 warded (not received) is automatically marked as pruned. Data is 241 permitted to be received via a pruned interface, but must not be for- 242 warded over a pruned interface. Prune state can also be instantiated 243 by the QUIT_NOTIFICATION message (see section 4.8). 245 A join-request is made uni-directional by the inclusion of the "uni- 246 directional" join option (see section 7.2.1), which is copied to the 247 corresponding join-ack; join-request options are always copied to the 248 corresponding join-ack. 250 CBT now supports source specific joins/prunes so as to be better 251 equipped when deployed in a transit domain; source specific control 252 messages are only ever generated by CBT Border Routers (BRs). Source 253 specific control messages follow G, not S, i.e. they are routed 254 towards the core (not S) and no further. Thus, (S, G) state only 255 exists on the "core tree" in a CBT domain - those routers and links 256 between a BR and core router. 258 4.2. Transient State 260 The join message sets up transient join state in the router that 261 originates it (a LAN's designated router (DR)) and the routers it 262 traverses (an exception is described in section 4.9), and this state 263 consists of ; 264 "source" is optional, and relevant only to source specific control 265 messages. 267 On broadcast networks "downstream address" is the local IP address of 268 the interface over which this router received the join (or IGMP Host 269 Membership Report), and "upstream address" is the local IP address of 270 the interface over which this router forwarded the join (according to 271 this router's routing table). On non-broadcast networks "downstream 272 address" is the IP address of the join's previous hop, and "upstream 273 address" is the IP address of the next hop (according to this 274 router's routing table). Transient state eventually times out unless 275 the join is explicitly acknowledged. When a join is acknowledged, the 276 transient join state is transferred to the router's multicast for- 277 warding cache, thus becoming "permanent". 279 If "downstream address" implies a broadcast LAN, the transient state 280 MUST be able to distinguish between a member host being reachable 281 over that interface, and a downstream router being reachable over 282 that interface. This is necessary so that, on receipt of a JOIN_ACK, 283 a router with transient state knows whether "downstream address" only 284 leads to a group member, in which case the JOIN_ACK need not be for- 285 warded, or whether "downstream address" leads to a downstream router 286 that either originated or forwarded the join prior to this router 287 receiving it, in which case this router must forward a received 288 JOIN_ACK. Precisely how this distinction is made is implementation 289 dependent. A router must also be able to distinguish these two condi- 290 tions wrt its forwarding cache. 292 4.3. Getting "On-tree" 294 A router which terminates a JOIN_REQUEST (see section 4.8) sends a 295 JOIN_ACK in response. A join acknowledgement (JOIN_ACK) traverses 296 the reverse path of the corresponding join message, which is possible 297 due to the presence of the transient join state. Once the acknowl- 298 edgement reaches the router that originated the join message, the new 299 receiver can receive traffic sent to the group. 301 A router is not considered "on-tree" until it has received a JOIN_ACK 302 for a previously sent/forwarded JOIN_REQUEST, and has instantiated 303 the relevant forwarding state. 305 Loops cannot be created in a CBT tree because a) there is only one 306 active core per group, and b) tree building/maintenance scenarios 307 which may lead to the creation of tree loops are avoided. For exam- 308 ple, if a router's parent router for a group becomes unreachable, the 309 router (child) immediately "flushes" all of its downstream branches, 310 allowing them to individually rejoin if necessary. Transient unicast 311 loops do not pose a threat because a new join message that loops back 312 on itself will never get acknowledged, and thus eventually times out. 314 4.4. Pruning and Prune State 316 Any of a forwarding cache entry's children can be "pruned" by the 317 immediate downstream router (child); in CBT, pruning is implemented 318 by means of the QUIT_NOTIFICATION message, which is sent hop-by-hop 319 in the direction: downstream --> upstream. A pruned child must be 320 distinguishable from a non-pruned child - how is implementation 321 dependent. One possible way would be to associate a "prune bit" with 322 each child in the forwarding cache. 324 The granularity of a quit (prune) can be (*, G), (*, Core), or (S, 325 G). (*, Core) and (S, G) prunes are only relevant to core tree 326 branches, i.e. those routers between a CBT BR and a core (inclu- 327 sive). (*, G) prunes are applicable anywhere on a CBT tree. 329 In previous versions of CBT, a quit was sent by a child router to 330 cause its parent to remove it from the tree. Whilst this capability 331 remains, in this version of CBT a quit can also be sent by a child to 332 make the parent's forwarding state more specific. 334 Refer to section 4.8 for the procedures relating to receiving and 335 forwarding a quit (prune) message. 337 Data is permitted to be received via a pruned interface, but must not 338 be forwarded over a pruned interface. Thus, pruning is always uni- 339 directional - it can stop data flowing downstream, but does not pre- 340 vent data from flowing upstream. 342 CBT BRs are able to take advantage of this uni-directionality; if the 343 BR does not have any directly attached group members, and is not 344 serving a neighbouring domain with group traffic, it can elect not to 345 receive traffic for the group which is sourced inside, or received 346 via, the CBT domain. At the same time, if the BR is the ingress BR 347 for a particular (*, G), or (S, G), externally sourced traffic for 348 (*, G) or (S, G) need not be encapsulated by the ingress BR and uni- 349 cast to the relevant core router - the BR can send the traffic using 350 native IP multicast. 352 4.5. The Forwarding Cache 354 A CBT router MUST implement a multicast forwarding cache which sup- 355 ports source specific (i.e. (S, G)) as well as source independent 356 (i.e. (*, G) and (*, Core)) entries. This forwarding cache is known 357 as the router's private CBT forwarding cache, or PFC. 359 All implementations SHOULD also implement a shared (i.e. protocol 360 independent) multicast forwarding cache - recommended in [8] to 361 facilitate interoperability - which is only used by Border Routers 362 and shared by all protocols operating on the Border Router (hence 363 "shared"). This forwarding cache is known as the router's shared for- 364 warding cache, or SFC. By having all CBT implementations support an 365 SFC, any CBT router is eligible to become a Border Router. 367 (*, Core) entries are only relevant to a CBT PFC. This state is rep- 368 resented in the cache by specifying the core's IP unicast address in 369 place of a group address/group address range. 371 Wrt representing groups (G's) in the forwarding cache, G may be an 372 individual Class D 32-bit group address, or may be a prefix repre- 373 senting a contiguous range of group addresses (a group aggregate). 375 Similarly, for source specific PFC entries, S can be an aggregate. 376 Therefore, the PFC SHOULD support the inclusion of masks or mask 377 lengths to be associated with each of S and G. 379 In CBT, all PFC entries require that an entry's "upstream" interface 380 is distinguishable as such - how is implementation dependent. CBT 381 uses the term "parent" interchangeably with "upstream", and 382 "child/children" interchangeably with "downstream". A core router's 383 parent is always NULL. 385 Whenever the sending/receiving of a CBT join or prune results in the 386 instantiation of more specific state in the router (e.g. (*, Core) 387 state exists, then a (*, G) join arrives), the children of the new 388 entry represent the union of the children from all other less spe- 389 cific forwarding cache entries, as well as the child (interface) over 390 which the message was received (if not already included). This is so 391 that at most a single forwarding cache entry need be matched with an 392 incoming packet. 394 Note that in CBT, there is no notion of "expected" or "incoming" 395 interface for (S, G) forwarding entries - these are treated just like 396 (*, G) entries. Take the following example: 398 core 399 |\ 400 | \ 401 R1 \ 402 | R2 - s1 403 | | 404 | | 405 R4-R3 - g1 406 | 407 | 408 BR 410 Figure 1. 412 In figure 1 suppose R3 joins (*, g1) via the path R4 --> R1 --> core. 413 BR joins (*, core) via the path R4 --> R1 --> core. BR issues a (s1, 414 g1) QUIT_NOTIFICATION resulting in the instantiation of (s1, g1) 415 between BR and the core. Thus, on R4 (s1, g1) and (*, g1) states 416 exist. Assuming (s1, g1) state was instantiated on R4 AFTER (*, g1) 417 state, R4's (s1, g1) child list comprises two interfaces, one point- 418 ing to BR, the other pointing to R3 (the latter copied from R4's (*, 419 g1) entry). R4's (s1, g1) parent points towards R1. 421 Wrt R4's (s1, g1) entry, it is not possible for R4 to determine which 422 is the correct incoming interface for s1 traffic, since R2 may send 423 s1 traffic towards the core, or towards R3. Thus, R4 may receive (s1, 424 g1) traffic via any of its on-tree interfaces, though R4 will not 425 forward the traffic over a pruned child. 427 A forwarding cache entry whose children are ALL marked as pruned as a 428 result of receiving quit messages may delete the entry provided there 429 exists no less specific state with at least one non-pruned child. 431 4.6. Packet Forwarding 433 When a data packet arrives, the forwarding cache is searched for a 434 best matching (according to longest match) entry. If no match is 435 found the packet is discarded. If the packet arrived natively it is 436 accepted if it arrives via an on-tree interface, i.e. any interface 437 listed in a matching entry, otherwise the packet is discarded. Assum- 438 ing the packet is accepted, a copy of the packet is forwarded over 439 each other (outgoing) non-pruned interface listed in the matching 440 entry. 442 If the packet arrived IP-in-IP encapsulated and the packet has 443 reached its final destination, the packet is decapsulated and treated 444 as described above, EXCEPT the packet need not have arrived via an 445 on-tree interface according to the matching entry. 447 4.7. The "Keepalive" Protocol 449 The CBT forwarding state created by join/ack messages is soft state. 450 This soft state is maintained by a separate "keepalive" mechanism 451 rather than by join/ack refreshes. 453 The CBT "keepalive" mechanism operates between adjacent on-tree 454 routers. The keepalive mechanism is implemented by means of group 455 specific ECHO_REQUEST and ECHO_REPLY messages, with the child routers 456 responsible for periodically (explicitly) querying the parent router. 457 The parent router (implicitly) monitors its children by expecting to 458 periodically receive queries (ECHO_REQUESTs) from each child (per 459 child router on non-broadcast networks; per child interface on broad- 460 cast networks). The repeated absence of either an expected query 461 (ECHO_REQUEST) or expected response (ECHO_REPLY) results in the cor- 462 responding interface being marked as pruned in the router's forward- 463 ing cache. This constitutes a state timeout due to an exception con- 464 dition. An interface can also be pruned in an explicit and timely 465 fashion by means of either a QUIT_NOTIFICATION (downstream to 466 upstream) or FLUSH_TREE (upstream to downstream) message. 468 Note that the network path comprising a CBT branch only changes due 469 to connectivity failure. An implementation could, however, invoke 470 the tearing down and rebuilding of a tree branch whenever an underly- 471 ing routing change occurs, irrespective of whether that change is due 472 to connectivity failure. This is not CBT's default behaviour. 474 4.8. Control Message Precedence & Forwarding Criteria 476 When a router receives a CBT join or (quit) prune message, if the 477 message contains state for which the receiving router has no matching 478 (according to longest match) state in its forwarding cache, the 479 receiving router creates a forwarding cache entry for the correspond- 480 ing state and forwards the control message upstream. 482 CBT join and quit (prune) messages are forwarded as far upstream as 483 the corresponding core router, or first router encountered with 484 equally- or less specific state AND at least one other non-pruned 485 child for that state. Forwarding state corresponding exactly to the 486 granularity of the join/quit is instantiated in all routers between 487 the join/quit originator and join/quit terminator, inclusive. Take 488 the following examples: 490 core core 491 | | 492 | | 493 R R 494 | / \ 495 | / \ 496 BR BR1 BR2 498 Figure 2. Figure 3. 500 Assume in figure 2 BR has instantiated a priori (*, Core) state 501 between itself and the core. It subsequently wishes to prune (*, G) 502 from (*, Core) so sends a (*, G) QUIT_NOTIFICATION upstream. When the 503 quit (prune) reaches router R, R already has less specific state 504 (i.e. (*, Core)), but this quit message results in its only child 505 interface (leading to BR) being marked as pruned under newly instan- 506 tiated (*, G) state. Since router R has no other child under either 507 (*, Core) or (*, G) states, R can forward the received (*, G) quit. 509 Assume in figure 3 neither BR1 nor BR2 has a priori state between 510 itself and the core. Assume that BR1 is explicitly notified by its 511 neighbouring domain of group membership for G, causing BR1 to send a 512 (*, G) (bi-directional) JOIN_REQUEST towards the core, via router R. 513 R receives the join, instantiates (*, G) state, and forwards the join 514 since it has no pre-existing equal- or less specific state. 516 Assume subsequently that BR2 is explicitly notified by its neighbour- 517 ing domain of interest in (S, G) traffic. BR2 sends a (S, G) (bi- 518 directional) JOIN_REQUEST towards the core, via router R. R receives 519 the join, and already has less specific state (i.e. (*, G)) with one 520 other child (leading to BR1). Thus, R instantiates (S, G) state 521 (copying children from (*, G) state) and includes the child (pointing 522 to BR2), but does not forward the (S, G) join due to the pre-exis- 523 tence of less specific state with one other non-pruned child. 525 A router with a forwarding cache entry whose children are ALL pruned 526 can remove (delete) the corresponding entry UNLESS there exists less 527 specific state with at least one non-pruned child. If an entry is 528 eligible for deletion, a quit representing the same granularity as 529 the forwarding cache entry is sent upstream. 531 Returning to the example used with figure 2 above, when router R 532 receives the (*, G) quit sent by BR and instantiates the correspond- 533 ing state, R can send a (*, G) quit upstream since there are no less 534 specific entries with _other_ non-pruned children. However, the (*, 535 G) state in R cannot be removed despite all (*, G) children being 536 pruned (in this e.g. there is only one child) because a less specific 537 (i.e. (*, Core)) cache entry exists with a non-pruned child. 539 CBT flush messages are forwarded downstream removing all equally- and 540 more specific state. A flush messsage is terminated by a leaf router, 541 or a router with less specific state; the flush message does not 542 affect the terminating router's less specific state. 544 4.9. Broadcast LANs 546 It cannot be assumed all of the routers on a broadcast link have a 547 uniform view of unicast routing; this is particularly the case when a 548 broadcast link spans two or more unicast routing domains. This could 549 lead to multiple upstream tree branches being formed for any one 550 group (an error condition) unless steps are taken to ensure all 551 routers on the link agree on a single LAN upstream forwarding router. 552 CBT routers attached to a broadcast link participate in an explicit 553 election mechanism that elects a single router, the designated router 554 (DR); the DR is a "join broker" for all LAN routers in so far as 555 joins are routed according to the DR's view of routing - without a DR 556 there could be conflicts potentially resulting in tree loops. The 557 router that actually forwards a join off-LAN for a group (towards the 558 group's core) is known as the LAN "upstream router" for that group. 559 A group's LAN upstream router may or may not be the LAN DR. 561 With regards to a JOIN_REQUEST being multicast onto a broadcast LAN, 562 the LAN DR decides over which interface to forward it. Depending on 563 the group's core location, the DR may re-direct (unicast) the join 564 back across the same link as it arrived to what it considers is the 565 best next hop towards the core. In this case, the LAN DR does not 566 keep any transient state for the JOIN_REQUEST it passed on. This best 567 next hop router is then the LAN upstream forwarder for the corre- 568 sponding group. This re-direction only applies to joins, which are 569 relatively infrequent - native multicast data never traverses a link 570 more than once. 572 For the case where a DR *originates* a join, and has to unicast it to 573 a LAN neighbour, the DR MUST keep transient state for the join. 575 On broadcast LANs it is necessary for a router to be able distinguish 576 between a directly attached (downstream) group member, and any (at 577 least one) downstream on-tree router(s). For a router to be able to 578 send a QUIT_NOTIFICATION (prune) upstream it must be sure it neither 579 has any (downstream) directly attached group members or on-tree 580 routers reachable via a downstream interface. How this is achieved is 581 implementation-dependent. One possible way would be for a CBT for- 582 warding cache to maintain 2 extra bits for each child entry - one bit 583 to indicate the presence of a group member on that interface, the 584 other bit indicating the presence of an on-tree router on that inter- 585 face. Both these bits must be clear (i.e. unset) before this router 586 can send a QUIT_NOTIFICATION for the corresponding state upstream. 588 4.10. The "all-cbt-routers" Group 590 The IP destination address of CBT control messages is either the 591 "all-cbt-routers" group address, or a unicast address, as appropri- 592 ate. 594 All CBT control messages are multicast over broadcast links to the 595 "all-cbt-routers" group (IANA assigned as 224.0.0.15), with IP TTL 1. 596 The exception to this is if a DR decides to forward a control packet 597 back over the interface on which it arrived, in which the DR unicasts 598 the control packet. The IP source address of CBT control messages is 599 the sending router's outgoing interface. 601 CBT control messages are unicast over non-broadcast media. 603 A CBT control message originated or forwarded by a router is never 604 processed by itself. 606 4.11. Non-Member Sending 608 This section is relevant to non-member sending where the data is 609 sourced inside the CBT domain. 611 A host always originates native multicast data. All multicast traffic 612 is received promiscuously by CBT routers. All but the LAN's desig- 613 nated router (DR) discard the packet. The DR looks up the relevant 614 mapping, encapsulates (IP-in-IP) the data, and unicasts 615 it to the group's core router. Consequently, no group state is 616 required in the network between the first hop router and the group's 617 core. 619 On arriving at the core router, the data packet is decapsulated and 620 disemminated over the group tree in the manner already described. 622 5. Protocol Specification Details 624 Details of the CBT protocol are presented in the context of a single 625 router implementation. 627 5.1. CBT HELLO Protocol 629 The HELLO protocol is used to elect a designated router (DR) on 630 broadcast-type links. 632 A router represents its status as a link's DR by setting the DR-flag 633 on that interface; a DR flag is associated with each of a router's 634 broadcast interfaces. This flag can only assume one of two values: 635 TRUE or FALSE. By default, this flag is FALSE. 637 A network manager can preference a router's DR eligibility by option- 638 ally configuring an HELLO preference, which is included in the 639 router's HELLO messages. Valid configuration values range from 1 to 640 254 (decimal), 1 representing the "most eligible" value. In the 641 absence of explicit configuration, a router assumes the default HELLO 642 preference value of 255. The elected DR uses HELLO preference zero 643 (0) in HELLO advertisements, irrespective of any configured prefer- 644 ence. The DR continues to use preference zero for as long as it is 645 running. 647 HELLO messages are multicast periodically to the all-cbt-routers 648 group, 224.0.0.15, using IP TTL 1. The advertisement period is speci- 649 fied by an hello timer, which is [HELLO_INTERVAL] seconds. 651 HELLO messages have a suppressing effect on those routers which would 652 advertise a "lesser preference" in their HELLO messages; a router 653 resets its hello timer if the received HELLO is "better" than its 654 own. Thus, in steady state, the HELLO protocol incurs very little 655 traffic overhead. 657 The DR election winner is that which advertises the lowest HELLO 658 preference, or the lowest-addressed in the event of a tie. 660 The situation where two or more routers attached to the same broad- 661 cast link are advertising HELLO preference 0 should never arise. How- 662 ever, should this situation arise, all but the lowest addressed zero- 663 advertising router relinquishes its claim as DR immediately by unset- 664 ting the DR flag on the corresponding interface. The relinquishing 665 router(s) subsequently advertise their previously used preference 666 value in HELLO advertisements. 668 5.1.1. Sending HELLOs 670 When a router starts up, it multicasts two HELLO messages over each 671 of its broadcast interfaces in successsion. The DR flag is initially 672 unset (FALSE) on each broadcast interface. This avoids the situation 673 in which each router on a broadcast subnet believes it is the DR, 674 thus preventing the multiple forwarding of join-requests should they 675 arrive during this start up period. 677 If, after sending an HELLO message, no "better" HELLO message is 678 received after HOLDTIME seconds, the router assumes the role of DR on 679 the corresponding interface. Whenever a router's status goes from 680 non-DR to DR it immediately sends a zero preferenced HELLO message. 682 Once a router becomes DR on an interface, it should remain DR for as 683 long as it is running (assuming a lower-addressed router on the same 684 subnet does not advertise a zero-preferenced HELLO message). 686 A router sends an HELLO message whenever its hello timer expires, or 687 its transition timer [DR_TRANS_TIMER] (if running) expires. Whenever 688 a router sends an HELLO message, it resets its hello timer. The 689 hello timer of the DR is [HELLO_INTERVAL] seconds. The hello timer of 690 all other (non-DR) routers is [HELLO_INTERVAL] + rnd seconds, where 691 "rnd" is a random interval between 1 and [HOLDTIME] seconds. 693 5.1.2. Receiving HELLOs 695 A router does not respond to an HELLO message if the received HELLO 696 is "better" than its own, or equally preferenced but lower addressed. 697 In this case, if the router has a transition timer [DR_TRANS_TIMER] 698 running on the same interface, the timer is cancelled. 700 A router must respond to an HELLO message if that received is lesser 701 preferenced (or equally preferenced but higher addressed) than would 702 be sent by this router over the same interface. This response HELLO 703 is sent immediately by the DR, or on expiry of an interval timer 704 which is set between one and [HOLDTIME] seconds by non-DRs - this 705 interval is known as the [DR_TRANS_TIMER] interval. Non-DRs cancel 706 this transition timer if a better hello is received whilst this timer 707 is running. 709 Figure 4 shows the state diagram for the HELLO protocol. 711 The following apply to the state diagram: 713 +o for the DR, hello timer = HELLO_INTERVAL 715 +o for non-DR(s), hello timer = HELLO_INTERVAL + rnd 717 +o rnd = random delay timer between 1 and HOLDTIME seconds 719 +o the DR always sends HELLO message with Preference zero 721 +o trans timer ([DR_TRANS_TIMER]) is a transition timer, set to rnd 722 Start O 723 | A: Send 2 HELLO's 724 | A: Start HOLDTIME 725 V 726 E: Recv better HELLO **********---- 727 A: Reset hello timer * Init * | E: Recv worse HELLO 728 -------------------------------* *<--- 729 | ********** 730 | | 731 | | E: HOLDTIME expires 732 | | A: Send HELLO 733 | | A: Reset hello timer 734 | V 735 | ********** 736 | ----* *---- 737 | E: Rec worse HELLO | * DR * | E: hello timer expires 738 | A: Send HELLO | * * | A: Send HELLO 739 | A: Reset hello timer --->**********<--- A: Reset hello timer 740 | | ^ 741 | | | E: HOLDTIME expires 742 | | | A: Send HELLO 743 | | | A: Reset hello timer 744 | E: Recv better HELLO | ------------------------------- 745 | A: Reset hello timer | | 746 |________________________________ | | 747 | | | 748 | | | 749 E: Recv better HELLO | | | 750 A: Cancel trans timer V V E: Recv better HELLO | 751 ********** A: Reset hello timer ************* A: Reset hello timer ******* 752 * Not DR *-------------------->* *<-----------------------* * 753 * & recd * * Not DR * * DR * 754 * worse * * * *wait * 755 * hello *<--------------------* *----------------------->* * 756 ********** E: Recv worse HELLO ************* E: hello timer expires ******* 757 | A: Start trans timer | ^ A: Send HELLO ^ 758 | | | A: Start HOLDTIME | 759 | --------- A: Reset hello timer | 760 | E: Rec better HELLO | 761 | A: Reset hello time | 762 | | 763 ------------------------------------------------------------------- 764 E: trans timer expires A: Send HELLO A: Start HOLDTIME A: Reset hello timer 766 Figure 4: HELLO Protocol State Diagram 768 5.2. JOIN_REQUEST Processing 770 A JOIN_REQUEST is the CBT control message used to register a member 771 host's interest in joining the distribution tree for the group. 773 A JOIN_REQUEST can be of (*, G), (*, Core), or (S, G) granularity. 775 5.2.1. Sending JOIN_REQUESTs 777 A JOIN_REQUEST can be only be originated by a LAN designated router 778 (DR), or by a CBT Border Router (BR). A join message cannot be sent 779 by a router that is the core router for the group. 781 A join message is sent hop-by-hop towards the core router for the 782 group (see section 8 - Core Router Discovery). 784 Refer to section 4.8 for the procedures relating to forward- 785 ing/receiving a join message. 787 A router sending a join message caches state for each join sent/forwarded. This 789 state is known as "transient join state". The router MUST be able to 790 distinguish between reaching a group member host, or a router, or 791 both, via its "Downstream address". How this is achieved is implemen- 792 tation dependent (see section 4.9). A join originator is responsible 793 for any retransmissions of this message if a response is not received 794 within [RTX_INTERVAL]. Retransmissions are not generated by any 795 router other than the join originator. 797 It is an error if no response is received after [JOIN_TIMEOUT] sec- 798 onds. If this error condition occurs, the joining process may be re- 799 invoked by the receipt of the next IGMP host membership report from a 800 locally attached member host. IGMP host membership reporting may not 801 be applicable to a CBT BR, and so it is recommended [JOIN_TIMEOUT] be 802 extended to, for example, 3 times the default value (see section 6). 804 5.2.2. Receiving JOIN_REQUESTs 806 If a JOIN_REQUEST is eligible for forwarding upstream (see section 807 4.8), transient join state is created for this join (unless it 808 already exists) and the join is forwarded upstream. 810 If this transient join state is not "confirmed" with a join acknowl- 811 edgement (JOIN_ACK), the state is timed out after [TRANSIENT_TIMEOUT] 812 seconds. 814 A join cannot be acknowledged by an on-tree router if the join 815 arrives via the router's parent interface for the group. A router 816 which originates an acknowledgment for a join never forwards the join 817 further. 819 5.2.3. Additional Aspects Related to Receiving Multicast JOIN_REQUESTs 821 Some aspects related to receiving multicast joins have already been 822 discussed in section 4.9. 824 In addition to that section, if a router receives a multicast join 825 and the router has a child interface deletion timer 826 [CHILD_DEL_TIMER] running on the same interface that is equally- or 827 less-specific than the received join, the timer is cancelled (see 828 section 5.4.2). This router acknowledges the received join. 830 5.3. JOIN_ACK Processing 832 A JOIN_ACK is the mechanism used by a router to confirm to a down- 833 stream router that the upstream router has instantiated the desired 834 forwarding state. 836 A JOIN_ACK must be of the same granularity as the corresponding 837 JOIN_REQUEST, and any JOIN_REQUEST options must be copied to the 838 JOIN_ACK. The downstream router receiving the join-ack converts its 839 corresponding transient state to its forwarding cache, then removes 840 the relevant transient state. 842 5.3.1. Sending JOIN_ACKs 844 A router which terminates a JOIN_REQUEST (see section 4.8) sends a 845 JOIN_ACK in response. A JOIN_ACK is sent over the same interface as 846 the corresponding JOIN_REQUEST was received. Any options present in 847 the join must be copied to the join-ack. 849 The sending of a JOIN_ACK - which inlcudes the "uni-directional" 850 option - over a child results in the child being pruned. The sending 851 of a JOIN_ACK over a child that is marked as pruned results in that 852 child being "un-pruned", unless the join-ack contains the uni-direc- 853 tional option. 855 5.3.2. Receiving JOIN_ACKs 857 An arriving JOIN_ACK must be matched to the corresponding from the router's 859 cached transient state. If no match is found, the JOIN_ACK is dis- 860 carded. If a match is found, a CBT forwarding cache entry is created 861 (or updated) by transferring the necessary transient join state to 862 the router's forwarding cache. The interface over which the join-ack 863 arrives becomes the entry's parent. 865 If the router's transient join state indicates that a router is pre- 866 sent downstream, it forwards the join-ack accordingly. A join-ack is 867 not forwarded downstream if this router's transient state indicates 868 ONLY group member hosts reside downstream (as opposed to router(s)). 869 An implementation SHOULD be able to distinguish these two conditions. 871 Once transient state has been confirmed by transferring it to the 872 forwarding cache, the transient state is deleted. 874 5.4. QUIT_NOTIFICATION Processing 876 A QUIT_NOTIFICATION (quit or prune) is both a means of improving, 877 i.e. speeding up, group leave latency for CBT leaf routers, and a 878 means for CBT Border Routers to elect not to receive traffic either 879 from sources within, or via, the CBT domain. 881 A quit (prune) can be of (*, G), (*, Core), or (S, G) granularity. A 882 single quit message can carry information representing multiple dif- 883 ferent states. 885 5.4.1. Sending QUIT_NOTIFICATIONs 887 A CBT router *originates* a QUIT_NOTIFICATION of the relevant granu- 888 larity when all children of a forwarding cache entry become pruned, 889 AND there exists no less specific state with at least one _other_ 890 non-pruned child. 892 Forwarding rules for a quit are explained in section 4.8. 894 A QUIT_NOTIFICATION is not acknowledged. 896 To help ensure consistency between a child and parent router given the 897 potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX] 898 QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous 899 one. 901 5.4.2. Receiving QUIT_NOTIFICATIONs 903 The receipt of a valid QUIT_NOTIFICATION results in the arrival 904 interface being marked as pruned. Rules regarding the forwarding of 905 a received quit (prune) are explained in section 4.8. 907 If a quit is accepted and was unicast, the child via which the quit 908 was received is added to the entry's child list (if not already), and 909 immediately marked as pruned. 911 If the quit is accepted and was multicast, and the receiving router 912 has pre-existing forwarding cache state of equal granularity, the 913 router sets a child interface deletion timer [CHILD_DEL_TIMER] on the 914 arrival interface with the same granularity. 916 Because this router might be acting as a parent router for multiple 917 downstream routers attached to the arrival link, [CHILD_DEL_TIMER] 918 interval gives those routers that did not send the QUIT_NOTIFICATION, 919 but received it over their parent interface, the opportunity to 920 ensure that the parent router does not remove the link from its child 921 interface list. Therefore, on receipt of a multicast QUIT_NOTIFICA- 922 TION over a PARENT interface, a receiving router schedules an 923 ECHO_REQUEST for the group for sending at a random interval between 0 924 (zero) and HOLDTIME seconds. The granularity of the echo MUST be 925 equal or less specific than the received quit. 927 The receipt of an ECHO_REQUEST for the group by the parent router 928 over a child interface on which [CHILD_DEL_TIMER] is running for the 929 group, results in the timer being cancelled, provided the echo is 930 equal or less specific than the granularity of the timer. 932 If the [CHILD_DEL_TIMER] expires, it implies no downstream on-tree 933 router is present on that interface. If no group member is present on 934 the same interface, the child can be marked as pruned in the relevant 935 forwarding cache entry. 937 5.5. ECHO_REQUEST Processing 939 The ECHO_REQUEST/ECHO_REPLY messages constitute a "keepalive" mecha- 940 nism which allows a group's child and parent routers to monitor each 941 other's liveness. 943 ECHO_REQUESTs can be of (*, G), (*, Core), or (S, G) granularity. A 944 single echo can carry information representing multiple different 945 states. 947 The following timers are specifically relevant to the "keepalive" 948 mechanism. The granularity of the timers corresponds the granularity 949 of the state that is to be "kept alive", i.e. it can be (*, G), (*, 950 Core), or (S, G), and is per interface: [ECHO_INTERVAL], 951 [UPSTREAM_EXPIRE_TIME] (monitors parent interface), and [DOWN- 952 STREAM_EXPIRE_TIME] (monitors child interface). 954 5.5.1. Sending ECHO_REQUESTs 956 Whenever a router creates a forwarding cache entry due to the receipt 957 of a JOIN_ACK, the router begins the periodic sending of ECHO_REQUEST 958 messages over its parent interface. The granularity of the echo is 959 equal to that of the sending router's forwarding cache entry, i.e. 960 (*, G), (*, Core), or (S, G). An ECHO_REQUEST is multicast 961 (224.0.0.15, TTL 1) or unicast, as appropriate. 963 ECHO_REQUEST messages are sent at [ECHO_INTERVAL] second intervals. 964 To avoid undesirable synchronisation effects each of a host's inter- 965 face's [ECHO_INTERVAL] timers includes a random response interval. 966 Whenever an ECHO_REQUEST is sent, [ECHO_INTERVAL] is reset for each 967 (*, G), or (*, Core), or (S, G), reported in the ECHO_REQUEST. 969 If no response is forthcoming, the upstream interface timer 970 [UPSTREAM_EXPIRE_TIME] running on the upstream interface for the 971 state reported in the ECHO_REQUEST will eventually expire. A 972 FLUSH_TREE message is sent over all pruned and non-pruned children. 973 The flush message reports the same state granularity as the echo for 974 which no response was forthcoming. 976 5.5.2. Receiving ECHO_REQUESTs 978 Whenever an ECHO_REQUEST is received on an interface, if the router's 979 interface is a parent interface for the reported state(s) it resets 980 its [ECHO_INTERVAL] timer on that interface for those state(s), if 981 appropriate. This implies that an ECHO_REQUEST which is multicast on 982 a LAN suppresses the ECHO_REQUEST that is about to be sent by another 983 router(s) for the same state(s) over the same interface. 985 If the router's receiving interface is a child interface for the 986 reported state(s), it resets its [DOWNSTREAM_EXPIRE_TIME] timer on 987 that interface for those state(s), if appropriate, and sends (multi- 988 cast) an ECHO_REPLY reporting all states for which this router con- 989 siders itself the parent wrt the child (interface). 991 Failure to receive an ECHO_REQUEST for a state(s) from a child after 992 [DOWNSTREAM_EXPIRE_TIME] results in the immediate removal of the 993 child from the relevant forwarding cache entry if the child is reach- 994 able via a non-broadcast network. If the child is reachable via a 995 broadcast network, the expiry of [DOWNSTREAM_EXPIRE_TIME] results in 996 the removal of the child from the router's relevant forwarding cache 997 entry provided no group members are present on that interface. 999 5.6. ECHO_REPLY Processing 1001 ECHO_REPLY messages are sent in immediate response to ECHO_REQUEST 1002 messages received over a valid child interface for the reported 1003 state(s). The ECHO_REPLY reports all state(s) for which this router 1004 considers itself the parent to the echo-requesting child. 1006 If multiple states need reporting, one or more ECHO_REPLYs may be 1007 sent in response to a single ECHO_REQUEST, as necessary. 1009 5.6.1. Sending ECHO_REPLY messages 1011 An ECHO_REPLY message is sent in immediate response to receiving an 1012 ECHO_REQUEST message via one of this router's valid children for the 1013 reported state(s). The ECHO_REPLY(s) contains a list of all states 1014 for which this router considers itself the parent to the child. 1016 5.6.2. Receiving ECHO_REPLY messages 1018 For each state reported in an ECHO_REPLY message received from a 1019 valid parent, the timers [UPSTREAM_EXPIRE_TIME] and [ECHO_INTERVAL] 1020 are refreshed for the reported states. 1022 Failure to receive the relevant ECHO_REPLY [HOLDTIME] seconds after 1023 sending an ECHO_REQUEST results in the corresponding ECHO_REQUEST 1024 being resent. An ECHO_REQUEST can be resent a maximum of [MAX_RTX] 1025 times. If no response is forthcoming, the corresponding state(s) is 1026 removed from the parent after [UPSTREAM_EXPIRE_TIME] seconds, and a 1027 FLUSH_TREE message is sent over each of the children represented by 1028 the state(s). 1030 [Note: If this router has directly attached members for any of the 1031 flushed groups, the receipt of an IGMP host membership report for any 1032 of those groups will prompt this router to rejoin the corresponding 1033 tree(s).] 1035 5.7. FLUSH_TREE Processing 1037 The FLUSH_TREE (flush) message is the mechanism by which a router 1038 invokes the tearing down of all its downstream branches for a partic- 1039 ular group. 1041 A flush can be of (*, G), (*, Core), or (S, G) granularity. A single 1042 flush message can carry information representing multiple different 1043 states. 1045 5.7.1. Sending FLUSH_TREE messages 1047 A FLUSH_TREE message is sent over all pruned and non-pruned children 1048 whenever a router loses connectivity to its parent. 1050 Once a flush message(s) has been sent, the relevant forwarding cache 1051 entry/entries are deleted. 1053 5.7.2. Receiving FLUSH_TREE messages 1055 CBT flush messages are forwarded downstream removing all equally- and 1056 more specific state. A flush messsage is terminated by a leaf router, 1057 or a router with less specific state; the flush message does not 1058 affect the terminating router's less specific state. 1060 6. Timers and Default Values 1062 This section provides a summary of the timers described above, 1063 together with their recommended default values. Other values may be 1064 configured; if so, the values used should be consistent across all 1065 CBT routers attached to the same network. 1067 +o [HELLO_INTERVAL]: the interval between sending an HELLO message. 1068 Default: 60 seconds. 1070 +o [HELLO_PREFERENCE]: Default: 255. 1072 +o [HOLDTIME]: generic response interval. Default: 3 seconds. 1074 +o [DR_TRANS_TIMER]: random delay timer used in transition from non-DR 1075 to DR. Default: delay set at between 1 and [HOLDTIME] seconds. 1077 +o [MAX_RTX]: default maximum number of retransmissions. Default 3. 1079 +o [RTX_INTERVAL]: message retransmission time. Default: 5 seconds. 1081 +o [JOIN_TIMEOUT]: raise exception due to tree join failure. Default: 1082 (3.5*[RTX_INTERVAL]) seconds. 1084 +o [TRANSIENT_TIMEOUT]: delete (unconfirmed) transient state. Default: 1085 [JOIN_TIMEOUT] seconds. 1087 +o [CHILD_DEL_TIMER]: remove child interface from forwarding cache. 1088 Default: (1.5*HOLDTIME) seconds. 1090 +o [UPSTREAM_EXPIRE_TIME]: time to send a QUIT_NOTIFICATION to our 1091 non-responding parent. Default: ([MAX_RTX]*[RTX_INTERVAL] + [HOLD- 1092 TIME]) seconds. 1094 +o [DOWNSTREAM_EXPIRE_TIME]: not heard from child, time to remove 1095 child interface. Default: ([ECHO_INTERVAL] + 1096 [UPSTREAM_EXPIRE_TIME]) seconds. 1098 +o [ECHO_INTERVAL]: interval between sending ECHO_REQUEST to parent 1099 routers. Default: 60 + rnd seconds, where "rnd" is between 0 and 1100 [HOLDTIME] seconds. 1102 7. CBT Packet Formats and Message Types 1104 CBT control packets are encapsulated in IP. CBT has been assigned IP 1105 protocol number 7 by IANA [4]. 1107 7.1. CBT Common Control Packet Header 1109 All CBT control messages have a common fixed length header. 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | vers | type | addr len | checksum | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 Figure 5. CBT Common Control Packet Header 1119 This CBT specification is version 3. 1121 CBT packet types are: 1123 +o type 0: HELLO 1125 +o type 1: JOIN_REQUEST 1127 +o type 2: JOIN_ACK 1129 +o type 3: QUIT_NOTIFICATION 1131 +o type 4: ECHO_REQUEST 1133 +o type 5: ECHO_REPLY 1135 +o type 6: FLUSH_TREE 1137 +o type 7: Bootstrap Message (optional) 1139 +o type 8: Candidate Core Advertisement (optional) 1141 +o Addr Length: address length in bytes of unicast or multicast 1142 addresses carried in the control packet. 1144 +o Checksum: the 16-bit one's complement of the one's complement sum 1145 of the entire CBT control packet. 1147 7.2. Packet Format for CBT Control Packet Types 0 - 6 1149 A CBT control packet is divided into 3 parts: 1151 +o Common Control Packet Header, 1153 +o Control Packet Payload, and 1155 +o Control Packet Option(s). 1157 0 1 2 3 1158 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 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1160 | CBT Control Packet Header | Header 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1162 |Payload Length | # of options | reserved | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control 1164 | address #1 | Packet 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload 1166 | address #2 | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | address #n | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1170 | option type | option len | option value... | Option(s) 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Figure 6. CBT Control Packet Format for Types 0 - 6. 1175 Control Packet Field Definitions: 1177 +o # Payload Length: the length of the CBT control packet payload, 1178 excluding the common control packet header and option(s). 1180 +o # of options: the number of distinct options (as defined by option 1181 type) carried in this control packet. 1183 +o address #n: control packet payload address(es). Different control 1184 packet types can carry addresses (multicast and/or unicast) as 1185 their payload (e.g. JOIN_REQUESTs), and some control packet types 1186 carry no addresses in the payload (e.g. HELLOs). 1188 +o option type: unique option identifier. 1190 +o option len: option length. The number of bytes consumed by this 1191 option's value. 1193 +o option value: variable length option value. 1195 NOTE: all control messages are padded to a 32-bit boundary. 1197 7.2.1. Option Type Definitions 1199 +o type 1: Hello Preference. Applicable only to HELLO packets to 1200 denote this HELLO packet's preference value. This option consumes 1 1201 byte of "option value". 1203 +o type 2: Uni-directional. Applicable only to JOIN_REQUESTs to indi- 1204 cate a uni-directional join. 1206 +o type 3: Inclusion List. Enables the reporting of a contiguous set 1207 of groups using a group mask, for which this control message should 1208 apply. The mask is represented by an 8-bit "masklen" field which 1209 is always included as the first 8 bits of this option's value. One 1210 or more group prefixes follow, each padded out (zeroed) to 32 bits. 1212 +o type 4: Exclusion List. This option allows for the reporting of 1213 group(s) to be exempted from the set reported elsewhere in this 1214 control packet. A contiguous range of groups may be specified 1215 using a group mask. The mask is represented by an 8-bit "masklen" 1216 field which is always included as the first 8 bits of this option's 1217 value. One or more group prefixes follow, each padded out (zeroed) 1218 to 32 bits. 1220 +o type 5: Source Information. This option enables a control message 1221 to specify source(s) to be associated with a group(s) carried else- 1222 where in the control message; if this option is specified as the 1223 first option after the control packet payload, the source informa- 1224 tion applies to the group specified in the payload. If this source 1225 information is to apply to a group aggregate (as specified by 1226 option type 3), the option specifying the group prefix MUST appear 1227 immediately before this option. 1229 A source aggregate (prefix) may be specified using a source mask. 1230 The mask is represented by an 8-bit "masklen" field which is always 1231 included as the first 8 bits of this option's value. The source 1232 (prefix) follows, padded out (zeroed) to 32 bits. 1234 7.2.2. Sample Control Packets 1236 This section shows some sample constructions of a selection of dif- 1237 ferent CBT control packet types. 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1242 | 3 | 0 | 4 | Checksum | Header 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1244 | 4 | 1 | reserved | Payload 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1246 | 1 | 1 | Preference | Padding | Option 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1249 Figure 7. Sample HELLO packet 1251 0 1 2 3 1252 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 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1254 | 3 | 1 | 4 | Checksum | Header 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1256 | 16 | 0 | reserved | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control 1258 | Group Address | Packet 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload 1260 | Core Address | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Join-Originating DR | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1265 Figure 8. Sample (*, G) JOIN_REQUEST (no options included) 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1270 | 3 | 2 | 4 | Checksum | Header 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1272 | 12 | 0 | reserved | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control 1274 | Group Address | Packet 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload 1276 | Join Originating DR (copied from JOIN_REQUEST) | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1279 Figure 9. Sample (*, G) JOIN_ACK (no options included) 1281 0 1 2 3 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1284 | 3 | 1 | 4 | Checksum | Header 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1286 | 16 | 1 | reserved | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control 1288 | Group Address | Packet 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload 1290 | Core Address | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Join-Originating DR | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1294 | 5 | 5 | 24 | Src Addr Pfx..| Option 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 |.............. Src Addr Prefix .............. | Padding | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1299 Figure 10. Sample (S, G) JOIN_REQUEST 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1304 | 3 | 4 | 4 | Checksum | Header 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1306 | 8 + (n x 4) | 0 | reserved | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control 1308 | ECHO_REQUEST Originating Router | Packet 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload 1310 | Address #1 | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Address #2 | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Address #n | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1317 Figure 11. Sample ECHO_REQUEST 1319 0 1 2 3 1320 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 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Common 1322 | 3 | 5 | 4 | Checksum | Header 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1324 | 8 + (n x 4) | 0 | reserved | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control 1326 | ECHO_REPLY Originating Router | Packet 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload 1328 | Address #1 | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Address #2 | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Address #n | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------- 1335 Figure 12. Sample ECHO_REPLY 1337 8. Core Router Discovery 1339 There are two available options for CBTv2 core discovery; the "boot- 1340 strap" mechanism (as currently specified with the PIM sparse mode 1341 protocol [2]) is applicable only to intra-domain core discovery, and 1342 allows for a "plug & play" type operation with minimal configuration. 1344 The disadvantage of the bootstrap mechanism is that it is much more 1345 difficult to affect the shape, and thus optimality, of the resulting 1346 distribution tree. Also, to be applicable, all CBT routers within a 1347 domain must implement the bootstrap mechanism. 1349 The other option is to manually configure leaf routers with mappings (note: leaf routers only); this imposes a degree of 1351 administrative burden - the mapping for a particular group must be 1352 coordinated across all leaf routers to ensure consistency. Hence, 1353 this method does not scale particularly well. However, it is likely 1354 that "better" trees will result from this method, and it is also the 1355 only available option for inter-domain core discovery currently 1356 available. 1358 8.1. "Bootstrap" Mechanism Overview 1360 It is unlikely that the bootstrap mechanism will be appended to a 1361 well-known network layer protocol, such as IGMP [3], though this 1362 would facilitate its ubiquitous (intra-domain) deployment. Therefore, 1363 each multicast routing protocol requiring the bootstrap mechanism 1364 must implement it as part of the multicast routing protocol itself. 1366 A summary of the operation of the bootstrap mechanism follows 1367 (details are provided in [6]). It is assumed that all routers within 1368 the domain implement the "bootstrap" protocol, or at least forward 1369 bootstrap protocol messages. 1371 A subset of the domain's routers are configured to be CBT candidate 1372 core routers. Each candidate core router periodically (default every 1373 60 secs) advertises itself to the domain's Bootstrap Router (BSR), 1374 using "Core Advertisement" messages. The BSR is itself elected 1375 dynamically from all (or participating) routers in the domain. The 1376 domain's elected BSR collects "Core Advertisement" messages from can- 1377 didate core routers and periodically advertises a candidate core set 1378 (CC-set) to each other router in the domain, using traditional hop- 1379 by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to 1380 advertise the CC-set. Together, "Core Advertisements" and "Bootstrap 1381 Messages" comprise the "bootstrap" protocol. 1383 When a router receives an IGMP host membership report from one of its 1384 directly attached hosts, the local router uses a hash function on the 1385 reported group address, the result of which is used as an index into 1386 the CC-set. This is how local routers discover which core to use for 1387 a particular group. 1389 Note the hash function is specifically tailored such that a small 1390 number of consecutive groups always hash to the same core. Further- 1391 more, bootstrap messages can carry a "group mask", potentially limit- 1392 ing a CC-set to a particular range of groups. This can help reduce 1393 traffic concentration at the core. 1395 If a BSR detects a particular core as being unreachable (it has not 1396 announced its availability within some period), it deletes the rele- 1397 vant core from the CC-set sent in its next bootstrap message. This is 1398 how a local router discovers a group's core is unreachable; the 1399 router must re-hash for each affected group and join the new core 1400 after removing the old state. The removal of the "old" state follows 1401 the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message 1402 downstream. 1404 8.2. Bootstrap Message Format 1406 0 1 2 3 1407 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 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | CBT common control packet header | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | For full Bootstrap Message specification, see [6] | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 Figure 13. Bootstrap Message Format 1416 8.3. Candidate Core Advertisement Message Format 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | CBT common control packet header | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | For full Candidate Core Adv. Message specification, see [6] | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 Figure 14. Candidate Core Advertisement Message Format 1428 Acknowledgements 1430 Special thanks goes to Paul Francis, NTT Japan, for the original 1431 brainstorming sessions that brought about this work. 1433 The use of a single core model since CBTv2 owes much to Clay Shields 1434 and his work on Ordered CBT (OCBT) [7]. Clay identified and proved 1435 several failure modes of CBT(v1) as it was specified with multiple 1436 cores, and also suggested using an unreliable quit mechanism, which 1437 has appeared since the CBTv2 specification as the QUIT_NOTIFICATION. 1438 Clay also provided more general constructive comments on the CBT 1439 architecture and specification. 1441 Others that have contributed to the progress of CBT include Ken Carl- 1442 berg, Eric Crawley, Jon Crowcroft, Bill Fenner, Mark Handley, Ahmed 1443 Helmy, Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, 1444 Scott Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, 1445 Paul White, and other participants of the IETF IDMR working group. 1447 Thanks also to 3Com Corporation and British Telecom (BT) Plc for 1448 assisting with funding this work. 1450 Finally, thanks to Graeme Brown, BT Labs UK, for his ongoing imple- 1451 mentation effort porting CBT to FreeBSD. For further information on 1452 this implementation contact , Alan 1453 O'Neill , or Tony Ballardie . 1456 References 1458 [1] Core Based Trees (CBT) Multicast Routing Architecture; A. Bal- 1459 lardie; RFC 2201; ftp://ds.internic.net/rfc/rfc2201.txt. 1461 [2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D. 1462 Estrin et al; http://netweb.usc.edu/pim RFC XXXX and Working drafts. 1464 [3] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner; 1465 ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-v2-08.txt. 1466 Working draft, 1998. 1468 [4] Assigned Numbers; J. Reynolds and J. Postel; RFC 1700, October 1469 1994. 1471 [5] CBT Multicast Border Router Specification; A. Ballardie, B. Cain, 1472 Z. Zhang; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt- 1473 br-spec-**.txt. Working draft, March 1998. 1475 [6] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Rout- 1476 ing; D. Estrin et al.; Technical Report; http://catarina.usc.edu/pim 1478 [7] The Ordered Core Based Tree Protocol; C. Shields and J.J. Garcia- 1479 Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan, April 1480 1997; http://www.cse.ucsc.edu/research/ccrg/publications/info- 1481 comm97ocbt.ps.gz 1483 [8] Interoperability Rules for Multicast Routing Protocols; D. Thaler; 1484 ftp://ds.internic.net/internet-drafts/draft-thaler-multicast- 1485 interop-01.txt; March 1997. 1487 Author Information: 1489 Tony Ballardie, 1490 Research Consultant, 1492 e-mail: ABallardie@acm.org 1494 Brad Cain, 1495 Bay Networks Inc., 1496 3, Federal Street, 1497 Billerica, MA 01821, USA. 1498 e-mail: bcain@baynetworks.com 1499 voice: +1 978 916 1316 1501 Zhaohui "Jeffrey" Zhang, 1502 Argon Networks Inc., 1503 25, Porter Road, 1504 Littleton, MA 01460, USA. 1505 Phone: +1 (978) 392 4681 1506 e-mail: zzhang@argon.com