idnits 2.17.1 draft-ietf-pim-v2-dm-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-04-27) 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 15 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 248 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 ...' == (243 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 (Nov 3, 1998) is 9307 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 316, but not defined == Missing Reference: 'Neighbor-Timer' is mentioned on line 318, but not defined == Missing Reference: 'Data-Timeout' is mentioned on line 456, but not defined == Unused Reference: 'PIMARCH' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 588, 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-01.txt Nov 3, 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 broadcast of datagrams followed by pruning of unwanted branches is 93 often referred to as a broadcast-and-prune cycle, typical of dense 94 mode protocols. The broadcast-and-prune mechanism in dense mode PIM 95 uses a technique called reverse path forwarding (RPF), in which a 96 multicast datagram is forwarded if the receiving interface is the one 97 used to 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 broadcast-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. A source does not give any prior notifications to the 120 network when it sends multicast datagrams to a group G. If a receiving 121 router does not already have a forwarding entry, it creates it for the 122 source and group G. This forwarding entry is called a (S,G) entry. It 123 includes the following contents: source address, group address, the 124 incoming interface, a list of outgoing interfaces, a few flags and a 125 few 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 router should not populate a 167 forwarding entry's outgoing interface list with a leaf network 168 interface 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 an 177 assert process. Please see section 5.5 for more details. 179 A dense mode PIM implementation must take proper actions when a non- 180 leaf router becomes a leaf router. When the last PIM neighbor on an 181 interface goes away and turns the connected subnet into a leaf 182 network, the router should delete that interface from the outgoing 183 interface lists of all groups without attached group members. 185 5.2 Pruning of branches 187 5.2.1 Pruning on multi-access LANs and prune-override 189 To avoid PIM-Prune message storms, PIM-Prune messages must not be sent 190 on LANs in response to each received multicast packet that is 191 associated with an existing negative cache entry. 193 A prune is sent upstream when a router creates a (S,G) entry with an 194 empty outgoing interface list, or when the outgoing interface list 195 becomes empty. [*] 197 Prune information is flushed periodically. This causes multicast 198 datagrams to be sent in RPF mode again which in turn triggers prune 199 messages. 201 When a prune message is sent onto an upstream LAN, it is data link 202 multicast and IP addressed to the all PIM routers group address 203 224.0.0.13. The router to process the prune will be indicated by 204 inclusion of its address in the "Address" field of the message. This 205 address is obtained by an RPF look up for the source. When the prune 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 message is sent, the expected upstream router will schedule a deletion 212 request of the LAN from its outgoing interfaces for the (S,G) entry 213 from the prune list. The suggested delay time before deletion should 214 be greater than 3 seconds. The default prune delay time is 3 seconds. 216 Other routers on the LAN will hear the prune message and respond with 217 a join if they still expect multicast datagrams from the expected 218 upstream router. The PIM-Join message is data link multicast and IP 219 addressed to the all PIM routers group address 224.0.0.13. The router 220 to process the join will be indicated by inclusion of its address in 221 the "Address" field of the message. The address is determined by an 222 RPF lookup for the source. When the expected router receives the join 223 message, it will cancel the deletion request. This process is called 224 prune-override. 226 Routers that need to send prune-override joins will randomly generate 227 a join message delay timer. If a join is heard from another router 228 before a router sends its own, it will cancel sending its own join. 229 This will reduce control traffic on the LAN. The maximum join delay 230 timer should be equal to or smaller than the prune delay timer value. 231 The default is 3 seconds. 233 If the expected upstream router does not receive any PIM-Join messages 234 before the scheduled expiration time for the deletion request, it 235 prunes the outgoing LAN interface from the (S,G) multicast forwarding 236 entry. 238 However, if the prune-override join message is lost, the deletion will 239 occur and there will be no data delivery for the amount of time the 240 interface remains in prune state. To reduce the probability of this 241 occurance, a router that has scheduled to prune the interface off is 242 required to immediately send a prune onto the interface. This gives 243 other routers another chance to hear the prune, and to respond with a 244 join. 246 Additionally, equal-cost paths leading to a LAN presents a special 247 case for join/prune processing. When an upstream router is chosen by 248 an RPF lookup there may be equal-cost paths to reach the source. The 249 higher IP addressed system is always chosen. If the unicast routing 250 protocol does not store all available equal-cost paths in the routing 251 table, the "Address" field may contain the address of the wrong 252 upstream router. To avoid this situation, the "Address" field may 253 optionally be set to 0.0.0.0 which means that all upstream routers 254 (the ones that have the LAN as an outgoing interface for the (S,G) 255 entry) may process the packet. 257 5.2.2 Pruning a Point-to-point link 259 PIM-Prune messages received on a point to point link are not delayed 260 before processing as they are in the LAN procedure. If the prune is 261 received on an interface that is in the outgoing interface list, it is 262 deleted immediately. 264 Prunes may be rate-limited on point-to-point interfaces when a 265 multicast datagram is received for a negative cache entry, or if the 266 point-to-point interface receiving the datagram is not the RPF 267 interface toward the source. 269 5.3 New members joining an existing group 271 If a router is directly connected to a host that wants to become a 272 member of a group, the router may send a PIM-Graft message toward 273 known sources. This allows join latency to be reduced below that 274 indicated by the relatively large timeout value suggested for prune 275 information. 277 The host indicates its interest in group G by sending an IGMP report. 278 If a receiving router has state for group G, it adds the interface on 279 which the IGMP Report or PIM-Graft was received for all known (S,G)'s. 280 If the (S,G) entry was a negative cache entry, the router sends a 281 PIM-Graft message upstream toward S. 283 A router receiving the PIM-Graft message adds the received interface 284 into the matching (S,G) entry's outgoing interface list. If the entry 285 transitions to forward state due to this added outgoing interface, the 286 router must send a PIM-Graft message toward the source. 288 Routers with no group state do nothing on receipt of IGMP reports, 289 since dense-mode PIM will deliver multicast datagrams to all 290 interfaces when creating state for a group. 292 PIM-Graft message is the only PIM message that uses a positive 293 acknowledgment strategy. Senders of PIM-Graft messages unicast them to 294 their upstream RPF neighbors. The neighbor processes each (S,G) and 295 immediately acknowledges each (S,G) in a PIM-GraftAck message. This is 296 relatively easy, since the receiver simply changes the PIM message 297 type from Graft to Graft-Ack and unicasts the original packet back to 298 the source. The sender periodically retransmits the PIM-Graft message 299 for any (S,G) that has not been acknowledged. The interval between 300 each retransmission is 3 seconds. Note that the sender need not keep a 301 retransmission list for each neighbor since PIM-Grafts are only sent 302 to the RPF neighbor. Only the (S,G) entry needs to be tagged for 303 retransmission. 305 5.4 Designated Router Election 307 Dense mode PIM itself does not need the function of a designated 308 router (DR). But a DR is needed on multi-access LANs running IGMP 309 version 1, which relies on a routing protocol to select a query router 310 for the purpose of sending IGMP Host-Query messages. Dense-mode PIM 311 designated router (DR) election has the same procedure sparse-mode PIM 312 uses. 314 Each PIM router connected to a multi-access LAN should periodicly 315 transmit PIM-Hello messages onto the LAN. The period is specified as 316 [Hello-Timer] in the sparse mode specification (default 30 seconds). 317 The highest IP addressed router becomes the DR. The discovered PIM 318 routers should be timed out after 105 seconds (the [Neighbor-Timer] in 319 the PIM-SM specification]. If the DR goes down, a new DR is elected. 321 DR election is only necessary on multi-access networks. 323 5.5 Parallel paths to a source 325 Two or more routers may receive the same multicast datagram that was 326 replicated upstream. In particular, if two routers have equal cost 327 paths to a source and are connected on a common multi-access network, 328 duplicate datagrams will travel downstream onto the LAN. Dense-mode 329 PIM will detect such a situation and will not let it persist. 331 If a router receives a multicast datagram on an outgoing interface on 332 a multi-access LAN, the packet must be a duplicate. In this case a 333 single forwarder must be elected. Using PIM Assert messages addressed 334 to 224.0.0.13 on the LAN, upstream routers can decide which one 335 becomes the forwarder. Downstream routers listen to the Asserts so 336 they know which one was elected (typically this is the same as the 337 downstream router's RPF neighbor but there are circumstances when 338 using different unicast protocols where this might not be the case). 340 The upstream router elected is the one that has the best metric to the 341 source. When a packet is received on an outgoing interface, a router 342 will send an Assert packet on the LAN indicating what metric it uses 343 to reach the source of the data packet. If metrics are comparable, the 344 router with the best metric will become the forwarder. Incomparable 345 metrics will be discussed later in this section when metric preference 346 is described. All other upstream routers will delete the interface 347 from their outgoing interface list. The downstream routers also do the 348 comparison in case the forwarder is different than the RPF neighbor. 349 This is important so downstream routers send subsequent Prunes or 350 Grafts to the correct neighbor. 352 Associated with the metric is a metric preference value. This is 353 provided to deal with the case where the upstream routers may run 354 different unicast routing protocols. The numerically smaller metric 355 preference is always preferred. The metric preference should be 356 treated as the high-order part of an Assert metric comparison. 357 Therefore, a metric value can be compared with another metric value 358 provided both metric preferences are the same. A metric preference can 359 be assigned per unicast routing protocol and needs to be consistent 360 for all PIM routers on the LAN. 362 Asserts are rate-limited. The recommended minimum interval between two 363 subsequent asserts out the same outgoing interface of an (S,G) entry 364 is 1 second. 366 The following Assert rules must be observed: 368 Multicast packet received on outgoing interface: 370 1 Do unicast routing table lookup on source IP address from data 371 packet. 373 2 Send Assert on interface for source IP address from data packet. 374 The assert message includes metric preference of routing protocol 375 and metric from routing table lookup. 377 3 If route is not found, Use metric preference of 0x7fffffff and 378 metric 0xffffffff. 380 Asserts received on outgoing interface: 382 1 Compare metric received in Assert with the one you would have 383 advertised in an Assert. If the value in the Assert is less than 384 your value, prune the interface. If the value is the same, and 385 your address is less than the Assert sender, prune the interface. 387 2 If you have won the election and there are directly connected 388 members on the LAN, keep the interface in your outgoing interface 389 list. You are the forwarder for the LAN. 391 3 If you have won the election but there are no directly connected 392 members on the LAN, schedule to prune the interface. The LAN might 393 be a stub LAN with no members (and no downstream routers). If no 394 subsequent Joins are received, delete the interface from the 395 outgoing interface list. Otherwise keep the interface in your 396 outgoing interface. You are the forwarder for the LAN. 398 4 The assert winner sends an assert with its own metric on the LAN, 399 so that all other routers know who the winner is. 401 Asserts received on incoming interface: 403 1 Downstream routers will select the upstream router with the 404 smallest metric as their RPF neighbor. If two metrics are the 405 same, the highest IP address is chosen to break the tie. 407 If the upstream router selected is different from the RPF neighbor 408 selected natively, it should start an Assert-Timer. When this 409 timer expires, it restores the RPF information obtained by the RPF 410 lookup. 412 2 If the downstream routers have downstream members, they must 413 schedule a join to inform the upstream router packets should be 414 forwarded on the LAN. This will cause the upstream forwarder to 415 cancel its delayed pruning of the interface. 417 3 Whent he assert state times out, the downstream router may switch 418 from the assert winner to the original RPF neighbor, if different. 420 5.6 Timers in Multicast Forwarding Entries 422 An (S,G) entry has a number of associated timers. One for the 423 multicast routing entry itself, one for each pruned interface in the 424 outgoing interface list and one to time out information about upstream 425 assert winner (Assert_timer). An outgoing interface in forward state 426 does not time out or change state without external events. The 427 outgoing interface stays in forward state in the list as long as there 428 is a group member connected, or there is a downstream PIM neighbor 429 that has not sent a prune to it. The interface is deleted from the 430 outgoing interface list if it is on a leaf network and there is no 431 connected member. The interface timer for a pruned interface should be 432 started with the holdtime in the prune message (also referred to as 433 the prune timer). 435 When a (S,G) entry is in forwarding state, its expiration timer is set 436 to [Data-Timeout], as specified in the companion sparse mode 437 specification [PIMSM], which is 210 seconds by default. This timer is 438 restarted when a data packet is being forwarded. The (S,G) entry is 439 deleted if this timer expires. 441 Once all interfaces in the outgoing interface list are pruned, the 442 (S,G)'s expiration timer should be set to the maximum prune timer 443 among all its outgoing interfaces. During this time the entry is known 444 as a negative cache entry. 446 If the prune timers on different outgoing interfaces are different, 447 the pruned interface with the shortest remaining timer may expire 448 first and turn the negative cache entry into forwarding state. When 449 this happens, a graft should be triggered upstream. When a negative 450 cache entry turns into a forward entry, the entry timer should be 451 restarted with the default expiration timer. Once the (S,G) entry 452 times out, it will be recreated when the next multicast packet or join 453 arrives. 455 The prune message sent upstream contains a holdtime. Its default value 456 is [Data-Timeout], except when the Assert timer is also running, the 457 holdtime in the prune message is set to the smaller value between the 458 prune holdtime the system uses, and the remaining assert timer value 459 before its expiration. The Assert Timer is started with a default 460 value of 210 seconds. 462 5.7 Adapting to unicast route changes 464 When unicast route changes occur, the RPF interface for many (S,G) 465 entries will also change. The following should be done for the 466 affected entries: 468 1 A prune should be sent toward the old incoming interface; 470 2 A graft should be sent to the new RPF neighbor. 472 6 Packet Formats 474 This section describes the details of the packet formats for PIM 475 control messages. 477 All PIM control messages have protocol number 103. 479 Basically, PIM messages are either unicast (e.g. Registers and 480 Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group 481 `224.0.0.13' (e.g. Join/Prune, Asserts, etc.). 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |PIM Ver| Type | reserved | Checksum | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 PIM Ver 490 PIM Version number is 2. 492 Type Types for specific PIM messages. PIM Types are: 494 0 = Hello 495 1 = Register 496 2 = Register-Stop 497 3 = Join/Prune 498 4 = Bootstrap 499 5 = Assert 500 6 = Graft (used in PIM-DM only) 501 7 = Graft-Ack (used in PIM-DM only) 502 8 = Candidate-RP-Advertisement 504 Reserved 505 Set to zero. Ignored upon receipt. 507 Checksum 508 The checksum is the 16-bit one's complement of the one's 509 complement sum of the entire PIM message. For computing the 510 checksum, the checksum field is zeroed. 512 { For all the packet format details, refer to the PIM sparse-mode 513 specification.} 515 6.1 PIM-Hello Message 517 It is sent periodically by PIM routers on all interfaces. 519 6.2 PIM-SM-Register Message 521 Used in sparse-mode. Refer to PIM sparse-mode specification. 523 6.3 PIM-SM-Register-Stop Message 525 Used in sparse-mode. Refer to PIM sparse-mode specification. 527 6.4 Join/Prune Message 529 It is sent by routers toward upstream sources. A join creates 530 forwarding state and a prune destroys forwarding state. Refer to PIM 531 sparse-mode specification. 533 6.5 PIM-SM-Bootstrap Message 535 Used in sparse-mode. Refer to PIM sparse-mode specification. 537 6.6 PIM-Assert Message 539 The PIM-Assert message is sent when a multicast data packet is 540 received on an outgoing interface corresponding to the (S,G) or (*,G) 541 associated with the source. This message is used in both dense-mode 542 and sparse-mode PIM. For packet format, refer to PIM sparse-mode 543 specification. 545 6.7 PIM-Graft Message 547 This message is sent by a downstream router to a neighboring upstream 548 router to reinstate a previously pruned branch of a source tree. This 549 is done for dense-mode groups only. The format is the same as a 550 Join/Prune message, except that the value in the type field is 6. The 551 source address hsould be included in teh join section of the message. 552 The holdtime field is unused, and is ignored when a graft is received. 554 6.8 PIM-Graft-Ack Message 556 Sent in response to a received Graft message. The Graft-Ack is only 557 sent if the interface in which the Graft was received is not the 558 incoming interface for the respective (S,G). This is done for dense- 559 mode groups only. The format is the same as Join/Prune message, except 560 that the value of the message type field is 7. The ``Encoded-Unicast- 561 Upstream Neighbor Address'' field is unused and needs not be checked 562 when this message is received. The holdtime field in the packet is 563 ignored when received. 565 7 Acknowledgement 567 Thanks to Manoj Leelanivas, Sangeeta Mukherjee, Nitin Jain and many 568 members of the PIM/IDMR working group for their helpful comments. 570 8 References 572 [Deering91] S.E. Deering. Multicast Routing in a Datagram 573 Internetwork. PhD thesis, Electrical Engineering Dept., Stanford 574 University, December 1991. 576 [DVMRP] RFC 1075, Distance Vector Multicast Routing Protocol. 577 Waitzman, D., Partridge, C., Deering, S.E, November 1988 579 [PIMSM] Protocol Independent Multicast Sparse-Mode (PIM-SM): Protocol 580 Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. 581 Deering, M. Handley, V. Jacobson, C. Liu, P.Sharma, L. Wei draft- 582 ietf-idmr-pim-sm-specv2-00.txt. 584 [PIMARCH] An Architecture for Wide-Area Multicast Routing, S. Deering, 585 D. Estrin, D. Farinacci, V. Jacobson, G. Liu,L. Wei, USC Technical 586 Report, available from authors, Nov 1996. 588 [RFC1112] Host Extensions for IP Multicasting, Network Working Group, 589 RFC 1112, S. Deering, August 1989 591 9 Security Considerations 593 Security issues are not discussed in this memo. 595 10 Authors' Addresses 596 Stephen Deering 597 Cisco Systems Inc 598 170 West Tasman Drive, 599 San Jose, CA 95134 600 deering@cisco.com 602 Deborah Estrin 603 Computer Science Department/ISI 604 University of Southern California 605 Los Angeles, CA 90089 606 estrin@usc.edu 608 Dino Farinacci 609 cisco Systems Inc 610 170 West Tasman Drive 611 San Jose, CA 95134 612 dino@cisco.com 614 Van Jacobson 615 Lawrence Berkeley Laboratory 616 1 Cyclotron Road 617 Berkeley, CA 94720 618 van@ee.lbl.gov 620 Ahmed Helmy 621 Computer Science Department 622 University of Southern California 623 Los Angeles, CA 90089 624 ahelmy@catarina.usc.edu 626 David Meyer 627 cisco Systems, Inc 628 170 West Tasman Drive 629 San Jose, CA95134 630 meyer@cisco.com 632 Liming Wei 633 cisco Systems Inc 634 170 West Tasman Drive 635 San Jose, CA 95134 636 lwei@cisco.com