idnits 2.17.1 draft-ietf-pim-v2-dm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 255 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 ** 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 396: '...he assert winner SHOULD send an assert...' RFC 2119 keyword, line 480: '... PIM Hello messages SHOULD carry a...' RFC 2119 keyword, line 482: '... number, that MUST be different ...' RFC 2119 keyword, line 490: '...that interface SHOULD be turned in...' RFC 2119 keyword, line 492: '... MUST be sent to the upstream RPF nei...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 19 has weird spacing: '...), its areas...' == Line 20 has weird spacing: '...ups may also ...' == Line 24 has weird spacing: '... and may be...' == Line 25 has weird spacing: '...opriate to u...' == Line 37 has weird spacing: '...lticast group...' == (250 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 (May 18, 1999) is 9109 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 313, but not defined == Missing Reference: 'Neighbor-Timer' is mentioned on line 315, but not defined == Missing Reference: 'Data-Timeout' is mentioned on line 454, but not defined == Unused Reference: 'PIMARCH' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 628, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMAU' Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 5 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 (Cisco) 5 Ahmed Helmy (USC) 6 David Meyer (Cisco) 7 Liming Wei (Cisco) 9 draft-ietf-pim-v2-dm-02.txt May 18, 1999 11 Protocol Independent Multicast Version 2 Dense Mode Specification 13 Status of This Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as work in progress. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 1 Introduction 36 This specification defines a multicast routing algorithm efficient for 37 multicast groups that are densely distributed across a network. This 38 protocol does not have a topology discovery mechanism often used by a 39 unicast routing protocol. It employs the same packet formats sparse- 40 mode PIM [PIMSM] uses. This protocol is called dense-mode PIM. The 41 foundation of this design was largely built on Deering's early work on 42 IP multicast routing [Deering91]. 44 2 Terminology 46 The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL 47 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and 48 ``OPTIONAL'' in this document are to be interpreted as described in 49 RFC 2119. 51 3 Glossary 53 Reverse Path Forwarding (RPF) / RPF interface / RPF lookup 55 RPF is a multicast forwarding mode where a data packet is 56 accepted for forwarding if it is received on an interface 57 used to reach the source in unicast. The interface passing 58 this check is called the RPF interface. 60 An RPF lookup for a source returns the RPF interface and the 61 next-hop information, as if a route lookup is done for the 62 source on a unicast routing table. 64 Topology Discovery Mechanism/Protocol 66 This mechanism provides sufficient topological information 67 for a router to determine whether a neighbor system is 68 upstream with respect to each multicast source. Some topology 69 discovery mechanism can also determine if a neighbor is 70 downstream with respect to each multicast source. An existing 71 unicast routing protocol or a clone of it is sometimes used 72 for this purpose (such as in DVMRP[DVMRP]). When a multicast 73 routing protocol has a topology discovery mechanism built-in, 74 the topology discovery mechanism is sometimes referred to as 75 the unicast routing part of the protocol (even though it is 76 not used for forwarding unicast packets). 78 4 PIM-DM Protocol Overview 80 Dense-mode PIM assumes that when a source starts sending, all 81 downstream systems want to receive multicast datagrams. Initially, 82 multicast datagrams are flooded to all areas of the network. If some 83 areas of the network do not have group members, dense-mode PIM will 84 prune off the forwarding branch by setting up prune state. The prune 85 state has an associated timer, which on expiration will turn into 86 forward state, allowing data to go down the branch previously in prune 87 state. 89 The prune state contains source and group address information. When a 90 new member appears in a pruned area, a router can ``graft'' toward the 91 source for the group, turning the pruned branch into forward state. 93 The forwarding branches form a tree rooted at the source leading to 94 all members of the group. This tree is called a source rooted tree. 96 The broadcast of datagrams followed by pruning of unwanted branches is 97 often referred to as a broadcast-and-prune cycle, typical of dense 98 mode protocols. The broadcast-and-prune mechanism in dense mode PIM 99 uses a technique called reverse path forwarding (RPF), in which a 100 multicast datagram is forwarded if the receiving interface is the one 101 used to forward unicast datagrams to the source of the datagram. 103 Compared with multicast routing protocols with built-in topology 104 discovery mechanisms (e.g. DVMRP with its own RIP-like ``unicast'' 105 routing protocol), dense mode PIM has simplified design, and is not 106 hard-wired into a specific type of topology discovery protocol. 107 However, such simplification does incur more overhead and cause 108 broadcast-and-prune to occur on some links that could be avoided if 109 sufficient topology information is available, e.g. to decide whether 110 each interface leads to any downstream neighbors for a particular 111 source. We chose to accept the additional overhead in favor of the 112 simplification and flexibility gained by not depending on a specific 113 type of topology discovery protocol. 115 In relation to sparse-mode PIM, dense-mode PIM differs in two 116 essential ways: 1) there are no periodic joins transmitted, only 117 explicit triggered grafts/prunes, and 2) there is no Rendezvous Point 118 (RP). 120 5 Protocol Description 122 Dense mode PIM initiates forwarding state in routers when a source 123 begins to send. A source does not give any prior notifications to the 124 network when it sends multicast datagrams to a group G. If a receiving 125 router does not already have a forwarding entry, it creates it for the 126 source and group G. This forwarding entry is called a (S,G) entry. It 127 includes the following contents: source address, group address, the 128 incoming interface, a list of outgoing interfaces, a few flags and a 129 few timers. The incoming interface for (S,G) is determined by an RPF 130 lookup in the unicast routing table. The (S,G) outgoing interface list 131 contains interfaces that have PIM routers present or host members for 132 group G. 134 If a router creates a (S,G) entry with an empty outgoing interface 135 list after receiving a multicast datagram, it must trigger a PIM-Prune 136 message toward the source S. This type of entry is called a negative 137 cache entry. Negative cache entries can be found on leaf routers with 138 no local group members, or on routers where prune messages were 139 received from downstream routers that caused the outgoing interface 140 list to become NULL. 142 Dense mode PIM routers send periodic Hello messages out of each 143 interface and keep track of neighbors based on received Hello 144 messages. The Hello message has a Holdtime field that tells the 145 neighbor to delete neighbor information if it is not refreshed before 146 expiration. 148 The following sections describe in detail how leaf network is defined 149 and detected; how pruning is done on multi-access LANs; and actions 150 related to new members joining an existing group; issues with 151 designated router election; parallel path resolution; multicast 152 forwarding entry expiration and the adaptation to topology changes. 154 5.1 Leaf network detection 156 In dense mode PIM, prune state is first instantiated on routers 157 connected to leaf networks without group members. A network on a 158 router interface is deemed a leaf if there is no other PIM neighbors 159 on that network. The notion of leaf network here might be slightly 160 different from that defined in other protocols. [*] 161 _________________________ 162 [*] E.g. In DVMRP a leaf network for a source is 163 defined as one without downstream neighbor DVMRP 164 routers. Each DVMRP router is able to decide whether it 165 has a downstream DVMRP neighbor with respect to each 166 source. This is due to the RIP-like mechanism used in 167 A router determines it is a leaf by not receiving PIM Hello messages. 168 A leaf router can detect that there are no members downstream when it 169 is the only router on a network and there are no IGMP Host-Report 170 messages received from hosts. A router should not populate a 171 forwarding entry's outgoing interface list with a leaf network 172 interface without downstream members. 174 It should be noted that a non-leaf router in PIM dense-mode is not 175 necessarily a non-leaf node on a particular multicast forwarding tree. 176 There are topologies where two parallel routers are connected to a 177 common LAN where none of the routers uses the other one to reach a 178 source. Therefore both routers will be leaves of the shortest path 179 tree rooted at the source. When there are no group members on this 180 LAN, both routers must not forward packets onto it. This is achieved 181 by an assert process. See section 5.5 for more details. 183 A dense mode PIM implementation must take proper actions when a non- 184 leaf router becomes a leaf router. When the last PIM neighbor on an 185 interface goes away and turns the connected subnet into a leaf 186 network, the router should delete that interface from the outgoing 187 interface lists of all groups without attached group members. 189 5.2 Pruning of branches 191 5.2.1 Pruning on multi-access LANs and prune-override 193 To avoid PIM Prune message storms, PIM Prune messages must not be sent 194 on LANs in response to each received multicast packet that is 195 associated with an existing negative cache entry. 197 A prune is sent upstream when a router creates a (S,G) negative cache 198 entry, or when the entry turns into a negative cache. Prune 199 information is flushed periodically. This causes multicast datagrams 200 to be sent in RPF mode again which in turn triggers prune 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 address is obtained by an RPF look up for the source. When the prune 207 message is sent, the expected upstream router will schedule a prune 208 request of the LAN from its outgoing interfaces for the (S,G) entry. 209 The suggested default delay time before deletion is 3 seconds. 211 _________________________ 212 its topology discovery (or ``unicast routing'') 213 protocol. 215 Other routers on the LAN will hear the prune message and respond with 216 a join if they still expect multicast datagrams from the expected 217 upstream router. The Join message is data link multicast and IP 218 addressed to the all PIM routers group address 224.0.0.13. The router 219 to process the join will be indicated by inclusion of its address in 220 the "Address" field of the message. The address is determined by an 221 RPF lookup for the source. When the expected router receives the join 222 message, it will cancel the prune request. This process is called 223 prune-override. 225 Routers that need to send prune-override joins will randomly generate 226 a join message delay timer. If a join is heard from another router 227 before a router sends its own, it will cancel sending its own join. 228 This will reduce control traffic on the LAN. The maximum join delay 229 timer should be equal to or smaller than the prune delay timer value. 230 The default is 3 seconds. 232 If the expected upstream router does not receive any PIM Join messages 233 before the scheduled expiration time for the deletion request, it 234 prunes the outgoing LAN interface from the (S,G) multicast forwarding 235 entry. 237 However, if the prune-override join message is lost, the deletion will 238 occur and there will be no data delivery for the amount of time the 239 interface remains in prune state. To reduce the probability of this 240 occurence, a router that has scheduled to prune the interface off 241 should immediately send a prune onto the interface. This gives other 242 routers another chance to hear the prune, and to respond with a join. 244 Additionally, equal-cost paths leading to a LAN presents a special 245 case for join/prune processing. When an upstream router is chosen by 246 an RPF lookup there may be equal-cost paths to reach the source. The 247 higher IP addressed system is always chosen. If the unicast routing 248 protocol does not store all available equal-cost paths in the routing 249 table, the "Address" field may contain the address of the wrong 250 upstream router. To avoid this situation, the "Address" field may 251 optionally be set to 0.0.0.0 which means that all upstream routers 252 (the ones that have the LAN as an outgoing interface for the (S,G) 253 entry) may process the packet. 255 5.2.2 Pruning a Point-to-point link 257 Prune messages received on a point to point link are not delayed 258 before processing as they are in the LAN procedure. If the prune is 259 received on an interface in the outgoing interface list, it is pruned 260 immediately. 262 Prunes may be rate-limited on point-to-point interfaces when a 263 multicast datagram is received for a negative cache entry, or if the 264 point-to-point interface receiving the datagram is not the RPF 265 interface toward the source. 267 5.3 New members joining an existing group 269 If a router is directly connected to a host that wants to become a 270 member of a group, the router may send a Graft message toward known 271 sources. This allows join latency to be reduced below that indicated 272 by the relatively large timeout value suggested for prune information. 274 The host indicates its interest in group G by sending an IGMP report. 275 If a receiving router has state for group G, it adds the interface on 276 which the IGMP Report or Graft was received for all known (S,G)'s. If 277 the (S,G) entry was a negative cache entry, the router sends a Graft 278 message upstream toward S. 280 A router receiving the Graft message adds the received interface into 281 the matching (S,G) entry's outgoing interface list. If the entry 282 transitions to forward state due to this added outgoing interface, the 283 router must send a Graft message toward the source. 285 Routers with no group state do nothing on receipt of IGMP reports, 286 since dense-mode PIM will deliver multicast datagrams to all 287 interfaces when creating state for a group. 289 Graft message is the only PIM message that uses a positive 290 acknowledgment strategy. Senders of Graft messages unicast them to 291 their upstream RPF neighbors. The neighbor processes each (S,G) and 292 immediately acknowledges each (S,G) in a GraftAck message. This is 293 relatively easy, since the receiver simply changes the PIM message 294 type from Graft to Graft-Ack and unicasts the original packet back to 295 the source. The sender periodically retransmits the Graft message for 296 any (S,G) that has not been acknowledged. The interval between each 297 retransmission is 3 seconds. Note that the sender need not keep a 298 retransmission list for each neighbor since Grafts are only sent to 299 the RPF neighbor. Only the (S,G) entry needs to be tagged for 300 retransmission. 302 5.4 Designated Router Election 304 Dense mode PIM itself does not need the function of a designated 305 router (DR). But a DR is needed on multi-access LANs running IGMP 306 version 1, which relies on a routing protocol to select a query router 307 for the purpose of sending IGMP Host-Query messages. Dense-mode PIM 308 designated router (DR) election has the same procedure sparse-mode PIM 309 uses. 311 Each PIM router connected to a multi-access LAN should periodically 312 transmit Hello messages onto the LAN. The period is specified as 313 [Hello-Timer] in the sparse mode specification (default 30 seconds). 314 The highest IP addressed router becomes the DR. The discovered PIM 315 routers should be timed out after [Neighbor-Timer] (default 105 316 seconds) in the PIM-SM specification. If the DR goes down, a new DR is 317 elected. 319 DR election is only necessary on multi-access networks. 321 5.5 Parallel paths to a source 323 Two or more routers may receive the same multicast datagram replicated 324 upstream. In particular, if two routers have equal cost paths to a 325 source and are connected on a common multi-access network, duplicate 326 datagrams will travel downstream onto the LAN. Dense-mode PIM will 327 detect such a situation and will not let it persist. 329 If a router receives a multicast datagram on an outgoing interface on 330 a multi-access LAN, the packet must be a duplicate. In this case a 331 single forwarder must be elected. The upstream routers can decide 332 which one becomes the forwarder, using Assert messages addressed to 333 224.0.0.13 on the LAN. Downstream routers listen to the Asserts so 334 they know which one was elected (typically this is the same as the 335 downstream router's RPF neighbor but there are circumstances when 336 using different unicast protocols where this might not be the case). 338 The upstream router elected is the one that has the best metric to the 339 source. When a packet is received on an outgoing interface, a router 340 will send an Assert packet on the LAN indicating what metric it uses 341 to reach the source of the data packet. If metrics are comparable, the 342 router with the best metric will become the forwarder. Incomparable 343 metrics will be discussed later in this section when metric preference 344 is described. All other upstream routers will prune the interface from 345 their outgoing interface list. The downstream routers also do the 346 comparison in case the forwarder is different than the RPF neighbor. 347 This is important so downstream routers send subsequent Prunes or 348 Grafts to the correct neighbor. 350 Associated with the metric is a metric preference value. This is 351 provided to deal with the case where the upstream routers may run 352 different unicast routing protocols. The numerically smaller metric 353 preference is always preferred. The metric preference should be 354 treated as the high-order part of an Assert metric comparison. 355 Therefore, a metric value can be compared with another metric value 356 provided both metric preferences are the same. A metric preference can 357 be assigned per unicast routing protocol and needs to be consistent 358 for all PIM routers on the LAN. 360 Asserts are rate-limited. The recommended minimum interval between two 361 subsequent asserts out the same outgoing interface of an (S,G) entry 362 is 1 second. 364 The following Assert rules must be observed: 366 Multicast packet received on outgoing interface: 368 1 Do unicast routing table lookup on source IP address from data 369 packet. 371 2 Send Assert on interface for source IP address from data packet. 372 The assert message includes metric preference of routing protocol 373 and metric from routing table lookup. 375 3 If route is not found, Use metric preference of 0x7fffffff and 376 metric 0xffffffff. 378 Asserts received on outgoing interface: 380 1 Compare metric received in Assert with the one you would have 381 advertised in an Assert. If the value in the Assert is less than 382 your value, prune the interface. If the value is the same, and 383 your address is less than the Assert sender, prune the interface. 385 2 If you have won the election and there are directly connected 386 members on the LAN, keep the interface in your outgoing interface 387 list. You are the forwarder for the LAN. 389 3 If you have won the election but there are no directly connected 390 members on the LAN, schedule to prune the interface. The LAN might 391 be a stub LAN with no members (and no downstream routers). If no 392 subsequent Joins are received, prune the interface from the 393 outgoing interface list. Otherwise keep the interface in your 394 outgoing interface. You are the forwarder for the LAN. 396 4 The assert winner SHOULD send an assert with its own metric on the 397 LAN, so that all other routers know who the winner is. 399 Asserts received on incoming interface: 401 1 Downstream routers will select the upstream router with the 402 smallest metric as their RPF neighbor. If two metrics are the 403 same, the highest IP address is chosen to break the tie. 405 If the upstream router selected is different from the RPF neighbor 406 selected natively, it should start an Assert-Timer. When this 407 timer expires, it restores the RPF information obtained by the RPF 408 lookup. 410 2 If the downstream routers have downstream members, they must 411 schedule a join to inform the upstream router packets should be 412 forwarded on the LAN. This will cause the upstream forwarder to 413 cancel its delayed pruning of the interface. 415 3 When the assert state times out, the downstream router may switch 416 from the assert winner to the original RPF neighbor, if different. 418 5.6 Timers in Multicast Forwarding Entries 420 An (S,G) entry has a number of associated timers. One for the 421 multicast routing entry itself, one for each pruned interface in the 422 outgoing interface list and one to time out information about upstream 423 assert winner (Assert_timer). An outgoing interface in forward state 424 does not time out or change state without external events. The 425 outgoing interface stays in forward state in the list as long as there 426 is a group member connected, or there is a downstream PIM neighbor 427 that has not sent a prune to it. The interface is deleted from the 428 outgoing interface list if it is on a leaf network and there is no 429 connected member. The interface timer for a pruned interface should be 430 started with the holdtime in the prune message (also referred to as 431 the prune timer). 433 When a (S,G) entry is in forwarding state, its expiration timer is set 434 to [Data-Timeout], as specified in the companion sparse mode 435 specification [PIMSM], default is 210 seconds. This timer is restarted 436 when a data packet is forwarded. The (S,G) entry is deleted when this 437 timer expires. 439 Once all interfaces in the outgoing interface list are pruned, the 440 (S,G)'s expiration timer should be set to the maximum prune timer 441 among all its outgoing interfaces. During this time the entry is known 442 as a negative cache entry. 444 If the prune timers on different outgoing interfaces are different, 445 the pruned interface with the shortest remaining timer may expire 446 first and turn the negative cache entry into forwarding state. When 447 this happens, a graft should be triggered upstream. When a negative 448 cache entry turns into a forward entry, the entry timer should be 449 restarted with the default expiration timer. Once the (S,G) entry 450 times out, it will be recreated when the next multicast packet or join 451 arrives. 453 The prune message sent upstream contains a holdtime. Its default value 454 is [Data-Timeout], except when the Assert timer is also running, the 455 holdtime in the prune message is set to the smaller value between the 456 prune holdtime the system uses, and the remaining assert timer value 457 before its expiration. The Assert Timer is started with a default 458 value of 210 seconds. 460 5.7 Adapting to unicast route changes 462 When unicast route changes occur, the RPF interface for many (S,G) 463 entries will also change. The following should be done for the 464 affected entries: 466 1 A prune should be sent toward the old incoming interface; 468 2 A graft should be sent to the new RPF neighbor. 470 6 Generation Identifier (GenID) 472 When a router goes offline and restarts, it loses all multicast 473 forwarding state. If the upstream router has (S,G) entries in forward 474 state, data will come down and recreate state in the restarted router. 475 However, if the upstream router is in negative cache state, no data 476 packet can flow down until the upstream negative cache state expires. 477 This results in join latencies for new members joining after the 478 router went down. 480 To reduce this join latency, all PIM Hello messages SHOULD carry a 481 ``Generation ID''(GenID) option. The GenID is a randomly generated 482 32-bit number, that MUST be different between different router 483 reloads. 485 When a new GenID is detected from a PIM neighbor, the local router 486 will need to go through its multicast forwarding table, and attempt to 487 recover the prune state for the PIM neighbor. 489 If a new GenID is received on a pruned outgoing interface of a (S,G) 490 entry, that interface SHOULD be turned into forward state. If the 491 (S,G) entry transitions into forward state from pruned state, a graft 492 MUST be sent to the upstream RPF neighbor. 494 If the new GenID is sent by the RPF neighbor of a negative cache (S,G) 495 entry, a (S,G) prune SHOULD be immediately sent to that RPF neighbor, 496 as if the local state just transitioned into prune state. 498 7 Packet Formats 500 This section describes the details of the packet formats for PIM 501 control messages. 503 All PIM control messages have protocol number 103. 505 Basically, PIM messages are either unicast (e.g. Registers and 506 Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group 507 `224.0.0.13' (e.g. Join/Prune, Asserts, etc.). 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 |PIM Ver| Type | reserved | Checksum | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 PIM Ver 516 PIM Version number is 2. 518 Type Types for specific PIM messages. PIM Types are: 520 0 = Hello 521 1 = Register 522 2 = Register-Stop 523 3 = Join/Prune 524 4 = Bootstrap 525 5 = Assert 526 6 = Graft (used in PIM-DM only) 527 7 = Graft-Ack (used in PIM-DM only) 528 8 = Candidate-RP-Advertisement 530 Reserved 531 Set to zero. Ignored upon receipt. 533 Checksum 534 The checksum is the 16-bit one's complement of the one's 536 complement sum of the entire PIM message. For computing the 537 checksum, the checksum field is zeroed. 539 { For all the packet format details, refer to the PIM sparse-mode 540 specification.} 542 7.1 PIM-Hello Message 544 It is sent periodically by PIM routers on all interfaces. 546 The Generation ID option has OptionType of 20, and OptionLength of 4. 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | OptionType = 20 (GenID) | OptionLength = 4 | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Random Number | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 7.2 PIM-SM-Register Message 556 Used in sparse-mode. Refer to PIM sparse-mode specification. 558 7.3 PIM-SM-Register-Stop Message 560 Used in sparse-mode. Refer to PIM sparse-mode specification. 562 7.4 Join/Prune Message 564 It is sent by routers toward upstream sources. A join creates 565 forwarding state and a prune destroys forwarding state. Refer to PIM 566 sparse-mode specification. 568 7.5 PIM-SM-Bootstrap Message 570 Used in sparse-mode. Refer to PIM sparse-mode specification. 572 7.6 PIM-Assert Message 574 The PIM-Assert message is sent when a multicast data packet is 575 received on an outgoing interface corresponding to the (S,G) or (*,G) 576 associated with the source. This message is used in both dense-mode 577 and sparse-mode PIM. For packet format, refer to PIM sparse-mode 578 specification. 580 7.7 PIM-Graft Message 582 This message is sent by a downstream router to a neighboring upstream 583 router to reinstate a previously pruned branch of a source tree. This 584 is done for dense-mode groups only. The format is the same as a 585 Join/Prune message, except that the value in the type field is 6. The 586 source address should be included in the join section of the message. 587 The holdtime field is unused, and is ignored when a graft is received. 589 7.8 PIM-Graft-Ack Message 591 Sent in response to a received Graft message. The Graft-Ack is only 592 sent if the interface in which the Graft was received is not the 593 incoming interface for the respective (S,G). This is done for dense- 594 mode groups only. The format is the same as Join/Prune message, except 595 that the value of the message type field is 7. The ``Encoded-Unicast- 596 Upstream Neighbor Address'' field is unused and needs not be checked 597 when this message is received. The holdtime field in the packet is 598 ignored when received. 600 8 Security Considerations 602 Security issues are discussed in detail in the companion document 603 ``Authenticating PIM Version 2 Messages'' [PIMAU]. 605 9 Acknowledgement 607 Thanks to Manoj Leelanivas, Sangeeta Mukherjee, Nitin Jain and many 608 members of the PIM/IDMR working group for their helpful comments. 610 10 References 612 [Deering91] S.E. Deering. Multicast Routing in a Datagram 613 Internetwork. PhD thesis, Electrical Engineering Dept., Stanford 614 University, December 1991. 616 [DVMRP] RFC 1075, Distance Vector Multicast Routing Protocol. 617 Waitzman, D., Partridge, C., Deering, S.E, November 1988 619 [PIMSM] Protocol Independent Multicast Sparse-Mode (PIM-SM): Protocol 620 Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. 621 Deering, M. Handley, V. Jacobson, C. Liu, P.Sharma, L. Wei draft- 622 ietf-idmr-pim-sm-specv2-00.txt. 624 [PIMARCH] An Architecture for Wide-Area Multicast Routing, S. Deering, 625 D. Estrin, D. Farinacci, V. Jacobson, G. Liu,L. Wei, USC Technical 626 Report, available from authors, Nov 1996. 628 [RFC1112] Host Extensions for IP Multicasting, Network Working Group, 629 RFC 1112, S. Deering, August 1989 631 [PIMAU] Authenticating PIM Version 2 Messages, L. Wei. , Nov, 1999 634 11 Authors' Addresses 636 Stephen Deering 637 Cisco Systems Inc 638 170 West Tasman Drive, 639 San Jose, CA 95134 640 deering@cisco.com 642 Deborah Estrin 643 Computer Science Department/ISI 644 University of Southern California 645 Los Angeles, CA 90089 646 estrin@usc.edu 648 Dino Farinacci 649 cisco Systems Inc 650 170 West Tasman Drive 651 San Jose, CA 95134 652 dino@cisco.com 654 Van Jacobson 655 cisco Systems Inc 656 170 West Tasman Drive 657 San Jose, CA 95134 658 van@cisco.com 660 Ahmed Helmy 661 Computer Science Department 662 University of Southern California 663 Los Angeles, CA 90089 664 ahelmy@catarina.usc.edu 665 David Meyer 666 cisco Systems, Inc 667 170 West Tasman Drive 668 San Jose, CA95134 669 meyer@cisco.com 671 Liming Wei 672 cisco Systems Inc 673 170 West Tasman Drive 674 San Jose, CA 95134 675 lwei@cisco.com