idnits 2.17.1 draft-ietf-pim-v2-dm-00.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-20) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 243 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? == There are 3 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 15 has weird spacing: '... Drafts are ...' == Line 16 has weird spacing: '...cuments of t...' == Line 17 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '... Drafts may ...' == Line 22 has weird spacing: '...iate to use ...' == (238 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Aug 10, 1998) is 9385 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) == Missing Reference: 'Hello-Timer' is mentioned on line 315, but not defined == Missing Reference: 'Neighbor-Timer' is mentioned on line 317, but not defined == Missing Reference: 'Data-Timeout' is mentioned on line 455, but not defined == Unused Reference: 'PIMARCH' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 582, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Deering91' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'DVMRP') ** Downref: Normative reference to an Experimental draft: draft-ietf-idmr-pim-sm-specv2 (ref. 'PIMSM') -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMARCH' Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Stephen Deering (cisco) 2 Internet Draft Deborah Estrin (USC) 3 Dino Farinacci (cisco) 4 Van Jacobson (LBL) 5 Ahmed Helmy (USC) 6 David Meyer (cisco) 7 Liming Wei (cisco) 9 draft-ietf-pim-v2-dm-00.txt Aug 10, 1998 11 Protocol Independent Multicast Version 2 Dense Mode Specification 13 Status of This Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. (Note that other groups may also distribute 18 working documents as Internet Drafts). 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a 24 ``working'' draft'' or ``work in progress.'' 26 Please check the I-D abstract listing contained in each Internet 27 Draft directory to learn the current status of this or any other 28 Internet Draft. 30 1 Introduction 32 This specification defines a multicast routing algorithm efficient for 33 multicast groups that are densely distributed across a network. This 34 protocol does not have a topology discovery mechanism often used by a 35 unicast routing protocol. It employes the same packet formats sparse- 36 mode PIM [PIMSM] uses. This protocol is called dense-mode PIM. The 37 foundation of this design was largely built on Deering's early work on 38 IP multicast routing [Deering91]. 40 2 Terminology 42 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL 43 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and 44 ``OPTIONAL'' in this document are to be interpreted as described in 45 RFC 2119. 47 3 Glossary 49 Reverse Path Forwarding (RPF) / RPF interface / RPF lookup 51 RPF is a multicast forwarding mode where a data packet is 52 accepted for forwarding if it is received on an interface 53 used to reach the source in unicast. The interface passing 54 this check is called the RPF interface. 56 An RPF lookup for a source returns the RPF interface and the 57 next-hop information, as if a route lookup is done for the 58 source on a unicast routing table. 60 Topology Discovery Mechanism/Protocol 62 This mechanism provides sufficient topological information 63 for a router to determine whether a neighbor system is 64 upstream with respect to each multicast source. Some topology 65 discovery mechanism can also determine if a neighbor is 66 downstream with respect to each multicast source. An existing 67 unicast routing protocol or a clone of it is sometimes used 68 for this purpose (such as in DVMRP[DVMRP]). When a multicast 69 routing protocol has a topology discovery mechanism built-in, 70 the topology discovery mechanism is sometimes referred to as 71 the unicast routing part of the protocol (even though it is 72 not used for forwarding unicast packets). 74 4 PIM-DM Protocol Overview 76 Dense-mode PIM assumes that when a source starts sending, all 77 downstream systems want to receive multicast datagrams. Initially, 78 multicast datagrams are flooded to all areas of the network. If some 79 areas of the network do not have group members, dense-mode PIM will 80 prune off the forwarding branch by setting up prune state. The prune 81 state has an associated timer, which on expiration will turn into 82 forward state, allowing data to go down the branch previously in prune 83 state. 85 The prune state contains source and group address information. When a 86 new member appears in a pruned area, a router can ``graft'' toward the 87 source for the group, turning the pruned branch into forward state. 89 The forwarding branches form a tree rooted at the source leading to 90 all members of the group. This tree is called a source rooted tree. 92 The flooding of datagrams followed by pruning of unwanted branches is 93 often referred to as a flood-and-prune cycle, typical of dense mode 94 protocols. The flood-and-prune mechanism in dense mode PIM uses a 95 technique called reverse path forwarding (RPF), in which a multicast 96 datagram is forwarded if the receiving interface is the one used to 97 forward unicast datagrams to the source of the datagram. 99 Compared with multicast routing protocols with built-in topology 100 discovery mechanisms (e.g. DVMRP with its own RIP-like ``unicast'' 101 routing protocol), dense mode PIM has simplified design, and is not 102 hard-wired into a specific type of topology discovery protocol. 103 However, such simplification does incur more overhead and cause 104 flood-and-prune to occur on some links that could be avoided if 105 sufficient topology information is available, e.g. to decide whether 106 each interface leads to any downstream neighbors for a particular 107 source. We chose to accept the additional overhead in favor of the 108 simplification and flexibility gained by not depending on a specific 109 type of topology discovery protocol. 111 In relation to sparse-mode PIM, dense-mode PIM differs in two 112 essential ways: 1) there are no periodic joins transmitted, only 113 explicit triggered grafts/prunes, and 2) there is no Rendezvous Point 114 (RP). 116 5 Protocol Description 118 Dense mode PIM initiates forwarding state in routers when a source 119 begins to send. When a source sends multicast datagrams to a group G, 120 it does not give any prior notifications to the network. A receiving 121 router creates a forwarding entry for the source and group G, if it 122 does not already have it. This is called a (S,G) entry. It includes 123 the following contents: source address, group address, the incoming 124 interface, a list of outgoing interfaces, a few flags and a few 125 timers. The incoming interface for (S,G) is determined by an RPF 126 lookup in the unicast routing table. The (S,G) outgoing interface list 127 contains interfaces that have PIM routers present or host members for 128 group G. 130 If a router creates a (S,G) entry with an empty outgoing interface 131 list after receiving a multicast datagram, it must trigger a PIM-Prune 132 message toward the source S. This type of entry is called a negative 133 cache entry. Negative cache entries can be found on leaf routers with 134 no local group members, or on routers where prune messages were 135 received from downstream routers that caused the outgoing interface 136 list to become NULL. 138 Dense mode PIM routers send periodic Hello messages out of each 139 interface and keep track of neighbors based on received Hello 140 messages. The Hello message has a Holdtime field that tells the 141 neighbor to delete neighbor information if it is not refreshed before 142 expiration. 144 The following sections describe in detail how leaf network is defined 145 and detected; how pruning is done on multi-access LANs; and actions 146 related to new members joining an existing group; issues with 147 designated router election; parallel path resolution; multicast 148 forwarding entry expiration and the adaptation to topology changes. 150 5.1 Leaf network detection 152 In dense mode PIM, prune state is first instantiated on routers 153 connected to leaf networks without group members. A network on a 154 router interface is deemed a leaf if there is no other PIM neighbors 155 on that network. The notion of leaf network here might be slightly 156 different from that defined in other protocols. [*] 157 _________________________ 158 [*] E.g. In DVMRP a leaf network for a source is de- 159 fined as one without downstream neighbor DVMRP routers. 160 Each DVMRP router is able to decide whether it has a 161 downstream DVMRP neighbor with respect to each source. 162 This is due to the RIP-like mechanism used in its to- 163 A router determines it is a leaf by not receiving PIM Hello messages. 164 A leaf router can detect that there are no members downstream when it 165 is the only router on a network and there are no IGMP Host-Report 166 messages received from hosts. A leaf router should not populate a 167 forwarding entry's outgoing interface list with such leaf network 168 without downstream members. 170 It should be noted that a non-leaf router in PIM dense-mode is not 171 necessarily a non-leaf node on a particular multicast forwarding tree. 172 There are topologies where two parallel routers are connected to a 173 common LAN where none of the routers uses the other one to reach a 174 source. Therefore both routers will be leaves of any forwarding trees 175 rooted at the source. When there are no group members on this LAN, 176 both routers must not forward packets onto it. This is achieved by 177 prune messages sent on the LAN as a result of an assert process. 178 Please 180 A dense mode PIM implementation must take proper actions when a non- 181 leaf router becomes a leaf router. When the last PIM neighbor on an 182 interface goes away and turns the connected subnet into a leaf 183 network, the router should delete that interface from the outgoing 184 interface lists of all groups without attached group members. 186 5.2 Pruning of branches 188 5.2.1 Pruning on multi-access LANs and prune-override 190 To avoid PIM-Prune message storms, PIM-Prune messages are never sent 191 on LANs in response to a received multicast packet that is associated 192 with an existing negative cache entry. 194 A prune is sent upstream when a router creates a (S,G) entry with an 195 empty outgoing interface list, or when the outgoing interface list 196 becomes empty. [*] 198 Prune information is flushed periodically. This causes multicast 199 datagrams to be sent in RPF mode again which in turn triggers prune 200 messages. 202 When a prune message is sent onto an upstream LAN, it is data link 203 multicast and IP addressed to the all PIM routers group address 204 224.0.0.13. The router to process the prune will be indicated by 205 inclusion of its address in the "Address" field of the message. This 206 _________________________ 207 pology discovery (or ``unicast routing'') protocol. 208 [*] I.e. the set of forwarding interfaces in the out- 209 going interface list is NULL. 211 address is obtained by an RPF look up for the source. When the prune 212 message is sent, the expected upstream router will schedule a deletion 213 request of the LAN from its outgoing interfaces for the (S,G) entry 214 from the prune list. The suggested delay time before deletion should 215 be greater than 3 seconds. The default prune delay time is 3 seconds. 217 Other routers on the LAN will hear the prune message and respond with 218 a join if they still expect multicast datagrams from the expected 219 upstream router. The PIM-Join message is data link multicast and IP 220 addressed to the all PIM routers group address 224.0.0.13. The router 221 to process the join will be indicated by inclusion of its address in 222 the "Address" field of the message. The address is determined by an 223 RPF lookup for the source. When the expected router receives the join 224 message, it will cancel the deletion request. This process is called 225 prune-override. 227 Routers that need to send prune-override joins will randomly generate 228 a join message delay timer. If a join is heard from another router 229 before a router sends its own, it will cancel sending its own join. 230 This will reduce control traffic on the LAN. The maximum join delay 231 timer should be equal to or smaller than the prune delay timer value. 232 The default is 3 seconds. 234 If the expected upstream router does not receive any PIM-Join messages 235 before the scheduled expiration time for the deletion request, it 236 prunes the outgoing LAN interface from the (S,G) multicast forwarding 237 entry. 239 However, if the prune-override join message is lost, the deletion will 240 occur and there will be no data delivery for the amount of time the 241 interface remains in prune state. To reduce the probability of this 242 occurance, a router that has scheduled to prune the interface off is 243 required to immediately send a prune onto the interface. This gives 244 other routers another chance to hear the prune, and to respond with a 245 join. 247 Finally, equal-cost paths leading to a LAN presents a special case for 248 join/prune processing. When an upstream router is chosen by an RPF 249 lookup there may be equal-cost paths to reach the source. The higher 250 IP addressed system is always chosen. If the unicast routing protocol 251 does not store all available equal-cost paths in the routing table, 252 the "Address" field may contain the address of the wrong upstream 253 router. To avoid this situation, the "Address" field may optionally be 254 set to 0.0.0.0 which means that all upstream routers (the ones that 255 have the LAN as an outgoing interface for the (S,G) entry) may process 256 the packet. 258 5.2.2 Pruning a Point-to-point link 260 PIM-Prune messages received on a point to point link are not delayed 261 before processing as they are in the LAN procedure. If the prune is 262 received on an interface that is in the outgoing interface list, it is 263 deleted immediately. 265 Prunes may be rate-limited on point-to-point interfaces when a 266 multicast datagram is received for a negative cache entry. 268 5.3 New members joining an existing group 270 If a router is directly connected to a host that wants to become a 271 member of a group, the router may send a PIM-Graft message toward 272 known sources. This allows join latency to be reduced below that 273 indicated by the relatively large timeout value suggested for prune 274 information. 276 The host indicates its interest in group G by sending an IGMP report. 277 If a receiving router has state for group G, it adds the interface on 278 which the IGMP Report or PIM-Graft was received for all known (S,G)'s. 279 If the (S,G) entry was a negative cache entry, the router sends a 280 PIM-Graft message upstream toward S. 282 A router receiving the PIM-Graft message adds the received interface 283 into the matching (S,G) entry's outgoing interface list. If the entry 284 transitions to forward state due to this added outgoing interface, the 285 router must send a PIM-Graft message toward the source. 287 Routers with no group state do nothing on receipt of IGMP reports, 288 since dense-mode PIM will deliver multicast datagrams to all 289 interfaces when creating state for a group. 291 PIM-Graft message is the only PIM message that uses a positive 292 acknowledgment strategy. Senders of PIM-Graft messages unicast them to 293 their upstream RPF neighbors. The neighbor processes each (S,G) and 294 immediately acknowledges each (S,G) in a PIM-GraftAck message. This is 295 relatively easy, since the receiver simply changes the PIM message 296 type from Graft to Graft-Ack and unicasts the original packet back to 297 the source. The sender periodically retransmits the PIM-Graft message 298 for any (S,G) that has not been acknowledged. The interval between 299 each retransmission is 3 seconds. Note that the sender need not keep a 300 retransmission list for each neighbor since PIM-Grafts are only sent 301 to the RPF neighbor. Only the (S,G) entry needs to be tagged for 302 retransmission. 304 5.4 Designated Router Election 306 Dense mode PIM itself does not need the function of a designated 307 router (DR). But a DR is needed on multi-access LANs running IGMP 308 version 1, which relies on a routing protocol to select a query router 309 for the purpose of sending IGMP Host-Query messages. Dense-mode PIM 310 designated router (DR) election has the same procedure sparse-mode PIM 311 uses. 313 Each PIM router connected to a multi-access LAN should periodicly 314 transmit PIM-Hello messages onto the LAN. The period is specified as 315 [Hello-Timer] in the sparse mode specification (default 30 seconds). 316 The highest IP addressed router becomes the DR. The discovered PIM 317 routers should be timed out after 105 seconds (the [Neighbor-Timer] in 318 the PIM-SM specification]. If the DR goes down, a new DR is elected. 320 DR election is only necessary on multi-access networks. 322 5.5 Parallel paths to a source 324 Two or more routers may receive the same multicast datagram that was 325 replicated upstream. In particular, if two routers have equal cost 326 paths to a source and are connected on a common multi-access network, 327 duplicate datagrams will travel downstream onto the LAN. Dense-mode 328 PIM will detect such a situation and will not let it persist. 330 If a router receives a multicast datagram on an outgoing interface on 331 a multi-access LAN, the packet must be a duplicate. In this case a 332 single forwarder must be elected. Using PIM Assert messages addressed 333 to 224.0.0.13 on the LAN, upstream routers can decide which one 334 becomes the forwarder. Downstream routers listen to the Asserts so 335 they know which one was elected (typically this is the same as the 336 downstream router's RPF neighbor but there are circumstances when 337 using different unicast protocols where this might not be the case). 339 The upstream router elected is the one that has the best metric to the 340 source. When a packet is received on an outgoing interface, a router 341 will send an Assert packet on the LAN indicating what metric it uses 342 to reach the source of the data packet. If metrics are comparable, the 343 router with the best metric will become the forwarder. Incomparable 344 metrics will be discussed later in this section when metric preference 345 is described. All other upstream routers will delete the interface 346 from their outgoing interface list. The downstream routers also do the 347 comparison in case the forwarder is different than the RPF neighbor. 348 This is important so downstream routers send subsequent Prunes or 349 Grafts to the correct neighbor. 351 Associated with the metric is a metric preference value. This is 352 provided to deal with the case where the upstream routers may run 353 different unicast routing protocols. The numerically smaller metric 354 preference is always preferred. The metric preference should be 355 treated as the high-order part of an Assert metric comparison. 356 Therefore, a metric value can be compared with another metric value 357 provided both metric preferences are the same. A metric preference can 358 be assigned per unicast routing protocol and needs to be consistent 359 for all PIM routers on the LAN. 361 Asserts are rate-limited. The recommended minimum interval between two 362 subsequent asserts out the same outgoing interface of an (S,G) entry 363 is 1 second. 365 The following Assert rules must be observed: 367 Multicast packet received on outgoing interface: 369 1 Do unicast routing table lookup on source IP address from data 370 packet. 372 2 Send Assert on interface for source IP address from data packet. 373 The assert message includes metric preference of routing protocol 374 and metric from routing table lookup. 376 3 If route is not found, Use metric preference of 0x7fffffff and 377 metric 0xffffffff. 379 Asserts received on outgoing interface: 381 1 Compare metric received in Assert with the one you would have 382 advertised in an Assert. If the value in the Assert is less than 383 your value, prune the interface. If the value is the same, and 384 your address is less than the Assert sender, prune the interface. 386 2 If you have won the election and there are directly connected 387 members on the LAN, keep the interface in your outgoing interface 388 list. You are the forwarder for the LAN. 390 3 If you have won the election but there are no directly connected 391 members on the LAN, schedule to prune the interface. The LAN might 392 be a stub LAN with no members (and no downstream routers). If no 393 subsequent Joins are received, delete the interface from the 394 outgoing interface list. Otherwise keep the interface in your 395 outgoing interface. You are the forwarder for the LAN. 397 4 The assert winner sends an assert with its own metric on the LAN, 398 so that all other routers know who the winner is. 400 Asserts received on incoming interface: 402 1 Downstream routers will select the upstream router with the 403 smallest metric as their RPF neighbor. If two metrics are the 404 same, the highest IP address is chosen to break the tie. 406 If the upstream router selected is different from the RPF neighbor 407 selected natively, it should start an Assert-Timer. When this 408 timer expires, it restores the RPF information obtained by the RPF 409 lookup. 411 2 If the downstream routers have downstream members, they must 412 schedule a join to inform the upstream router packets should be 413 forwarded on the LAN. This will cause the upstream forwarder to 414 cancel its delayed pruning of the interface. 416 3 Whent he assert state times out, the downstream router may switch 417 from the assert winner to the original RPF neighbor, if different. 419 5.6 Timers in Multicast Forwarding Entries 421 An (S,G) entry has a number of associated timers. One for the 422 multicast routing entry itself, one for each pruned interface in the 423 outgoing interface list and one to time out information about upstream 424 assert winner (Assert_timer). An outgoing interface in forward state 425 does not time out or change state without external events. The 426 outgoing interface stays in forward state in the list as long as there 427 is a group member connected, or there is a downstream PIM neighbor 428 that has not sent a prune to it. The interface is deleted from the 429 outgoing interface list if it is on a leaf network and there is no 430 connected member. The interface timer for a pruned interface should be 431 started with the holdtime in the prune message (also referred to as 432 the prune timer). 434 When a (S,G) entry is in forwarding state, its expiration timer is set 435 to [Data-Timeout], as specified in the companion sparse mode 436 specification [PIMSM], which is 210 seconds by default. This timer is 437 restarted when a data packet is being forwarded. The (S,G) entry is 438 deleted if this timer expires. 440 Once all interfaces in the outgoing interface list are pruned, the 441 (S,G)'s expiration timer should be set to the maximum prune timer 442 among all its outgoing interfaces. During this time the entry is known 443 as a negative cache entry. 445 If the prune timers on different outgoing interfaces are different, 446 the pruned interface with the shortest remaining timer may expire 447 first and turn the negative cache entry into forwarding state. When 448 this happens, a graft should be triggered upstream. When a negative 449 cache entry turns into a forward entry, the entry timer should be 450 restarted with the default expiration timer. Once the (S,G) entry 451 times out, it will be recreated when the next multicast packet or join 452 arrives. 454 The prune message sent upstream contains a holdtime. Its default value 455 is [Data-Timeout], except when the Assert timer is also running, the 456 holdtime in the prune message is set to the smaller value between the 457 prune holdtime the system uses, and the remaining assert timer value 458 before its expiration. The Assert Timer has a default value of 210 459 seconds. 461 5.7 Adapting to unicast route changes 463 When unicast route changes occur, the RPF interface for many (S,G) 464 entries will also change. The following should be done for the 465 affected entries: 467 1 A prune should be sent toward the old incoming interface; 469 2 A graft should be sent to the new RPF neighbor. 471 6 Packet Formats 473 This section describes the details of the packet formats for PIM 474 control messages. 476 All PIM control messages have protocol number 103. 478 Basically, PIM messages are either unicast (e.g. Registers and 479 Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group 480 `224.0.0.13' (e.g. Join/Prune, Asserts, etc.). 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |PIM Ver| Type | reserved | Checksum | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 PIM Ver 489 PIM Version number is 2. 491 Type Types for specific PIM messages. PIM Types are: 493 0 = Hello 494 1 = Register 495 2 = Register-Stop 496 3 = Join/Prune 497 4 = Bootstrap 498 5 = Assert 499 6 = Graft (used in PIM-DM only) 500 7 = Graft-Ack (used in PIM-DM only) 501 8 = Candidate-RP-Advertisement 503 Reserved 504 Set to zero. Ignored upon receipt. 506 Checksum 507 The checksum is the 16-bit one's complement of the one's 508 complement sum of the entire PIM message. For computing the 509 checksum, the checksum field is zeroed. 511 { For all the packet format details, refer to the PIM sparse-mode 512 specification.} 514 6.1 PIM-Hello Message 516 It is sent periodically by PIM routers on all interfaces. 518 6.2 PIM-SM-Register Message 520 Used in sparse-mode. Refer to PIM sparse-mode specification. 522 6.3 PIM-SM-Register-Stop Message 524 Used in sparse-mode. Refer to PIM sparse-mode specification. 526 6.4 Join/Prune Message 528 It is sent by routers toward upstream sources. A join creates 529 forwarding state and a prune destroys forwarding state. Refer to PIM 530 sparse-mode specification. 532 6.5 PIM-SM-Bootstrap Message 534 Used in sparse-mode. Refer to PIM sparse-mode specification. 536 6.6 PIM-Assert Message 538 The PIM-Assert message is sent when a multicast data packet is 539 received on an outgoing interface corresponding to the (S,G) or (*,G) 540 associated with the source. This message is used in both dense-mode 541 and sparse-mode PIM. For packet format, refer to PIM sparse-mode 542 specification. 544 6.7 PIM-Graft Message 546 This message is sent by a downstream router to a neighboring upstream 547 router to reinstate a previously pruned branch of a source tree. This 548 is done for dense-mode groups only. The format is the same as a 549 Join/Prune message, except that the value in the type field is 6. 551 6.8 PIM-Graft-Ack Message 553 Sent in response to a received Graft message. The Graft-Ack is only 554 sent if the interface in which the Graft was received is not the 555 incoming interface for the respective (S,G). This is done for dense- 556 mode groups only. The format is the same as Join/Prune message, except 557 that the value of the message type field is 7. 559 7 Acknowledgement 561 Thanks to Manoj Leelanivas, Sangeeta Mukherjee, Nitin Jain and many 562 members of the IDMR working group for their helpful comments. 564 8 References 566 [Deering91] S.E. Deering. Multicast Routing in a Datagram 567 Internetwork. PhD thesis, Electrical Engineering Dept., Stanford 568 University, December 1991. 570 [DVMRP] RFC 1075, Distance Vector Multicast Routing Protocol. 571 Waitzman, D., Partridge, C., Deering, S.E, November 1988 573 [PIMSM] Protocol Independent Multicast Sparse-Mode (PIM-SM): Protocol 574 Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. 575 Deering, M. Handley, V. Jacobson, C. Liu, P.Sharma, L. Wei draft- 576 ietf-idmr-pim-sm-specv2-00.txt. 578 [PIMARCH] An Architecture for Wide-Area Multicast Routing, S. Deering, 579 D. Estrin, D. Farinacci, V. Jacobson, G. Liu,L. Wei, USC Technical 580 Report, available from authors, Nov 1996. 582 [RFC1112] Host Extensions for IP Multicasting, Network Working Group, 583 RFC 1112, S. Deering, August 1989 585 9 Security Considerations 587 Security issues are not discussed in this memo. 589 10 Authors' Addresses 590 Stephen Deering 591 Cisco Systems Inc 592 170 West Tasman Drive, 593 San Jose, CA 95134 594 deering@cisco.com 596 Deborah Estrin 597 Computer Science Department/ISI 598 University of Southern California 599 Los Angeles, CA 90089 600 estrin@usc.edu 602 Dino Farinacci 603 cisco Systems Inc 604 170 West Tasman Drive 605 San Jose, CA 95134 606 dino@cisco.com 608 Van Jacobson 609 Lawrence Berkeley Laboratory 610 1 Cyclotron Road 611 Berkeley, CA 94720 612 van@ee.lbl.gov 614 Ahmed Helmy 615 Computer Science Department 616 University of Southern California 617 Los Angeles, CA 90089 618 ahelmy@catarina.usc.edu 620 David Meyer 621 cisco Systems, Inc 622 170 West Tasman Drive 623 San Jose, CA95134 624 meyer@cisco.com 626 Liming Wei 627 cisco Systems Inc 628 170 West Tasman Drive 629 San Jose, CA 95134 630 lwei@cisco.com