idnits 2.17.1 draft-ietf-idmr-pim-dm-spec-02.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. ** Bad filename characters: the document name given in the document, 'draft-ietf-idmr-PIM-DM-spec-02', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-ietf-idmr-PIM-DM-spec-02', but the file name used is 'draft-ietf-idmr-pim-dm-spec-02' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 200 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 18 has weird spacing: '... Drafts are ...' == Line 19 has weird spacing: '...cuments of t...' == Line 20 has weird spacing: '...ups may also ...' == Line 24 has weird spacing: '... Drafts may ...' == Line 25 has weird spacing: '...iate to use ...' == (195 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 17, 1996) is 10321 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 section? 'Deering95' on line 528 looks like a reference -- Missing reference section? 'Deering91' on line 521 looks like a reference -- Missing reference section? 'DVMRP' on line 525 looks like a reference -- Missing reference section? 'RFC1112' on line 536 looks like a reference -- Missing reference section? 'Deering94b' on line 532 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Deborah Estrin (USC) 3 Internet Draft Dino Farinacci (CISCO) 4 Van Jacobson (LBL) 5 Chinggung Liu (USC) 6 Liming Wei (USC) 7 Puneet Sharma (USC) 8 Ahmed Helmy (USC) 10 draft-ietf-idmr-PIM-DM-spec-02.txt January 17, 1996 11 Expire in six months 13 Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol 14 Specification 16 Status of This Memo 18 This document is an Internet Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its Areas, 20 and its Working Groups. (Note that other groups may also distribute 21 working documents as Internet Drafts). 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a 27 ``working'' draft'' or ``work in progress.'' 29 Please check the I-D abstract listing contained in each Internet 30 Draft directory to learn the current status of this or any other 31 Internet Draft. 33 1 Introduction 35 This specification defines a multicast routing algorithm for 36 multicast groups that are densely distributed across an internet. The 37 protocol is unicast routing protocol independent. It is based on the 38 PIM sparse-mode [Deering95] and employs the same packet formats. This 39 protocol is called dense-mode PIM. The design is based largely on 40 foundational work by Deering [Deering91]. 42 2 PIM-DM Protocol Overview 44 Dense-mode PIM uses Reverse Path Multicasting (RPM). RPM is a 45 technique in which a multicast datagram is forwarded if the receiving 46 interface is one used to forward unicast datagrams to the source of 47 the datagram. The multicast datagram is then forwarded out all other 48 interfaces. Dense-mode PIM builds source-based acyclic trees. 50 Dense-mode PIM is data driven, whereby it is assumed that all 51 downstream systems want to receive multicast datagrams. For densely 52 populated groups this is optimal. If some areas of the network do not 53 have group members, dense-mode PIM will prune branches of the 54 source-based tree. When group members leave the group, branches will 55 also be pruned. 57 Unlike DVMRP [DVMRP] packets are forwarded on all outgoing interfaces 58 (except the incoming) until pruning and truncation occurs. DVMRP 59 makes use of parent-child data to reduce the number of outgoing 60 interfaces used before pruning. In both protocols, once truncation 61 occurs pruning state is maintained and packets are only forwarded 62 onto outgoing interfaces that in fact reach downstream members. 64 We chose to accept additional overhead in favor of reduced dependency 65 on the unicast routing protocol, and reduced overall protocol 66 complexity. 68 Dense-mode PIM differs from sparse-mode PIM in two essential points: 69 1) there are no periodic joins transmitted, only explicit triggered 70 grafts/prunes, and 2) there is no Rendezvous Point (RP). 72 3 Background 74 Reverse Path Broadcasting (RPB) is different from RPF because 75 duplicate packets are avoided in the RPB that are sent in RPF. In 76 general, the number of duplicates sent on a link can be as high as 77 the number of routers directly connected to that link. 79 Reverse Path Multicasting (RPM) is different from RPF or RPB because 80 pruning information is propagated upstream. Leaf routers must know 81 that they are leaf routers so that in response to no IGMP reports for 82 a group, those leaf routers know to initiate the prune process. 84 In DVMRP there are routing protocol dependencies for a) building a 85 parent-child database so that duplicate packets can be eliminated, b) 86 eliminating duplicate packets on multi-access LANs, and c) sending 87 "split horizon with poison reverse" information to detect that a 88 router is not a leaf router (if a router does not receive any poison 89 reverse messages from other routers on a multi-access LAN then that 90 router acts as a leaf router for that LAN and knows to prune if there 91 are not IGMP reports on that LAN for a group G). 93 Dense-mode PIM will accept some duplicate packets in order to avoid 94 being routing protocol dependent and avoid building a child parent 95 database. 97 We introduce a simple prune mechanism for reducing duplicates on 98 multi-access LANs. We introduce a simple graft mechanism to reduce 99 join latency on previously pruned branches of a source-based 100 multicast tree. 102 We introduce an alternative leaf-router detection mechanism that does 103 not rely on a specific unicast routing protocol mechanism such as 104 split horizon with poison reverse. 106 These mechanisms are described below. 108 4 Protocol Description 110 4.1 Leaf network detection 112 In DVMRP poison reverse information tells a router that other routers 113 on the shared LAN use the LAN as their incoming interface. As a 114 result, even if the DR for that LAN does not hear any IGMP Reports 115 for a group, the DR will know to continue to forward multicast data 116 packets to that group, and NOT to send a prune message to its 117 upstream neighbor. 119 Since dense-mode PIM does not rely on any unicast routing protocol 120 mechanisms, this problem is solved by using prune messages sent 121 upstream on a LAN. If a downstream router on a LAN determines that it 122 has no more downstream members for a group, then it can multicast a 123 prune message on the LAN. 125 A leaf router detects that there are no members downstream when it is 126 the only router on a network and there are no IGMP Host-Report 127 messages received from hosts. It determines there are no other 128 routers by not receiving PIM Router-Query messages. 130 When a prune message is sent on an upstream LAN, it is data link 131 multicast and IP addressed to the all routers group address 132 224.0.0.2. The router to process the prune will be indicated by 133 inserting its address in the "Address" field of the message. The 134 address is obtained by an RPF lookup from the unicast routing table. 135 When the prune message is sent, the expected upstream router will 136 schedule a deletion request of the LAN from its outgoing interfaces 137 for the (S,G) entry from the prune list. The suggested delay time 138 before deletion should be greater than 3 seconds. 140 Note the special case for equal-cost paths. When an upstream router 141 is chosen by an RPF lookup there may be equal-cost paths to reach the 142 source. The higher IP addressed system is always chosen. If the 143 unicast routing protocol does not store all available equal-cost 144 paths in the routing table, the "Address" field may contain the 145 address of the wrong upstream router. To avoid this situation, the 146 "Address" field may optionally be set to 0.0.0.0 which means that all 147 upstream routers (the ones that have the LAN as an outgoing interface 148 for the (S,G) entry) may process the packet. 150 Other routers on the LAN will hear the prune message and respond with 151 a join if they still expect multicast datagrams from the expected 152 upstream router. The PIM-Join message is data link multicast and IP 153 addressed to the all routers group address 224.0.0.2. The router to 154 process the join will be indicated by inserting its address in the 155 "Address" field of the message. The address is determined by an RPF 156 lookup from the unicast routing table. When the expected router 157 receives the join message, it will cancel the deletion request. 159 Routers will randomly generate a join message delay timer. If a join 160 is heard from another router before a router sends its own, it will 161 cancel sending its own join. This will reduce traffic on the LAN. The 162 suggested join delay timer should be from 1 to 3 seconds. 164 If the expected upstream router does not receive any PIM-Join 165 messages before the schedule time for the deletion request expires, 166 it deletes the outgoing LAN interface from the (S,G) multicast 167 forwarding entry. 169 If an (S,G) entry contains an empty outgoing interface list, a prune 170 is sent upstream. Prune information is flushed periodically. This (or 171 a loss of state) causes the packets to be sent in RPF mode again 172 which in turn triggers prune messages. 174 4.2 New members joining an existing group 176 If a router is directly connected to a host that wants to become a 177 member of a group, the router may optionally, send a PIM-Graft 178 message towards known sources. This allows join latency to be reduced 179 below that indicated by the relatively large timeout value suggested 180 for prune information. 182 If a receiving router has state for group G, it adds the interface on 183 which the IGMP Report or PIM-Graft was received for all known (S,G). 184 If the (S,G) entry was a negative cache entry, the router sends a 185 PIM-Graft message upstream towards S. 187 If routers have no group state, they do nothing since dense-mode PIM 188 will deliver a multicast datagram to all interfaces when creating 189 state for a group. 191 Any routers receiving the PIM-Graft message, uses the received 192 interface as an incoming interface for any (S,G) entry, will not add 193 the interface to the outgoing interface list. 195 The PIM-Graft message is the only PIM message that uses a positive 196 acknowledgment strategy. Senders of PIM-Graft messages unicast them 197 to their upstream RPF neighbors. The neighbor processes each (S,G) 198 and immediately acknowledges each (S,G) in a PIM-GraftAck message. 199 This is relatively easy, since the receiver simply changes the IGMP 200 code from Graft to Graft-Ack and unicasts the original packet back to 201 the source. The sender periodically retransmits the PIM-Graft message 202 for any (S,G) that has not been acknowledged. Note that the sender 203 need not keep a retransmission list for each neighbor since PIM- 204 Grafts are only sent to the RPF neighbor. Only the (S,G) entry needs 205 to be tagged for retransmission. 207 4.3 Protocol Scenario 209 A multicast datagram is sent by a source host. If a receiving router 210 has no forwarding cache state for the source sending to group G, it 211 creates an (S,G) entry. The incoming interface for (S,G) is 212 determined by doing an RPF lookup in the unicast routing table. The 213 (S,G) outgoing interface list contains dense-mode configured 214 interfaces that have PIM routers present or host members for group G. 216 A PIM-Prune message is triggered when an (S,G) entry is built with an 217 empty outgoing interface list. This type of entry is called a 218 negative cache entry. This can occur when a leaf router has no local 219 members for group G or a prune message was received from a downstream 220 router which causes the outgoing interface list to become NULL. PIM- 221 Prune messages are never sent on LANs in response to a received 222 multicast packet that is associated with a negative cache entry. 224 PIM-Prune messages received on a point to point link are not delayed 225 before processing as they are in the LAN procedure. If the prune is 226 received on an interface that is in the outgoing interface list, it 227 is deleted immediately. Otherwise the prune is ignored. 229 When a multicast datagram is received on the incorrect LAN interface 230 (i.e. not the RPF interface) the packet is silently discarded. If it 231 is received on an incorrect point-to-point interface, Prunes may be 232 sent in a rate-limited fashion. Prunes may also be rate-limited on 233 point-to-point interfaces when a multicast datagram is received for a 234 negative cache entry. 236 4.4 Designated Router election 238 The dense-mode PIM designated router (DR) election uses the same 239 procedure as in sparse-mode PIM. A DR is necessary for each multi- 240 access LAN so a single router sends IGMP Host-Query messages to 241 solicit host group membership. 243 Each PIM router connected to a multi-access LAN should transmit PIM 244 Router-Query messages every 30 seconds onto the LAN to support DR 245 election. The highest addressed router becomes the DR. The discovered 246 PIM routers should be timed out after 90 seconds. If the DR goes 247 down, a new DR is elected. 249 DR election is only necessary on multi-access networks. It is not 250 required that PIM Query messages be sent on point-to-point links. 252 4.5 Parallel paths to a source 254 Two or more routers may receive the same multicast datagram that was 255 replicated upstream. In particular, if two routers have equal cost 256 paths to a source and are connected on a common multi-access network, 257 duplicate datagrams will travel downstream onto the LAN. Dense-mode 258 PIM will detect such a situation and will not let it persist. 260 If a router receives a multicast datagram on a multi-access LAN from 261 a source whose corresponding (S,G) outgoing interface list includes 262 the received interface, the packet must be a duplicate. In this case 263 a single forwarder must be elected. Using PIM Assert messages 264 addressed to 224.0.0.2 on the LAN, upstream routers can decide which 265 one becomes the forwarder. Downstream routers listen to the Asserts 266 so they know which one was elected (i.e. typically this is the same 267 as the downstream router's RPF neighbor but there are circumstances 268 when using different unicast protocols where this might not be the 269 case). 271 The upstream router elected is the one that has the shortest distance 272 to the source. Therefore, when a packet is received on an outgoing 273 interface a router will send an Assert packet on the LAN indicating 274 what metric it uses to reach the source of the data packet. The 275 router with the smallest numerical metric will become the forwarder. 276 All other upstream routers will delete the interface from their 277 outgoing interface list. The downstream routers also do the 278 comparison in case the forwarder is different than the RPF neighbor. 279 This is important so downstream routers send subsequent Prunes or 280 Grafts to the correct neighbor. 282 Associated with the metric is a metric preference value. This is 283 provided to deal with the case where the upstream routers may run 284 different unicast routing protocols. The numerically smaller metric 285 preference is always preferred. The metric preference should be 286 treated as the high-order part of an Assert metric comparison. 287 Therefore, a metric value can be compared with another metric value 288 provided both metric preferences are the same. A metric preference 289 can be assigned per unicast routing protocol and needs to be 290 consistent for all routers on the LAN. 292 The following Assert rules are provided: 294 Multicast packet received on outgoing interface: 296 1 Do unicast routing table lookup on source IP address from 297 data packet. 299 2 Send Assert on interface for source IP address from data 300 packet, include metric preference of routing protocol and 301 metric from routing table lookup. 303 3 If route is not found, Use metric preference of 0x7fffffff 304 and metric 0xffffffff. 306 Asserts received on outgoing interface: 308 1 Compare metric received in Assert with the one you would 309 have advertised in an Assert. If the value in the Assert is 310 less than your value, prune the interface. If the value is 311 the same, compare IP addresses, if your address is less 312 than the Assert sender, prune the interface. 314 2 If you have won the election and there are directly 315 connected members on the LAN, keep the interface in your 316 outgoing interface list. You are the forwarder for the LAN. 318 3 If you have won the election but there are no directly 319 connected members on the LAN, schedule to prune the 320 interface. The LAN might be a stub LAN with no members (and 321 no downstream routers). If no subsequent Joins are 322 received, delete the interface from the outgoing interface 323 list. Otherwise keep the interface in your outgoing 324 interface. You are the forwarder for the LAN. 326 Asserts received on incoming interface: 328 1 Downstream routers will select the upstream router with the 329 smallest metric as their RPF neighbor. If two metrics are 330 the same, the highest IP address is chosen to break the 331 tie. 333 2 If the downstream routers have downstream members, they 334 must schedule a join to inform the upstream router packets 335 should be forwarded on the LAN. This will cause the 336 upstream forwarder to cancel its delayed pruning of the 337 interface. 339 4.6 Timing out multicast forwarding entries 341 Each (S,G) entry has timers associated with it. During this time 342 source-based tree state is kept in the network. 344 There should be multiple timers set. One for the multicast 345 routing entry itself and one for each interface in the outgoing 346 interface list. The outgoing interface stays active in the list 347 as long as there is multicast traffic for the entry or there is 348 an explicit Graft received on the interface. If neither occurs 349 the interface will be deleted from the list after 3 minutes, by 350 default. 352 Once all interfaces in the outgoing interface list are not 353 active, a timer should be set for the (S,G) entry. During this 354 time the entry is known as a negative state entry at which a 355 prune is triggered. Once the (S,G) entry times out, it can be 356 recreated when the next multicast packet or join arrives. 358 4.7 Source address aggregation and Pruning 360 An (S,G) entry in the multicast routing table will contain a 361 source address to be as specific as necessary depending where 362 the router is in relation to a source. Close to the source, this 363 will typically be a subnet number. Far from the source, it may 364 be a network number or a supernet route. Prunes sent may be 365 rather ineffective if the source being pruned is not specific 366 enough. 368 For example, initially a multicast datagram may be flooded 369 throughout an Autonomous System (AS). Within the AS, there is 370 complete subnet information in the unicast routing tables of all 371 routers. Once the datagram exits the AS, it is likely there are 372 routers that don't have subnet information. If these routers 373 send Prunes for aggregate sources, routers close to the source 374 will not know where to reach the source since they have more 375 specific information than what was provided in the Prune 376 message. This results in traffic being sent further on a branch 377 of the multicast tree than necessary. 379 The problem is fixed by sending source host specific prunes. 380 However, to maintain proper scaling of routing information, each 381 router along the path performs longest match lookups for the 382 source specified in the Prune message. Therefore, they keep the 383 level of aggregation that best suits thier position to the 384 source in the topology. 386 A source host specific Prune is encoded by copying the 387 instigating source IP address from the multicast datagram into 388 the PIM message using a mask length of 32. 390 5 Packet Formats 392 RFC-1112, see [RFC1112], specifies two types of IGMP packets for 393 hosts and routers to convey multicast group membership and 394 reachability information. An IGMP Host-Query packet is 395 transmitted periodically by routers to ask hosts to report which 396 multicast groups they are members of. An IGMP Host- Report 397 packet is transmitted by hosts in response to received queries 398 advertising group membership. 400 This section introduces new types of IGMP packets that are used 401 by PIM-SM routers. All PIM-SM control mesages are encoded in 402 IGMP messages. 404 The fixed header packet format is: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |Version| Type | Code | Checksum | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Address | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Version 415 This memo specifies version 1 of IGMP. 417 Type There are nine types of IGMP messages: 419 1 = Host Membership Query 420 2 = Host Membership Report 421 3 = Router DVMRP Messages 422 4 = Router PIM Messages 423 5 = Cisco Trace Messages 424 6 = New Host Membership Report 425 7 = Host Membership Leave 426 14 = Mtrace Response 427 15 = Mtrace Request 429 Code Codes for specific message types. Used only by DVMRP and 430 PIM. PIM codes are: 432 0 = Router-Query 433 1 = Register 434 2 = Register-Ack 435 3 = Join/Prune 436 4 = RP-Reachability 437 5 = Assert 438 6 = Graft 439 7 = Graft-Ack 440 8 = RP-Advertisement 441 9 = Ping 443 Checksum 444 The checksum is the 16-bit one's complement of the one's 445 complement sum of the entire IGMP message. For computing 446 the checksum, the checksum field is zeroed. 448 Address 449 PIM Version field when IGMP type is PIM. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 |PIM Ver| Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 PIM Ver 458 PIM Version number is 2. 460 Reserved 461 Transmitted as zero, ignored on receipt. 463 { For all the packet format details, refer to the PIM sparse- 464 mode specification.} 466 5.1 PIM-Query Message 468 It is sent periodically by PIM routers on all interfaces. 470 5.2 PIM-SM-Register Message 472 Used in sparse-mode. Refer to PIM sparse-mode specification. 474 5.3 PIM-SM-Register-Ack Message 476 Used in sparse-mode. Refer to PIM sparse-mode specification. 478 5.4 Join/Prune Message 480 It is sent by routers towards upstream sources. A join creates 481 forwarding state and a prune destroys forwarding state. Joins 482 are sent to build source specific trees. Prunes are sent to 483 prune source trees when members leave groups as well as sources 484 that do not use the shared tree. 486 5.5 PIM-SM-RP-Reachability Message 488 Used in sparse-mode. Refer to PIM sparse-mode specification. 490 5.6 PIM-Assert Message 492 The PIM-Assert message is sent when a multicast data packet is 493 received on an outgoing interface corresponding to the (S,G) or 494 (*,G) associated with the source. 496 5.7 PIM-Graft Message 498 This message is sent by a downstream router to a neighboring 499 upstream router to reinstate a previously pruned branch of a 500 source tree. This is done for dense-mode groups only. The format 501 is the same as a Join/Prune message. 503 5.8 PIM-Graft-Ack Message 505 Sent in response to a received Graft message. The Graft-Ack is 506 only sent if the interface in which the Graft was received is 507 not the incoming interface for the respective (S,G). This is 508 done for dense-mode groups only. The format is the same as 509 Join/Prune message. 511 5.9 PIM-SM-PING and PING-Response Message 513 Used in sparse-mode. Refer to PIM sparse-mode specification. 515 5.10 RP-Advertisement 517 Used in sparse-mode. Refer to PIM sparse-mode specification. 519 6 References 521 [Deering91] S.E. Deering. Multicast Routing in a Datagram 522 Internetwork. PhD thesis, Electrical Engineering Dept., Stanford 523 University, December 1991. 525 [DVMRP] RFC 1075, Distance Vector Multicast Routing Protocol. 526 Waitzman, D., Partridge, C., Deering, S.E, November 1988 528 [Deering95] Protocol Independent Multicast Sparse-Mode (PIM-SM): 529 Protocol Specification. S. Deering, D. Estrin, D. Farinacci, V. 530 Jacobson, G. Liu, L. Wei, P. Sharma, A. Helmy, September 1995 532 [Deering94b] An Architecture for Wide-Area Multicast Routing, S. 533 Deering, D. Estrin, D. Farinacci, V. Jacobson, G. Liu,L. Wei, 534 USC Technical Report, available from authors, Feburary 1994. 536 [RFC1112] Host Extensions for IP Multicasting, Network Working 537 Group, RFC 1112, S. Deering, August 1989 539 References