< draft-ietf-pim-dm-new-v2-01.txt		draft-ietf-pim-dm-new-v2-02.txt >
	Internet Engineering Task Force PIM WG		Internet Engineering Task Force PIM WG
	INTERNET DRAFT Andrew Adams (NextHop Technolgies)		INTERNET DRAFT Andrew Adams (NextHop Technolgies)
	draft-ietf-pim-dm-new-v2-01.txt Jonathan Nicholas (ITT A/CD)		draft-ietf-pim-dm-new-v2-02.txt Jonathan Nicholas (ITT A/CD)
	William Siadak (NextHop Technologies)		William Siadak (NextHop Technologies)
	February 15, 2002		October 2002
			Expires April 2003
	Protocol Independent Multicast - Dense Mode (PIM-DM):		Protocol Independent Multicast - Dense Mode (PIM-DM):
	Protocol Specification (Revised)		Protocol Specification (Revised)
	Status of this Document		Status of this Document
	This document is an Internet Draft and is in full conformance with all		This document is an Internet Draft and is in full conformance with all
	provisions of Section 10 of RFC 2026.		provisions of Section 10 of RFC 2026.
	Internet Drafts are working documents of the Internet Engineering Task		Internet Drafts are working documents of the Internet Engineering Task
	skipping to change at page 2, line 6 ¶		skipping to change at page 2, line 6 ¶
	Abstract		Abstract
	This document specifies Protocol Independent Multicast - Dense Mode		This document specifies Protocol Independent Multicast - Dense Mode
	(PIM-DM). PIM-DM is a multicast routing protocol that uses the		(PIM-DM). PIM-DM is a multicast routing protocol that uses the
	underlying unicast routing information base to flood multicast datagrams		underlying unicast routing information base to flood multicast datagrams
	to all multicast routers. Prune messages are used to prevent future		to all multicast routers. Prune messages are used to prevent future
	messages from propagating to routers with no group membership		messages from propagating to routers with no group membership
	information.		information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Pseudocode Notation . . . . . . . . . . . . . . . . . . . . . . . 3
	5. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4
	6. Protocol Specification . . . . . . . . . . . . . . . . . . . . . . 5
	6.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . . . 5
	6.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . . 6
	6.1.2. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1.3. State Summarization Macros . . . . . . . . . . . . . . . . . . 7
	6.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . . . 8
	6.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.3.1. Sending Hello Messages . . . . . . . . . . . . . . . . . . . . 9
	6.3.2. Receiving Hello Messages . . . . . . . . . . . . . . . . . . . 9
	6.3.3. Hello Message Hold Time . . . . . . . . . . . . . . . . . . . 9
	6.3.4. Handling Router Failures . . . . . . . . . . . . . . . . . . . 10
	6.3.5. Reducing Prune Propagation Delay on LANs . . . . . . . . . . 11
	6.4. PIM-DM Prune, Join and Graft Messages . . . . . . . . . . . . . 11
	6.4.1. Upstream Prune, Join and Graft Messages . . . . . . . . . . . 11
	6.4.2. Downstream Prune, Join and Graft Messages . . . . . . . . . . 17
	6.5. State Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.5.1. Forwarding of State Refresh Messages . . . . . . . . . . . . . 21
	6.5.2. State Refresh Message Origination . . . . . . . . . . . . . . 22
	6.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . . . . . 25
	6.6.1. Assert Metrics . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.6.2. AssertCancel Messages . . . . . . . . . . . . . . . . . . . . 26
	6.6.3. Assert State Macros . . . . . . . . . . . . . . . . . . . . . 26
	6.6.4. (S,G) Assert Message State Machine . . . . . . . . . . . . . . 26
	6.6.5. Rationale for Assert Rules . . . . . . . . . . . . . . . . . . 31
	6.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31
	6.7.1. PIM Header . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.7.2. Encoded Unicast Address . . . . . . . . . . . . . . . . . . . 32
	6.7.3. Encoded Group Address . . . . . . . . . . . . . . . . . . . . 32
	6.7.4. Encoded Source Address . . . . . . . . . . . . . . . . . . . . 34
	6.7.5. Hello Message Format . . . . . . . . . . . . . . . . . . . . . 35
	6.7.6. Join/Prune Message Format . . . . . . . . . . . . . . . . . . 37
	6.7.7. Assert Message Format . . . . . . . . . . . . . . . . . . . . 39
	6.7.8. Graft Message Format . . . . . . . . . . . . . . . . . . . . . 39
	6.7.9. Graft Ack Message Format . . . . . . . . . . . . . . . . . . . 39
	6.6.10. State Refresh Message Format . . . . . . . . . . . . . . . . 40
	6.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . . . . . 41
	6.8.1. Timer Values . . . . . . . . . . . . . . . . . . . . . . . . . 42
	7. Protocol Interaction Considerations . . . . . . . . . . . . . . . 43
	7.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . . . . . 44
	7.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . . . . . 44
	7.3. Source Specific Multicast (SSM) Interactions . . . . . . . . . . 44
	7.4. Multicast Group Scope Boundary Interactions . . . . . . . . . . 45
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 45
	8.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . . . 45
	8.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . . 45
	9. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 45
	10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
			2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
			2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
			2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . . . 5
			3. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . 5
			4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6
			4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . 6
			4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . 7
			4.1.2. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . 7
			4.1.3. State Summarization Macros . . . . . . . . . . . . . . . . . 8
			4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . 10
			4.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . . . 10
			4.3.1. Sending Hello Messages . . . . . . . . . . . . . . . . . . . 10
			4.3.2. Receiving Hello Messages . . . . . . . . . . . . . . . . . . 11
			4.3.3. Hello Message Hold Time . . . . . . . . . . . . . . . . . . 11
			4.3.4. Handling Router Failures . . . . . . . . . . . . . . . . . . 11
			4.3.5. Reducing Prune Propagation Delay on LANs . . . . . . . . . . 12
			4.4. PIM-DM Prune, Join and Graft Messages . . . . . . . . . . . 13
			4.4.1. Upstream Prune, Join and Graft Messages . . . . . . . . . . 13
			4.4.1.1. Transitions from the Forwarding (F) State . . . . . . . . . 16
			4.4.1.2. Transitions from the Pruned (P) State . . . . . . . . . . . 17
			4.4.1.3. Transitions from the AckPending (AP) State . . . . . . . . . 18
			4.4.2. Downstream Prune, Join and Graft Messages . . . . . . . . . 19
			4.4.2.1. Transitions from the NoInfo State . . . . . . . . . . . . . 21
			4.4.2.2. Transitions from the PrunePending (PP) State . . . . . . . . 22
			4.4.2.3. Transitions from the Prune (P) State . . . . . . . . . . . . 23
			4.5. State Refresh . . . . . . . . . . . . . . . . . . . . . . . 24
			4.5.1. Forwarding of State Refresh Messages . . . . . . . . . . . . 24
			4.5.2. State Refresh Message Origination . . . . . . . . . . . . . 25
			4.5.2.1. Transitions from the NotOriginator (NO) State . . . . . . . 27
			4.5.2.2. Transitions from the Originator (O) State . . . . . . . . . 27
			4.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . . . 28
			4.6.1. Assert Metrics . . . . . . . . . . . . . . . . . . . . . . . 28
			4.6.2. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 29
			4.6.3. Assert State Macros . . . . . . . . . . . . . . . . . . . . 29
			4.6.4. (S,G) Assert Message State Machine . . . . . . . . . . . . . 29
			4.6.4.1. Transitions from NoInfo State . . . . . . . . . . . . . . . 31
			4.6.4.2. Transitions from Winner State . . . . . . . . . . . . . . . 32
			4.6.4.3. Transitions from Loser State . . . . . . . . . . . . . . . . 33
			4.6.5. Rationale for Assert Rules . . . . . . . . . . . . . . . . . 34
			4.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . 35
			4.7.1. PIM Header . . . . . . . . . . . . . . . . . . . . . . . . . 35
			4.7.2. Encoded Unicast Address . . . . . . . . . . . . . . . . . . 36
			4.7.3. Encoded Group Address . . . . . . . . . . . . . . . . . . . 36
			4.7.4. Encoded Source Address . . . . . . . . . . . . . . . . . . . 37
			4.7.5. Hello Message Format . . . . . . . . . . . . . . . . . . . . 38
			4.7.5.1. Hello Hold Time Option . . . . . . . . . . . . . . . . . . . 39
			4.7.5.2. LAN Prune Delay Option . . . . . . . . . . . . . . . . . . . 39
			4.7.5.3. Generation ID Option . . . . . . . . . . . . . . . . . . . . 40
			4.7.5.4. State Refresh Capable Option . . . . . . . . . . . . . . . . 40
			4.7.6. Join/Prune Message Format . . . . . . . . . . . . . . . . . 40
			4.7.7. Assert Message Format . . . . . . . . . . . . . . . . . . . 42
			4.7.8. Graft Message Format . . . . . . . . . . . . . . . . . . . . 43
			4.7.9. Graft Ack Message Format . . . . . . . . . . . . . . . . . . 43
			4.7.10. State Refresh Message Format . . . . . . . . . . . . . . . . 44
			4.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . . . 45
			5. Protocol Interaction Considerations . . . . . . . . . . . . 48
			5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . . . 48
			5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . . . 49
			5.3. Source Specific Multicast (SSM) Interactions . . . . . . . . 49
			5.4. Multicast Group Scope Boundary Interactions . . . . . . . . 49
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
			6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . 49
			6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . 50
			7. Security Considerations. . . . . . . . . . . . . . . . . . . 50
			7.1. Attacks Based on Forged Messages . . . . . . . . . . . . . . 50
			7.2. Non-cryptographic Authentication Mechanisms . . . . . . . . 51
			7.3. Authentication Using IPsec . . . . . . . . . . . . . . . . . 51
			7.4. Denial of Service Attacks . . . . . . . . . . . . . . . . . 52
			8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
			9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
	1. Introduction		1. Introduction
	This specification defines a multicast routing algorithm for multicast		This specification defines a multicast routing algorithm for multicast
	groups that are densely distributed across a network. This protocol		groups that are densely distributed across a network. This protocol
	does not have a topology discovery mechanism often used by a unicast		does not have a topology discovery mechanism often used by a unicast
	routing protocol. It employs the same packet formats sparse mode PIM		routing protocol. It employs the same packet formats sparse mode PIM
	(PIM-SM) uses. This protocol is called PIM - Dense Mode. The		(PIM-SM) uses. This protocol is called PIM - Dense Mode. The
	foundation of this design was largely built on Deering's early work on		foundation of this design was largely built on Deering's early work on
	IP multicast routing [1].		IP multicast routing [1].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
	interpreted as described in RFC 2119 and indicate requirement levels for		interpreted as described in RFC 2119 and indicate requirement levels for
	compliant PIM-DM implementations.		compliant PIM-DM implementations.
	3. Definitions		2.1. Definitions
	Multicast Routing Information Base (MRIB)		Multicast Routing Information Base (MRIB)
	This is the multicast topology table, which is typically derived from		This is the multicast topology table, which is typically derived from
	the unicast routing table, or routing protocols such as MBGP that		the unicast routing table, or routing protocols such as MBGP that
	carry multicast-specific topology information. PIM-DM uses the MRIB		carry multicast-specific topology information. PIM-DM uses the MRIB
	to make decisions regarding RPF interfaces.		to make decisions regarding RPF interfaces.
	Tree Information Base (TIB)		Tree Information Base (TIB)
	This is the collection of state maintained by a PIM router and created		This is the collection of state maintained by a PIM router and created
	by receiving PIM messages and IGMP information from local hosts. It		by receiving PIM messages and IGMP information from local hosts. It
	essentially stores the state of all multicast distribution trees at		essentially stores the state of all multicast distribution trees at
	that router.		that router.
	Reverse Path Forwarding (RPF)		Reverse Path Forwarding (RPF)
	RPF is a multicast forwarding mode where a data packet is accepted for		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		forwarding only if it is received on an interface used to reach the
	in unicast.		source in unicast.
	Upstream Interface		Upstream Interface
	Interface towards the source of the datagram. Also known as the RPF		Interface towards the source of the datagram. Also known as the RPF
	Interface.		Interface.
	Downstream Interface		Downstream Interface
	All interfaces that are not the upstream interface, including the		All interfaces that are not the upstream interface, including the
	router itself.		router itself.
	(S,G) Pair		(S,G) Pair
	Source S and destination group G associated with an IP packet.		Source S and destination group G associated with an IP packet.
	4. Pseudocode Notation		2.2. Pseudocode Notation
	We use set notation in several places in this specification.		We use set notation in several places in this specification.
	A (+) B		A (+) B
	is the union of two sets A and B.		is the union of two sets A and B.
	A (-) B		A (-) B
	are the elements of set A that are not in set B.		are the elements of set A that are not in set B.
	NULL		NULL
	skipping to change at page 4, line 21 ¶		skipping to change at page 5, line 28 ¶
	Note that (+) and (-) operators are NOT commutative, and must be		Note that (+) and (-) operators are NOT commutative, and must be
	conducted in the order specified.		conducted in the order specified.
	In addition we use C-like syntax:		In addition we use C-like syntax:
	= denotes assignment of a variable.		= denotes assignment of a variable.
	== denotes a comparison for equality.		== denotes a comparison for equality.
	!= denotes a comparison for inequality.		!= denotes a comparison for inequality.
	Braces { and } are used for grouping.		Braces { and } are used for grouping.
	5. PIM-DM Protocol Overview		3. PIM-DM Protocol Overview
	This section provides an overview of PIM-DM behavior. It is intended as		This section provides an overview of PIM-DM behavior. It is intended as
	an introduction to how PIM-DM works, and is NOT definitive. For the		an introduction to how PIM-DM works, and is NOT definitive. For the
	definitive specification, see Section 6 - Protocol Specification.		definitive specification, see Section 4 - Protocol Specification.
	PIM-DM assumes that when a source starts sending, all downstream systems		PIM-DM assumes that when a source starts sending, all downstream systems
	want to receive multicast datagrams. Initially, multicast datagrams are		want to receive multicast datagrams. Initially, multicast datagrams are
	flooded to all areas of the network. PIM-DM uses RPF to prevent looping		flooded to all areas of the network. PIM-DM uses RPF to prevent looping
	of multicast datagrams while flooding. If some areas of the network do		of multicast datagrams while flooding. If some areas of the network do
	not have group members, PIM-DM will prune off the forwarding branch by		not have group members, PIM-DM will prune off the forwarding branch by
	instantiating prune state.		instantiating prune state.
	Prune state has a finite lifetime. When that lifetime expires, data		Prune state has a finite lifetime. When that lifetime expires, data
	will again be forwarded down the previously pruned branch.		will again be forwarded down the previously pruned branch.
	skipping to change at page 5, line 21 ¶		skipping to change at page 6, line 28 ¶
	leads to any downstream members of a particular group. Additional		leads to any downstream members of a particular group. Additional
	overhead is chosen in favor of the simplification and flexibility gained		overhead is chosen in favor of the simplification and flexibility gained
	by not depending on a specific topology discovery protocol.		by not depending on a specific topology discovery protocol.
	PIM-DM differs from PIM-SM in two essential ways: 1) There are no		PIM-DM differs from PIM-SM in two essential ways: 1) There are no
	periodic joins transmitted, only explicitly triggered prunes and grafts.		periodic joins transmitted, only explicitly triggered prunes and grafts.
	2) There is no Rendezvous Point (RP). This is particularly important in		2) There is no Rendezvous Point (RP). This is particularly important in
	networks that cannot tolerate a single point of failure. (An RP is the		networks that cannot tolerate a single point of failure. (An RP is the
	root of a shared multicast distribution tree. For more details see [3]).		root of a shared multicast distribution tree. For more details see [3]).
	6. Protocol Specification		4. Protocol Specification
	The specification of PIM-DM is broken into several parts:		The specification of PIM-DM is broken into several parts:
	* Section 6.1 details the protocol state stored.		* Section 4.1 details the protocol state stored.
	* Section 6.2 specifies the data packet forwarding rules.		* Section 4.2 specifies the data packet forwarding rules.
	* Section 6.3 specifies generation and processing of Hello messages.		* Section 4.3 specifies generation and processing of Hello messages.
	* Section 6.4 specifies the Join, Prune and Graft generation and		* Section 4.4 specifies the Join, Prune and Graft generation and
	processing rules.		processing rules.
	* Section 6.5 specifies the State Refresh generation and forwarding		* Section 4.5 specifies the State Refresh generation and forwarding
	rules.		rules.
	* Section 6.6 specifies the Assert generation and processing rules.		* Section 4.6 specifies the Assert generation and processing rules.
	* Section 6.7 gives details on PIM-DM Packet Formats.		* Section 4.7 gives details on PIM-DM Packet Formats.
	* Section 6.8 summarizes PIM-DM timers and their defaults.		* Section 4.8 summarizes PIM-DM timers and their defaults.
	6.1 PIM Protocol State		4.1. PIM Protocol State
	This section specifies all the protocol states that a PIM-DM		This section specifies all the protocol states that a PIM-DM
	implementation should maintain in order to function correctly. We term		implementation should maintain in order to function correctly. We term
	this state the Tree Information Base or TIB, as it holds the state of		this state the Tree Information Base or TIB, as it holds the state of
	all the multicast distribution trees at this router. In this		all the multicast distribution trees at this router. In this
	specification, we define PIM-DM mechanisms in terms of the TIB.		specification, we define PIM-DM mechanisms in terms of the TIB.
	However, only a very simple implementation would actually implement		However, only a very simple implementation would actually implement
	packet forwarding operations in terms of this state. Most		packet forwarding operations in terms of this state. Most
	implementations will use this state to build a multicast forwarding		implementations will use this state to build a multicast forwarding
	table, which would then be updated when the relevant state in the TIB		table, which would then be updated when the relevant state in the TIB
	changes.		changes.
			Unlike PIM-SM, PIM-DM does not maintain a keepalive timer associated
			with each (S,G) route. Within PIM-DM, route and state information
			associated with an (S,G) entry MUST be maintained as long as any timer
			associated with that (S,G) entry is active. When no timer associated
			with an (S,G) entry is active, all information concerning that (S,G)
			route may be discarded.
	Although we specify precisely the state to be kept, this does not mean		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.		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		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		to specify the router's behavior. A PIM-DM implementation is free to
	hold whatever internal state it requires, and will still be conformant		hold whatever internal state it requires, and will still be conformant
	with this specification so long as it results in the same externally		with this specification so long as it results in the same externally
	visible protocol behavior as an abstract router that holds the following		visible protocol behavior as an abstract router that holds the following
	state.		state.
	6.1.1 General Purpose State		4.1.1. General Purpose State
	A router stores the following non-group-specific state:		A router stores the following non-group-specific state:
	For each interface:		For each interface:
	Hello Timer (HT)		Hello Timer (HT)
	State Refresh Capable		State Refresh Capable
	LAN Delay Enabled		LAN Delay Enabled
	Propagation Delay (PD)		Propagation Delay (PD)
	Override Interval (OI)		Override Interval (OI)
	Neighbor State:		Neighbor State:
	For each neighbor:		For each neighbor:
	Information from neighbor's Hello		Information from neighbor's Hello
	Neighbor's Gen ID.		Neighbor's Gen ID.
	Neighbor's LAN Prune Delay		Neighbor's LAN Prune Delay
	Neighbor's Override Interval		Neighbor's Override Interval
	Neighbor's State Refresh Capability		Neighbor's State Refresh Capability
	Neighbor Liveness Timer (NLT)		Neighbor Liveness Timer (NLT)
	6.1.2 (S,G) State		4.1.2. (S,G) State
	For every source/group pair (S,G), a router stores the following state:		For every source/group pair (S,G), a router stores the following state:
	(S,G) state:		(S,G) state:
	For each interface:		For each interface:
	Local Membership:		Local Membership:
	State: One of {"NoInfo", "Include"}		State: One of {"NoInfo", "Include"}
	PIM (S,G) Prune State:		PIM (S,G) Prune State:
	State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending" (PP)}		State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending" (PP)}
	skipping to change at page 7, line 5 ¶		skipping to change at page 8, line 24 ¶
	State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F),		State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F),
	"AckPending" (AP) }		"AckPending" (AP) }
	GraftRetry Timer (GRT)		GraftRetry Timer (GRT)
	Override Timer (OT)		Override Timer (OT)
	Prune Limit Timer (PLT)		Prune Limit Timer (PLT)
	Originator State:		Originator State:
	Source Active Timer (SAT)		Source Active Timer (SAT)
	State Refresh Timer (SRT)		State Refresh Timer (SRT)
	6.1.3 State Summarization Macros		4.1.3. State Summarization Macros
	Using the state defined above, the following "macros" are defined and		Using the state defined above, the following "macros" are defined and
	will be used in the descriptions of the state machines and pseudocode in		will be used in the descriptions of the state machines and pseudocode in
	the following sections.		the following sections.
	The most important macros are those defining the outgoing interface list		The most important macros are those defining the outgoing interface list
	(or "olist") for the relevant state.		(or "olist") for the relevant state.
	immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+)		immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+)
	( pim_include(*,G) (-) pim_exclude(S,G) ) (+)		( pim_include(*,G) (-) pim_exclude(S,G) ) (+)
	skipping to change at page 8, line 28 ¶		skipping to change at page 9, line 52 ¶
	neighbor RPF'(S,G) {		neighbor RPF'(S,G) {
	if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) {		if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) {
	return AssertWinner(S, G, RPF_interface(S) )		return AssertWinner(S, G, RPF_interface(S) )
	} else {		} else {
	return MRIB.next_hop( S )		return MRIB.next_hop( S )
	}		}
	}		}
	The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine		The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine
	(in section 6.6) for (S,G) on interface I is in the "I am Assert Loser"		(in section 4.6) for (S,G) on interface I is in the "I am Assert Loser"
	state.		state.
	6.2 Data Packet Forwarding Rules		4.2. Data Packet Forwarding Rules
	The PIM-DM packet forwarding rules are defined below in pseudocode.		The PIM-DM packet forwarding rules are defined below in pseudocode.
	iif is the incoming interface of the packet.		iif is the incoming interface of the packet.
	S is the source address of the packet.		S is the source address of the packet.
	G is the destination address of the packet (group address).		G is the destination address of the packet (group address).
	RPF_interface(S) is the interface the MRIB indicates would be used to		RPF_interface(S) is the interface the MRIB indicates would be used to
	route packets to S.		route packets to S.
	First, an RPF check MUST be performed to determine whether the packet		First, an RPF check MUST be performed to determine whether the packet
	skipping to change at page 9, line 17 ¶		skipping to change at page 10, line 40 ¶
	if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) {		if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) {
	oiflist = olist(S,G)		oiflist = olist(S,G)
	} else {		} else {
	oiflist = NULL		oiflist = NULL
	}		}
	forward packet on all interfaces in oiflist		forward packet on all interfaces in oiflist
	This pseudocode employs the following "macro" definition:		This pseudocode employs the following "macro" definition:
	UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in		UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in
	section 6.4.1.		section 4.4.1.
	6.3 Hello Messages		4.3. Hello Messages
	This section describes the generation and processing of Hello messages.		This section describes the generation and processing of Hello messages.
	6.3.1 Sending Hello Messages		4.3.1. Sending Hello Messages
	PIM-DM uses Hello messages to detect other PIM routers. Hello messages		PIM-DM uses Hello messages to detect other PIM routers. Hello messages
	are sent periodically on each PIM enabled interface. Hello messages are		are sent periodically on each PIM enabled interface. Hello messages are
	multicast to the ALL-PIM-ROUTERS group. When PIM is enabled on an		multicast to the ALL-PIM-ROUTERS group. When PIM is enabled on an
	interface or a router first starts, the Hello Timer (HT) MUST be set to		interface or a router first starts, the Hello Timer (HT) MUST be set to
	random value between 0 and Triggered_Hello_Delay. This prevents		random value between 0 and Triggered_Hello_Delay. This prevents
	synchronization of Hello messages if multiple routers are powered on		synchronization of Hello messages if multiple routers are powered on
	simultaneously.		simultaneously.
	After the initial Hello message, a Hello message MUST be sent every		After the initial Hello message, a Hello message MUST be sent every
	Hello_Period. A single Hello timer MAY be used to trigger sending		Hello_Period. A single Hello timer MAY be used to trigger sending
	Hello messages on all active interfaces. The Hello Timer SHOULD NOT be		Hello messages on all active interfaces. The Hello Timer SHOULD NOT be
	reset except when it expires.		reset except when it expires.
	6.3.2 Receiving Hello Messages		4.3.2. Receiving Hello Messages
	When a Hello message is received, the receiving router SHALL record the		When a Hello message is received, the receiving router SHALL record the
	receiving interface, the sender and any information contained in		receiving interface, the sender and any information contained in
	recognized options. This information is retained for a number of		recognized options. This information is retained for a number of
	seconds in the Hold Time field of the Hello Message. If a new Hello		seconds in the Hold Time field of the Hello Message. If a new Hello
	message is received from a particular neighbor N, the Neighbor Liveness		message is received from a particular neighbor N, the Neighbor Liveness
	Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime. If		Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime. If
	a Hello message is received from a new neighbor, the receiving router		a Hello message is received from a new neighbor, the receiving router
	SHOULD send its own Hello message after a random delay between 0 and		SHOULD send its own Hello message after a random delay between 0 and
	Triggered_Hello_Delay.		Triggered_Hello_Delay.
	6.3.3 Hello Message Hold Time		4.3.3. Hello Message Hold Time
	The Hold Time in the Hello Message should be set to a value that can		The Hold Time in the Hello Message should be set to a value that can
	reasonably be expected to keep the Hello active until a new Hello		reasonably be expected to keep the Hello active until a new Hello
	message is received. On most links, this will be 3.5 times the value of		message is received. On most links, this will be 3.5 times the value of
	Hello_Period.		Hello_Period.
	If the Hold Time is set to '0xffff', the receiving router MUST NOT time		If the Hold Time is set to '0xffff', the receiving router MUST NOT time
	out that Hello message. This feature might be used for on-demand links		out that Hello message. This feature might be used for on-demand links
	to avoid keeping the link up with periodic Hello messages.		to avoid keeping the link up with periodic Hello messages.
	If a Hold Time of '0' is received, the corresponding neighbor state is		If a Hold Time of '0' is received, the corresponding neighbor state is
	expired immediately. When a PIM router takes an interface down or		expired immediately. When a PIM router takes an interface down or
	changes IP address, a Hello message with a zero Hold Time SHOULD be sent		changes IP address, a Hello message with a zero Hold Time SHOULD be sent
	immediately (with the old IP address if the IP address is changed) to		immediately (with the old IP address if the IP address is changed) to
	cause any PIM neighbors to remove the old information immediately.		cause any PIM neighbors to remove the old information immediately.
	6.3.4 Handling Router Failures		4.3.4. Handling Router Failures
	If a Hello message is received from an active downstream neighbor with		If a Hello message is received from an active neighbor with a different
	a different Generation ID (GenID), the neighbor has restarted and may		Generation ID (GenID), the neighbor has restarted and may not contain
	not contain the correct (S,G) state. A Hello message SHOULD be sent		the correct (S,G) state. A Hello message SHOULD be sent after a random
	after a random delay between 0 and Triggered_Hello_Delay (see 6.8.1)		delay between 0 and Triggered_Hello_Delay (see 4.8) before any other
	before any other messages are sent. The router MAY replay the last		messages are sent. If the neighbor is downstream, the router MAY
	State Refresh message for any (S,G) pairs for which it is the Assert		replay the last State Refresh message for any (S,G) pairs for which it
	Winner indicating Prune and Assert status to the downstream router.		is the Assert Winner indicating Prune and Assert status to the
	These State Refresh messages SHOULD be sent out immediately after the		downstream router. These State Refresh messages SHOULD be sent out
	Hello message.		immediately after the Hello message. If the neighbor is the upstream
			neighbor for an (S,G) entry, the router MAY cancel its Prune Limit
			Timer to permit sending a prune and reestablishing a Pruned state in the
			upstream router.
	Upon startup, a router MAY use any State Refresh messages received		Upon startup, a router MAY use any State Refresh messages received
	within Hello_Period of its first Hello message on an interface to		within Hello_Period of its first Hello message on an interface to
	establish state information. The State Refresh source will be the		establish state information. The State Refresh source will be the
	RPF'(S), and Prune status for all interfaces will be set according to		RPF'(S), and Prune status for all interfaces will be set according to
	the Prune Indicator bit in the State Refresh message. If the Prune		the Prune Indicator bit in the State Refresh message. If the Prune
	Indicator is set, the router SHOULD set the PruneLimitTimer to		Indicator is set, the router SHOULD set the PruneLimitTimer to
	Prune_Holdtime and set the PruneTimer on all downstream interfaces to		Prune_Holdtime and set the PruneTimer on all downstream interfaces to
	the State Refresh's Interval times two. The router SHOULD then		the State Refresh's Interval times two. The router SHOULD then
	propagate the State Refresh as described in section 6.5.1.		propagate the State Refresh as described in section 4.5.1.
	6.3.5 Reducing Prune Propagation Delay on LANs		4.3.5. Reducing Prune Propagation Delay on LANs
	If all routers on a LAN support the LAN Prune Delay option, then the PIM		If all routers on a LAN support the LAN Prune Delay option, then the PIM
	routers on that LAN will use the values received to adjust its		routers on that LAN will use the values received to adjust their
	J/P_Override_Interval on that interface and the interface is LAN Delay		J/P_Override_Interval on that interface and the interface is LAN Delay
	Enabled. Briefly, to avoid synchronization of Prune Override (Join)		Enabled. Briefly, to avoid synchronization of Prune Override (Join)
	messages when multiple downstream routers share a multi-access link,		messages when multiple downstream routers share a multi-access link,
	sending of such messages is delayed by a small random amount of time.		sending of such messages is delayed by a small random amount of time.
	The period of randomization is configurable and has a default value of 3		The period of randomization is configurable and has a default value of 3
	seconds.		seconds.
	Each router on the LAN expresses its view of the amount of randomization		Each router on the LAN expresses its view of the amount of randomization
	necessary in the Override Interval field of the LAN Prune Delay option.		necessary in the Override Interval field of the LAN Prune Delay option.
	When all routers on a LAN use the LAN Prune Delay Option, all routers on		When all routers on a LAN use the LAN Prune Delay Option, all routers on
	skipping to change at page 11, line 14 ¶		skipping to change at page 13, line 5 ¶
	PIM implementers should enforce a lower bound on the permitted values		PIM implementers should enforce a lower bound on the permitted values
	for this delay to allow for scheduling and processing delays within		for this delay to allow for scheduling and processing delays within
	their router. Such delays may cause received messages to be processed		their router. Such delays may cause received messages to be processed
	later as well as triggered messages to be sent later than intended.		later as well as triggered messages to be sent later than intended.
	Setting this LAN Prune Delay to too low a value may result in temporary		Setting this LAN Prune Delay to too low a value may result in temporary
	forwarding outages because a downstream router will not be able to		forwarding outages because a downstream router will not be able to
	override a neighbor's prune message before the upstream neighbor stops		override a neighbor's prune message before the upstream neighbor stops
	forwarding.		forwarding.
	6.4 PIM-DM Prune, Join and Graft Messages		4.4. PIM-DM Prune, Join and Graft Messages
	This section describes the generation and processing of PIM-DM Join,		This section describes the generation and processing of PIM-DM Join,
	Prune and Graft messages. Prune messages are sent towards the upstream		Prune and Graft messages. Prune messages are sent towards the upstream
	neighbor for S to indicate that traffic from S addressed to group G is		neighbor for S to indicate that traffic from S addressed to group G is
	not desired. In the case of two downstream routers A and B, where A		not desired. In the case of two downstream routers A and B, where A
	wishes to continue receiving data and B does not, A will send a Join in		wishes to continue receiving data and B does not, A will send a Join in
	response to B's Prune to override the Prune. This is the only situation		response to B's Prune to override the Prune. This is the only situation
	in PIM-DM in which a Join message is used. Finally, a Graft message is		in PIM-DM in which a Join message is used. Finally, a Graft message is
	used to re-join a previously pruned branch to the delivery tree.		used to re-join a previously pruned branch to the delivery tree.
	6.4.1 Upstream Prune, Join and Graft Messages		4.4.1. Upstream Prune, Join and Graft Messages
	The Upstream(S,G) state machine for sending Prune, Graft and Join		The Upstream(S,G) state machine for sending Prune, Graft and Join
	messages is given below. There are three states.		messages is given below. There are three states.
	Forwarding (F)		Forwarding (F)
	This is the starting state of the Upsteam(S,G) state machine. The		This is the starting state of the Upsteam(S,G) state machine. The
	state machine is in this state if it just started or if		state machine is in this state if it just started or if
	oiflist(S,G) != NULL.		oiflist(S,G) != NULL.
	Pruned(P)		Pruned(P)
	skipping to change at page 11, line 53 ¶		skipping to change at page 13, line 44 ¶
	should again be forwarded. A Graft message has been sent to RPF'(S)		should again be forwarded. A Graft message has been sent to RPF'(S)
	but a Graft Ack message has not yet been received.		but a Graft Ack message has not yet been received.
	In addition there are three state-machine-specific timers:		In addition there are three state-machine-specific timers:
	GraftRetry Timer (GRT(S,G))		GraftRetry Timer (GRT(S,G))
	This timer is set when a Graft is sent upstream. If a corresponding		This timer is set when a Graft is sent upstream. If a corresponding
	GraftAck is not received before the timer expires, then another		GraftAck is not received before the timer expires, then another
	Graft is sent and the GraftRetry Timer is reset. The timer is		Graft is sent and the GraftRetry Timer is reset. The timer is
	stopped when a Graft Ack message is received. This timer is normally		stopped when a Graft Ack message is received. This timer is normally
	set to Graft_Retry_Period (see 6.8.1).		set to Graft_Retry_Period (see 4.8).
	Override Timer (OT(S,G))		Override Timer (OT(S,G))
	This timer is set when a Prune(S,G) is received on the upstream		This timer is set when a Prune(S,G) is received on the upstream
	interface where olist(S,G) != NULL. When the timer expires, a		interface where olist(S,G) != NULL. When the timer expires, a
	Join(S,G) message is sent on the upstream interface. This timer is		Join(S,G) message is sent on the upstream interface. This timer is
	normally set to t_override (see 6.8.1).		normally set to t_override (see 4.8).
	Prune Limit Timer (PLT(S,G))		Prune Limit Timer (PLT(S,G))
	This timer is used to rate-limit Prunes on a LAN. It is only used		This timer is used to rate-limit Prunes on a LAN. It is only used
	when the Upstream(S,G) state machine is in the Pruned state. A Prune		when the Upstream(S,G) state machine is in the Pruned state. A Prune
	cannot be sent if this timer is running. This timer is normally set		cannot be sent if this timer is running. This timer is normally set
	to t_limit (see 6.8.1)		to t_limit (see 4.8).
	+-------------+ +-------------+		+-------------+ +-------------+
	| | olist == NULL | |		| | olist == NULL | |
	| Forward |----------------------->| Pruned |		| Forward |----------------------->| Pruned |
	| | | |		| | | |
	+-------------+ +-------------+		+-------------+ +-------------+
	^ | ^ |		^ | ^ |
	| | | |		| | | |
	| |RPF`(S) Changes olist == NULL| |		| |RPF`(S) Changes olist == NULL| |
	| | | |		| | | |
	skipping to change at page 13, line 4 ¶		skipping to change at page 14, line 52 ¶
	| from RPF`(S) AND | | Prune(S,G) | GRT(S,G) |		| from RPF`(S) AND | | Prune(S,G) | GRT(S,G) |
	| Prune Indicator == 0 AND | |Set PLT(S,G)| |		| Prune Indicator == 0 AND | |Set PLT(S,G)| |
	| PLT(S,G) not running | | | |		| PLT(S,G) not running | | | |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel |		| See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel |
	| | OT(S,G) | | OT(S,G) |		| | OT(S,G) | | OT(S,G) |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| See Prune(S,G) | ->F Set | ->P |->AP Set |		| See Prune(S,G) | ->F Set | ->P |->AP Set |
	| | OT(S,G) | | OT(S,G) |		| | OT(S,G) | | OT(S,G) |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
			| OT(S,G) Expires | ->F Send | N/A |->AP Send |
			| | Join(S,G) | | Join(S,G) |
			+-------------------------------+------------+------------+------------+
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| | Previous State |		| | Previous State |
	| +------------+------------+------------+		| +------------+------------+------------+
	| Event | Forwarding | Pruned | AckPending |		| Event | Forwarding | Pruned | AckPending |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| OT(S,G) Expires | ->F Send | N/A |->AP Send |
	| | Join(S,G) | | Join(S,G) |
	+-------------------------------+------------+------------+------------+
	| olist(S,G)->NULL | ->P Send | N/A |->P Send |		| olist(S,G)->NULL | ->P Send | N/A |->P Send |
	| | Prune(S,G) | | Prune(S,G) |		| | Prune(S,G) | | Prune(S,G) |
	| |Set PLT(S,G)| |Set PLT(S,G)|		| |Set PLT(S,G)| |Set PLT(S,G)|
	| | | | Cancel |		| | | | Cancel |
	| | | | GRT(S,G) |		| | | | GRT(S,G) |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| olist(S,G)->non-NULL | N/A | ->AP Send | N/A |		| olist(S,G)->non-NULL | N/A | ->AP Send | N/A |
	| | | Graft(S,G) | |		| | | Graft(S,G) | |
	| | |Set GRT(S,G)| |		| | |Set GRT(S,G)| |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	skipping to change at page 13, line 46 ¶		skipping to change at page 15, line 42 ¶
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| Receive GraftAck(S,G) from | ->F | ->P |->F Cancel |		| Receive GraftAck(S,G) from | ->F | ->P |->F Cancel |
	| RPF'(S) | | | GRT(S,G) |		| RPF'(S) | | | GRT(S,G) |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack		The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack
	message targeted to this router's address on the incoming interface for		message targeted to this router's address on the incoming interface for
	the (S,G) entry. If the destination address is not correct, the state		the (S,G) entry. If the destination address is not correct, the state
	transitions in this state machine must not occur.		transitions in this state machine must not occur.
	Transitions from the Forwarding (F) State		4.4.1.1. Transitions from the Forwarding (F) State
	When the Upstream(S,G) state machine is in the Forwarding (F) state, the		When the Upstream(S,G) state machine is in the Forwarding (F) state, the
	following events may trigger a transition:		following events may trigger a transition:
	Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S		Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S
	NOT directly connected		NOT directly connected
	The Upstream(S,G) state machine MUST transition to the Pruned (P)		The Upstream(S,G) state machine MUST transition to the Pruned (P)
	state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit		state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit
	seconds.		seconds.
	skipping to change at page 15, line 5 ¶		skipping to change at page 17, line 5 ¶
	changes to RPF_Interface(S). The Upstream(S,G) state machine MUST		changes to RPF_Interface(S). The Upstream(S,G) state machine MUST
	transition to the AckPending (AP) state, unicast a Graft to the new		transition to the AckPending (AP) state, unicast a Graft to the new
	RPF'(S) and set the GraftRetry Timer (GRT(S,G)) to		RPF'(S) and set the GraftRetry Timer (GRT(S,G)) to
	Graft_Retry_Period.		Graft_Retry_Period.
	RPF'(S) Changes AND olist(S,G) is NULL		RPF'(S) Changes AND olist(S,G) is NULL
	Unicast routing or Assert state causes RPF'(S) to change, including		Unicast routing or Assert state causes RPF'(S) to change, including
	changes to RPF_Interface(S). The Upstream(S,G) state machine MUST		changes to RPF_Interface(S). The Upstream(S,G) state machine MUST
	transition to the Pruned (P) state.		transition to the Pruned (P) state.
	Transitions from the Pruned (P) State		4.4.1.2. Transitions from the Pruned (P) State
	When the Upstream(S,G) state machine is in the Pruned (P) state, the		When the Upstream(S,G) state machine is in the Pruned (P) state, the
	following events may trigger a transition:		following events may trigger a transition:
	Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT		Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT
	directly connected		directly connected
	Either another router on the LAN desires traffic from S addressed to		Either another router on the LAN desires traffic from S addressed to
	G or a previous Prune was lost. In order to prevent generating a		G or a previous Prune was lost. In order to prevent generating a
	Prune(S,G) in response to every data packet, the PruneLimit Timer		Prune(S,G) in response to every data packet, the PruneLimit Timer
	(PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs to		(PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs to
	skipping to change at page 16, line 5 ¶		skipping to change at page 18, line 9 ¶
	RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected		RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected
	Unicast routing or Assert state causes RPF'(S) to change, including		Unicast routing or Assert state causes RPF'(S) to change, including
	changes to RPF_Interface(S). The Upstream(S,G) state machine stays		changes to RPF_Interface(S). The Upstream(S,G) state machine stays
	in the Pruned (P) state and MUST cancel the PLT(S,G) timer.		in the Pruned (P) state and MUST cancel the PLT(S,G) timer.
	S becomes directly connected		S becomes directly connected
	Unicast routing changed so that S is directly connected. The		Unicast routing changed so that S is directly connected. The
	Upstream(S,G) state machine remains in the Pruned (P) state.		Upstream(S,G) state machine remains in the Pruned (P) state.
	Transitions from the AckPending (AP) State		4.4.1.3. Transitions from the AckPending (AP) State
	When the Upstream(S,G) state machine is in the AckPending (AP) state,		When the Upstream(S,G) state machine is in the AckPending (AP) state,
	the following events may trigger a transition:		the following events may trigger a transition:
	State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1		State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1
	The Upstream(S,G) state machine remains in an AckPending state. The		The Upstream(S,G) state machine remains in an AckPending state. The
	router must override the upstream router's Prune state after a short		router must override the upstream router's Prune state after a short
	random interval. If OT(S,G) is not running and the Prune Indicator		random interval. If OT(S,G) is not running and the Prune Indicator
	bit equals one, the router MUST set OT(S,G) to t_override seconds.		bit equals one, the router MUST set OT(S,G) to t_override seconds.
	skipping to change at page 17, line 29 ¶		skipping to change at page 19, line 37 ¶
	Another Graft message for (S,G) SHOULD be unicasted to RPF'(S) and		Another Graft message for (S,G) SHOULD be unicasted to RPF'(S) and
	the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is		the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is
	RECOMMENDED that the router retry a configured number of times		RECOMMENDED that the router retry a configured number of times
	before ceasing retries.		before ceasing retries.
	See GraftAck(S,G) from RPF'(S)		See GraftAck(S,G) from RPF'(S)
	A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be		A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be
	cancelled and the Upstream(S,G) state machine MUST transition to the		cancelled and the Upstream(S,G) state machine MUST transition to the
	Forwarding(F) state.		Forwarding(F) state.
	6.4.2 Downstream Prune, Join and Graft Messages		4.4.2 Downstream Prune, Join and Graft Messages
	The Prune(S,G) Downstream state machine for receiving Prune, Join and		The Prune(S,G) Downstream state machine for receiving Prune, Join and
	Graft messages on interface I is given below. This state machine MUST		Graft messages on interface I is given below. This state machine MUST
	always be in the NoInfo state on the upstream interface. It contains		always be in the NoInfo state on the upstream interface. It contains
	three states.		three states.
	NoInfo(NI)		NoInfo(NI)
	The interface has no (S,G) Prune state and neither the Prune timer		The interface has no (S,G) Prune state and neither the Prune timer
	(PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running.		(PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running.
	skipping to change at page 18, line 27 ¶		skipping to change at page 20, line 39 ¶
	| | |		| | |
	| |Rcv Prune |		| |Rcv Prune |
	| | |		| | |
	| | +-------------+ |		| | +-------------+ |
	| +---------| | |		| +---------| | |
	| | NoInfo |<-------------+		| | NoInfo |<-------------+
	+------------>| | Rcv Join/Graft OR		+------------>| | Rcv Join/Graft OR
	Rcv Join/Graft OR +-------------+ PT Expires OR		Rcv Join/Graft OR +-------------+ PT Expires OR
	RPF_Interface(S)->I RPF_Interface(S)->I		RPF_Interface(S)->I RPF_Interface(S)->I
	Figure 2: Prune(S,G) Downstream State Machine		Figure 2: Downstream Interface State Machine
	In tabular form, the state machine is:		In tabular form, the state machine is:
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| | Previous State |		| | Previous State |
	+ +------------+------------+------------+		+ +------------+------------+------------+
	| Event | No Info | PrunePend | Pruned |		| Event | No Info | PrunePend | Pruned |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| Receive Prune(S,G) |->PP Set |->PP |->P Reset |		| Receive Prune(S,G) |->PP Set |->PP |->P Reset |
	| | PPT(S,G,I) | | PT(S,G,I) |		| | PPT(S,G,I) | | PT(S,G,I) |
	skipping to change at page 19, line 4 ¶		skipping to change at page 21, line 31 ¶
	| | | PPT(S,G,I) | PT(S,G,I) |		| | | PPT(S,G,I) | PT(S,G,I) |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| PPT(S,G) Expires | N/A |->P Set | N/A |		| PPT(S,G) Expires | N/A |->P Set | N/A |
	| | | PT(S,G,I) | |		| | | PT(S,G,I) | |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| PT(S,G) Expires | N/A | N/A |->NI |		| PT(S,G) Expires | N/A | N/A |->NI |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel |		| RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel |
	| | | PPT(S,G,I) | PT(S,G,I) |		| | | PPT(S,G,I) | PT(S,G,I) |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
			| Send State Refresh(S,G) out I |->NI |->PP |->P Reset |
			| | | | PT(S,G,I) |
			+-------------------------------+------------+------------+------------+
	The transition events "Receive Graft(S,G)", "Receive Prune(S,G)" and		The transition events "Receive Graft(S,G)", "Receive Prune(S,G)" and
	"Receive Join(S,G)" denote receiving a Graft, Prune or Join message in		"Receive Join(S,G)" denote receiving a Graft, Prune or Join message in
	which this router's address on I is contained in the message's upstream		which this router's address on I is contained in the message's upstream
	neighbor field. If the upstream neighbor field does not match this		neighbor field. If the upstream neighbor field does not match this
	router's address on I, then these state transitions in this state		router's address on I, then these state transitions in this state
	machine must not occur.		machine must not occur.
	Transitions from the NoInfo State		4.4.2.1. Transitions from the NoInfo State
	When the Prune(S,G) Downstream state machine is in the NoInfo (NI)		When the Prune(S,G) Downstream state machine is in the NoInfo (NI)
	state, the following events may trigger a transition:		state, the following events may trigger a transition:
	Receive Prune(S,G)		Receive Prune(S,G)
	A Prune(S,G) is received on interface I with the upstream neighbor		A Prune(S,G) is received on interface I with the upstream neighbor
	field set to the router's address on I. The Prune(S,G) Downstream		field set to the router's address on I. The Prune(S,G) Downstream
	state machine on interface I MUST transition to the PrunePending		state machine on interface I MUST transition to the PrunePending
	(PP) state. The PrunePending Timer (PPT(S,G,I)) MUST be set to		(PP) state. The PrunePending Timer (PPT(S,G,I)) MUST be set to
	J/P_Override_Interval if the router has more than one neighbor on I.		J/P_Override_Interval if the router has more than one neighbor on I.
	skipping to change at page 19, line 34 ¶		skipping to change at page 22, line 12 ¶
	set the PPT(S,G,I) to zero, effectively transitioning immediately to		set the PPT(S,G,I) to zero, effectively transitioning immediately to
	the Pruned (P) state.		the Pruned (P) state.
	Receive Graft(S,G)		Receive Graft(S,G)
	A Graft(S,G) is received on the interface I with the upstream		A Graft(S,G) is received on the interface I with the upstream
	neighbor field set to the router's address on I. The Prune(S,G)		neighbor field set to the router's address on I. The Prune(S,G)
	Downstream state machine on interface I stays in the NoInfo (NI)		Downstream state machine on interface I stays in the NoInfo (NI)
	state. A GraftAck(S,G) MUST be unicasted to the originator of the		state. A GraftAck(S,G) MUST be unicasted to the originator of the
	Graft(S,G) message.		Graft(S,G) message.
	Transitions from the PrunePending (PP) State		4.4.2.2. Transitions from the PrunePending (PP) State
	When the Prune(S,G) downstream state machine is in the PrunePending (PP)		When the Prune(S,G) downstream state machine is in the PrunePending (PP)
	state, the following events may trigger a transition.		state, the following events may trigger a transition.
	Receive Join(S,G)		Receive Join(S,G)
	A Join(S,G) is received on interface I with the upstream neighbor		A Join(S,G) is received on interface I with the upstream neighbor
	field set to the router's address on I. The Prune(S,G) Downstream		field set to the router's address on I. The Prune(S,G) Downstream
	state machine on interface I MUST transition to the NoInfo (NI)		state machine on interface I MUST transition to the NoInfo (NI)
	state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.		state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
	skipping to change at page 20, line 18 ¶		skipping to change at page 22, line 43 ¶
	Prune(S,G) Downstream state machine on interface I MUST transition		Prune(S,G) Downstream state machine on interface I MUST transition
	to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and		to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and
	MUST be initialized to the received Prune_Hold_Time minus		MUST be initialized to the received Prune_Hold_Time minus
	J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has		J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has
	more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G)		more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G)
	message multicast by the upstream router to a LAN with itself as the		message multicast by the upstream router to a LAN with itself as the
	Upstream Neighbor. Its purpose is to add additional reliability so		Upstream Neighbor. Its purpose is to add additional reliability so
	that if a Join that should have overridden the Prune is lost locally		that if a Join that should have overridden the Prune is lost locally
	on the LAN, then the PruneEcho(S,G) may be received and trigger a		on the LAN, then the PruneEcho(S,G) may be received and trigger a
	new Join message . A PruneEcho(S,G) is OPTIONAL on an interface		new Join message . A PruneEcho(S,G) is OPTIONAL on an interface
	with only one PIM neighbor.		with only one PIM neighbor. In addition, the router MUST evaluate any
			possible transitions in the Upstream(S,G) state machine.
	RPF_Interface(S) becomes interface I		RPF_Interface(S) becomes interface I
	The upstream interface for S has changed. The Prune(S,G) Downstream		The upstream interface for S has changed. The Prune(S,G) Downstream
	state machine on interface I MUST transition to the NoInfo (NI)		state machine on interface I MUST transition to the NoInfo (NI)
	state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.		state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled.
	Transitions from the Prune (P) State		4.4.2.3. Transitions from the Prune (P) State
	When the Prune(S,G) Downstream state machine is in the Pruned (P) state,		When the Prune(S,G) Downstream state machine is in the Pruned (P) state,
	the following events may trigger a transition.		the following events may trigger a transition.
	Receive Prune(S,G)		Receive Prune(S,G)
	A Prune(S,G) is received on the interface I with the upstream		A Prune(S,G) is received on the interface I with the upstream
	neighbor field set to the router's address on I. The Prune(S,G)		neighbor field set to the router's address on I. The Prune(S,G)
	Downstream state machine on interface I remains in the Pruned (P)		Downstream state machine on interface I remains in the Pruned (P)
	state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime		state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime
	contained in the Prune(S,G) message if it is greater than the		contained in the Prune(S,G) message if it is greater than the
	skipping to change at page 21, line 10 ¶		skipping to change at page 23, line 46 ¶
	to flood data from S addressed to group G onto interface I. The		to flood data from S addressed to group G onto interface I. The
	Prune(S,G) Downstream state machine on interface I MUST transition		Prune(S,G) Downstream state machine on interface I MUST transition
	to the NoInfo (NI) state. The router MUST evaluate any possible		to the NoInfo (NI) state. The router MUST evaluate any possible
	transitions in the Upstream(S,G) state machine.		transitions in the Upstream(S,G) state machine.
	RPF_Interface(S) becomes interface I		RPF_Interface(S) becomes interface I
	The upstream interface for S has changed. The Prune(S,G) Downstream		The upstream interface for S has changed. The Prune(S,G) Downstream
	state machine on interface I MUST transition to the NoInfo (NI)		state machine on interface I MUST transition to the NoInfo (NI)
	state. The PruneTimer (PT(S,G,I)) MUST be cancelled.		state. The PruneTimer (PT(S,G,I)) MUST be cancelled.
	6.5 State Refresh		Send State Refresh(S,G) out interface I
			The router has refreshed the Prune(S,G) state on interface I. The
			router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime from
			an active Prune received on interface I. The Holdtime used SHOULD
			be the largest active one, but MAY be the most recently received
			active Prune Holdtime.
			4.5. State Refresh
	This section describes the major portions of the state refresh		This section describes the major portions of the state refresh
	mechanism.		mechanism.
	6.5.1 Forwarding of State Refresh Messages		4.5.1. Forwarding of State Refresh Messages
	When a State Refresh message, SRM, is received, it is forwarded		When a State Refresh message, SRM, is received, it is forwarded
	according to the following pseudo-code.		according to the following pseudo-code.
	if (iif != RPF_interface(S))		if (iif != RPF_interface(S))
	return;		return;
	if (RPF'(S) != srcaddr(SRM))		if (RPF'(S) != srcaddr(SRM))
	return;		return;
	if (StateRefreshRateLimit(S,G) == TRUE)		if (StateRefreshRateLimit(S,G) == TRUE)
	return;		return;
	skipping to change at page 22, line 38 ¶		skipping to change at page 25, line 37 ¶
	Threshold(I) returns the minimum TTL that a packet must have before it		Threshold(I) returns the minimum TTL that a packet must have before it
	can be transmitted on interface I.		can be transmitted on interface I.
	srcaddr(SRM) returns the source address contained in the network		srcaddr(SRM) returns the source address contained in the network
	protocol (e.g. IPv4) header of the State Refresh Message, SRM.		protocol (e.g. IPv4) header of the State Refresh Message, SRM.
	my_addr(I) returns this node's network (e.g. IPv4) address on interface		my_addr(I) returns this node's network (e.g. IPv4) address on interface
	I.		I.
	6.5.2 State Refresh Message Origination		4.5.2 State Refresh Message Origination
	This section describes the origination of State Refresh messages. These		This section describes the origination of State Refresh messages. These
	messages are generated periodically by the PIM-DM router that is		messages are generated periodically by the PIM-DM router that is
	directly connected to a source. One Origination(S,G) state machine		directly connected to a source. One Origination(S,G) state machine
	exists per (S,G) entry in a PIM-DM router.		exists per (S,G) entry in a PIM-DM router.
	The Origination(S,G) state machine has the following states:		The Origination(S,G) state machine has the following states:
	NotOriginator(NO)		NotOriginator(NO)
	This is the starting state of the Origination(S,G) state machine.		This is the starting state of the Origination(S,G) state machine.
	While in this state a router will not originate State Refresh		While in this state a router will not originate State Refresh
	messages for the (S,G) pair.		messages for the (S,G) pair.
	Originator(O)		Originator(O)
	When in this state the router will periodically originate State		When in this state the router will periodically originate State
	Refresh messages. Only routers which are directly connected to S		Refresh messages. Only routers which are directly connected to S
	may transition to this state.		may transition to this state.
	In addition there are two state-machine-specific timers:		In addition there are two state-machine-specific timers:
	StateRefresh Timer (SRT(S,G))		State Refresh Timer (SRT(S,G))
	This timer is controls when State Refresh messages are generated.		This timer is controls when State Refresh messages are generated.
	The timer is initially set when that Origination(S,G) state machine		The timer is initially set when that Origination(S,G) state machine
	transitions to the O state. It is cancelled when the		transitions to the O state. It is cancelled when the
	Origination(S,G) state machine transitions to the NO state. This		Origination(S,G) state machine transitions to the NO state. This
	timer is normally set to StateRefreshInterval (see 6.8.1).		timer is normally set to StateRefreshInterval (see 4.8).
	SourceActive Timer (SAT(S,G))		Source Active Timer (SAT(S,G))
	This timer is first set when the Origination(S,G) state machine		This timer is first set when the Origination(S,G) state machine
	transitions to the O state and is reset on the receipt of every		transitions to the O state and is reset on the receipt of every
	data packet from S addressed to group G. When it expires, the		data packet from S addressed to group G. When it expires, the
	Origination(S,G) state machine transitions to the NO state. This		Origination(S,G) state machine transitions to the NO state. This
	timer is normally set to SourceLifetime (see 6.8.1).		timer is normally set to SourceLifetime (see 4.8).
	+-------------+ Rcv Directly From S +-------------+		+-------------+ Rcv Directly From S +-------------+
	| |----------------------->| |		| |----------------------->| |
	|NotOriginator| | Originator |		|NotOriginator| | Originator |
	| |<-----------------------| |		| |<-----------------------| |
	+-------------+ SAT Expires OR +-------------+		+-------------+ SAT Expires OR +-------------+
	S NOT Direct Connect		S NOT Direct Connect
	Figure 3: Per-interface State Refresh State Diagram		Figure 3: State Refresh State Machine
	In tabular form, the state machine is defined as follows:		In tabular form, the state machine is defined as follows:
	+----------------------------------------------------------------------+		+----------------------------------------------------------------------+
	| | Previous State |		| | Previous State |
	| +---------------+-------------------+		| +---------------+-------------------+
	| Event | NotOriginator | Originator |		| Event | NotOriginator | Originator |
	+----------------------------------+---------------+-------------------+		+----------------------------------+---------------+-------------------+
	| Receive Data from S AND | ->O | ->O Reset |		| Receive Data from S AND | ->O | ->O Reset |
	| S directly connected | Set SRT(S,G) | SAT(S,G) |		| S directly connected | Set SRT(S,G) | SAT(S,G) |
	skipping to change at page 24, line 4 ¶		skipping to change at page 27, line 4 ¶
	| | | StateRefresh(S,G) |		| | | StateRefresh(S,G) |
	| | | Reset SRT(S,G) |		| | | Reset SRT(S,G) |
	+----------------------------------+---------------+-------------------+		+----------------------------------+---------------+-------------------+
	| SAT(S,G) Expires | N/A | ->NO Cancel |		| SAT(S,G) Expires | N/A | ->NO Cancel |
	| | | SRT(S,G) |		| | | SRT(S,G) |
	+----------------------------------+---------------+-------------------+		+----------------------------------+---------------+-------------------+
	| S no longer directly connected | ->NO | ->NO |		| S no longer directly connected | ->NO | ->NO |
	| | | Cancel SRT(S,G) |		| | | Cancel SRT(S,G) |
	| | | Cancel SAT(S,G) |		| | | Cancel SAT(S,G) |
	+----------------------------------+---------------+-------------------+		+----------------------------------+---------------+-------------------+
			4.5.2.1. Transitions from the NotOriginator (NO) State
	Transitions from the NotOriginator (NO) State
	When the Originating(S,G) state machine is in the NotOriginator (NO)		When the Originating(S,G) state machine is in the NotOriginator (NO)
	state, the following event may trigger a transition:		state, the following event may trigger a transition:
	Data Packet received from directly connected Source S addressed to		Data Packet received from directly connected Source S addressed to
	group G		group G
	The router MUST transition to an Originator (O) state, set SAT(S,G)		The router MUST transition to an Originator (O) state, set SAT(S,G)
	to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The		to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The
	router SHOULD record the TTL of the packet for use in State Refresh		router SHOULD record the TTL of the packet for use in State Refresh
	messages.		messages.
	Transitions from the Originator (O) State		4.5.2.2. Transitions from the Originator (O) State
	When the Originating(S,G) state machine is in the Originator (O) state,		When the Originating(S,G) state machine is in the Originator (O) state,
	the following events may trigger a transition:		the following events may trigger a transition:
	Receive Data Packet from S addressed to G		Receive Data Packet from S addressed to G
	The router remains in the Originator (O) state and MUST reset		The router remains in the Originator (O) state and MUST reset
	SAT(S,G) to SourceLifetime. The router SHOULD increase its recorded		SAT(S,G) to SourceLifetime. The router SHOULD increase its recorded
	TTL to match the TTL of the packet, if the packet's TTL is larger		TTL to match the TTL of the packet, if the packet's TTL is larger
	than the previously recorded TTL.		than the previously recorded TTL.
	SRT(S,G) Expires		SRT(S,G) Expires
	The router remains in the Originator (O) state and MUST reset		The router remains in the Originator (O) state and MUST reset
	SRT(S,G) to StateRefreshInterval. The router MUST also generate		SRT(S,G) to StateRefreshInterval. The router MUST also generate
	State Refresh messages for transmission as described in the State		State Refresh messages for transmission as described in the State
	Refresh Forwarding rules (section 6.5.1) except for the TTL. If the		Refresh Forwarding rules (section 4.5.1) except for the TTL. If the
	TTL of data packets from S to G are being recorded, then the TTL of		TTL of data packets from S to G are being recorded, then the TTL of
	each State Refresh message is set to the highest recorded TTL.		each State Refresh message is set to the highest recorded TTL.
	Otherwise, the TTL is set to the configured State Refresh TTL. Let		Otherwise, the TTL is set to the configured State Refresh TTL. Let
	I denote the interface over which a State Refresh message is being		I denote the interface over which a State Refresh message is being
	sent. If the Prune(S,G) Downstream state machine for I is in the		sent. If the Prune(S,G) Downstream state machine for I is in the
	NoInfo (NI) state, then the Prune-Indicator bit MUST be set to 0 in		NoInfo (NI) state, then the Prune-Indicator bit MUST be set to 0 in
	the State Refresh message being sent over I. Otherwise the		the State Refresh message being sent over I. Otherwise the
	Prune-Indicator bit MUST be set to 1.		Prune-Indicator bit MUST be set to 1.
	SAT(S,G) Expires		SAT(S,G) Expires
	The router MUST cancel the SRT(S,G) timer and transition to the		The router MUST cancel the SRT(S,G) timer and transition to the
	NotOriginator (NO) state.		NotOriginator (NO) state.
	S is no longer directly connected		S is no longer directly connected
	The router MUST transition to the NotOriginator (NO) state and		The router MUST transition to the NotOriginator (NO) state and
	cancel both the SAT(S,G) and SRT(S,G).		cancel both the SAT(S,G) and SRT(S,G).
	6.6 PIM Assert Messages		4.6. PIM Assert Messages
	6.6.1 Assert Metrics		4.6.1. Assert Metrics
	Assert metrics are defined as:		Assert metrics are defined as:
	struct assert_metric {		struct assert_metric {
	metric_preference;		metric_preference;
	route_metric;		route_metric;
	ip_address;		ip_address;
	};		};
	When comparing assert_metrics, the metric_preference and route_metric		When comparing assert_metrics, the metric_preference and route_metric
	skipping to change at page 26, line 4 ¶		skipping to change at page 29, line 4 ¶
	X, as determined by the MRIB. my_addr(I) is simply the router's network		X, as determined by the MRIB. my_addr(I) is simply the router's network
	(e.g. IP) address that is associated with the local interface I.		(e.g. IP) address that is associated with the local interface I.
	infinite_assert_metric() gives the Assert metric we need to send an		infinite_assert_metric() gives the Assert metric we need to send an
	Assert but doesn't match (S,G) forwarding state:		Assert but doesn't match (S,G) forwarding state:
	assert_metric		assert_metric
	infinite_assert_metric() {		infinite_assert_metric() {
	return {1,infinity,infinity,0}		return {1,infinity,infinity,0}
	}		}
			4.6.2. AssertCancel Messages
	6.6.2 AssertCancel Messages
	An AssertCancel(S,G) message is simply an Assert message for (S,G) with		An AssertCancel(S,G) message is simply an Assert message for (S,G) with
	infinite metric. The Assert winner sends such a message when it changes		infinite metric. The Assert winner sends such a message when it changes
	its upstream interface to this interface. Other routers will see this		its upstream interface to this interface. Other routers will see this
	metric, causing those with forwarding state to send their own Asserts		metric, causing those with forwarding state to send their own Asserts
	and re-establish an Assert winner.		and re-establish an Assert winner.
	AssertCancel messages are simply an optimization. The original Assert		AssertCancel messages are simply an optimization. The original Assert
	timeout mechanism will allow a subnet to eventually become consistent;		timeout mechanism will allow a subnet to eventually become consistent;
	the AssertCancel mechanism simply causes faster convergence. No special		the AssertCancel mechanism simply causes faster convergence. No special
	processing is required for an AssertCancel message, since it is simply		processing is required for an AssertCancel message, since it is simply
	an Assert message from the current winner.		an Assert message from the current winner.
	6.6.3 Assert State Macros		4.6.3. Assert State Macros
	The macro lost_assert(S,G,I), is used in the olist computations of		The macro lost_assert(S,G,I), is used in the olist computations of
	section 6.1.3, and is defined as follows:		section 4.1.3, and is defined as follows:
	bool lost_assert(S,G,I) {		bool lost_assert(S,G,I) {
	if ( RPF_interface(S) == I ) {		if ( RPF_interface(S) == I ) {
	return FALSE		return FALSE
	} else {		} else {
	return (AssertWinner(S,G,I) != me AND		return (AssertWinner(S,G,I) != me AND
	(AssertWinnerMetric(S,G,I) is better than		(AssertWinnerMetric(S,G,I) is better than
	spt_assert_metric(S,G,I)))		spt_assert_metric(S,G,I)))
	}		}
	}		}
	AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I)		AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I)
	defaults to Infinity when in the NoInfo state.		defaults to Infinity when in the NoInfo state.
	6.6.4 (S,G) Assert Message State Machine		4.6.4. (S,G) Assert Message State Machine
	The (S,G) Assert state machine for interface I is shown in Figure 4.		The (S,G) Assert state machine for interface I is shown in Figure 4.
	There are three states:		There are three states:
	NoInfo (NI)		NoInfo (NI)
	This router has no (S,G) Assert state on interface I.		This router has no (S,G) Assert state on interface I.
	I am Assert Winner (W)		I am Assert Winner (W)
	This router has won an (S,G) Assert on interface I. It is now		This router has won an (S,G) Assert on interface I. It is now
	responsible for forwarding traffic from S destined for G via		responsible for forwarding traffic from S destined for G via
	skipping to change at page 27, line 25 ¶		skipping to change at page 30, line 32 ¶
	| | +-------------+ | |		| | +-------------+ | |
	| +-------->| |----------+ |		| +-------->| |----------+ |
	| | No Info | |		| | No Info | |
	+-------------| |<-------------+		+-------------| |<-------------+
	Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR		Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR
	OR Rcv Inferior Assert Rcv Inf SR from Winner OR		OR Rcv Inferior Assert Rcv Inf SR from Winner OR
	OR Rcv Inferior SR AT Expires OR		OR Rcv Inferior SR AT Expires OR
	CouldAssert Changes OR		CouldAssert Changes OR
	Winner's NLT Expires		Winner's NLT Expires
	Figure 4: Per-interface (S,G) Assert state machine		Figure 4: Assert State Machine
	In tabular form the state machine is defined as follows:		In tabular form the state machine is defined as follows:
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| | Previous State |		| | Previous State |
	| +------------+------------+------------+		| +------------+------------+------------+
	| Event | No Info | Winner | Loser |		| Event | No Info | Winner | Loser |
	+-------------------------------+------------+------------+------------+		+-------------------------------+------------+------------+------------+
	| An (S,G) Data packet received | ->W Send | ->W Send | ->L |		| An (S,G) Data packet received | ->W Send | ->W Send | ->L |
	| on downstream interface | Assert(S,G)| Assert(S,G)| |		| on downstream interface | Assert(S,G)| Assert(S,G)| |
	skipping to change at page 27, line 48 ¶		skipping to change at page 31, line 4 ¶
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| Receive Inferior (Assert OR | N/A | N/A |->NI Cancel |		| Receive Inferior (Assert OR | N/A | N/A |->NI Cancel |
	| State Refresh) from Assert | | | AT(S,G,I) |		| State Refresh) from Assert | | | AT(S,G,I) |
	| Winner | | | |		| Winner | | | |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| Receive Inferior (Assert OR | ->W Send | ->W Send | ->L |		| Receive Inferior (Assert OR | ->W Send | ->W Send | ->L |
	| State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| |		| State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| |
	| Winner AND CouldAssert==TRUE | Set | Set | |		| Winner AND CouldAssert==TRUE | Set | Set | |
	| | AT(S,G,I) | AT(S,G,I) | |		| | AT(S,G,I) | AT(S,G,I) | |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
			+-------------------------------+--------------------------------------+
			| | Previous State |
			| +------------+------------+------------+
			| Event | No Info | Winner | Loser |
			+-------------------------------+------------+------------+------------+
	| Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set |		| Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set |
	| State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) |		| State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) |
	| | Set | Set | |		| | Set | Set | |
	| | AT(S,G,I) | AT(S,G,I) | |		| | AT(S,G,I) | AT(S,G,I) | |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| Send State Refresh | ->NI | ->W Reset | N/A |		| Send State Refresh | ->NI | ->W Reset | N/A |
	| | | AT(S,G,I) | |		| | | AT(S,G,I) | |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| AT(S,G) Expires | N/A | ->NI | ->NI |		| AT(S,G) Expires | N/A | ->NI | ->NI |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	+-------------------------------+--------------------------------------+
	| | Previous State |
	| +------------+------------+------------+
	| Event | No Info | Winner | Loser |
	+-------------------------------+------------+------------+------------+
	| CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel |		| CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel |
	| | | AT(S,G,I) | AT(S,G,I) |		| | | AT(S,G,I) | AT(S,G,I) |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| CouldAssert -> TRUE | ->NI | N/A |->NI Cancel |		| CouldAssert -> TRUE | ->NI | N/A |->NI Cancel |
	| | | | AT(S,G,I) |		| | | | AT(S,G,I) |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel |		| Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel |
	| | | | AT(S,G,I) |		| | | | AT(S,G,I) |
	+-------------------------------+--------------------------------------+		+-------------------------------+--------------------------------------+
	| Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send |		| Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send |
	skipping to change at page 28, line 32 ¶		skipping to change at page 31, line 41 ¶
	Terminology:		Terminology:
	A "preferred assert" is one with a better metric than the current		A "preferred assert" is one with a better metric than the current
	winner. An "inferior assert" is one with a worse metric than		winner. An "inferior assert" is one with a worse metric than
	my_assert_metric(S,G,I).		my_assert_metric(S,G,I).
	The state machine uses the following macro:		The state machine uses the following macro:
	CouldAssert(S,G,I) = (RPF_interface(S) != I)		CouldAssert(S,G,I) = (RPF_interface(S) != I)
	Transitions from NoInfo State		4.6.4.1. Transitions from NoInfo State
	When in NoInfo state, the following events may trigger transitions:		When in NoInfo state, the following events may trigger transitions:
	An (S,G) data packet arrives on downstream interface I		An (S,G) data packet arrives on downstream interface I
	An (S,G) data packet arrived on a downstream interface. It is		An (S,G) data packet arrived on a downstream interface. It is
	optimistically assumed that this router will be the Assert winner		optimistically assumed that this router will be the Assert winner
	for this (S,G). The Assert state machine MUST transition to the "I		for this (S,G). The Assert state machine MUST transition to the "I
	am Assert Winner" state, send an Assert(S,G) to interface I, store		am Assert Winner" state, send an Assert(S,G) to interface I, store
	its own address and metric as the Assert Winner and set the		its own address and metric as the Assert Winner and set the
	Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating the		Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating the
	skipping to change at page 29, line 13 ¶		skipping to change at page 32, line 21 ¶
	Assert Winner and set the Assert Timer (AT(S,G,I)) to Assert_Time.		Assert Winner and set the Assert Timer (AT(S,G,I)) to Assert_Time.
	Receive Preferred Assert or State Refresh		Receive Preferred Assert or State Refresh
	The received Assert or State Refresh has a better metric than this		The received Assert or State Refresh has a better metric than this
	router's and therefore the Assert state machine MUST transition to		router's and therefore the Assert state machine MUST transition to
	the "I am Assert Loser" state and store the Assert Winner's address		the "I am Assert Loser" state and store the Assert Winner's address
	and metric. If the metric was received in an Assert, the router MUST		and metric. If the metric was received in an Assert, the router MUST
	set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was		set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was
	received in a State Refresh, the router MUST set the Assert Timer		received in a State Refresh, the router MUST set the Assert Timer
	(AT(S,G,I)) to three times the received State Refresh Interval. The		(AT(S,G,I)) to three times the received State Refresh Interval. The
	router MUST also multicast a Prune(S,G) to the Assert winner and		router MUST also multicast a Prune(S,G) to the Assert winner with a
	evaluate any changes in its Upstream(S,G) state machine.		Prune Hold Time equal to the Assert Timer and evaluate any changes
			in its Upstream(S,G) state machine.
	Transitions from Winner State		4.6.4.2. Transitions from Winner State
	When in "I am Assert Winner" state, the following events trigger		When in "I am Assert Winner" state, the following events trigger
	transitions:		transitions:
	An (S,G) data packet arrives on downstream interface I		An (S,G) data packet arrives on downstream interface I
	An (S,G) data packet arrived on a downstream interface. The Assert		An (S,G) data packet arrived on a downstream interface. The Assert
	state machine remains in the "I am Assert Winner" state. The router		state machine remains in the "I am Assert Winner" state. The router
	MUST send an Assert(S,G) to interface I and set the Assert Timer		MUST send an Assert(S,G) to interface I and set the Assert Timer
	(AT(S,G,I) to Assert_Time.		(AT(S,G,I) to Assert_Time.
	skipping to change at page 29, line 42 ¶		skipping to change at page 32, line 51 ¶
	Receive Preferred Assert or State Refresh		Receive Preferred Assert or State Refresh
	An (S,G) Assert or State Refresh is received that has a better		An (S,G) Assert or State Refresh is received that has a better
	metric than this router's metric for S on interface I. The Assert		metric than this router's metric for S on interface I. The Assert
	state machine MUST transition to "I am Assert Loser" state and		state machine MUST transition to "I am Assert Loser" state and
	store the new Assert Winner's address and metric. If the metric was		store the new Assert Winner's address and metric. If the metric was
	received in an Assert, the router MUST set the Assert Timer		received in an Assert, the router MUST set the Assert Timer
	(AT(S,G,I)) to Assert_Time. If the metric was received in a State		(AT(S,G,I)) to Assert_Time. If the metric was received in a State
	Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three		Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three
	times the State Refresh Interval. The router MUST also multicast a		times the State Refresh Interval. The router MUST also multicast a
	Prune(S,G) to the Assert winner and evaluate any changes in its		Prune(S,G) to the Assert winner with a Prune Hold Time equal to the
	Upstream(S,G) state machine.		Assert Timer and evaluate any changes in its Upstream(S,G) state
			machine.
	Send State Refresh		Send State Refresh
	The router is sending a State Refresh(S,G) message on interface I.		The router is sending a State Refresh(S,G) message on interface I.
	The router MUST set the Assert Timer (AT(S,G,I)) to three times the		The router MUST set the Assert Timer (AT(S,G,I)) to three times the
	State Refresh Interval contained in the State Refresh(S,G) message.		State Refresh Interval contained in the State Refresh(S,G) message.
	AT(S,G,I) Expires		AT(S,G,I) Expires
	The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine		The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine
	MUST transition to the NoInfo (NI) state.		MUST transition to the NoInfo (NI) state.
	CouldAssert(S,G,I) -> FALSE		CouldAssert(S,G,I) -> FALSE
	This router's RPF interface changed so as to make CouldAssert(S,G,I)		This router's RPF interface changed so as to make CouldAssert(S,G,I)
	become false. This router can no longer perform the actions of the		become false. This router can no longer perform the actions of the
	Assert winner, and so the Assert state machine MUST transition to		Assert winner, and so the Assert state machine MUST transition to
	NoInfo (NI) state, send an AssertCancel(S,G) to interface I, cancel		NoInfo (NI) state, send an AssertCancel(S,G) to interface I, cancel
	the Assert Timer (AT(S,G,I)) and remove itself as the Assert Winner.		the Assert Timer (AT(S,G,I)) and remove itself as the Assert Winner.
	Transitions from Loser State		4.6.4.3. Transitions from Loser State
	When in "I am Assert Loser" state, the following transitions can occur:		When in "I am Assert Loser" state, the following transitions can occur:
	Receive Inferior Assert or State Refresh from Current Winner		Receive Inferior Assert or State Refresh from Current Winner
	An Assert or State Refresh is received from the current Assert		An Assert or State Refresh is received from the current Assert
	winner that is worse than this router's metric for S (typically the		winner that is worse than this router's metric for S (typically the
	winner's metric became worse). The Assert state machine MUST		winner's metric became worse). The Assert state machine MUST
	transition to NoInfo (NI) state and cancel AT(S,G,I). The router		transition to NoInfo (NI) state and cancel AT(S,G,I). The router
	MUST delete the previous Assert Winner's address and metric and		MUST delete the previous Assert Winner's address and metric and
	evaluate any possible transitions to its Upstream(S,G) state		evaluate any possible transitions to its Upstream(S,G) state
	skipping to change at page 31, line 13 ¶		skipping to change at page 34, line 32 ¶
	machine.		machine.
	Receive Prune(S,G), Join(S,G) or Graft(S,G)		Receive Prune(S,G), Join(S,G) or Graft(S,G)
	A Prune(S,G), Join(S,G) or Graft(S,G) message was received on		A Prune(S,G), Join(S,G) or Graft(S,G) message was received on
	interface I with its upstream neighbor address set to the router's		interface I with its upstream neighbor address set to the router's
	address on I. The router MUST send an Assert(S,G) on the receiving		address on I. The router MUST send an Assert(S,G) on the receiving
	interface I to initiate an Assert negotiation. The Assert state		interface I to initiate an Assert negotiation. The Assert state
	machine remains in the Assert Loser(L) state. If a Graft(S,G) was		machine remains in the Assert Loser(L) state. If a Graft(S,G) was
	received, the router MUST respond with a GraftAck(S,G).		received, the router MUST respond with a GraftAck(S,G).
	6.6.5 Rationale for Assert Rules		4.6.5. Rationale for Assert Rules
	The following is a summary of the rules for generating and processing		The following is a summary of the rules for generating and processing
	Assert messages. It is not intended to be definitive (the state		Assert messages. It is not intended to be definitive (the state
	machines and pseudocode provide the definitive behavior). Instead it		machines and pseudocode provide the definitive behavior). Instead it
	provides some rationale for the behavior.		provides some rationale for the behavior.
	1. The Assert winner for (S,G) must act as the local forwarder for (S,G)		1. The Assert winner for (S,G) must act as the local forwarder for (S,G)
	on behalf all downstream members.		on behalf all downstream members.
	2. PIM messages are directed towards to the RPF' neighbor and not to the		2. PIM messages are directed towards to the RPF' neighbor and not to the
	regular RPF neighbor.		regular RPF neighbor.
	3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G)		3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G)
	directed to it initiates a new Assert negotiation so the downstream		directed to it initiates a new Assert negotiation so the downstream
	router can correct its RPF'(S).		router can correct its RPF'(S).
	4. An assert winner for (S,G) sends a canceling assert when it is about		4. An Assert winner for (S,G) sends a cancelling assert when it is about
	to stop forwarding on an (S,G) entry. Example : if a router is being		to stop forwarding on an (S,G) entry. Example: if a router is being
	taken down, then a canceling assert is sent.		taken down, then a canceling assert is sent.
	6.7 PIM Packet Formats		4.7. PIM Packet Formats
	All PIM-DM packets use the same format as PIM-SM packets. All PIM		All PIM-DM packets use the same format as PIM-SM packets. All PIM
	control messages have IP protocol number 103. All PIM-DM messages MUST		control messages have IP protocol number 103. All PIM-DM messages MUST
	be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack		be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack
	messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages		messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages
	SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to		SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to
	the sender of the Graft.		the sender of the Graft.
	The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM- ROUTERS		The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS
	group is 'ff02::d'.		group is 'ff02::d'.
	6.7.1 PIM Header		4.7.1. PIM Header
	All PIM control messages have the following header:		All PIM control messages have the following header:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type | Reserved | Checksum |		|PIM Ver| Type | Reserved | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	PIM Ver		PIM Ver
	skipping to change at page 32, line 27 ¶		skipping to change at page 35, line 52 ¶
	Reserved		Reserved
	Set to zero on transmission. Ignored upon receipt.		Set to zero on transmission. Ignored upon receipt.
	Checksum		Checksum
	The checksum is standard IP checksum, i.e. the 16 bit one's complement		The checksum is standard IP checksum, i.e. the 16 bit one's complement
	of the one's complement sum of the entire PIM message. For computing		of the one's complement sum of the entire PIM message. For computing
	checksum, the checksum field is zeroed.		checksum, the checksum field is zeroed.
	For IPv6, the checksum also includes the IPv6 "pseudo-header", as		For IPv6, the checksum also includes the IPv6 "pseudo-header", as
	specified in RFC 2460, section 8.1 [13]. This "pseudo-header" is		specified in RFC 2460, section 8.1 [13].
	prepended to the PIM header for the purposes of calculating the
	checksum. The "Upper-Layer Packet Length" in the pseudo-header is set
	to the length of the PIM message. The Next Header value used in the
	pseudo-header is 103. If the packet's length is not an integral number
	of 16-bit words, the packet is padded with a byte of zero before
	performing the checksum.
	6.7.2 Encoded Unicast Address		4.7.2. Encoded Unicast Address
	An Encoded Unicast Address has the following format:		An Encoded Unicast Address has the following format:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Addr Family | Encoding Type | Unicast Address		| Addr Family | Encoding Type | Unicast Address
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
	Addr Family		Addr Family
	skipping to change at page 33, line 9 ¶		skipping to change at page 36, line 32 ¶
	Encoding Type		Encoding Type
	The type of encoding used with a specific Address Family. The value		The type of encoding used with a specific Address Family. The value
	'0' is reserved for this field, and represents the native encoding of		'0' is reserved for this field, and represents the native encoding of
	the Address Family		the Address Family
	Unicast Address		Unicast Address
	The unicast address as represented by the given Address Family and		The unicast address as represented by the given Address Family and
	Encoding Type.		Encoding Type.
	6.7.3 Encoded Group Address		4.7.3. Encoded Group Address
	An Encoded Group address has the following format:		An Encoded Group address has the following format:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |		| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Multicast Address		| Group Multicast Address
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
	skipping to change at page 33, line 37 ¶		skipping to change at page 37, line 8 ¶
	B		B
	Indicates the group range should use Bidirectional PIM [14].		Indicates the group range should use Bidirectional PIM [14].
	Transmitted as zero, ignored upon receipt.		Transmitted as zero, ignored upon receipt.
	Reserved		Reserved
	Transmitted as zero. Ignored upon receipt.		Transmitted as zero. Ignored upon receipt.
	Z		Z
	Indicates the group range is an admin scope zone. This is used in the		Indicates the group range is an admin scope zone. This is used in the
	Bootstrap Router Mechanism [15] only. For all other purposes, this bit		Bootstrap Router Mechanism [15] only. For all other purposes, this bit
	is set to zero and ignored on receipt.		is set to zero and ignored on receipt.
	Mask Len		Mask Len
	The mask length field is 8 bits. The value is the number of		The mask length field is 8 bits. The value is the number of
	contiguous on bits left justified used as a mask, which combined with		contiguous on bits left justified used as a mask, which combined with
	the address, describes a range of addresses. It is less than or equal		the address, describes a range of addresses. It is less than or equal
	to the address length in bits for the given Address Family and		to the address length in bits for the given Address Family and
	Encoding Type. If the message is sent for a single address then the		Encoding Type. If the message is sent for a single address then the
	mask length MUST equal the address length. PIM-DM routers MUST only		mask length MUST equal the address length. PIM-DM routers MUST only
	send for a single address.		send for a single address.
	Group Multicast Address		Group Multicast Address
	The address of the multicast group.		The address of the multicast group.
	6.7.4 Encoded Source Address		4.7.4. Encoded Source Address
	An Encoded Source address has the following format:		An Encoded Source address has the following format:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |		| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address		| Source Address
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
	skipping to change at page 35, line 5 ¶		skipping to change at page 38, line 8 ¶
	The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon		The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon
	receipt.		receipt.
	Mask Len		Mask Len
	As described above. PIM-DM routers MUST only send for a single		As described above. PIM-DM routers MUST only send for a single
	source address.		source address.
	Source Address		Source Address
	The source address.		The source address.
	6.7.5 Hello Message Format		4.7.5. Hello Message Format
	The PIM Hello message has the following format:		The PIM Hello message has the following format:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type | Reserved | Checksum |		|PIM Ver| Type | Reserved | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option Type | Option Length |		| Option Type | Option Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 35, line 44 ¶		skipping to change at page 38, line 47 ¶
	are:		are:
	0 Reserved		0 Reserved
	1 Hello Hold Time		1 Hello Hold Time
	2 LAN Prune Delay		2 LAN Prune Delay
	3-16 Reserved		3-16 Reserved
	17 To be assigned by IANA		17 To be assigned by IANA
	18 Deprecated and SHOULD NOT be used		18 Deprecated and SHOULD NOT be used
	19 DR Priority (PIM-SM Only)		19 DR Priority (PIM-SM Only)
	20 Generation ID		20 Generation ID
	21 State Refresh Capable		21 State Refresh Capable
	22-65000 To be assigned by IANA		22 Bidir Capable
			23-65000 To be assigned by IANA
	65001-65535 Reserved for Private Use [7]		65001-65535 Reserved for Private Use [7]
	Unknown options SHOULD be ignored.		Unknown options SHOULD be ignored.
	6.7.5.1 Hello Hold Time Option		4.7.5.1. Hello Hold Time Option
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 1 | Length = 2 |		| Type = 1 | Length = 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hold Time |		| Hold Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Hold Time is the number of seconds a receiver MUST keep the neighbor		Hold Time is the number of seconds a receiver MUST keep the neighbor
	reachable. If the Hold Time is set to '0xffff', the receiver of this		reachable. If the Hold Time is set to '0xffff', the receiver of this
	message never times out the neighbor. This may be used with dial-on-		message never times out the neighbor. This may be used with dial-on-
	demand links, to avoid keeping the link up with periodic Hello messages.		demand links, to avoid keeping the link up with periodic Hello messages.
	Furthermore, if the Holdtime is set to '0', the information is timed out		Furthermore, if the Holdtime is set to '0', the information is timed out
	immediately. The Hello Hold Time option MUST be used by PIM-DM routers.		immediately. The Hello Hold Time option MUST be used by PIM-DM routers.
	6.7.5.2 LAN Prune Delay Option		4.7.5.2. LAN Prune Delay Option
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 2 | Length = 4 |		| Type = 2 | Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|T| LAN Prune Delay | Override Interval |		|T| LAN Prune Delay | Override Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The LAN_Prune_Delay option is used to tune the prune propagation delay		The LAN_Prune_Delay option is used to tune the prune propagation delay
	on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0		on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0
	by PIM-DM routers and ignored upon receipt. The LAN Delay and Override		by PIM-DM routers and ignored upon receipt. The LAN Delay and Override
	Interval fields are time intervals in units of milliseconds and are used		Interval fields are time intervals in units of milliseconds and are used
	to tune the value of the J/P Override Interval and its derived timer		to tune the value of the J/P Override Interval and its derived timer
	values. Section 6.3.5 describes how these values affect the behavior of		values. Section 4.3.5 describes how these values affect the behavior of
	a router. The LAN Prune Delay SHOULD be used by PIM-DM routers.		a router. The LAN Prune Delay SHOULD be used by PIM-DM routers.
	6.7.5.3 Generation ID Option		4.7.5.3. Generation ID Option
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 20 | Length = 4 |		| Type = 20 | Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Generation ID |		| Generation ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Generation ID is a random value for the interface on which the Hello		Generation ID is a random value for the interface on which the Hello
	message is sent. The Generation ID is regenerated whenever PIM		message is sent. The Generation ID is regenerated whenever PIM
	forwarding is started or restarted on the interface. The Generation ID		forwarding is started or restarted on the interface. The Generation ID
	option MAY be used by PIM-DM routers.		option MAY be used by PIM-DM routers.
	6.7.5.4 State Refresh Capable Option		4.7.5.4. State Refresh Capable Option
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 21 | Length = 4 |		| Type = 21 | Length = 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version = 1 | Interval | Reserved |		| Version = 1 | Interval | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Interval field is the router's configured State Refresh Interval in		The Interval field is the router's configured State Refresh Interval in
	seconds. The Reserved field is set to zero and ignored upon reception.		seconds. The Reserved field is set to zero and ignored upon reception.
	The State Refresh Capable option MUST be used by State Refresh capable		The State Refresh Capable option MUST be used by State Refresh capable
	PIM-DM routers.		PIM-DM routers.
	6.7.6 Join/Prune Message Format		4.7.6. Join/Prune Message Format
	PIM Join/Prune messages have the following format:		PIM Join/Prune messages have the following format:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type | Reserved | Checksum |		|PIM Ver| Type | Reserved | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Upstream Neighbor Address (Encoded Unicast Format) |		| Upstream Neighbor Address (Encoded Unicast Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Num Groups | Hold Time |		| Reserved | Num Groups | Hold Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Multicast Group Address 1 (Encoded Group Format) |		| Multicast Group Address 1 (Encoded Group Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number of Joined Sources | Number of Pruned Sources |		| Number of Joined Sources | Number of Pruned Sources |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Joined Source Address 1 (Encoded Source Format) |		| Joined Source Address 1 (Encoded Source Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| . |		| . |
	| . |		| . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Joined Source Address n (Encoded Source Format) |		| Joined Source Address n (Encoded Source Format) |
	skipping to change at page 38, line 10 ¶		skipping to change at page 41, line 51 ¶
	| . |		| . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Pruned Source Address n (Encoded Source Format) |		| Pruned Source Address n (Encoded Source Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	PIM Ver, Type, Reserved, Checksum		PIM Ver, Type, Reserved, Checksum
	Described above.		Described above.
	Upstream Neighbor Address		Upstream Neighbor Address
	The address of the upstream neighbor. The format for this address is		The address of the upstream neighbor. The format for this address is
	given in the Encoded Unicast address in section 6.7.2. PIM-DM routers		given in the Encoded Unicast address in section 4.7.2. PIM-DM routers
	MUST set this field to the RPF next hop.		MUST set this field to the RPF next hop.
	Reserved		Reserved
	Transmitted as zero. Ignored upon receipt.		Transmitted as zero. Ignored upon receipt.
	Hold Time		Hold Time
	The number of seconds a receiving PIM-DM router MUST keep a Prune		The number of seconds a receiving PIM-DM router MUST keep a Prune
	state alive, unless removed by a Join or Graft message. If the Hold		state alive, unless removed by a Join or Graft message. If the Hold
	Time is '0xffff', the receiver MUST NOT remove the Prune state unless		Time is '0xffff', the receiver MUST NOT remove the Prune state unless
	a corresponding Join or Graft message is received. The Hold Time is		a corresponding Join or Graft message is received. The Hold Time is
	ignored in Join messages.		ignored in Join messages.
	Number of Groups		Number of Groups
	Number of multicast group sets contained in the message.		Number of multicast group sets contained in the message.
	Multicast Group Address		Multicast Group Address
	The multicast group address in the Encoded Multicast address format		The multicast group address in the Encoded Multicast address format
	given in section 6.7.3.		given in section 4.7.3.
	Number of Joined Sources		Number of Joined Sources
	Number of Join source addresses listed for a given group.		Number of Join source addresses listed for a given group.
	Number of Pruned Sources		Number of Pruned Sources
	Number of Prune source addresses listed for a given group.		Number of Prune source addresses listed for a given group.
	Join Source Address 1..n		Join Source Address 1..n
	This list contains the sources from which the sending router wishes to		This list contains the sources from which the sending router wishes to
	continue to receive multicast messages for the given group on this		continue to receive multicast messages for the given group on this
	interface. The addresses use the Encoded Source address format given		interface. The addresses use the Encoded Source address format given
	in section 6.7.4.		in section 4.7.4.
	Prune Source Address 1..n		Prune Source Address 1..n
	This list contains the sources from which the sending router does not		This list contains the sources from which the sending router does not
	wish to receive multicast messages for the given group on this		wish to receive multicast messages for the given group on this
	interface. The addresses use the Encoded Source address format given		interface. The addresses use the Encoded Source address format given
	in section 6.7.4.		in section 4.7.4.
	6.7.7 Assert Message Format		4.7.7. Assert Message Format
	PIM Assert Messages have the following format:		PIM Assert Messages have the following format:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type | Reserved | Checksum |		|PIM Ver| Type | Reserved | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Multicast Group Address (Encoded Group Format) |		| Multicast Group Address (Encoded Group Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 39, line 22 ¶		skipping to change at page 43, line 4 ¶
	|PIM Ver| Type | Reserved | Checksum |		|PIM Ver| Type | Reserved | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Multicast Group Address (Encoded Group Format) |		| Multicast Group Address (Encoded Group Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Address (Encoded Unicast Format) |		| Source Address (Encoded Unicast Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| Metric Preference |		|R| Metric Preference |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric |		| Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	PIM Ver, Type, Reserved, Checksum		PIM Ver, Type, Reserved, Checksum
	Described above.		Described above.
	Multicast Group Address		Multicast Group Address
	The multicast group address in the Encoded Multicast address format		The multicast group address in the Encoded Multicast address format
	given in section 6.7.3.		given in section 4.7.3.
	Source Address		Source Address
	The source address in the Encoded Source address format given in		The source address in the Encoded Source address format given in
	section 6.7.4.		section 4.7.4.
	R		R
	The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon		The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon
	receipt.		receipt.
	Metric Preference		Metric Preference
	The preference value assigned to the unicast routing protocol that		The preference value assigned to the unicast routing protocol that
	provided the route to the source.		provided the route to the source.
	Metric		Metric
	The cost metric of the unicast route to the source. The metric is in		The cost metric of the unicast route to the source. The metric is in
	units applicable to the unicast routing protocol used.		units applicable to the unicast routing protocol used.
	6.7.8 Graft Message Format		4.7.8. Graft Message Format
	PIM Graft messages use the same format as Join/Prune messages except the		PIM Graft messages use the same format as Join/Prune messages except the
	Type field is set to 6. The source address MUST be in the Join section		Type field is set to 6. The source address MUST be in the Join section
	of the message. The Hold Time field SHOULD be zero and SHOULD be		of the message. The Hold Time field SHOULD be zero and SHOULD be
	ignored when a Graft is received.		ignored when a Graft is received.
	6.7.9 Graft Ack Message Format		4.7.9. Graft Ack Message Format
	PIM Graft Ack messages are identical in format to the received Graft		PIM Graft Ack messages are identical in format to the received Graft
	message except the Type field is set to 7. The Upstream Neighbor		message except the Type field is set to 7. The Upstream Neighbor
	Address field SHOULD be set to the sender of the Graft message and		Address field SHOULD be set to the sender of the Graft message and
	SHOULD be ignored upon receipt.		SHOULD be ignored upon receipt.
	6.7.10 State Refresh Message Format		4.7.10. State Refresh Message Format
	PIM State Refresh Messages have the following format:		PIM State Refresh Messages have the following format:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|PIM Ver| Type | Reserved | Checksum |		|PIM Ver| Type | Reserved | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Multicast Group Address (Encoded Group Format) |		| Multicast Group Address (Encoded Group Format) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 40, line 32 ¶		skipping to change at page 44, line 32 ¶
	| Metric |		| Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Masklen | TTL |P|N|O|Reserved | Interval |		| Masklen | TTL |P|N|O|Reserved | Interval |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	PIM Ver, Type, Reserved, Checksum		PIM Ver, Type, Reserved, Checksum
	Described above.		Described above.
	Multicast Group Address		Multicast Group Address
	The multicast group address in the Encoded Multicast address format		The multicast group address in the Encoded Multicast address format
	given in section 6.7.3.		given in section 4.7.3.
	Source Address		Source Address
	The address of the data source in the Encoded Source address format		The address of the data source in the Encoded Source address format
	given in section 6.7.4.		given in section 4.7.4.
	Originator Address		Originator Address
	The address of the first hop router in the Encoded Source address		The address of the first hop router in the Encoded Source address
	format given in section 6.7.4.		format given in section 4.7.4.
	R		R
	The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon		The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon
	receipt.		receipt.
	Metric Preference		Metric Preference
	The preference value assigned to the unicast routing protocol that		The preference value assigned to the unicast routing protocol that
	provided the route to the source.		provided the route to the source.
	Metric		Metric
	skipping to change at page 41, line 33 ¶		skipping to change at page 45, line 33 ¶
	ignored upon receipt. This is for compatibility with earlier versions		ignored upon receipt. This is for compatibility with earlier versions
	of state refresh.		of state refresh.
	Reserved		Reserved
	Set to zero and ignored upon receipt.		Set to zero and ignored upon receipt.
	Interval		Interval
	Set by the originating router to the interval (in seconds) between		Set by the originating router to the interval (in seconds) between
	consecutive State Refresh messages for this (S,G) pair.		consecutive State Refresh messages for this (S,G) pair.
	6.8 PIM-DM Timers		4.8. PIM-DM Timers
	PIM-DM maintains the following timers. All timers are countdown timers		PIM-DM maintains the following timers. All timers are countdown timers
	- they are set to a value and count down to zero, at which point they		- they are set to a value and count down to zero, at which point they
	typically trigger an action. Of course they can just as easily be		typically trigger an action. Of course they can just as easily be
	implemented as count-up timers, where the absolute expiry time is stored		implemented as count-up timers, where the absolute expiry time is stored
	and compared against a real-time clock, but the language in this		and compared against a real-time clock, but the language in this
	specification assumes that they count downwards towards zero.		specification assumes that they count downwards towards zero.
	Global Timers		Global Timers
	Hello Timer: HT		Hello Timer: HT
	skipping to change at page 41, line 55 ¶		skipping to change at page 46, line 6 ¶
	Per interface (I):		Per interface (I):
	Per neighbor (N):		Per neighbor (N):
	Neighbor Liveness Timer: NLT(N,I)		Neighbor Liveness Timer: NLT(N,I)
	Per (S,G) Pair:		Per (S,G) Pair:
	(S,G) Assert Timer: AT(S,G,I)		(S,G) Assert Timer: AT(S,G,I)
	(S,G) Prune Timer: PT(S,G,I)		(S,G) Prune Timer: PT(S,G,I)
	(S,G) PrunePending Timer: PPT(S,G,I)		(S,G) PrunePending Timer: PPT(S,G,I)
	Per (S,G) Pair:		Per (S,G) Pair:
	(S,G) Graft Retry Timer: GT(S,G)		(S,G) Graft Retry Timer: GRT(S,G)
	(S,G) Upstream Override Timer: OT(S,G)		(S,G) Upstream Override Timer: OT(S,G)
	(S,G) Prune Limit Timer: PLT(S,G)		(S,G) Prune Limit Timer: PLT(S,G)
	(S,G) Source Active Timer: SAT(S,G)		(S,G) Source Active Timer: SAT(S,G)
	(S,G) State Refresh Timer: SRT(S,G)		(S,G) State Refresh Timer: SRT(S,G)
	6.8.1 Timer Values
	When timer values are started or restarted, they are set to default		When timer values are started or restarted, they are set to default
	values. This section summarizes those default values.		values. The following tables summarize those default values.
	Timer Name: Hello Timer (HT)		Timer Name: Hello Timer (HT)
	+----------------------+--------+--------------------------------------+		+----------------------+--------+--------------------------------------+
	| Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+----------------------+--------+--------------------------------------+		+----------------------+--------+--------------------------------------+
	|Hello_Period | 30 sec | Periodic interval for hello messages |		|Hello_Period | 30 sec | Periodic interval for hello messages |
	+----------------------+--------+--------------------------------------+		+----------------------+--------+--------------------------------------+
	|Triggered_Hello_Delay | 5 sec | Random interval for initial Hello |		|Triggered_Hello_Delay | 5 sec | Random interval for initial Hello |
	| | | message on bootup or triggered Hello |		| | | message on bootup or triggered Hello |
	| | | message to a rebooting neighbor |		| | | message to a rebooting neighbor |
	skipping to change at page 42, line 39 ¶		skipping to change at page 46, line 44 ¶
	| Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+-------------------+-----------------+--------------------------------+		+-------------------+-----------------+--------------------------------+
	| Hello Holdtime | From message | Hold Time from Hello Message |		| Hello Holdtime | From message | Hold Time from Hello Message |
	+-------------------+-----------------+--------------------------------+		+-------------------+-----------------+--------------------------------+
	Timer Name: PrunePending Timer (PPT(S,G,I))		Timer Name: PrunePending Timer (PPT(S,G,I))
	+-----------------------+---------------+------------------------------+		+-----------------------+---------------+------------------------------+
	| Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+-----------------------+---------------+------------------------------+		+-----------------------+---------------+------------------------------+
	| J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to |		| J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to |
	| | | allow other routers to on |		| | | allow other routers on the |
	| | | the LAN to send a Join |		| | | LAN to send a Join |
	+-----------------------+---------------+------------------------------+		+-----------------------+---------------+------------------------------+
	The J/P_Override_Interval is the sum of the interface's		The J/P_Override_Interval is the sum of the interface's
	Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all routers		Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all routers
	on a LAN are using the LAN Prune Delay option, both parameters MUST be		on a LAN are using the LAN Prune Delay option, both parameters MUST be
	set to the largest value on the LAN. Otherwise, the Override_Interval		set to the largest value on the LAN. Otherwise, the Override_Interval
	(OI(I)) MUST be set to 2.5 seconds and the Propagation_Delay (PD(I))		(OI(I)) MUST be set to 2.5 seconds and the Propagation_Delay (PD(I))
	MUST be set to 0.5 seconds.		MUST be set to 0.5 seconds.
	Timer Name: Prune Timer (PT(S,G,I))		Timer Name: Prune Timer (PT(S,G,I))
	skipping to change at page 43, line 28 ¶		skipping to change at page 47, line 35 ¶
	Timer Name: Graft Retry Timer (GRT(S,G))		Timer Name: Graft Retry Timer (GRT(S,G))
	+--------------------+-------+-----------------------------------------+		+--------------------+-------+-----------------------------------------+
	| Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+--------------------+-------+-----------------------------------------+		+--------------------+-------+-----------------------------------------+
	| Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck |		| Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck |
	| | | message, the time before retransmission |		| | | message, the time before retransmission |
	| | | of a Graft message |		| | | of a Graft message |
	+--------------------+-------+-----------------------------------------+		+--------------------+-------+-----------------------------------------+
	Timer Name: Upstream Override Timer (OT(S,G))		Timer Name: Upstream Override Timer (OT(S,G))
	+-----------+----------------+-----------------------------------------+		+------------+----------------+----------------------------------------+
	|Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+-----------+----------------+-----------------------------------------|		+------------+----------------+----------------------------------------|
	|t_override | rand(0, OI(I)) | Randomized delay to prevent response |		| t_override | rand(0, OI(I)) | Randomized delay to prevent response |
	| | | implosion when sending a join message |		| | | implosion when sending a join message |
	| | | to override someone else's prune |		| | | to override someone else's prune |
	+-----------+----------------+-----------------------------------------+		+------------+----------------+----------------------------------------+
	t_override is a random value between 0 and the interface's		t_override is a random value between 0 and the interface's
	Override_Interval (OI(I)). If all routers on a LAN are using the LAN		Override_Interval (OI(I)). If all routers on a LAN are using the LAN
	Prune Delay option, the Override_Interval (OI(I)) MUST be set to the		Prune Delay option, the Override_Interval (OI(I)) MUST be set to the
	largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST		largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST
	be set to 2.5 seconds.		be set to 2.5 seconds.
	Timer Name: Prune Limit Timer (PLT(S,G))		Timer Name: Prune Limit Timer (PLT(S,G))
	+-----------+--------------------+-------------------------------------+		+------------+--------------------+------------------------------------+
	|Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+-----------+--------------------+-------------------------------------|		+------------+--------------------+------------------------------------|
	|t_limit | Equal to the Prune | Used to prevent Prune storms on a |		| t_limit | Equal to the Prune | Used to prevent Prune storms on a |
	| | Holdtime sent | LAN |		| | Holdtime sent | LAN |
	+-----------+--------------------+-------------------------------------+		+------------+--------------------+------------------------------------+
			Timer Name: Source Active Timer (SAT(S,G))
	Timer Name: Source Activity Timer (SAT(S,G))
	+----------------+-------------------+---------------------------------+		+----------------+-------------------+---------------------------------+
	| Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+----------------+-------------------+---------------------------------+		+----------------+-------------------+---------------------------------+
	| SourceLifetime | Default: 210 secs | Period of time after receiving |		| SourceLifetime | Default: 210 secs | Period of time after receiving |
	| | | a multicast message a directly |		| | | a multicast message a directly |
	| | | attached router will continue |		| | | attached router will continue |
	| | | to send State Refresh messages |		| | | to send State Refresh messages |
	+----------------+-------------------+---------------------------------+		+----------------+-------------------+---------------------------------+
	Timer Name: State Refresh Timer (SRT(S,G))		Timer Name: State Refresh Timer (SRT(S,G))
	+-----------------+------------------+---------------------------------+		+-----------------+------------------+---------------------------------+
	| Value Name | Value | Explanation |		| Value Name | Value | Explanation |
	+-----------------+------------------+---------------------------------+		+-----------------+------------------+---------------------------------+
	| RefreshInterval | Default: 60 secs | Interval between successive |		| RefreshInterval | Default: 60 secs | Interval between successive |
	| | | state refresh messages |		| | | state refresh messages |
	+-----------------+------------------+---------------------------------+		+-----------------+------------------+---------------------------------+
	7. Protocol Interaction Considerations		5. Protocol Interaction Considerations
	PIM-DM is designed to be independent of underlying unicast routing		PIM-DM is designed to be independent of underlying unicast routing
	protocols and will interact only to the extent needed to perform RPF		protocols and will interact only to the extent needed to perform RPF
	checks. It is generally assumed that multicast area and autonomous		checks. It is generally assumed that multicast area and autonomous
	system boundaries will correspond to the same boundaries for unicast		system boundaries will correspond to the same boundaries for unicast
	routing, though a deployment which does not follow this assumption is		routing, though a deployment which does not follow this assumption is
	not precluded by this specification.		not precluded by this specification.
	In general, PIM-DM interactions with other multicast routing protocols		In general, PIM-DM interactions with other multicast routing protocols
	should be in compliance with RFC 2715 [11]. Other specific		should be in compliance with RFC 2715 [11]. Other specific
	interactions are noted below.		interactions are noted below.
	7.1 PIM-SM Interactions		5.1. PIM-SM Interactions
	PIM-DM is not intended to interact directly with PIM-SM, even though		PIM-DM is not intended to interact directly with PIM-SM, even though
	they share a common packet format. It is particularly important to note		they share a common packet format. It is particularly important to note
	that a router cannot differentiate between a PIM-DM neighbor and a		that a router cannot differentiate between a PIM-DM neighbor and a
	PIM-SM neighbor based on Hello messages.		PIM-SM neighbor based on Hello messages.
	In the event that a PIM-DM router becomes a neighbor of a PIM-SM router		In the event that a PIM-DM router becomes a neighbor of a PIM-SM router
	they will effectively form a simplex link with the PIM-DM router sending		they will effectively form a simplex link with the PIM-DM router sending
	all multicast messages to the PIM-SM router while the PIM-SM router		all multicast messages to the PIM-SM router while the PIM-SM router
	sends no multicast messages to the PIM-DM router.		sends no multicast messages to the PIM-DM router.
	The common packet format permits a hybrid PIM-SM/DM implementation that		The common packet format permits a hybrid PIM-SM/DM implementation that
	would use PIM-SM when a rendezvous point is known and PIM-DM when one is		would use PIM-SM when a rendezvous point is known and PIM-DM when one is
	not. Such an implementation is outside the scope of this document.		not. Such an implementation is outside the scope of this document.
	7.2 IGMP Interactions		5.2. IGMP Interactions
	PIM-DM will forward received multicast data packets to neighboring host		PIM-DM will forward received multicast data packets to neighboring host
	group members in all cases except when the PIM-DM router is in an Assert		group members in all cases except when the PIM-DM router is in an Assert
	Loser state on that interface. Note that a PIM Prune message is not		Loser state on that interface. Note that a PIM Prune message is not
	permitted to prevent the delivery of messages to a network with group		permitted to prevent the delivery of messages to a network with group
	members.		members.
	A PIM-DM Router MAY use the DR Priority option described in PIM-SM [3]		A PIM-DM Router MAY use the DR Priority option described in PIM-SM [3]
	to elect an IGMP v1 querier.		to elect an IGMP v1 querier.
	7.3 Source Specific Multicast (SSM) Interactions		5.3. Source Specific Multicast (SSM) Interactions
	PIM-DM makes no special considerations for SSM [9]. All Prunes and		PIM-DM makes no special considerations for SSM [9]. All Prunes and
	Grafts within the protocol are for a specific source, so no additional		Grafts within the protocol are for a specific source, so no additional
	checks need be made.		checks need be made.
	7.4 Multicast Group Scope Boundary Interactions		5.4. Multicast Group Scope Boundary Interactions
	While multicast group scope boundaries are generally identical to		While multicast group scope boundaries are generally identical to
	routing area boundaries, it is conceivable that a routing area might be		routing area boundaries, it is conceivable that a routing area might be
	partitioned for a particular multicast group. PIM-DM routers MUST NOT		partitioned for a particular multicast group. PIM-DM routers MUST NOT
	send any messages concerning a particular group across that group's		send any messages concerning a particular group across that group's
	scope boundary.		scope boundary.
	8. IANA Considerations		6. IANA Considerations
	8.1 PIM Address Family		6.1. PIM Address Family
	The PIM Address Family field was chosen to be 8 bits as a tradeoff		The PIM Address Family field was chosen to be 8 bits as a tradeoff
	between packet format and use of the IANA assigned numbers. When the		between packet format and use of the IANA assigned numbers. When the
	PIM packet format was designed, only 15 values were assigned for Address		PIM packet format was designed, only 15 values were assigned for Address
	Families and large numbers of new Address Families were not envisioned,		Families and large numbers of new Address Families were not envisioned,
	8 bits seemed large enough. However, the IANA assigns Address Families		8 bits seemed large enough. However, the IANA assigns Address Families
	in a 16 bit value. Therefore, the PIM Address Family is allocated as		in a 16 bit value. Therefore, the PIM Address Family is allocated as
	follows:		follows:
	Values 0 through 127 are designated to have the same meaning as IANA		Values 0 through 127 are designated to have the same meaning as IANA
	assigned Address Family Numbers [6].		assigned Address Family Numbers [6].
	Values 128 through 250 are designated to be assigned by the IANA based		Values 128 through 250 are designated to be assigned by the IANA based
	upon IESG approval as defined in [7].		upon IESG approval as defined in [7].
	Values 251 through 255 are designated for Private Use, as defined in		Values 251 through 255 are designated for Private Use, as defined in
	[7].		[7].
	8.2 PIM Hello Options		6.2. PIM Hello Options
	Values 17 through 65000 are to be assigned by the IANA. Since the space		Values 17 through 65000 are to be assigned by the IANA. Since the space
	is large, they may be assigned as First Come First Served as defined in		is large, they may be assigned as First Come First Served as defined in
	[7]. Such assignments are valid for one year, and may be renewed.		[7]. Such assignments are valid for one year, and may be renewed.
	Permanent assignments require a specification as defined in [7].		Permanent assignments require a specification as defined in [7].
	9. Security Considerations		7. Security Considerations
	The IPsec authentication header [8] MAY be used to provide data		The IPsec authentication header [8] MAY be used to provide data
	integrity protection and groupwise data origin authentication of PIM		integrity protection and groupwise data origin authentication of PIM
	protocol messages. Authentication of PIM messages can protect against		protocol messages. Authentication of PIM messages can protect against
	unwanted behaviors caused by unauthorized or altered PIM messages. In		unwanted behaviors caused by unauthorized or altered PIM messages. In
	any case, PIM router SHOULD NOT accept and process PIM messages from		any case, PIM router SHOULD NOT accept and process PIM messages from
	neighbors unless a valid Hello message has been received from that		neighbors unless a valid Hello message has been received from that
	neighbor.		neighbor.
	We should note that PIM-DM has no rendezvous point, and therefore no		We should note that PIM-DM has no rendezvous point, and therefore no
	single point of failure that may be vulnerable. It is further worth		single point of failure that may be vulnerable. It is further worth
	noting that because PIM-DM uses unicast routes provided by an unknown		noting that because PIM-DM uses unicast routes provided by an unknown
	routing protocol, it may suffer collateral effects if the unicast		routing protocol, it may suffer collateral effects if the unicast
	routing protocol is attacked.		routing protocol is attacked.
	9.1 Attacks Based on Forged Messages		7.1. Attacks Based on Forged Messages
	The extent of possible damage depends on the type of counterfeit		The extent of possible damage depends on the type of counterfeit
	messages accepted. We next consider the impact of possible forgeries. A		messages accepted. We next consider the impact of possible forgeries. A
	forged PIM-DM message is link local, and can only reach a LAN if it was		forged PIM-DM message is link local, and can only reach a LAN if it was
	sent by a local host or if it was allowed onto the LAN by a compromised		sent by a local host or if it was allowed onto the LAN by a compromised
	or non-compliant router.		or non-compliant router.
	1. A forged a Hello message can cause multicast traffic to be delivered		1. A forged a Hello message can cause multicast traffic to be delivered
	to links where there are no legitimate requestors, potentially		to links where there are no legitimate requestors, potentially
	wasting bandwidth on that link. On a multi-access LAN, the effects		wasting bandwidth on that link. On a multi-access LAN, the effects
	skipping to change at page 46, line 50 ¶		skipping to change at page 51, line 28 ¶
	Such a forgery would prevent any hosts downstream of that LAN from		Such a forgery would prevent any hosts downstream of that LAN from
	receiving traffic.		receiving traffic.
	6. A forged State Refresh message on a multi-access LAN would have the		6. A forged State Refresh message on a multi-access LAN would have the
	same impact as a forged Assert message, having the same general		same impact as a forged Assert message, having the same general
	functions. In addition, forged State Refresh messages would be		functions. In addition, forged State Refresh messages would be
	propagated downstream and might be used in a denial of service		propagated downstream and might be used in a denial of service
	attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh		attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh
	messages propagated.		messages propagated.
	9.2 Non-cryptographic Authentication Mechanisms		7.2. Non-cryptographic Authentication Mechanisms
	A PIM-DM router SHOULD provide an option to limit the set of neighbors		A PIM-DM router SHOULD provide an option to limit the set of neighbors
	from which it will accept PIM-DM messages. Either static configuration		from which it will accept PIM-DM messages. Either static configuration
	of IP addresses or an IPsec security association may be used. All		of IP addresses or an IPsec security association may be used. All
	options that restrict the range of addresses from which packets are		options that restrict the range of addresses from which packets are
	accepted MUST default to allowing all packets.		accepted MUST default to allowing all packets.
	Furthermore, a PIM router SHOULD NOT accept protocol messages from a		Furthermore, a PIM router SHOULD NOT accept protocol messages from a
	router from which it has not yet received a valid Hello message.		router from which it has not yet received a valid Hello message.
	9.3 Authentication Using IPsec		7.3. Authentication Using IPsec
	The IPsec [8] transport mode using the Authentication Header (AH) is the		The IPsec [8] transport mode using the Authentication Header (AH) is the
	recommended method to prevent the above attacks in PIM. The anti-replay		recommended method to prevent the above attacks in PIM. The anti-replay
	option provided by IPsec SHOULD also be enabled. The specific AH		option provided by IPsec SHOULD also be enabled. The specific AH
	authentication algorithm and parameters, including the choice of		authentication algorithm and parameters, including the choice of
	authentication algorithm and the choice of key, are configured by the		authentication algorithm and the choice of key, are configured by the
	network administrator. The Encapsulating Security Payload (ESP) MAY also		network administrator. The Encapsulating Security Payload (ESP) MAY also
	be used to provide both encryption and authentication of PIM protocol		be used to provide both encryption and authentication of PIM protocol
	messages. When IPsec authentication is used, a PIM router SHOULD reject		messages. When IPsec authentication is used, a PIM router SHOULD reject
	(drop without processing) any unauthorized PIM protocol messages.		(drop without processing) any unauthorized PIM protocol messages.
	skipping to change at page 47, line 31 ¶		skipping to change at page 52, line 19 ¶
	does not describe protocols for establishing Security Associations. It		does not describe protocols for establishing Security Associations. It
	assumes that manual configuration of Security Associations is performed,		assumes that manual configuration of Security Associations is performed,
	but it does not preclude the use of some future negotiation protocol		but it does not preclude the use of some future negotiation protocol
	such as GDOI [16] to establish Security Associations.		such as GDOI [16] to establish Security Associations.
	The network administrator defines a Security Association (SA) and		The network administrator defines a Security Association (SA) and
	Security Parameters Index (SPI) that is to be used to authenticate all		Security Parameters Index (SPI) that is to be used to authenticate all
	PIM-DM protocol messages from each router on each link in a PIM-DM		PIM-DM protocol messages from each router on each link in a PIM-DM
	domain. Note that if the same SA is used by different sending routers on		domain. Note that if the same SA is used by different sending routers on
	the same link, anti-replay mechanisms could prevent the acceptance of		the same link, anti-replay mechanisms could prevent the acceptance of
	legitimate PIM-DM messages. All PIM-DM protocol messages use SPI 0.		legitimate PIM-DM messages.
	The Security Policy Database at a PIM-DM router should be configured to		The Security Policy Database at a PIM-DM router should be configured to
	ensure that all incoming and outgoing PIM-DM packets use the SA		ensure that all incoming and outgoing PIM-DM packets use the SA
	associated with the interface to which the packet is sent. Note that,		associated with the interface to which the packet is sent. Note that,
	according to [8], there is nominally a different Security Association		according to [8], there is nominally a different Security Association
	Database (SAD) for each router interface. Thus, the selected Security		Database (SAD) for each router interface. Thus, the selected Security
	Association for an inbound PIM-DM packet can vary depending on the		Association for an inbound PIM-DM packet can vary depending on the
	interface on which the packet arrived. This fact allows the network		interface on which the packet arrived. This fact allows the network
	administrator to use different authentication methods for each link,		administrator to use different authentication methods for each link,
	even though the destination address is the same for most PIM-DM packets,		even though the destination address is the same for most PIM-DM packets,
	regardless of interface.		regardless of interface.
	9.4 Denial of Service Attacks		7.4. Denial of Service Attacks
	There are a number of possible denial of service attacks against PIM		There are a number of possible denial of service attacks against PIM
	that can be caused by generating false PIM protocol messages or even by		that can be caused by generating false PIM protocol messages or even by
	generating false data traffic. Authenticating PIM protocol traffic		generating false data traffic. Authenticating PIM protocol traffic
	prevents some, but not all of these attacks. The possible attacks		prevents some, but not all of these attacks. The possible attacks
	include:		include:
	* Sending packets to many different group addresses quickly can be a		* Sending packets to many different group addresses quickly can be a
	denial of service attack in and of itself. These messages will		denial of service attack in and of itself. These messages will
	initially be flooded throughout the network before they are pruned		initially be flooded throughout the network before they are pruned
	back. The maintenance of state machines and State Refresh messages		back. The maintenance of state machines and State Refresh messages
	will be a continual drain on network resources.		will be a continual drain on network resources.
	* Forged State Refresh messages sent quickly could be propagated by		* Forged State Refresh messages sent quickly could be propagated by
	downstream routers, creating a potential denial of service attack.		downstream routers, creating a potential denial of service attack.
	Therefore, a PIM-DM router SHOULD rate limit State Refresh messages		Therefore, a PIM-DM router SHOULD rate limit State Refresh messages
	propagated.		propagated.
	10. Authors' Addresses		8. Authors' Addresses
	Andrew Adams		Andrew Adams
	NextHop Technologies		NextHop Technologies
	825 Victors Way, Suite 100		825 Victors Way, Suite 100
	Ann Arbor, MI 48108-2738		Ann Arbor, MI 48108-2738
	ala@nexthop.com		ala@nexthop.com
	Jonathan Nicholas		Jonathan Nicholas
	ITT Industries		ITT Industries
	Aerospace/Communications Division		Aerospace/Communications Division
	100 Kingsland Rd		100 Kingsland Rd
	Clifton, NJ 07014		Clifton, NJ 07014
	jonathan.nicholas@itt.com		jonathan.nicholas@itt.com
	William Siadak		William Siadak
	NextHop Technologies		NextHop Technologies
	825 Victors Way, Suite 100		825 Victors Way, Suite 100
	Ann Arbor, MI 48108-2738		Ann Arbor, MI 48108-2738
	wfs@nexthop.com		wfs@nexthop.com
	11. Acknowledgments		9. Acknowledgments
	The major features of PIM-DM were originally designed by Stephen		The major features of PIM-DM were originally designed by Stephen
	Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy,		Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy,
	David Meyer, and Liming Wei. Additional features for state refresh		David Meyer, and Liming Wei. Additional features for state refresh
	were designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch.		were designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch.
	This revision was undertaken to incorporate some of the lessons learned		This revision was undertaken to incorporate some of the lessons learned
	during the evolution of the PIM-SM specification and early deployments		during the evolution of the PIM-SM specification and early deployments
	of PIM-DM.		of PIM-DM.
	Thanks the PIM Working Group for their comments.		Thanks the PIM Working Group for their comments.
	12. References		10. References
	[1] S.E. Deering, "Multicast Routing in a Datagram Internetwork",		[1] S.E. Deering, "Multicast Routing in a Datagram Internetwork",
	Ph.D. Thesis, Electrical Engineering Dept., Stanford University,		Ph.D. Thesis, Electrical Engineering Dept., Stanford University,
	December 1991.		December 1991.
	[2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast		[2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast
	Routing Protocol", November 1988, RFC 1075		Routing Protocol", November 1988, RFC 1075
	[3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol		[3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol
	Independent Multicast - Sparse Mode (PIM-SM)",		Independent Multicast - Sparse Mode (PIM-SM)",
	draft-ietf-pim-sm-v2-new-04.txt, work in progress.		draft-ietf-pim-sm-v2-new-05.txt, work in progress.
	[4] S.E. Deering, "Host Extensions for IP Multicasting", August 1989,		[4] S.E. Deering, "Host Extensions for IP Multicasting", August 1989,
	RFC 1112.		RFC 1112.
	[5] W.Fenner, "Internet Group Management Protocol, Version 2",		[5] W.Fenner, "Internet Group Management Protocol, Version 2",
	November 1997, RFC 2236.		November 1997, RFC 2236.
	[6] IANA, "Address Family Numbers", linked from		[6] IANA, "Address Family Numbers", linked from
	http://www.iana.org/numbers.html.		http://www.iana.org/numbers.html.
	skipping to change at page 49, line 31 ¶		skipping to change at page 54, line 31 ¶
	[11] D. Thaler, "Interoperability Rules for Multicast Routing		[11] D. Thaler, "Interoperability Rules for Multicast Routing
	Protocols", October 1999, RFC 2715		Protocols", October 1999, RFC 2715
	[12] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol		[12] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol
	Independent Multicast MIB for IPv4", October 2000, RFC 2934		Independent Multicast MIB for IPv4", October 2000, RFC 2934
	[13] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)		[13] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", December 1998, RFC 2460.		Specification", December 1998, RFC 2460.
	[14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional		[14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
	Protocol Independent Multicast", draft-ietf-pim-bidir-03.txt,		Protocol Independent Multicast", draft-ietf-pim-bidir-04.txt,
	work in progress.		work in progress.
	[15] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router		[15] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Bootstrap Router
	(BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-02.txt,		(BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-02.txt,
	work in progress.		work in progress.
	[16] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of		[16] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of
	Interpretation", draft-ietf-msec-gdoi-03.txt, work in progress.		Interpretation", draft-ietf-msec-gdoi-03.txt, work in progress.
End of changes. 131 change blocks.
	226 lines changed or deleted		258 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/