Internet Engineering Task Force                                   PIM WGINTERNET-DRAFT                                          Bill Fenner/AT&Tdraft-ietf-pim-sm-v2-new-03.txt                       Mark Handley/ACIRI                                                     Hugh Holbrook/Cisco                                                   Isidor Kouvelas/Cisco                                                            20 July 2001                                                   Expires: January 2002         Protocol Independent Multicast - Sparse Mode (PIM-SM):                    Protocol Specification (Revised)Status of this DocumentThis document is an Internet-Draft and is in full conformance with allprovisions of Section 10 of RFC2026.Internet-Drafts are working documents of the Internet Engineering TaskForce (IETF), its areas, and its working groups.  Note that other groupsmay also distribute working documents as Internet-Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime.  It is inappropriate to use Internet- Drafts as reference materialor to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txtThe list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.This document is a product of the IETF PIM WG.  Comments should beaddressed to the authors, or the WG's mailing list atpim@catarina.usc.edu.                                Abstract     This document specifies Protocol Independent Multicast -     Sparse Mode (PIM-SM).  PIM-SM is a multicast routing protocol     that can use the underlying unicast routing information base     or a separate multicast-capable routing information base.  ItFenner/Handley/Holbrook/Kouvelas                                [Page 1]INTERNET-DRAFT            Expires: January 2002                July 2001     builds unidirectional shared trees rooted at a Rendezvous     Point (RP) per group, and optionally creates shortest-path     trees per source.Note on PIM-SM statusPIM-SM v2 is currently widely implemented and deployed, but the existingspecification in RFC 2362 is insufficient to implement from, and isincorrect in a number of aspects.  This document is a complete re-writefrom RFC 2362, and is intended to obsolete RFC 2362.  The authors haveattempted to document current practice as far as possible, but a numberof cases have arisen where current practice is clearly incorrect,typically leading to traffic being black-holed.  In these cases wediverge from current practice, but always in a way that willinteroperate successfully with the legacy PIM v2 implementations that weare aware of.Fenner/Handley/Holbrook/Kouvelas                                [Page 2]INTERNET-DRAFT            Expires: January 2002                July 2001                           Table of Contents1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . .   52. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . .   5 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .   5 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . . . . . .   63. PIM-SM Protocol Overview. . . . . . . . . . . . . . . . . . . . .   74. Protocol Specification. . . . . . . . . . . . . . . . . . . . . .  12 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . .  12  4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . .  13  4.1.2. (*,*,RP) State. . . . . . . . . . . . . . . . . . . . . . .  14  4.1.3. (*,G) State . . . . . . . . . . . . . . . . . . . . . . . .  15  4.1.4. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . .  16  4.1.5. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . . . .  18  4.1.6. State Summarization Macros. . . . . . . . . . . . . . . . .  19 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . .  23  4.2.1. Last hop switchover to the SPT. . . . . . . . . . . . . . .  26  4.2.2. Setting and Clearing the (S,G) SPT bit. . . . . . . . . . .  26 4.3. PIM Register Messages. . . . . . . . . . . . . . . . . . . . .  28  4.3.1. Sending Register Messages from the DR . . . . . . . . . . .  28  4.3.2. Receiving Register Messages at the RP . . . . . . . . . . .  31 4.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . . . . . .  33  4.4.1. Receiving (*,*,RP) Join/Prune Messages. . . . . . . . . . .  33  4.4.2. Receiving (*,G) Join/Prune Messages . . . . . . . . . . . .  37  4.4.3. Receiving (S,G) Join/Prune Messages . . . . . . . . . . . .  41  4.4.4. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . . . .  44  4.4.5. Sending (*,*,RP) Join/Prune Messages. . . . . . . . . . . .  50  4.4.6. Sending (*,G) Join/Prune Messages . . . . . . . . . . . . .  55  4.4.7. Sending (S,G) Join/Prune Messages . . . . . . . . . . . . .  59  4.4.8. (S,G,rpt) Periodic Messages . . . . . . . . . . . . . . . .  64  4.4.9. State Machine for (S,G,rpt) Triggered  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  65 4.5. PIM Assert Messages. . . . . . . . . . . . . . . . . . . . . .  69  4.5.1. (S,G) Assert Message State Machine. . . . . . . . . . . . .  69  4.5.2. (*,G) Assert Message State Machine. . . . . . . . . . . . .  76  4.5.3. Assert Metrics. . . . . . . . . . . . . . . . . . . . . . .  82  4.5.4. AssertCancel Messages . . . . . . . . . . . . . . . . . . .  84  4.5.5. Assert State Macros . . . . . . . . . . . . . . . . . . . .  84 4.6. Designated Routers (DR) and Hello Messages . . . . . . . . . .  87  4.6.1. Sending Hello Messages. . . . . . . . . . . . . . . . . . .  87  4.6.2. DR Election . . . . . . . . . . . . . . . . . . . . . . . .  88  4.6.3. Reducing Prune Propagation Delay on LANs. . . . . . . . . .  90 4.7. PIM Bootstrap and RP Discovery . . . . . . . . . . . . . . . .  92  4.7.1. Group-to-RP Mapping . . . . . . . . . . . . . . . . . . . .  94  4.7.2. Hash Function . . . . . . . . . . . . . . . . . . . . . . .  94 4.8. Source-Specific Multicast. . . . . . . . . . . . . . . . . . .  95  4.8.1. Protocol Modifications for SSM destinationFenner/Handley/Holbrook/Kouvelas                                [Page 3]INTERNET-DRAFT            Expires: January 2002                July 2001  addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . .  96  4.8.2. PIM-SSM-only Routers. . . . . . . . . . . . . . . . . . . .  96 4.9. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . .  98  4.9.1. Encoded Source and Group Address Formats. . . . . . . . . .  99  4.9.2. Hello Message Format. . . . . . . . . . . . . . . . . . . . 102  4.9.3. Register Message Format . . . . . . . . . . . . . . . . . . 104  4.9.4. Register-Stop Message Format. . . . . . . . . . . . . . . . 106  4.9.5. Join/Prune Message Format . . . . . . . . . . . . . . . . . 106   4.9.5.1. Group Set Source List Rules. . . . . . . . . . . . . . . 109   4.9.5.2. Group Set Fragmentation. . . . . . . . . . . . . . . . . 112  4.9.6. Assert Message Format . . . . . . . . . . . . . . . . . . . 113 4.10. PIM Timers. . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.11. Timer Values. . . . . . . . . . . . . . . . . . . . . . . . . 1165. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 122 5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . 122 5.2. PIM Hello Options. . . . . . . . . . . . . . . . . . . . . . . 1236. Security Considerations . . . . . . . . . . . . . . . . . . . . . 123 6.1. Attacks based on forged messages . . . . . . . . . . . . . . . 123  6.1.1. Forged link-local messages. . . . . . . . . . . . . . . . . 123  6.1.2. Forged unicast messages . . . . . . . . . . . . . . . . . . 124 6.2. Non-cryptographic Authentication Mechanisms. . . . . . . . . . 124  6.2.1. Register Nonces . . . . . . . . . . . . . . . . . . . . . . 125 6.3. Authentication using IPsec . . . . . . . . . . . . . . . . . . 125  6.3.1. Protecting link-local multicast messages. . . . . . . . . . 126  6.3.2. Protecting unicast messages . . . . . . . . . . . . . . . . 126   6.3.2.1. Register messages. . . . . . . . . . . . . . . . . . . . 126   6.3.2.2. Register Stop messages . . . . . . . . . . . . . . . . . 127 6.4. Denial of Service Attacks. . . . . . . . . . . . . . . . . . . 1277. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 1278. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 1289. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12810. Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Fenner/Handley/Holbrook/Kouvelas                                [Page 4]INTERNET-DRAFT            Expires: January 2002                July 20011.  IntroductionThis document specifies a protocol for efficiently routing multicastgroups that may span wide-area (and inter-domain) internets.  Thisprotocol is called Protocol Independent Multicast - Sparse Mode (PIM-SM)because, although it may use the underlying unicast routing to providereverse-path information for multicast tree building, it is notdependent on any particular unicast routing protocol.PIM-SM version 2 was originally specified in RFC 2117, and revised inRFC 2362.  This document is intended to obsolete RFC 2362, and tocorrect a number of deficiencies that have been identified with the wayPIM-SM was previously specified.  As far as possible, this documentspecifies the same protocol as RFC 2362, and only diverges from thebehavior intended by RFC 2362 when the previously specified behavior wasclearly incorrect.  Routers implemented according to the specificationin this document will be able to successfully interoperate with routersimplemented according to RFC 2362.2.  TerminologyIn this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" are to be interpreted as described in RFC 2119 and indicaterequirement levels for compliant PIM-SM implementations.2.1.  DefinitionsThis specification uses a number of terms to refer to the roles ofrouters participating in PIM-SM.  The following terms have specialsignificance for PIM-SM:Rendezvous Point (RP):      An RP is a router that has been configured to be used as the root      of the non-source-specific distribution tree for a multicast      group.  Join messages from receivers for a group are sent towards      the RP, and data from senders is sent to the RP so that receivers      can discover who the senders are, and start to receive traffic      destined for the group.Designated Router (DR):      A shared-media LAN like Ethernet may have multiple PIM-SM routers      connected to it.  If the LAN has directly connected hosts, then a      single one of these routers, the DR, will act on behalf of those      hosts with respect to the PIM-SM protocol.  A single DR is elected      per LAN using a simple election process.Fenner/Handley/Holbrook/Kouvelas                  Section 2.1.  [Page 5]INTERNET-DRAFT            Expires: January 2002                July 2001MRIB  Multicast Routing Information Base.  This is the multicast      topology table, which is typically derived from the unicast      routing table, or routing protocols such as MBGP that carry      multicast-specific topology information.  In PIM-SM this is used      to make decisions regarding where to forward Join/Prune messages.RPF Neighbor      RPF stands for "Reverse Path Forwarding".  The RPF Neighbor of a      router with respect to an address is the neighbor that the MRIB      indicates should be used to forward packets to that address.  In      the case of a PIM-SM multicast group, the RPF neighbor is the      router that a Join message for that group would be directed to, in      the absence of modifying Assert state.TIB   Tree Information Base.  This is the collection of state at a PIM      router that has been created by receiving PIM Join/Prune messages,      PIM Assert messages, and IGMP information from local hosts.  It      essentially stores the state of all multicast distribution trees      at that router.MFIB  Multicast Forwarding Information Base.  The TIB holds all the      state that is necessary to forward multicast packets at a router.      However, although this specification defines forwarding in terms      of the TIB, to actually forward packets using the TIB is very      inefficient.  Instead a real router implementation will normally      build an efficient MFIB from the TIB state to perform forwarding.      How this is done is implementation-specific, and is not discussed      in this document.Upstream      Towards the root of the tree.  The root of tree may either be the      source or the RP depending on the context.Downstream      Away from the root of the tree.2.2.  Pseudocode NotationWe use set notation in several places in this specification.A (+) B    is the union of two sets A and B.A (-) B    is the elements of set A that are not in set B.NULL    is the empty set or list.Fenner/Handley/Holbrook/Kouvelas                  Section 2.2.  [Page 6]INTERNET-DRAFT            Expires: January 2002                July 2001