Internet Engineering Task Force	                                  PIM WGINTERNET DRAFT	                      Andrew Adams (NextHop Technolgies)draft-ietf-pim-dm-new-v2-01.txt	            Jonathan Nicholas (ITT A/CD)	                           William Siadak (NextHop Technologies)                                                       February 15, 2002          Protocol Independent Multicast - Dense Mode (PIM-DM):                   Protocol Specification (Revised)Status of this DocumentThis document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026.Internet Drafts are working documents of the Internet Engineering Task Force (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 months and may be updated, replaced, or obsoleted by other documents at any time.  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 at http://www.ietf.org/ietf/lid-abstracts.txt.The list of Internet Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.This document is a product of the IETF PIM WG.  Comments should be addressed to the authors, or the WG's mailing list at pim@catarina.usc.edu.                                AbstractThis document specifies Protocol Independent Multicast - Dense Mode (PIM-DM).  PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagramsto all multicast routers.  Prune messages are used to prevent future messages from propagating to routers with no group membership information.Adams, Nicholas, Siadak                                         [Page 1]                            Table of Contents1. Introduction	. . . . . . . . . . . . . . . . . . . . . . . . . . .  32. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . . .  33. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . . .  34. Pseudocode Notation  . . . . . . . . . . . . . . . . . . . . . . .  35. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . . . .  46. Protocol Specification . . . . . . . . . . . . . . . . . . . . . .  56.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . . .  56.1.1. General Purpose State  . . . . . . . . . . . . . . . . . . . .  66.1.2. (S,G) State  . . . . . . . . . . . . . . . . . . . . . . . . .  66.1.3. State Summarization Macros . . . . . . . . . . . . . . . . . .  76.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . . .  86.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . . . . .  96.3.1. Sending Hello Messages . . . . . . . . . . . . . . . . . . . .  96.3.2. Receiving Hello Messages	. . . . . . . . . . . . . . . . . . .  96.3.3. Hello Message Hold Time  . . . . . . . . . . . . . . . . . . .  96.3.4. Handling Router Failures . . . . . . . . . . . . . . . . . . . 106.3.5.  Reducing Prune Propagation Delay on LANs  . . . . . . . . . . 116.4. PIM-DM Prune, Join and Graft Messages  . . . . . . . . . . . . . 116.4.1. Upstream Prune, Join and Graft Messages  . . . . . . . . . . . 116.4.2. Downstream Prune, Join and Graft Messages  . . . . . . . . . . 176.5. State Refresh  . . . . . . . . . . . . . . . . . . . . . . . . . 216.5.1. Forwarding of State Refresh Messages . . . . . . . . . . . . . 216.5.2. State Refresh Message Origination  . . . . . . . . . . . . . . 226.6. PIM Assert Messages  . . . . . . . . . . . . . . . . . . . . . . 256.6.1. Assert Metrics . . . . . . . . . . . . . . . . . . . . . . . . 256.6.2. AssertCancel Messages  . . . . . . . . . . . . . . . . . . . . 266.6.3. Assert State Macros  . . . . . . . . . . . . . . . . . . . . . 266.6.4. (S,G) Assert Message State Machine . . . . . . . . . . . . . . 266.6.5. Rationale for Assert Rules . . . . . . . . . . . . . . . . . . 316.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 316.7.1. PIM Header . . . . . . . . . . . . . . . . . . . . . . . . . . 316.7.2. Encoded Unicast Address  . . . . . . . . . . . . . . . . . . . 326.7.3. Encoded Group Address  . . . . . . . . . . . . . . . . . . . . 326.7.4. Encoded Source Address . . . . . . . . . . . . . . . . . . . . 346.7.5. Hello Message Format . . . . . . . . . . . . . . . . . . . . . 356.7.6. Join/Prune Message Format  . . . . . . . . . . . . . . . . . . 376.7.7. Assert Message Format  . . . . . . . . . . . . . . . . . . . . 396.7.8. Graft Message Format . . . . . . . . . . . . . . . . . . . . . 396.7.9. Graft Ack Message Format . . . . . . . . . . . . . . . . . . . 396.6.10. State Refresh Message Format  . . . . . . . . . . . . . . . . 406.8. PIM-DM Timers  . . . . . . . . . . . . . . . . . . . . . . . . . 416.8.1. Timer Values . . . . . . . . . . . . . . . . . . . . . . . . . 427. Protocol Interaction Considerations  . . . . . . . . . . . . . . . 437.1. PIM-SM Interactions  . . . . . . . . . . . . . . . . . . . . . . 447.2. IGMP Interactions  . . . . . . . . . . . . . . . . . . . . . . . 447.3. Source Specific Multicast (SSM) Interactions . . . . . . . . . . 447.4. Multicast Group Scope Boundary Interactions  . . . . . . . . . . 458. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . . 458.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . . 458.2. PIM Hello Options  . . . . . . . . . . . . . . . . . . . . . . . 459. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 4510. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 4811. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 4812. References  . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Adams, Nicholas, Siadak                                         [Page 2]1. IntroductionThis specification defines a multicast routing algorithm for multicast groups that are densely distributed across a network.  This protocol does not have a topology discovery mechanism often used by a unicast routing protocol.  It employs the same packet formats sparse mode PIM (PIM-SM) uses.  This protocol is called PIM - Dense Mode.  The foundation of this design was largely built on Deering's early work on IP multicast routing [1].2. TerminologyThe 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 indicate requirement levels forcompliant PIM-DM implementations.3. DefinitionsMulticast Routing Information Base (MRIB)  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.  PIM-DM uses the MRIB   to make decisions regarding RPF interfaces.Tree Information Base (TIB)  This is the collection of state maintained by a PIM router and created  by receiving PIM messages and IGMP information from local hosts.  It  essentially stores the state of all multicast distribution trees at  that router.Reverse Path Forwarding (RPF)  RPF is a multicast forwarding mode where a data packet is accepted for  forwarding if it is received on an interface used to reach the source  in unicast.Upstream Interface  Interface towards the source of the datagram.  Also known as the RPF  Interface.Downstream Interface  All interfaces that are not the upstream interface, including the  router itself.(S,G) Pair  Source S and destination group G associated with an IP packet.4. Pseudocode NotationWe use set notation in several places in this specification.A (+) B  is the union of two sets A and B.Adams, Nicholas, Siadak                                         [Page 3]A (-) B  are the elements of set A that are not in set B.NULL  is the empty set or list.Note that (+) and (-) operators are NOT commutative, and must be conducted in the order specified.In addition we use C-like syntax:  =   denotes assignment of a variable.  ==  denotes a comparison for equality.  !=  denotes a comparison for inequality.Braces { and } are used for grouping.5. PIM-DM Protocol OverviewThis section provides an overview of PIM-DM behavior.  It is intended asan introduction to how PIM-DM works, and is NOT definitive.  For the definitive specification, see Section 6 - Protocol Specification.PIM-DM assumes that when a source starts sending, all downstream systemswant to receive multicast datagrams.  Initially, multicast datagrams areflooded to all areas of the network.  PIM-DM uses RPF to prevent loopingof multicast datagrams while flooding.  If some areas of the network do not have group members, PIM-DM will prune off the forwarding branch by instantiating prune state.Prune state has a finite lifetime.  When that lifetime expires, data will again be forwarded down the previously pruned branch.Prune state is associated with an (S,G) pair.  When a new member for a group G appears in a pruned area, a router can "graft" toward the sourceS for the group, thereby turning the pruned branch back into a forwarding branch.The broadcast of datagrams followed by pruning of unwanted branches is often referred to as a flood and prune cycle and is typical of dense mode protocols.In order to minimize repeated flooding of datagrams and subsequent pruning associated with a particular (S,G) pair, PIM-DM uses a state refresh message.  This message is sent by the router(s) directly connected to the source and is propagated throughout the network.  Whenreceived by a router on its RPF interface, the state refresh message causes an existing prune state to be refreshed.Adams, Nicholas, Siadak                                         [Page 4]Compared with multicast routing protocols with built in topology discovery mechanisms (e.g. DVMRP [2]) PIM-DM has a simplified design andis not hard-wired into a specific topology discovery protocol.  However,such a simplification does incur more overhead by causing flooding and pruning to occur on some links that could be avoided if sufficient topology information were available, i.e. to decide whether an interfaceleads to any downstream members of a particular group. Additional overhead is chosen in favor of the simplification and flexibility gainedby not depending on a specific topology discovery protocol.PIM-DM differs from PIM-SM in two essential ways: 1) There are no periodic joins transmitted, only explicitly triggered prunes and grafts.2) There is no Rendezvous Point (RP).  This is particularly important innetworks that cannot tolerate a single point of failure.  (An RP is theroot of a shared multicast distribution tree. For more details see [3]).6. Protocol SpecificationThe specification of PIM-DM is broken into several parts:* Section 6.1 details the protocol state stored.* Section 6.2 specifies the data packet forwarding rules.* Section 6.3 specifies generation and processing of Hello messages.* Section 6.4 specifies the Join, Prune and Graft generation and               processing rules.* Section 6.5 specifies the State Refresh generation and forwarding               rules.* Section 6.6 specifies the Assert generation and processing rules.* Section 6.7 gives details on PIM-DM Packet Formats.* Section 6.8 summarizes PIM-DM timers and their defaults.6.1 PIM Protocol StateThis section specifies all the protocol states that a PIM-DM implementation should maintain in order to function correctly.  We termthis state the Tree Information Base or TIB, as it holds the state of all the multicast distribution trees at this router.  In this specification, we define PIM-DM mechanisms in terms of the TIB.  However, only a very simple implementation would actually implement packet forwarding operations in terms of this state.  Most implementations will use this state to build a multicast forwarding table, which would then be updated when the relevant state in the TIB changes.Although we specify precisely the state to be kept, this does not mean that an implementation of PIM-DM needs to hold the state in this form. This is actually an abstract state definition, which is needed in order to specify the router's behavior.  A PIM-DM implementation is free to hold whatever internal state it requires, and will still be conformant with this specification so long as it results in the same externally visible protocol behavior as an abstract router that holds the followingstate.Adams, Nicholas, Siadak                                         [Page 5]6.1.1 General Purpose StateA router stores the following non-group-specific state:For each interface:  Hello Timer (HT)  State Refresh Capable  LAN Delay Enabled  Propagation Delay (PD)  Override Interval (OI)  Neighbor State:    For each neighbor:      Information from neighbor's Hello      Neighbor's Gen ID.      Neighbor's LAN Prune Delay      Neighbor's Override Interval      Neighbor's State Refresh Capability      Neighbor Liveness Timer (NLT)