draft-ietf-pim-rfc4601bis-06.txt   rfc7761.txt 
Network Working Group B. Fenner Internet Engineering Task Force (IETF) B. Fenner
Internet Draft Arista Networks Request for Comments: 7761 Arista Networks
Intended Status: Internet Standard M. Handley STD: 83 M. Handley
Expires: February 12, 2016 UCL Obsoletes: 4601 UCL
Obsoletes: 4601 H. Holbrook Category: Standards Track H. Holbrook
Arastra ISSN: 2070-1721 I. Kouvelas
I. Kouvelas Arista Networks
R. Parekh R. Parekh
Cisco Systems, Inc. Cisco Systems, Inc.
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
L. Zheng L. Zheng
Huawei Technologies Huawei Technologies
August 12, 2015 March 2016
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) Protocol Specification (Revised)
draft-ietf-pim-rfc4601bis-06
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2016.
Abstract Abstract
This document specifies Protocol Independent Multicast - Sparse Mode This document specifies Protocol Independent Multicast - Sparse Mode
(PIM-SM). PIM-SM is a multicast routing protocol that can use the (PIM-SM). PIM-SM is a multicast routing protocol that can use the
underlying unicast routing information base or a separate multicast- underlying unicast routing information base or a separate multicast-
capable routing information base. It builds unidirectional shared capable routing information base. It builds unidirectional shared
trees rooted at a Rendezvous Point (RP) per group, and optionally trees rooted at a Rendezvous Point (RP) per group, and it optionally
creates shortest-path trees per source. creates shortest-path trees per source.
This document obsoletes RFC 4601 by replacing it, addresses the This document obsoletes RFC 4601 by replacing it, addresses the
errata filed against it, removes the optional (*,*,RP),PIM Multicast errata filed against it, removes the optional (*,*,RP), PIM Multicast
Border Router features and authentication using IPsec that lack Border Router features and authentication using IPsec that lack
sufficient deployment experience (see Appendix A) and moves the PIM sufficient deployment experience (see Appendix A), and moves the PIM
specification to Internet Standard. specification to Internet Standard.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7761.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction ....................................................5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology .....................................................5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions ................................................5
2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . . 8 2.2. Pseudocode Notation ........................................7
3. PIM-SM Protocol Overview . . . . . . . . . . . . . . . . . . . 8 3. PIM-SM Protocol Overview ........................................7
3.1. Phase One: RP Tree . . . . . . . . . . . . . . . . . . . . 9 3.1. Phase One: RP Tree .........................................8
3.2. Phase Two: Register-Stop . . . . . . . . . . . . . . . . . 9 3.2. Phase Two: Register-Stop ...................................9
3.3. Phase Three: Shortest-Path Tree . . . . . . . . . . . . . 10 3.3. Phase Three: Shortest-Path Tree ...........................10
3.4. Source-Specific Joins . . . . . . . . . . . . . . . . . . 11 3.4. Source-Specific Joins .....................................10
3.5. Source-Specific Prunes . . . . . . . . . . . . . . . . . . 12 3.5. Source-Specific Prunes ....................................11
3.6. Multi-Access Transit LANs . . . . . . . . . . . . . . . . 12 3.6. Multi-Access Transit LANs .................................11
3.7. RP Discovery . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. RP Discovery ..............................................12
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 13 4. Protocol Specification .........................................12
4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . 14 4.1. PIM Protocol State ........................................13
4.1.1. General Purpose State . . . . . . . . . . . . . . . . 15 4.1.1. General-Purpose State ..............................14
4.1.2. (*,G) State . . . . . . . . . . . . . . . . . . . . . 16 4.1.2. (*,G) State ........................................15
4.1.3. (S,G) State . . . . . . . . . . . . . . . . . . . . . 17 4.1.3. (S,G) State ........................................17
4.1.4. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . 20 4.1.4. (S,G,rpt) State ....................................19
4.1.5. State Summarization Macros . . . . . . . . . . . . . . 21 4.1.5. State Summarization Macros .........................20
4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . 25 4.2. Data Packet Forwarding Rules ..............................24
4.2.1. Last-Hop Switchover to the SPT . . . . . . . . . . . . 27 4.2.1. Last-Hop Switchover to the SPT .....................27
4.2.2. Setting and Clearing the (S,G) SPTbit . . . . . . . . 28 4.2.2. Setting and Clearing the (S,G) SPTbit ..............27
4.3. Designated Routers (DR) and Hello Messages . . . . . . . . 29 4.3. Designated Routers (DRs) and Hello Messages ...............29
4.3.1. Sending Hello Messages . . . . . . . . . . . . . . . . 29 4.3.1. Sending Hello Messages .............................29
4.3.2. DR Election . . . . . . . . . . . . . . . . . . . . . 31 4.3.2. DR Election ........................................31
4.3.3. Reducing Prune Propagation Delay on LANs . . . . . . . 33 4.3.3. Reducing Prune Propagation Delay on LANs ...........33
4.3.4. Maintaining Secondary Address Lists . . . . . . . . . 36 4.3.4. Maintaining Secondary Address Lists ................36
4.4. PIM Register Messages . . . . . . . . . . . . . . . . . . 37 4.4. PIM Register Messages .....................................37
4.4.1. Sending Register Messages from the DR . . . . . . . . 37 4.4.1. Sending Register Messages from the DR ..............38
4.4.2. Receiving Register Messages at the RP . . . . . . . . 41 4.4.2. Receiving Register Messages at the RP ..............43
4.5. PIM Join/Prune Messages . . . . . . . . . . . . . . . . . 43
4.5.1. Receiving (*,G) Join/Prune Messages . . . . . . . . . 43
4.5.2. Receiving (S,G) Join/Prune Messages . . . . . . . . . 48
4.5.3. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . 51
4.5.4. Sending (*,G) Join/Prune Messages . . . . . . . . . . 56
4.5.5. Sending (S,G) Join/Prune Messages . . . . . . . . . . 61
4.5.6. (S,G,rpt) Periodic Messages . . . . . . . . . . . . . 66
4.5.7. State Machine for (S,G,rpt) Triggered Messages . . . . 67
4.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . . 71
4.6.1. (S,G) Assert Message State Machine . . . . . . . . . . 72
4.6.2. (*,G) Assert Message State Machine . . . . . . . . . . 79
4.6.3. Assert Metrics . . . . . . . . . . . . . . . . . . . . 85
4.6.4. AssertCancel Messages . . . . . . . . . . . . . . . . 87
4.6.5. Assert State Macros . . . . . . . . . . . . . . . . . 87
4.7. PIM Bootstrap and RP Discovery . . . . . . . . . . . . . . 91
4.7.1. Group-to-RP Mapping . . . . . . . . . . . . . . . . . 92
4.7.2. Hash Function . . . . . . . . . . . . . . . . . . . . 93
4.8. Source-Specific Multicast . . . . . . . . . . . . . . . . 94
4.8.1. Protocol Modifications for SSM Destination Addresses . 94
4.8.2. PIM-SSM-Only Routers . . . . . . . . . . . . . . . . . 95
4.9. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . 96
4.9.1. Encoded Source and Group Address Formats . . . . . . . 98
4.9.2. Hello Message Format . . . . . . . . . . . . . . . . .101
4.9.3. Register Message Format . . . . . . . . . . . . . . .105
4.9.4. Register-Stop Message Format . . . . . . . . . . . . .108
4.9.5. Join/Prune Message Format . . . . . . . . . . . . . .108
4.9.5.1. Group Set Source List Rules . . . . . . . . . . .111
4.9.5.2. Group Set Fragmentation . . . . . . . . . . . . .114
4.9.6. Assert Message Format . . . . . . . . . . . . . . . .115
4.10. PIM Timers . . . . . . . . . . . . . . . . . . . . . . .116
4.11. Timer Values . . . . . . . . . . . . . . . . . . . . . .118
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .123
5.1. PIM Address Family . . . . . . . . . . . . . . . . . . . .123
5.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . .124
6. Security Considerations . . . . . . . . . . . . . . . . . . .124
6.1. Attacks Based on Forged Messages . . . . . . . . . . . . .124
6.1.1. Forged Link-Local Messages . . . . . . . . . . . . . .124
6.1.2. Forged Unicast Messages . . . . . . . . . . . . . . .125
6.2. Non-Cryptographic Authentication Mechanisms . . . . . . .125
6.3. Authentication . . . . . . . . . . . . . . . . . . . . . .126
6.4. Denial-of-Service Attacks . . . . . . . . . . . . . . . .126
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .126
8. Normative References . . . . . . . . . . . . . . . . . . . . .127
9. Informative References . . . . . . . . . . . . . . . . . . . .127
Appendix A. Functionality removed from RFC 4601 . . . . . . . . .129
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .130
List of Figures 4.5. PIM Join/Prune Messages ...................................44
4.5.1. Receiving (*,G) Join/Prune Messages ................45
4.5.2. Receiving (S,G) Join/Prune Messages ................50
4.5.3. Receiving (S,G,rpt) Join/Prune Messages ............54
4.5.4. Sending (*,G) Join/Prune Messages ..................61
4.5.5. Sending (S,G) Join/Prune Messages ..................65
4.5.6. (S,G,rpt) Periodic Messages ........................71
4.5.7. State Machine for (S,G,rpt) Triggered Messages .....72
4.6. PIM Assert Messages .......................................76
4.6.1. (S,G) Assert Message State Machine .................77
4.6.2. (*,G) Assert Message State Machine .................85
4.6.3. Assert Metrics .....................................93
4.6.4. AssertCancel Messages ..............................94
4.6.5. Assert State Macros ................................95
4.7. PIM Bootstrap and RP Discovery ............................98
4.7.1. Group-to-RP Mapping ................................99
4.7.2. Hash Function .....................................100
4.8. Source-Specific Multicast ................................101
4.8.1. Protocol Modifications for SSM Destination
Addresses .........................................102
4.8.2. PIM-SSM-Only Routers ..............................102
4.9. PIM Packet Formats .......................................104
4.9.1. Encoded Source and Group Address Formats ..........105
4.9.2. Hello Message Format ..............................108
4.9.3. Register Message Format ...........................111
4.9.4. Register-Stop Message Format ......................113
4.9.5. Join/Prune Message Format .........................114
4.9.5.1. Group Set Source List Rules ..............117
4.9.5.2. Group Set Fragmentation ..................120
4.9.6. Assert Message Format .............................121
4.10. PIM Timers ..............................................122
4.11. Timer Values ............................................124
5. IANA Considerations ...........................................130
5.1. PIM Address Family .......................................130
5.2. PIM Hello Options ........................................130
6. Security Considerations .......................................131
6.1. Attacks Based on Forged Messages .........................131
6.1.1. Forged Link-Local Messages ........................131
6.1.2. Forged Unicast Messages ...........................132
6.2. Non-cryptographic Authentication Mechanisms ..............132
6.3. Authentication ...........................................133
6.4. Denial-of-Service Attacks ................................133
7. References ....................................................133
7.1. Normative References .....................................133
7.2. Informative References ...................................134
Appendix A. Functionality Removed from RFC 4601 ..................136
Acknowledgements .................................................136
Authors' Addresses ...............................................136
Figure 1. Per-(S,G) register state machine at a DR ................38 List of Figures (Shown in Tabular Form)
Figure 2. Downstream per-interface (*,G) state machine ............45
Figure 3. Downstream per-interface (S,G) state machine ............49 Figure 1. Per-(S,G) Register State Machine at a DR ................39
Figure 4. Downstream per-interface (S,G,rpt) state machine ........53 Figure 2. Downstream Per-Interface (*,G) State Machine ............47
Figure 5. Upstream (*,G) state machine ............................58 Figure 3. Downstream Per-Interface (S,G) State Machine ............51
Figure 6. Upstream (S,G) state machine ............................62 Figure 4. Downstream Per-Interface (S,G,rpt) State Machine ........56
Figure 7. Upstream (S,G,rpt) state machine for triggered Figure 5. Upstream (*,G) State Machine ............................62
messages ................................................67 Figure 6. Upstream (S,G) State Machine ............................66
Figure 8. Per-interface (S,G) Assert State machine ................72 Figure 7. Upstream (S,G,rpt) State Machine for Triggered
Figure 9. Per-interface (*,G) Assert State machine ................80 Messages ................................................72
Figure 8. Per-Interface (S,G) Assert State Machine ................78
Figure 9. Per-interface (*,G) Assert State Machine ................87
1. Introduction 1. Introduction
This document specifies a protocol for efficiently routing multicast This document specifies a protocol for efficiently routing multicast
groups that may span wide-area (and inter-domain) internets. This groups that may span wide-area (and inter-domain) internets. This
protocol is called Protocol Independent Multicast - Sparse Mode protocol is called Protocol Independent Multicast - Sparse Mode
(PIM-SM) because, although it may use the underlying unicast routing (PIM-SM) because, although it may use the underlying unicast routing
to provide reverse-path information for multicast tree building, it to provide reverse-path information for multicast tree building, it
is not dependent on any particular unicast routing protocol. is not dependent on any particular unicast routing protocol.
PIM-SM version 2 was specified in RFC 4601 as a Proposed Standard. PIM-SM Version 2 was specified in RFC 4601 as a Proposed Standard.
This document is intended to address the reported errata and to This document is intended to address the reported errata and to
remove the optional (*,*,RP), PIM Multicast Border Router features remove the optional (*,*,RP), PIM Multicast Border Router features
and authentication using IPsec that lacks sufficient deployment and authentication using IPsec that lacks sufficient deployment
experience, to advance PIM-SM to Internet Standard. experience, to advance PIM-SM to Internet Standard.
This document specifies the same protocol as RFC 4601 and This document specifies the same protocol as RFC 4601, and
implementations per the specification in this document will be able implementations per the specification in this document will be able
to interoperate successfully with implementations per RFC 4601. to interoperate successfully with implementations per RFC 4601.
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" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
2.1. Definitions 2.1. Definitions
The following terms have special significance for PIM-SM: The following terms have special significance for PIM-SM:
Rendezvous Point (RP): Rendezvous Point (RP)
An RP is a router that has been configured to be used as the An RP is a router that has been configured to be used as the root
root of the non-source-specific distribution tree for a of the non-source-specific distribution tree for a multicast
multicast group. Join messages from receivers for a group are group. Join messages from receivers for a group are sent towards
sent towards the RP, and data from senders is sent to the RP so the RP, and data from senders is sent to the RP so that receivers
that receivers can discover who the senders are and start to can discover who the senders are and start to receive traffic
receive traffic destined for the group. destined for the group.
Designated Router (DR): Designated Router (DR)
A shared-media LAN like Ethernet may have multiple PIM-SM A shared-media LAN like Ethernet may have multiple PIM-SM routers
routers connected to it. A single one of these routers, the connected to it. A single one of these routers, the DR, will act
DR, will act on behalf of directly connected hosts with respect on behalf of directly connected hosts with respect to the PIM-SM
to the PIM-SM protocol. A single DR is elected per interface protocol. A single DR is elected per interface (LAN or otherwise)
(LAN or otherwise) using a simple election process. using a simple election process.
MRIB Multicast Routing Information Base. This is the multicast MRIB
topology table, which is typically derived from the unicast Multicast Routing Information Base. This is the multicast
routing table, or routing protocols such as Multiprotocol BGP topology table, which is typically derived from the unicast
(MBGP) that carry multicast-specific topology information. In routing table, or routing protocols such as Multiprotocol BGP
PIM-SM, the MRIB is used to decide where to send Join/Prune (MBGP) that carry multicast-specific topology information. In
messages. A secondary function of the MRIB is to provide PIM-SM, the MRIB is used to decide where to send Join/Prune
routing metrics for destination addresses; these metrics are messages. A secondary function of the MRIB is to provide routing
used when sending and processing Assert messages. metrics for destination addresses; these metrics are used when
sending and processing Assert messages.
RPF Neighbor RPF Neighbor
RPF stands for "Reverse Path Forwarding". The RPF Neighbor of RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a
a router with respect to an address is the neighbor that the router with respect to an address is the neighbor that the MRIB
MRIB indicates should be used to forward packets to that indicates should be used to forward packets to that address. In
address. In the case of a PIM-SM multicast group, the RPF the case of a PIM-SM multicast group, the RPF neighbor is the
neighbor is the router that a Join message for that group would router that a Join message for that group would be directed to, in
be directed to, in the absence of modifying Assert state. the absence of modifying Assert state.
TIB Tree Information Base. This is the collection of state at a TIB
PIM router that has been created by receiving PIM Join/Prune Tree Information Base. This is the collection of state at a PIM
messages, PIM Assert messages, and Internet Group Management router that has been created by receiving PIM Join/Prune messages,
Protocol (IGMP) or Multicast Listener Discovery (MLD) PIM Assert messages, and Internet Group Management Protocol (IGMP)
information from local hosts. It essentially stores the state or Multicast Listener Discovery (MLD) information from local
of all multicast distribution trees at that router. hosts. It essentially stores the state of all multicast
distribution trees at that router.
MFIB Multicast Forwarding Information Base. The TIB holds all the MFIB
state that is necessary to forward multicast packets at a Multicast Forwarding Information Base. The TIB holds all the
router. However, although this specification defines forwarding state that is necessary to forward multicast packets at a router.
in terms of the TIB, to actually forward packets using the TIB However, although this specification defines forwarding in terms
is very inefficient. Instead, a real router implementation of the TIB, to actually forward packets using the TIB is very
will normally build an efficient MFIB from the TIB state to inefficient. Instead, a real router implementation will normally
perform forwarding. How this is done is implementation-specific build an efficient MFIB from the TIB state to perform forwarding.
and is not discussed in this document. How this is done is implementation-specific and is not discussed
in this document.
Upstream Upstream
Towards the root of the tree. The root of the tree may be Towards the root of the tree. The root of the tree may be either
either the source or the RP, depending on the context. the source or the RP, depending on the context.
Downstream Downstream
Away from the root of the tree. Away from the root of the tree.
GenID Generation Identifier, used to detect reboots. GenID
Generation Identifier, used to detect reboots.
2.2. 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 is the union of two sets, A and B. A (+) B is the union of two sets, A and B.
A (-) B is the elements of set A that are not in set B. A (-) B is the elements of set A that are not in set B.
NULL is the empty set or list. NULL is the empty set or list.
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.
Unless otherwise noted, operations specified by statements having Unless otherwise noted, operations specified by statements having
multiple (+) and (-) operators should be evaluated from left to multiple (+) and (-) operators should be evaluated from left to
right, i.e. A (+) B (-) C is the set resulting from union of sets A right, i.e., A (+) B (-) C is the set resulting from union of sets A
and B minus elements in set C. and B minus elements in set C.
3. PIM-SM Protocol Overview 3. PIM-SM Protocol Overview
This section provides an overview of PIM-SM behavior. It is intended This section provides an overview of PIM-SM behavior. It is intended
as an introduction to how PIM-SM works, and it is NOT definitive. as an introduction to how PIM-SM works, and it is NOT definitive.
For the definitive specification, see Section 4. For the definitive specification, see Section 4.
PIM relies on an underlying topology-gathering protocol to populate a PIM relies on an underlying topology-gathering protocol to populate a
routing table with routes. This routing table is called the routing table with routes. This routing table is called the
Multicast Routing Information Base (MRIB). The routes in this table Multicast Routing Information Base (MRIB). The routes in this table
may be taken directly from the unicast routing table, or they may be may be taken directly from the unicast routing table, or they may be
different and provided by a separate routing protocol such as MBGP different and provided by a separate routing protocol such as MBGP
[10]. Regardless of how it is created, the primary role of the MRIB [10]. Regardless of how it is created, the primary role of the MRIB
in the PIM protocol is to provide the next-hop router along a in the PIM protocol is to provide the next-hop router along a
multicast-capable path to each destination subnet. The MRIB is used multicast-capable path to each destination subnet. The MRIB is used
to determine the next-hop neighbor to which any PIM Join/Prune to determine the next-hop neighbor to which any PIM Join/Prune
message is sent. Data flows along the reverse path of the Join message is sent. Data flows along the reverse path of the Join
messages. Thus, in contrast to the unicast RIB, which specifies the messages. Thus, in contrast to the unicast RIB, which specifies the
next hop that a data packet would take to get to some subnet, the next hop that a data packet would take to get to some subnet, the
MRIB gives reverse-path information and indicates the path that a MRIB gives reverse-path information and indicates the path that a
multicast data packet would take from its origin subnet to the router multicast data packet would take from its origin subnet to the router
that has the MRIB. that has the MRIB.
skipping to change at page 9, line 15 skipping to change at page 8, line 17
sources to receivers without either the sources or receivers knowing sources to receivers without either the sources or receivers knowing
a priori of the existence of the others. This is essentially done in a priori of the existence of the others. This is essentially done in
three phases, although as senders and receivers may come and go at three phases, although as senders and receivers may come and go at
any time, all three phases may occur simultaneously. any time, all three phases may occur simultaneously.
3.1. Phase One: RP Tree 3.1. Phase One: RP Tree
In phase one, a multicast receiver expresses its interest in In phase one, a multicast receiver expresses its interest in
receiving traffic destined for a multicast group. Typically, it does receiving traffic destined for a multicast group. Typically, it does
this using IGMP [2] or MLD [4], but other mechanisms might also serve this using IGMP [2] or MLD [4], but other mechanisms might also serve
this purpose. One of the receiver's local routers is elected as the this purpose. One of the receiver's local routers is elected as the
Designated Router (DR) for that subnet. On receiving the receiver's Designated Router (DR) for that subnet. On receiving the receiver's
expression of interest, the DR then sends a PIM Join message towards expression of interest, the DR then sends a PIM Join message towards
the RP for that multicast group. This Join message is known as a the RP for that multicast group. This Join message is known as a
(*,G) Join because it joins group G for all sources to that group. (*,G) Join because it joins group G for all sources to that group.
The (*,G) Join travels hop-by-hop towards the RP for the group, and The (*,G) Join travels hop-by-hop towards the RP for the group, and
in each router it passes through, multicast tree state for group G is in each router it passes through, multicast tree state for group G is
instantiated. Eventually, the (*,G) Join either reaches the RP or instantiated. Eventually, the (*,G) Join either reaches the RP or
reaches a router that already has (*,G) Join state for that group. reaches a router that already has (*,G) Join state for that group.
When many receivers join the group, their Join messages converge on When many receivers join the group, their Join messages converge on
the RP and form a distribution tree for group G that is rooted at the the RP and form a distribution tree for group G that is rooted at the
skipping to change at page 9, line 37 skipping to change at page 8, line 39
shared tree because it is shared by all sources sending to that shared tree because it is shared by all sources sending to that
group. Join messages are resent periodically so long as the receiver group. Join messages are resent periodically so long as the receiver
remains in the group. When all receivers on a leaf-network leave the remains in the group. When all receivers on a leaf-network leave the
group, the DR will send a PIM (*,G) Prune message towards the RP for group, the DR will send a PIM (*,G) Prune message towards the RP for
that multicast group. However, if the Prune message is not sent for that multicast group. However, if the Prune message is not sent for
any reason, the state will eventually time out. any reason, the state will eventually time out.
A multicast data sender just starts sending data destined for a A multicast data sender just starts sending data destined for a
multicast group. The sender's local router (DR) takes those data multicast group. The sender's local router (DR) takes those data
packets, unicast-encapsulates them, and sends them directly to the packets, unicast-encapsulates them, and sends them directly to the
RP. The RP receives these encapsulated data packets, decapsulates RP. The RP receives these encapsulated data packets, decapsulates
them, and forwards them onto the shared tree. The packets then them, and forwards them onto the shared tree. The packets then
follow the (*,G) multicast tree state in the routers on the RP Tree, follow the (*,G) multicast tree state in the routers on the RP Tree,
being replicated wherever the RP Tree branches, and eventually being replicated wherever the RP Tree branches, and eventually
reaching all the receivers for that multicast group. The process of reaching all the receivers for that multicast group. The process of
encapsulating data packets to the RP is called registering, and the encapsulating data packets to the RP is called registering, and the
encapsulation packets are known as PIM Register packets. encapsulation packets are known as PIM Register packets.
At the end of phase one, multicast traffic is flowing encapsulated to At the end of phase one, multicast traffic is flowing encapsulated to
the RP, and then natively over the RP tree to the multicast the RP, and then natively over the RP tree to the multicast
receivers. receivers.
3.2. Phase Two: Register-Stop 3.2. Phase Two: Register-Stop
Register-encapsulation of data packets is inefficient for two Register-encapsulation of data packets is inefficient for two
reasons: reasons:
o Encapsulation and decapsulation may be relatively expensive o Encapsulation and decapsulation may be relatively expensive
operations for a router to perform, depending on whether or not the operations for a router to perform, depending on whether or not
router has appropriate hardware for these tasks. the router has appropriate hardware for these tasks.
o Traveling all the way to the RP, and then back down the shared tree o Traveling all the way to the RP, and then back down the shared
may result in the packets traveling a relatively long distance to tree may result in the packets traveling a relatively long
reach receivers that are close to the sender. For some distance to reach receivers that are close to the sender. For
applications, this increased latency or bandwidth consumption is some applications, this increased latency or bandwidth consumption
undesirable. is undesirable.
Although Register-encapsulation may continue indefinitely, for these Although Register-encapsulation may continue indefinitely, for these
reasons, the RP will normally choose to switch to native forwarding. reasons, the RP will normally choose to switch to native forwarding.
To do this, when the RP receives a register-encapsulated data packet To do this, when the RP receives a register-encapsulated data packet
from source S on group G, it will normally initiate an (S,G) source- from source S on group G, it will normally initiate an (S,G) source-
specific Join towards S. This Join message travels hop-by-hop specific Join towards S. This Join message travels hop-by-hop
towards S, instantiating (S,G) multicast tree state in the routers towards S, instantiating (S,G) multicast tree state in the routers
along the path. (S,G) multicast tree state is used only to forward along the path. (S,G) multicast tree state is used only to forward
packets for group G if those packets come from source S. Eventually packets for group G if those packets come from source S. Eventually
the Join message reaches S's subnet or a router that already has the Join message reaches S's subnet or a router that already has
(S,G) multicast tree state, and then packets from S start to flow (S,G) multicast tree state, and then packets from S start to flow
following the (S,G) tree state towards the RP. These data packets following the (S,G) tree state towards the RP. These data packets
may also reach routers with (*,G) state along the path towards the may also reach routers with (*,G) state along the path towards the
RP; if they do, they can shortcut onto the RP tree at this point. RP; if they do, they can shortcut onto the RP tree at this point.
While the RP is in the process of joining the source-specific tree While the RP is in the process of joining the source-specific tree
for S, the data packets will continue being encapsulated to the RP. for S, the data packets will continue being encapsulated to the RP.
When packets from S also start to arrive natively at the RP, the RP When packets from S also start to arrive natively at the RP, the RP
will be receiving two copies of each of these packets. At this will be receiving two copies of each of these packets. At this
point, the RP starts to discard the encapsulated copy of these point, the RP starts to discard the encapsulated copy of these
packets, and it sends a Register-Stop message back to S's DR to packets, and it sends a Register-Stop message back to S's DR to
prevent the DR from unnecessarily encapsulating the packets. prevent the DR from unnecessarily encapsulating the packets.
At the end of phase 2, traffic will be flowing natively from S along At the end of phase two, traffic will be flowing natively from S
a source-specific tree to the RP, and from there along the shared along a source-specific tree to the RP, and from there along the
tree to the receivers. Where the two trees intersect, traffic may shared tree to the receivers. Where the two trees intersect, traffic
transfer from the source-specific tree to the RP tree and thus avoid may transfer from the source-specific tree to the RP tree and thus
taking a long detour via the RP. avoid taking a long detour via the RP.
Note that a sender may start sending before or after a receiver joins Note that a sender may start sending before or after a receiver joins
the group, and thus phase two may happen before the shared tree to the group, and thus phase two may happen before the shared tree to
the receiver is built. the receiver is built.
3.3. Phase Three: Shortest-Path Tree 3.3. Phase Three: Shortest-Path Tree
Although having the RP join back towards the source removes the Although having the RP join back towards the source removes the
encapsulation overhead, it does not completely optimize the encapsulation overhead, it does not completely optimize the
forwarding paths. For many receivers, the route via the RP may forwarding paths. For many receivers, the route via the RP may
involve a significant detour when compared with the shortest path involve a significant detour when compared with the shortest path
from the source to the receiver. from the source to the receiver.
To obtain lower latencies or more efficient bandwidth utilization, a To obtain lower latencies or more efficient bandwidth utilization, a
router on the receiver's LAN, typically the DR, may optionally router on the receiver's LAN, typically the DR, may optionally
initiate a transfer from the shared tree to a source-specific initiate a transfer from the shared tree to a source-specific
shortest-path tree (SPT). To do this, it issues an (S,G) Join shortest-path tree (SPT). To do this, it issues an (S,G) Join
towards S. This instantiates state in the routers along the path to towards S. This instantiates state in the routers along the path to
S. Eventually, this join either reaches S's subnet or reaches a S. Eventually, this join either reaches S's subnet or reaches a
router that already has (S,G) state. When this happens, data packets router that already has (S,G) state. When this happens, data packets
from S start to flow following the (S,G) state until they reach the from S start to flow following the (S,G) state until they reach the
receiver. receiver.
At this point, the receiver (or a router upstream of the receiver) At this point, the receiver (or a router upstream of the receiver)
will be receiving two copies of the data: one from the SPT and one will be receiving two copies of the data: one from the SPT and one
from the RPT. When the first traffic starts to arrive from the SPT, from the RPT. When the first traffic starts to arrive from the SPT,
the DR or upstream router starts to drop the packets for G from S the DR or upstream router starts to drop the packets for G from S
that arrive via the RP tree. In addition, it sends an (S,G) Prune that arrive via the RP tree. In addition, it sends an (S,G) Prune
message towards the RP. This is known as an (S,G,rpt) Prune. The message towards the RP. This is known as an (S,G,rpt) Prune. The
Prune message travels hop-by-hop, instantiating state along the path Prune message travels hop-by-hop, instantiating state along the path
towards the RP indicating that traffic from S for G should NOT be towards the RP indicating that traffic from S for G should NOT be
forwarded in this direction. The prune is propagated until it reaches forwarded in this direction. The prune is propagated until it
the RP or a router that still needs the traffic from S for other reaches the RP or a router that still needs the traffic from S for
receivers. other receivers.
By now, the receiver will be receiving traffic from S along the By now, the receiver will be receiving traffic from S along the
shortest-path tree between the receiver and S. In addition, the RP shortest-path tree between the receiver and S. In addition, the RP
is receiving the traffic from S, but this traffic is no longer is receiving the traffic from S, but this traffic is no longer
reaching the receiver along the RP tree. As far as the receiver is reaching the receiver along the RP tree. As far as the receiver is
concerned, this is the final distribution tree. concerned, this is the final distribution tree.
3.4. Source-Specific Joins 3.4. Source-Specific Joins
IGMPv3 permits a receiver to join a group and specify that it only IGMPv3 permits a receiver to join a group and specify that it only
wants to receive traffic for a group if that traffic comes from a wants to receive traffic for a group if that traffic comes from a
particular source. If a receiver does this, and no other receiver on particular source. If a receiver does this, and no other receiver on
the LAN requires all the traffic for the group, then the DR may omit the LAN requires all the traffic for the group, then the DR may omit
performing a (*,G) join to set up the shared tree, and instead issue performing a (*,G) join to set up the shared tree, and instead issue
a source-specific (S,G) join only. a source-specific (S,G) join only.
The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is
currently set aside for source-specific multicast in IPv4. For currently set aside for source-specific multicast in IPv4. For
groups in this range, receivers should only issue source-specific groups in this range, receivers should only issue source-specific
IGMPv3 joins. If a PIM router receives a non-source-specific join for IGMPv3 joins. If a PIM router receives a non-source-specific join
a group in this range, it should ignore it, as described in Section for a group in this range, it should ignore it.
4.8.
3.5. Source-Specific Prunes 3.5. Source-Specific Prunes
IGMPv3 also permits a receiver to join a group and to specify that it IGMPv3 also permits a receiver to join a group and to specify that it
only wants to receive traffic for a group if that traffic does not only wants to receive traffic for a group if that traffic does not
come from a specific source or sources. In this case, the DR will come from a specific source or sources. In this case, the DR will
perform a (*,G) join as normal, but may combine this with an perform a (*,G) join as normal, but may combine this with an
(S,G,rpt) prune for each of the sources the receiver does not wish to (S,G,rpt) prune for each of the sources the receiver does not wish to
receive. receive.
3.6. Multi-Access Transit LANs 3.6. Multi-Access Transit LANs
The overview so far has concerned itself with point-to-point transit The overview so far has concerned itself with point-to-point transit
links. However, using multi-access LANs such as Ethernet for transit links. However, using multi-access LANs such as Ethernet for transit
is not uncommon. This can cause complications for three reasons: is not uncommon. This can cause complications for three reasons:
o Two or more routers on the LAN may issue (*,G) Joins to different o Two or more routers on the LAN may issue (*,G) Joins to different
upstream routers on the LAN because they have inconsistent MRIB upstream routers on the LAN because they have inconsistent MRIB
entries regarding how to reach the RP. Both paths on the RP tree entries regarding how to reach the RP. Both paths on the RP tree
will be set up, causing two copies of all the shared tree traffic will be set up, causing two copies of all the shared tree traffic
to appear on the LAN. to appear on the LAN.
o Two or more routers on the LAN may issue (S,G) Joins to different o Two or more routers on the LAN may issue (S,G) Joins to different
upstream routers on the LAN because they have inconsistent MRIB upstream routers on the LAN because they have inconsistent MRIB
entries regarding how to reach source S. Both paths on the source- entries regarding how to reach source S. Both paths on the
specific tree will be set up, causing two copies of all the traffic source-specific tree will be set up, causing two copies of all the
from S to appear on the LAN. traffic from S to appear on the LAN.
o A router on the LAN may issue a (*,G) Join to one upstream router o A router on the LAN may issue a (*,G) Join to one upstream router
on the LAN, and another router on the LAN may issue an (S,G) Join on the LAN, and another router on the LAN may issue an (S,G) Join
to a different upstream router on the same LAN. Traffic from S may to a different upstream router on the same LAN. Traffic from S
reach the LAN over both the RPT and the SPT. If the receiver may reach the LAN over both the RPT and the SPT. If the receiver
behind the downstream (*,G) router doesn't issue an (S,G,rpt) behind the downstream (*,G) router doesn't issue an (S,G,rpt)
prune, then this condition would persist. prune, then this condition would persist.
All of these problems are caused by there being more than one All of these problems are caused by there being more than one
upstream router with join state for the group or source-group pair. upstream router with join state for the group or source-group pair.
PIM does not prevent such duplicate joins from occurring; instead, PIM does not prevent such duplicate joins from occurring; instead,
when duplicate data packets appear on the LAN from different routers, when duplicate data packets appear on the LAN from different routers,
these routers notice this and then elect a single forwarder. This these routers notice this and then elect a single forwarder. This
election is performed using PIM Assert messages, which resolve the election is performed using PIM Assert messages, which resolve the
problem in favor of the upstream router that has (S,G) state; or, if problem in favor of the upstream router that has (S,G) state; or, if
neither or both router has (S,G) state, then the problem is resolved neither router or both routers have (S,G) state, then the problem is
in favor of the router with the best metric to the RP for RP trees, resolved in favor of the router with the best metric to the RP for RP
or the best metric to the source for source-specific trees. trees, or the best metric to the source for source-specific trees.
These Assert messages are also received by the downstream routers on These Assert messages are also received by the downstream routers on
the LAN, and these cause subsequent Join messages to be sent to the the LAN, and these cause subsequent Join messages to be sent to the
upstream router that won the Assert. upstream router that won the Assert.
3.7. RP Discovery 3.7. RP Discovery
PIM-SM routers need to know the address of the RP for each group for PIM-SM routers need to know the address of the RP for each group for
which they have (*,G) state. This address is obtained automatically which they have (*,G) state. This address is obtained automatically
(e.g., embedded-RP), through a bootstrap mechanism, or through static (e.g., embedded-RP), through a bootstrap mechanism, or through static
configuration. configuration.
One dynamic way to do this is to use the Bootstrap Router (BSR) One dynamic way to do this is to use the Bootstrap Router (BSR)
mechanism [11]. One router in each PIM domain is elected the mechanism [11]. One router in each PIM domain is elected the BSR
Bootstrap Router through a simple election process. All the routers through a simple election process. All the routers in the domain
in the domain that are configured to be candidates to be RPs that are configured to be candidates to be RPs periodically unicast
periodically unicast their candidacy to the BSR. From the their candidacy to the BSR. From the candidates, the BSR picks an
candidates, the BSR picks an RP-set, and periodically announces this RP-set, and periodically announces this set in a Bootstrap message.
set in a Bootstrap message. Bootstrap messages are flooded hop-by-hop Bootstrap messages are flooded hop-by-hop throughout the domain until
throughout the domain until all routers in the domain know the RP- all routers in the domain know the RP-Set.
Set.
To map a group to an RP, a router hashes the group address into the To map a group to an RP, a router hashes the group address into the
RP-set using an order-preserving hash function (one that minimizes RP-set using an order-preserving hash function (one that minimizes
changes if the RP-Set changes). The resulting RP is the one that it changes if the RP-Set changes). The resulting RP is the one that it
uses as the RP for that group. uses as the RP for that group.
4. Protocol Specification 4. Protocol Specification
The specification of PIM-SM is broken into several parts: The specification of PIM-SM is broken into several parts:
o Section 4.1 details the protocol state stored. o Section 4.1 details the protocol state stored.
o Section 4.2 specifies the data packet forwarding rules. o Section 4.2 specifies the data packet forwarding rules.
o Section 4.3 specifies Designated Router (DR) election and the rules o Section 4.3 specifies Designated Router (DR) election and the
for sending and processing Hello messages. rules for sending and processing Hello messages.
o Section 4.4 specifies the PIM Register generation and processing o Section 4.4 specifies the PIM Register generation and processing
rules. rules.
o Section 4.5 specifies the PIM Join/Prune generation and processing o Section 4.5 specifies the PIM Join/Prune generation and processing
rules. rules.
o Section 4.6 specifies the PIM Assert generation and processing o Section 4.6 specifies the PIM Assert generation and processing
rules. rules.
o Section 4.7 specifies the RP discovery mechanisms. o Section 4.7 specifies the RP discovery mechanisms.
o The subset of PIM required to support Source-Specific Multicast, o Section 4.8 describes PIM-SSM, the subset of PIM required to
PIM-SSM, is described in Section 4.8. support Source-Specific Multicast.
o PIM packet formats are specified in Section 4.9. o Section 4.9 specifies the PIM packet formats.
o A summary of PIM-SM timers and their default values is given in o Section 4.10 provides a summary of PIM-SM timers, and Section 4.11
Section 4.10. provides their default values.
4.1. PIM Protocol State 4.1. PIM Protocol State
This section specifies all the protocol state that a PIM This section specifies all the protocol state that a PIM
implementation should maintain in order to function correctly. We implementation should maintain in order to function correctly. We
term this state the Tree Information Base (TIB), as it holds the term this state the Tree Information Base (TIB), as it holds the
state of all the multicast distribution trees at this router. In state of all the multicast distribution trees at this router. In
this specification, we define PIM mechanisms in terms of the TIB. this specification, we define PIM 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.
Although we specify precisely the state to be kept, this does not Although we specify precisely the state to be kept, this does not
mean that an implementation of PIM-SM needs to hold the state in this mean that an implementation of PIM-SM needs to hold the state in this
form. This is actually an abstract state definition, which is needed form. This is actually an abstract state definition, which is needed
in order to specify the router's behavior. A PIM-SM implementation in order to specify the router's behavior. A PIM-SM implementation
is free to hold whatever internal state it requires and will still be is free to hold whatever internal state it requires and will still be
conformant with this specification so long as it results in the same conformant with this specification so long as it results in the same
externally visible protocol behavior as an abstract router that holds externally visible protocol behavior as an abstract router that holds
the following state. the following state.
We divide TIB state into three sections: We divide TIB state into three sections:
(*,G) state (*,G) state
State that maintains the RP tree for G. State that maintains the RP tree for G.
skipping to change at page 15, line 5 skipping to change at page 14, line 11
on the RP tree for G. For example, if a source is being on the RP tree for G. For example, if a source is being
received on the source-specific tree, it will normally have been received on the source-specific tree, it will normally have been
pruned off the RP tree. This prune state is (S,G,rpt) state. pruned off the RP tree. This prune state is (S,G,rpt) state.
The state that should be kept is described below. Of course, The state that should be kept is described below. Of course,
implementations will only maintain state when it is relevant to implementations will only maintain state when it is relevant to
forwarding operations; for example, the "NoInfo" state might be forwarding operations; for example, the "NoInfo" state might be
assumed from the lack of other state information rather than being assumed from the lack of other state information rather than being
held explicitly. held explicitly.
4.1.1. General Purpose State 4.1.1. General-Purpose State
A router holds the following non-group-specific state: A router holds the following non-group-specific state:
For each interface: For each interface:
o Effective Override Interval o Effective Override Interval
o Effective Propagation Delay o Effective Propagation Delay
o Suppression state: One of {"Enable", "Disable"} o Suppression state: One of {"Enable", "Disable"}
Neighbor State: Neighbor State:
For each neighbor: For each neighbor:
o Information from neighbor's Hello o Information from neighbor's Hello
o Neighbor's GenID. o Neighbor's GenID.
o Neighbor Liveness Timer (NLT) o Neighbor Liveness Timer (NLT)
Designated Router (DR) State: Designated Router (DR) State:
o Designated Router's IP Address o Designated Router's IP Address
o DR's DR Priority o DR's DR Priority
The Effective Override Interval, the Effective Propagation Delay and The Effective Override Interval, the Effective Propagation Delay, and
the Interface suppression state are described in Section 4.3.3. the Interface suppression state are described in Section 4.3.3.
Designated Router state is described in Section 4.3. Designated Router state is described in Section 4.3.
4.1.2. (*,G) State 4.1.2. (*,G) State
For every group G, a router keeps the following state: For every group G, a router keeps the following state:
(*,G) state: (*,G) state:
For each interface: For each interface:
Local Membership: Local Membership:
State: One of {"NoInfo", "Include"} State: One of {"NoInfo", "Include"}
PIM (*,G) Join/Prune State: PIM (*,G) Join/Prune State:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune- o State: One of {"NoInfo" (NI), "Join" (J),
Pending" (PP)} "Prune-Pending" (PP)}
o Prune-Pending Timer (PPT) o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
(*,G) Assert Winner State (*,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L), o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)} "I won Assert" (W)}
o Assert Timer (AT) o Assert Timer (AT)
o Assert winner's IP Address (AssertWinner) o Assert winner's IP Address (AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric) o Assert winner's Assert Metric (AssertWinnerMetric)
Not interface specific: Not interface specific:
Upstream (*,G) Join/Prune State: Upstream (*,G) Join/Prune State:
o State: One of {"NotJoined(*,G)", "Joined(*,G)"} o State: One of {"NotJoined(*,G)", "Joined(*,G)"}
o Upstream Join/Prune Timer (JT) o Upstream Join/Prune Timer (JT)
o Last RP Used o Last RP Used
o Last RPF Neighbor towards RP that was used o Last RPF Neighbor towards RP that was used
Local membership is the result of the local membership mechanism Local membership is the result of the local membership mechanism
(such as IGMP or MLD) running on that interface. It need not be kept (such as IGMP or MLD) running on that interface. It need not be kept
if this router is not the DR on that interface unless this router won if this router is not the DR on that interface unless this router won
a (*,G) assert on this interface for this group, although a (*,G) assert on this interface for this group, although
implementations may optionally keep this state in case they become implementations may optionally keep this state in case they become
the DR or assert winner. It is RECOMMENDED to store this information the DR or assert winner. It is RECOMMENDED to store this information
if possible, as it reduces latency converging to stable operating if possible, as it reduces latency converging to stable operating
conditions after a failure causing a change of DR. This information conditions after a failure causing a change of DR. This information
is used by the pim_include(*,G) macro described in Section 4.1.5. is used by the pim_include(*,G) macro described in Section 4.1.5.
PIM (*,G) Join/Prune state is the result of receiving PIM (*,G) PIM (*,G) Join/Prune state is the result of receiving PIM (*,G)
Join/Prune messages on this interface and is specified in Section Join/Prune messages on this interface and is specified in
4.5.1. The state is used by the macros that calculate the outgoing Section 4.5.1. The state is used by the macros that calculate the
interface list in Section 4.1.5, and in the JoinDesired(*,G) macro outgoing interface list in Section 4.1.5, and in the JoinDesired(*,G)
(defined in Section 4.5.4) that is used in deciding whether a macro (defined in Section 4.5.4) that is used in deciding whether a
Join(*,G) should be sent upstream. Join(*,G) should be sent upstream.
(*,G) Assert Winner state is the result of sending or receiving (*,G) (*,G) Assert Winner state is the result of sending or receiving (*,G)
Assert messages on this interface. It is specified in Section 4.6.2. Assert messages on this interface. It is specified in Section 4.6.2.
The upstream (*,G) Join/Prune State reflects the state of the The upstream (*,G) Join/Prune State reflects the state of the
upstream (*,G) state machine described in Section 4.5.4. upstream (*,G) state machine described in Section 4.5.4.
The upstream (*,G) Join/Prune Timer is used to send out periodic The upstream (*,G) Join/Prune Timer is used to send out periodic
Join(*,G) messages, and to override Prune(*,G) messages from peers on Join(*,G) messages, and to override Prune(*,G) messages from peers on
an upstream LAN interface. an upstream LAN interface.
The last RP used must be stored because if the RP-Set changes The last RP used must be stored because if the RP changes, then state
(Section 4.7), then state must be torn down and rebuilt for groups must be torn down and rebuilt for groups whose RP changes.
whose RP changes.
The last RPF neighbor towards the RP is stored because if the MRIB The last RPF neighbor towards the RP is stored because if the MRIB
changes, then the RPF neighbor towards the RP may change. If it does changes, then the RPF neighbor towards the RP may change. If it does
so, then we need to trigger a new Join(*,G) to the new upstream so, then we need to trigger a new Join(*,G) to the new upstream
neighbor and a Prune(*,G) to the old upstream neighbor. Similarly, neighbor and a Prune(*,G) to the old upstream neighbor. Similarly,
if a router detects through a changed GenID in a Hello message that if a router detects through a changed GenID in a Hello message that
the upstream neighbor towards the RP has rebooted, then it SHOULD re- the upstream neighbor towards the RP has rebooted, then it SHOULD
instantiate state by sending a Join(*,G). These mechanisms are re-instantiate state by sending a Join(*,G). These mechanisms are
specified in Section 4.5.4. specified in Section 4.5.4.
4.1.3. (S,G) State 4.1.3. (S,G) State
For every source/group pair (S,G), a router keeps the following For every source/group pair (S,G), a router keeps the following
state: 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) Join/Prune State: PIM (S,G) Join/Prune State:
o State: One of {"NoInfo" (NI), "Join" (J), "Prune- o State: One of {"NoInfo" (NI), "Join" (J),
Pending" (PP)} "Prune-Pending" (PP)}
o Prune-Pending Timer (PPT) o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
(S,G) Assert Winner State (S,G) Assert Winner State
o State: One of {"NoInfo" (NI), "I lost Assert" (L), o State: One of {"NoInfo" (NI), "I lost Assert" (L),
"I won Assert" (W)} "I won Assert" (W)}
o Assert Timer (AT) o Assert Timer (AT)
o Assert winner's IP Address (AssertWinner) o Assert winner's IP Address (AssertWinner)
o Assert winner's Assert Metric (AssertWinnerMetric) o Assert winner's Assert Metric (AssertWinnerMetric)
Not interface specific: Not interface specific:
Upstream (S,G) Join/Prune State: Upstream (S,G) Join/Prune State:
o State: One of {"NotJoined(S,G)", "Joined(S,G)"} o State: One of {"NotJoined(S,G)", "Joined(S,G)"}
o Upstream (S,G) Join/Prune Timer (JT)
o Last RPF Neighbor towards S that was used o Upstream (S,G) Join/Prune Timer (JT)
o SPTbit (indicates (S,G) state is active) o Last RPF Neighbor towards S that was used
o (S,G) Keepalive Timer (KAT) o SPTbit (indicates (S,G) state is active)
o (S,G) Keepalive Timer (KAT)
Additional (S,G) state at the DR: Additional (S,G) state at the DR:
o Register state: One of {"Join" (J), "Prune" (P), o Register state: One of {"Join" (J), "Prune" (P),
"Join-Pending" (JP), "NoInfo" (NI)} "Join-Pending" (JP), "NoInfo" (NI)}
o Register-Stop timer o Register-Stop Timer (RST)
Local membership is the result of the local source-specific Local membership is the result of the local source-specific
membership mechanism (such as IGMP version 3) running on that membership mechanism (such as IGMP Version 3) running on that
interface and specifying that this particular source should be interface and specifying that this particular source should be
included. As stored here, this state is the resulting state after included. As stored here, this state is the resulting state after
any IGMPv3 inconsistencies have been resolved. It need not be kept any IGMPv3 inconsistencies have been resolved. It need not be kept
if this router is not the DR on that interface unless this router won if this router is not the DR on that interface unless this router won
an (S,G) assert on this interface for this group. However, it is an (S,G) assert on this interface for this group. However, it is
RECOMMENDED to store this information if possible, as it reduces RECOMMENDED to store this information if possible, as it reduces
latency converging to stable operating conditions after a failure latency converging to stable operating conditions after a failure
causing a change of DR. This information is used by the causing a change of DR. This information is used by the
pim_include(S,G) macro described in Section 4.1.5. pim_include(S,G) macro described in Section 4.1.5.
PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) PIM (S,G) Join/Prune state is the result of receiving PIM (S,G)
Join/Prune messages on this interface and is specified in Section Join/Prune messages on this interface and is specified in
4.5.2. The state is used by the macros that calculate the outgoing Section 4.5.2. The state is used by the macros that calculate the
interface list in Section 4.1.5, and in the JoinDesired(S,G) macro outgoing interface list in Section 4.1.5, and in the JoinDesired(S,G)
(defined in Section 4.5.5) that is used in deciding whether a macro (defined in Section 4.5.5) that is used in deciding whether a
Join(S,G) should be sent upstream. Join(S,G) should be sent upstream.
(S,G) Assert Winner state is the result of sending or receiving (S,G) (S,G) Assert Winner state is the result of sending or receiving (S,G)
Assert messages on this interface. It is specified in Section 4.6.1. Assert messages on this interface. It is specified in Section 4.6.1.
The upstream (S,G) Join/Prune State reflects the state of the The upstream (S,G) Join/Prune State reflects the state of the
upstream (S,G) state machine described in Section 4.5.5. upstream (S,G) state machine described in Section 4.5.5.
The upstream (S,G) Join/Prune Timer is used to send out periodic The upstream (S,G) Join/Prune Timer is used to send out periodic
Join(S,G) messages, and to override Prune(S,G) messages from peers on Join(S,G) messages, and to override Prune(S,G) messages from peers on
an upstream LAN interface. an upstream LAN interface.
The last RPF neighbor towards S is stored because if the MRIB The last RPF neighbor towards S is stored because if the MRIB
changes, then the RPF neighbor towards S may change. If it does so, changes, then the RPF neighbor towards S may change. If it does so,
then we need to trigger a new Join(S,G) to the new upstream neighbor then we need to trigger a new Join(S,G) to the new upstream neighbor
and a Prune(S,G) to the old upstream neighbor. Similarly, if the and a Prune(S,G) to the old upstream neighbor. Similarly, if the
router detects through a changed GenID in a Hello message that the router detects through a changed GenID in a Hello message that the
upstream neighbor towards S has rebooted, then it SHOULD re- upstream neighbor towards S has rebooted, then it SHOULD
instantiate state by sending a Join(S,G). These mechanisms are re-instantiate state by sending a Join(S,G). These mechanisms are
specified in Section 4.5.5. specified in Section 4.5.5.
The SPTbit is used to indicate whether forwarding is taking place on The SPTbit is used to indicate whether forwarding is taking place on
the (S,G) Shortest Path Tree (SPT) or on the (*,G) tree. A router the (S,G) Shortest Path Tree (SPT) or on the (*,G) tree. A router
can have (S,G) state and still be forwarding on (*,G) state during can have (S,G) state and still be forwarding on (*,G) state during
the interval when the source-specific tree is being constructed. the interval when the source-specific tree is being constructed.
When SPTbit is FALSE, only (*,G) forwarding state is used to forward When SPTbit is FALSE, only (*,G) forwarding state is used to forward
packets from S to G. When SPTbit is TRUE, both (*,G) and (S,G) packets from S to G. When SPTbit is TRUE, both (*,G) and (S,G)
forwarding state are used. forwarding state are used.
The (S,G) Keepalive Timer is updated by data being forwarded using The (S,G) Keepalive Timer is updated by data being forwarded using
this (S,G) forwarding state. It is used to keep (S,G) state alive in this (S,G) forwarding state. It is used to keep (S,G) state alive in
the absence of explicit (S,G) Joins. Amongst other things, this is the absence of explicit (S,G) Joins. Amongst other things, this is
necessary for the so-called "turnaround rules" -- when the RP uses necessary for the so-called "turnaround rules" -- when the RP uses
(S,G) joins to stop encapsulation, and then (S,G) prunes to prevent (S,G) joins to stop encapsulation, and then (S,G) prunes to prevent
traffic from unnecessarily reaching the RP. traffic from unnecessarily reaching the RP.
On a DR, the (S,G) Register State is used to keep track of whether to On a DR, the (S,G) Register State is used to keep track of whether to
encapsulate data to the RP on the Register Tunnel; the (S,G) encapsulate data to the RP on the Register Tunnel; the (S,G)
Register-Stop timer tracks how long before encapsulation begins again Register-Stop Timer tracks how long before encapsulation begins again
for a given (S,G). for a given (S,G).
4.1.4. (S,G,rpt) State 4.1.4. (S,G,rpt) State
For every source/group pair (S,G) for which a router also has (*,G) For every source/group pair (S,G) for which a router also has (*,G)
state, it also keeps the following state: state, it also keeps the following state:
(S,G,rpt) state: (S,G,rpt) state:
For each interface: For each interface:
Local Membership: Local Membership:
State: One of {"NoInfo", "Exclude"} State: One of {"NoInfo", "Exclude"}
PIM (S,G,rpt) Join/Prune State: PIM (S,G,rpt) Join/Prune State:
o State: One of {"NoInfo", "Pruned", "Prune- o State: One of {"NoInfo", "Pruned",
Pending"} "Prune-Pending"}
o Prune-Pending Timer (PPT) o Prune-Pending Timer (PPT)
o Join/Prune Expiry Timer (ET) o Join/Prune Expiry Timer (ET)
Not interface specific: Not interface specific:
Upstream (S,G,rpt) Join/Prune State: Upstream (S,G,rpt) Join/Prune State:
o State: One of {"RPTNotJoined(G)", o State: One of {"RPTNotJoined(G)",
"NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"} "NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"}
o Override Timer (OT) o Override Timer (OT)
Local membership is the result of the local source-specific Local membership is the result of the local source-specific
membership mechanism (such as IGMPv3) running on that interface and membership mechanism (such as IGMPv3) running on that interface and
specifying that although there is (*,G) Include state, this specifying that although there is (*,G) Include state, this
particular source should be excluded. As stored here, this state is particular source should be excluded. As stored here, this state is
the resulting state after any IGMPv3 inconsistencies between LAN the resulting state after any IGMPv3 inconsistencies between LAN
members have been resolved. It need not be kept if this router is members have been resolved. It need not be kept if this router is
not the DR on that interface unless this router won a (*,G) assert on not the DR on that interface unless this router won a (*,G) assert on
this interface for this group. However, we RECOMMEND storing this this interface for this group. However, we RECOMMEND storing this
information if possible, as it reduces latency converging to stable information if possible, as it reduces latency converging to stable
operating conditions after a failure causing a change of DR. This operating conditions after a failure causing a change of DR. This
information is used by the pim_exclude(S,G) macro described in information is used by the pim_exclude(S,G) macro described in
Section 4.1.5. Section 4.1.5.
PIM (S,G,rpt) Join/Prune state is the result of receiving PIM PIM (S,G,rpt) Join/Prune state is the result of receiving PIM
(S,G,rpt) Join/Prune messages on this interface and is specified in (S,G,rpt) Join/Prune messages on this interface and is specified in
Section 4.5.3. The state is used by the macros that calculate the Section 4.5.3. The state is used by the macros that calculate the
outgoing interface list in Section 4.1.5, and in the rules for adding outgoing interface list in Section 4.1.5, and in the rules for adding
Prune(S,G,rpt) messages to Join(*,G) messages specified in Section Prune(S,G,rpt) messages to Join(*,G) messages specified in
4.5.6. Section 4.5.6.
The upstream (S,G,rpt) Join/Prune state is used along with the The upstream (S,G,rpt) Join/Prune state is used along with the
Override Timer to send the correct override messages in response to Override Timer to send the correct override messages in response to
Join/Prune messages sent by upstream peers on a LAN. This state and Join/Prune messages sent by upstream peers on a LAN. This state and
behavior are specified in Section 4.5.7. behavior are specified in Section 4.5.7.
4.1.5. State Summarization Macros 4.1.5. State Summarization Macros
Using this state, we define the following "macro" definitions, which Using this state, we define the following "macro" definitions, which
we will use in the descriptions of the state machines and pseudocode we will use in the descriptions of the state machines and pseudocode
skipping to change at page 21, line 33 skipping to change at page 20, line 46
The most important macros are those that define the outgoing The most important macros are those that define the outgoing
interface list (or "olist") for the relevant state. An olist can be interface list (or "olist") for the relevant state. An olist can be
"immediate" if it is built directly from the state of the relevant "immediate" if it is built directly from the state of the relevant
type. For example, the immediate_olist(S,G) is the olist that would type. For example, the immediate_olist(S,G) is the olist that would
be built if the router only had (S,G) state and no (*,G) or (S,G,rpt) be built if the router only had (S,G) state and no (*,G) or (S,G,rpt)
state. In contrast, the "inherited" olist inherits state from other state. In contrast, the "inherited" olist inherits state from other
types. For example, the inherited_olist(S,G) is the olist that is types. For example, the inherited_olist(S,G) is the olist that is
relevant for forwarding a packet from S to G using both source- relevant for forwarding a packet from S to G using both source-
specific and group-specific state. specific and group-specific state.
There is no immediate_olist(S,G,rpt) as (S,G,rpt) state is negative There is no immediate_olist(S,G,rpt), as (S,G,rpt) state is negative
state; it removes interfaces in the (*,G) olist from the olist that state; it removes interfaces in the (*,G) olist from the olist that
is actually used to forward traffic. The inherited_olist(S,G,rpt) is is actually used to forward traffic. The inherited_olist(S,G,rpt) is
therefore the olist that would be used for a packet from S to G therefore the olist that would be used for a packet from S to G
forwarding on the RP tree. It is a strict subset of forwarding on the RP tree. It is a strict subset of
immediate_olist(*,G). immediate_olist(*,G).
Generally speaking, the inherited olists are used for forwarding, and Generally speaking, the inherited_olists are used for forwarding, and
the immediate_olists are used to make decisions about state the immediate_olists are used to make decisions about state
maintenance. maintenance.
immediate_olist(*,G) = immediate_olist(*,G) =
joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G) joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)
immediate_olist(S,G) = immediate_olist(S,G) =
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G) joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
inherited_olist(S,G,rpt) = inherited_olist(S,G,rpt) =
skipping to change at page 22, line 22 skipping to change at page 21, line 32
joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G) joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)
The macros pim_include(*,G) and pim_include(S,G) indicate the The macros pim_include(*,G) and pim_include(S,G) indicate the
interfaces to which traffic might be forwarded because of hosts that interfaces to which traffic might be forwarded because of hosts that
are local members on that interface. Note that normally only the DR are local members on that interface. Note that normally only the DR
cares about local membership, but when an assert happens, the assert cares about local membership, but when an assert happens, the assert
winner takes over responsibility for forwarding traffic to local winner takes over responsibility for forwarding traffic to local
members that have requested traffic on a group or source/group pair. members that have requested traffic on a group or source/group pair.
pim_include(*,G) = pim_include(*,G) =
{ all interfaces I such that: { all interfaces I such that:
( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE ) ( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me ) OR AssertWinner(*,G,I) == me )
AND local_receiver_include(*,G,I) } AND local_receiver_include(*,G,I) }
pim_include(S,G) = pim_include(S,G) =
{ all interfaces I such that: { all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE ) ( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
OR AssertWinner(S,G,I) == me ) OR AssertWinner(S,G,I) == me )
AND local_receiver_include(S,G,I) } AND local_receiver_include(S,G,I) }
pim_exclude(S,G) = pim_exclude(S,G) =
{ all interfaces I such that: { all interfaces I such that:
( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE ) ( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
OR AssertWinner(*,G,I) == me ) OR AssertWinner(*,G,I) == me )
AND local_receiver_exclude(S,G,I) } AND local_receiver_exclude(S,G,I) }
The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD
module or other local membership mechanism has determined that local module or other local membership mechanism has determined that local
members on interface I desire to receive traffic sent specifically by members on interface I desire to receive traffic sent specifically by
S to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD S to G. "local_receiver_include(*,G,I)" is true if the IGMP/MLD
module or other local membership mechanism has determined that local module or other local membership mechanism has determined that local
members on interface I desire to receive all traffic sent to G members on interface I desire to receive all traffic sent to G
(possibly excluding traffic from a specific set of sources). (possibly excluding traffic from a specific set of sources).
"local_receiver_exclude(S,G,I) is true if "local_receiver_exclude(S,G,I)" is true if
"local_receiver_include(*,G,I)" is true but none of the local members "local_receiver_include(*,G,I)" is true but none of the local members
desire to receive traffic from S. desire to receive traffic from S.
The set "joins(*,G)" is the set of all interfaces on which the router The set "joins(*,G)" is the set of all interfaces on which the router
has received (*,G) Joins: has received (*,G) Joins:
joins(*,G) = joins(*,G) =
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(*,G,I) is either Join or Prune-Pending } DownstreamJPState(*,G,I) is either Join or Prune-Pending }
skipping to change at page 23, line 23 skipping to change at page 22, line 32
has received (S,G) Joins: has received (S,G) Joins:
joins(S,G) = joins(S,G) =
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(S,G,I) is either Join or Prune-Pending } DownstreamJPState(S,G,I) is either Join or Prune-Pending }
DownstreamJPState(S,G,I) is the state of the finite state machine in DownstreamJPState(S,G,I) is the state of the finite state machine in
Section 4.5.2. Section 4.5.2.
The set "prunes(S,G,rpt)" is the set of all interfaces on which the The set "prunes(S,G,rpt)" is the set of all interfaces on which the
router has received (*,G) joins and (S,G,rpt) prunes. router has received (*,G) joins and (S,G,rpt) prunes:
prunes(S,G,rpt) = prunes(S,G,rpt) =
{ all interfaces I such that { all interfaces I such that
DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp } DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp }
DownstreamJPState(S,G,rpt,I) is the state of the finite state machine DownstreamJPState(S,G,rpt,I) is the state of the finite state machine
in Section 4.5.3. in Section 4.5.3.
The set "lost_assert(*,G)" is the set of all interfaces on which the The set "lost_assert(*,G)" is the set of all interfaces on which the
router has received (*,G) joins but has lost a (*,G) assert. The router has received (*,G) joins but has lost a (*,G) assert. The
skipping to change at page 25, line 28 skipping to change at page 24, line 36
I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in
Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser" Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser"
state. state.
4.2. Data Packet Forwarding Rules 4.2. Data Packet Forwarding Rules
The PIM-SM packet forwarding rules are defined below in pseudocode. The PIM-SM 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).
RP is the address of the Rendezvous Point for this group. RP is the address of the Rendezvous Point for this group.
RPF_interface(S) is the interface the MRIB indicates would be used RPF_interface(S) is the interface the MRIB indicates would be used
to route packets to S. to route packets to S.
RPF_interface(RP) is the interface the MRIB indicates would be RPF_interface(RP) is the interface the MRIB indicates would be
used to route packets to the RP, except at the RP when it is the used to route packets to the RP, except at the RP when it is
decapsulation interface (the "virtual" interface on which register the decapsulation interface (the "virtual" interface on which
packets are received). Register packets are received).
First, we restart (or start) the Keepalive Timer if the source is on First, we restart (or start) the Keepalive Timer if the source is on
a directly connected subnet. a directly connected subnet.
Second, we check to see if the SPTbit should be set because we've now Second, we check to see if the SPTbit should be set because we've now
switched from the RP tree to the SPT. switched from the RP tree to the SPT.
Next, we check to see whether the packet should be accepted based on Next, we check to see whether the packet should be accepted based on
TIB state and the interface that the packet arrived on. TIB state and the interface that the packet arrived on.
If the packet should be forwarded using (S,G) state, we then build an If the packet should be forwarded using (S,G) state, we then build an
outgoing interface list for the packet. If this list is not empty, outgoing interface list for the packet. If this list is not empty,
then we restart the (S,G) state Keepalive Timer. then we restart the (S,G) state Keepalive Timer.
If the packet should be forwarded using (*,G) state, then we just If the packet should be forwarded using (*,G) state, then we just
build an outgoing interface list for the packet. We also check if we build an outgoing interface list for the packet. We also check if we
should initiate a switch to start receiving this source on a shortest should initiate a switch to start receiving this source on a shortest
path tree. path tree.
Finally we remove the incoming interface from the outgoing interface Finally, we remove the incoming interface from the outgoing interface
list we've created, and if the resulting outgoing interface list is list we've created, and if the resulting outgoing interface list is
not empty, we forward the packet out of those interfaces. not empty, we forward the packet out of those interfaces.
On receipt of data from S to G on interface iif: On receipt of data from S to G on interface iif:
if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) { if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
set KeepaliveTimer(S,G) to Keepalive_Period set KeepaliveTimer(S,G) to Keepalive_Period
# Note: a register state transition or UpstreamJPState(S,G) # Note: A register state transition or UpstreamJPState(S,G)
# transition may happen as a result of restarting # transition may happen as a result of restarting
# KeepaliveTimer, and must be dealt with here. # KeepaliveTimer, and must be dealt with here.
} }
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
inherited_olist(S,G) != NULL ) { inherited_olist(S,G) != NULL ) {
set KeepaliveTimer(S,G) to Keepalive_Period set KeepaliveTimer(S,G) to Keepalive_Period
} }
Update_SPTbit(S,G,iif) Update_SPTbit(S,G,iif)
skipping to change at page 26, line 26 skipping to change at page 26, line 4
# KeepaliveTimer, and must be dealt with here. # KeepaliveTimer, and must be dealt with here.
} }
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
inherited_olist(S,G) != NULL ) { inherited_olist(S,G) != NULL ) {
set KeepaliveTimer(S,G) to Keepalive_Period set KeepaliveTimer(S,G) to Keepalive_Period
} }
Update_SPTbit(S,G,iif) Update_SPTbit(S,G,iif)
oiflist = NULL oiflist = NULL
if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) { if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {
oiflist = inherited_olist(S,G) oiflist = inherited_olist(S,G)
} else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE ) { } else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE ) {
oiflist = inherited_olist(S,G,rpt) oiflist = inherited_olist(S,G,rpt)
CheckSwitchToSpt(S,G) CheckSwitchToSpt(S,G)
} else { } else {
# Note: RPF check failed # Note: RPF check failed.
# A transition in an Assert FSM may cause an Assert(S,G) # A transition in an Assert finite state machine may cause an
# or Assert(*,G) message to be sent out interface iif. # Assert(S,G) or Assert(*,G) message to be sent out interface iif.
# See section 4.6 for details. # See Section 4.6 for details.
if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) { if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif send Assert(S,G) on iif
} else if ( SPTbit(S,G) == FALSE AND } else if ( SPTbit(S,G) == FALSE AND
iif is in inherited_olist(S,G,rpt) ) { iif is in inherited_olist(S,G,rpt) ) {
send Assert(*,G) on iif send Assert(*,G) on iif
} }
} }
oiflist = oiflist (-) iif oiflist = oiflist (-) iif
forward packet on all interfaces in oiflist forward packet on all interfaces in oiflist
skipping to change at page 27, line 24 skipping to change at page 26, line 49
forwarded on (*,G) state, taking into account (S,G,rpt) prune state, forwarded on (*,G) state, taking into account (S,G,rpt) prune state,
asserts, etc. asserts, etc.
Update_SPTbit(S,G,iif) is defined in Section 4.2.2. Update_SPTbit(S,G,iif) is defined in Section 4.2.2.
CheckSwitchToSpt(S,G) is defined in Section 4.2.1. CheckSwitchToSpt(S,G) is defined in Section 4.2.1.
UpstreamJPState(S,G) is the state of the finite state machine in UpstreamJPState(S,G) is the state of the finite state machine in
Section 4.5.5. Section 4.5.5.
Keepalive_Period is defined in Section 4.10. Keepalive_Period is defined in Section 4.11.
Data-triggered PIM-Assert messages sent from the above forwarding Data-triggered PIM-Assert messages sent from the above forwarding
code SHOULD be rate-limited in an implementation-dependent manner. code SHOULD be rate-limited in an implementation-dependent manner.
4.2.1. Last-Hop Switchover to the SPT 4.2.1. Last-Hop Switchover to the SPT
In Sparse-Mode PIM, last-hop routers join the shared tree towards the In Sparse-Mode PIM, last-hop routers join the shared tree towards the
RP. Once traffic from sources to joined groups arrives at a last-hop RP. Once traffic from sources to joined groups arrives at a last-hop
router, it has the option of switching to receive the traffic on a router, it has the option of switching to receive the traffic on a
shortest path tree (SPT). shortest path tree (SPT).
The decision for a router to switch to the SPT is controlled as The decision for a router to switch to the SPT is controlled as
follows: follows:
void void
CheckSwitchToSpt(S,G) { CheckSwitchToSpt(S,G) {
if ( ( pim_include(*,G) (-) pim_exclude(S,G) if ( ( pim_include(*,G) (-) pim_exclude(S,G)
(+) pim_include(S,G) != NULL ) (+) pim_include(S,G) != NULL )
AND SwitchToSptDesired(S,G) ) { AND SwitchToSptDesired(S,G) ) {
# Note: Restarting the KAT will result in the SPT switch # Note: Restarting the KAT will result in the SPT switch.
set KeepaliveTimer(S,G) to Keepalive_Period set KeepaliveTimer(S,G) to Keepalive_Period
} }
} }
SwitchToSptDesired(S,G) is a policy function that is implementation SwitchToSptDesired(S,G) is a policy function that is implementation
defined. An "infinite threshold" policy can be implemented by making defined. An "infinite threshold" policy can be implemented by making
SwitchToSptDesired(S,G) return false all the time. A "switch on SwitchToSptDesired(S,G) return false all the time. A "switch on
first packet" policy can be implemented by making first packet" policy can be implemented by making
SwitchToSptDesired(S,G) return true once a single packet has been SwitchToSptDesired(S,G) return true once a single packet has been
received for the source and group. received for the source and group.
4.2.2. Setting and Clearing the (S,G) SPTbit 4.2.2. Setting and Clearing the (S,G) SPTbit
The (S,G) SPTbit is used to distinguish whether to forward on (*,G) The (S,G) SPTbit is used to distinguish whether to forward on (*,G)
or on (S,G) state. When switching from the RP tree to the source or on (S,G) state. When switching from the RP tree to the source
tree, there is a transition period when data is arriving due to tree, there is a transition period when data is arriving due to
upstream (*,G) state while upstream (S,G) state is being established, upstream (*,G) state while upstream (S,G) state is being established,
during which time a router should continue to forward only on (*,G) during which time a router should continue to forward only on (*,G)
state. This prevents temporary black-holes that would be caused by state. This prevents temporary black holes that would be caused by
sending a Prune(S,G,rpt) before the upstream (S,G) state has finished sending a Prune(S,G,rpt) before the upstream (S,G) state has finished
being established. being established.
Thus, when a packet arrives, the (S,G) SPTbit is updated as follows: Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:
void void
Update_SPTbit(S,G,iif) { Update_SPTbit(S,G,iif) {
if ( iif == RPF_interface(S) if ( iif == RPF_interface(S)
AND JoinDesired(S,G) == TRUE AND JoinDesired(S,G) == TRUE
AND ( DirectlyConnected(S) == TRUE AND ( DirectlyConnected(S) == TRUE
skipping to change at page 28, line 46 skipping to change at page 28, line 32
such as when it receives an Assert(S,G) on RPF_interface(S) (see such as when it receives an Assert(S,G) on RPF_interface(S) (see
Section 4.6.1). Section 4.6.1).
JoinDesired(S,G) is defined in Section 4.5.5 and indicates whether we JoinDesired(S,G) is defined in Section 4.5.5 and indicates whether we
have the appropriate (S,G) Join state to wish to send a Join(S,G) have the appropriate (S,G) Join state to wish to send a Join(S,G)
upstream. upstream.
Basically, Update_SPTbit(S,G,iif) will set the SPTbit if we have the Basically, Update_SPTbit(S,G,iif) will set the SPTbit if we have the
appropriate (S,G) join state, and if the packet arrived on the appropriate (S,G) join state, and if the packet arrived on the
correct upstream interface for S, and if one or more of the following correct upstream interface for S, and if one or more of the following
conditions applies: conditions apply:
1. The source is directly connected, in which case the switch to the 1. The source is directly connected, in which case the switch to the
SPT is a no-op. SPT is a no-op.
2. The RPF interface to S is different from the RPF interface to the 2. The RPF interface to S is different from the RPF interface to the
RP. The packet arrived on RPF_interface(S), and so the SPT must RP. The packet arrived on RPF_interface(S), and so the SPT must
have been completed. have been completed.
3. No One wants the packet on the RP tree. 3. No one wants the packet on the RP tree.
4. RPF'(S,G) == RPF'(*,G). In this case, the router will never be 4. RPF'(S,G) == RPF'(*,G). In this case, the router will never be
able to tell if the SPT has been completed, so it should just able to tell if the SPT has been completed, so it should just
switch immediately. RPF'(S,G) != NULL check ensures that SPTbit switch immediately. The RPF'(S,G) != NULL check ensures that the
is set only if RPF neighbor towards S is valid. SPTbit is set only if the RPF neighbor towards S is valid.
In the case where the RPF interface is the same for the RP and for S, In the case where the RPF interface is the same for the RP and for S,
but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which
indicates that the upstream router with (S,G) state believes the SPT indicates that the upstream router with (S,G) state believes the SPT
has been completed. However, item (3) above is needed because there has been completed. However, item (3) above is needed because there
may not be any (*,G) state to trigger an Assert(S,G) to happen. may not be any (*,G) state to trigger an Assert(S,G) to happen.
The SPTbit is cleared in the (S,G) upstream state machine (see The SPTbit is cleared in the (S,G) upstream state machine (see
Section 4.5.5) when JoinDesired(S,G) becomes FALSE. Section 4.5.5) when JoinDesired(S,G) becomes FALSE.
4.3. Designated Routers (DR) and Hello Messages 4.3. Designated Routers (DRs) and Hello Messages
A shared-media LAN like Ethernet may have multiple PIM-SM routers A shared-media LAN like Ethernet may have multiple PIM-SM routers
connected to it. A single one of these routers, the DR, will act on connected to it. A single one of these routers, the DR, will act on
behalf of directly connected hosts with respect to the PIM-SM behalf of directly connected hosts with respect to the PIM-SM
protocol. Because the distinction between LANs and point-to-point protocol. Because the distinction between LANs and point-to-point
interfaces can sometimes be blurred, and because routers may also interfaces can sometimes be blurred, and because routers may also
have multicast host functionality, the PIM-SM specification makes no have multicast host functionality, the PIM-SM specification makes no
distinction between the two. Thus, DR election will happen on all distinction between the two. Thus, DR election will happen on all
interfaces, LAN or otherwise. interfaces, LAN or otherwise.
DR election is performed using Hello messages. Hello messages are DR election is performed using Hello messages. Hello messages are
also the way that option negotiation takes place in PIM, so that also the way that option negotiation takes place in PIM, so that
additional functionality can be enabled, or parameters tuned. additional functionality can be enabled, or parameters tuned.
4.3.1. Sending Hello Messages 4.3.1. Sending Hello Messages
PIM Hello messages are sent periodically on each PIM-enabled PIM Hello messages are sent periodically on each PIM-enabled
interface. They allow a router to learn about the neighboring PIM interface. They allow a router to learn about the neighboring PIM
routers on each interface. Hello messages are also the mechanism routers on each interface. Hello messages are also the mechanism
used to elect a Designated Router (DR), and to negotiate additional used to elect a DR, and to negotiate additional capabilities. A
capabilities. A router must record the Hello information received router must record the Hello information received from each PIM
from each PIM neighbor. neighbor.
Hello messages MUST be sent on all active interfaces, including Hello messages MUST be sent on all active interfaces, including
physical point-to-point links, and are multicast to the 'ALL-PIM- physical point-to-point links, and are multicast to the
ROUTERS' group address ('224.0.0.13' for IPv4 and 'ff02::d' for 'ALL-PIM-ROUTERS' group address ('224.0.0.13' for IPv4 and 'ff02::d'
IPv6). for IPv6).
We note that some implementations do not send Hello messages on We note that some implementations do not send Hello messages on
point-to-point interfaces. This is non-compliant behavior. A point-to-point interfaces. This is non-compliant behavior. A
compliant PIM router MUST send Hello messages, even on point-to-point compliant PIM router MUST send Hello messages, even on point-to-point
interfaces. interfaces.
A per-interface Hello Timer (HT(I)) is used to trigger sending Hello A per-interface Hello Timer (HT(I)) is used to trigger sending Hello
messages on each active interface. When PIM is enabled on an messages on each active interface. When PIM is enabled on an
interface or a router first starts, the Hello Timer of that interface interface or a router first starts, the Hello Timer of that interface
is set to a random value between 0 and Triggered_Hello_Delay. This is set to a random value between 0 and Triggered_Hello_Delay. This
prevents synchronization of Hello messages if multiple routers are prevents synchronization of Hello messages if multiple routers are
powered on simultaneously. After the initial randomized interval, powered on simultaneously. After the initial randomized interval,
Hello messages MUST be sent every Hello_Period seconds. The Hello Hello messages MUST be sent every Hello_Period seconds. The
Timer SHOULD NOT be reset except when it expires. Hello Timer SHOULD NOT be reset except when it expires.
Note that neighbors will not accept Join/Prune or Assert messages Note that neighbors will not accept Join/Prune or Assert messages
from a router unless they have first heard a Hello message from that from a router unless they have first heard a Hello message from that
router. Thus, if a router needs to send a Join/Prune or Assert router. Thus, if a router needs to send a Join/Prune or Assert
message on an interface on which it has not yet sent a Hello message message on an interface on which it has not yet sent a Hello message
with the currently configured IP address, then it MUST immediately with the currently configured IP address, then it MUST immediately
send the relevant Hello message without waiting for the Hello Timer send the relevant Hello message without waiting for the Hello Timer
to expire, followed by the Join/Prune or Assert message. to expire, followed by the Join/Prune or Assert message.
The DR_Priority Option allows a network administrator to give The DR Priority option allows a network administrator to give
preference to a particular router in the DR election process by preference to a particular router in the DR election process by
giving it a numerically larger DR Priority. The DR_Priority Option giving it a numerically larger DR Priority. The DR Priority option
SHOULD be included in every Hello message, even if no DR Priority is SHOULD be included in every Hello message, even if no DR Priority is
explicitly configured on that interface. This is necessary because explicitly configured on that interface. This is necessary because
priority-based DR election is only enabled when all neighbors on an priority-based DR election is only enabled when all neighbors on an
interface advertise that they are capable of using the DR_Priority interface advertise that they are capable of using the DR Priority
Option. The default priority is 1. option. The default priority is 1.
The Generation_Identifier (GenID) Option SHOULD be included in all The Generation Identifier (GenID) option SHOULD be included in all
Hello messages. The GenID option contains a randomly generated Hello messages. The GenID option contains a randomly generated
32-bit value that is regenerated each time PIM forwarding is started 32-bit value that is regenerated each time PIM forwarding is started
or restarted on the interface, including when the router itself or restarted on the interface, including when the router itself
restarts. When a Hello message with a new GenID is received from a restarts. When a Hello message with a new GenID is received from a
neighbor, any old Hello information about that neighbor SHOULD be neighbor, any old Hello information about that neighbor SHOULD be
discarded and superseded by the information from the new Hello discarded and superseded by the information from the new Hello
message. This may cause a new DR to be chosen on that interface. message. This may cause a new DR to be chosen on that interface.
The LAN Prune Delay Option SHOULD be included in all Hello messages The LAN Prune Delay option SHOULD be included in all Hello messages
sent on multi-access LANs. This option advertises a router's sent on multi-access LANs. This option advertises a router's
capability to use values other than the defaults for the capability to use values other than the defaults for the
Propagation_Delay and Override_Interval, which affect the setting of Propagation_Delay and Override_Interval, which affect the setting of
the Prune-Pending, Upstream Join, and Override Timers (defined in the Prune-Pending, Upstream Join, and Override Timers (defined in
Section 4.10). Section 4.10).
The Address List Option advertises all the secondary addresses The Address List option advertises all the secondary addresses
associated with the source interface of the router originating the associated with the source interface of the router originating the
message. The option MUST be included in all Hello messages if there message. The option MUST be included in all Hello messages if there
are secondary addresses associated with the source interface and MAY are secondary addresses associated with the source interface and MAY
be omitted if no secondary addresses exist. be omitted if no secondary addresses exist.
To allow new or rebooting routers to learn of PIM neighbors quickly, To allow new or rebooting routers to learn of PIM neighbors quickly,
when a Hello message is received from a new neighbor, or a Hello when a Hello message is received from a new neighbor, or a Hello
message with a new GenID is received from an existing neighbor, a new message with a new GenID is received from an existing neighbor, a new
Hello message SHOULD be sent on this interface after a randomized Hello message SHOULD be sent on this interface after a randomized
delay between 0 and Triggered_Hello_Delay. This triggered message delay between 0 and Triggered_Hello_Delay. This triggered message
skipping to change at page 31, line 29 skipping to change at page 31, line 15
to expire, followed by the Join/Prune or Assert message. If it does to expire, followed by the Join/Prune or Assert message. If it does
not do this, then the new neighbor will discard the Join/Prune or not do this, then the new neighbor will discard the Join/Prune or
Assert message. Assert message.
Before an interface goes down or changes primary IP address, a Hello Before an interface goes down or changes primary IP address, a Hello
message with a zero HoldTime SHOULD be sent immediately (with the old message with a zero HoldTime SHOULD be sent immediately (with the old
IP address if the IP address changed). This will cause PIM neighbors IP address if the IP address changed). This will cause PIM neighbors
to remove this neighbor (or its old IP address) immediately. After to remove this neighbor (or its old IP address) immediately. After
an interface has changed its IP address, it MUST send a Hello message an interface has changed its IP address, it MUST send a Hello message
with its new IP address. If an interface changes one of its with its new IP address. If an interface changes one of its
secondary IP addresses, a Hello message with an updated Address_List secondary IP addresses, a Hello message with an updated Address List
option and a non-zero HoldTime SHOULD be sent immediately. This will option and a non-zero HoldTime SHOULD be sent immediately. This will
cause PIM neighbors to update this neighbor's list of secondary cause PIM neighbors to update this neighbor's list of secondary
addresses immediately. addresses immediately.
4.3.2. DR Election 4.3.2. DR Election
When a PIM Hello message is received on interface I, the following When a PIM Hello message is received on interface I, the following
information about the sending neighbor is recorded: information about the sending neighbor is recorded:
neighbor.interface neighbor.interface
The interface on which the Hello message arrived. The interface on which the Hello message arrived.
neighbor.primary_ip_address neighbor.primary_ip_address
The IP address that the PIM neighbor used as the source The IP address that the PIM neighbor used as the source
address of the Hello message. address of the Hello message.
neighbor.genid neighbor.genid
The Generation ID of the PIM neighbor. The Generation ID of the PIM neighbor.
neighbor.dr_priority neighbor.dr_priority
The DR Priority field of the PIM neighbor, if it is present in The DR Priority field of the PIM neighbor, if it is present
the Hello message. in the Hello message.
neighbor.dr_priority_present neighbor.dr_priority_present
A flag indicating if the DR Priority field was present in the A flag indicating if the DR Priority field was present in
Hello message. the Hello message.
neighbor.timeout neighbor.timeout
A timer value to time out the neighbor state when it becomes A timer value to time out the neighbor state when it becomes
stale, also known as the Neighbor Liveness Timer. stale, also known as the Neighbor Liveness Timer.
The Neighbor Liveness Timer (NLT(N,I)) is reset to The Neighbor Liveness Timer (NLT(N,I)) is reset to
Hello_Holdtime (from the Hello Holdtime option) whenever a Hello_Holdtime (from the Hello Holdtime option) whenever a
Hello message is received containing a Holdtime option, or to Hello message is received containing a Holdtime option, or
Default_Hello_Holdtime if the Hello message does not contain to Default_Hello_Holdtime if the Hello message does not
the Holdtime option. contain the Holdtime option.
Neighbor state is deleted when the neighbor timeout expires. Neighbor state is deleted when the neighbor timeout expires.
The function for computing the DR on interface I is: The function for computing the DR on interface I is:
host host
DR(I) { DR(I) {
dr = me dr = me
for each neighbor on interface I { for each neighbor on interface I {
if ( dr_is_better( neighbor, dr, I ) == TRUE ) { if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
dr = neighbor dr = neighbor
} }
skipping to change at page 33, line 18 skipping to change at page 33, line 13
} }
The DR Priority is a 32-bit unsigned number, and the numerically The DR Priority is a 32-bit unsigned number, and the numerically
larger priority is always preferred. A router's idea of the current larger priority is always preferred. A router's idea of the current
DR on an interface can change when a PIM Hello message is received, DR on an interface can change when a PIM Hello message is received,
when a neighbor times out, or when a router's own DR Priority when a neighbor times out, or when a router's own DR Priority
changes. If the router becomes the DR or ceases to be the DR, this changes. If the router becomes the DR or ceases to be the DR, this
will normally cause the DR Register state machine to change state. will normally cause the DR Register state machine to change state.
Subsequent actions are determined by that state machine. Subsequent actions are determined by that state machine.
We note that some PIM implementations do not send Hello messages on We note that some PIM implementations do not send Hello messages
point-to-point interfaces and thus cannot perform DR election on on point-to-point interfaces and thus cannot perform DR election
such interfaces. This is non-compliant behavior. DR election MUST on such interfaces. This is non-compliant behavior. DR election
be performed on ALL active PIM-SM interfaces. MUST be performed on ALL active PIM-SM interfaces.
4.3.3. Reducing Prune Propagation Delay on LANs 4.3.3. Reducing Prune Propagation Delay on LANs
In addition to the information recorded for the DR Election, the In addition to the information recorded for the DR Election, the
following per neighbor information is obtained from the LAN Prune following per-neighbor information is obtained from the LAN Prune
Delay Hello option: Delay Hello option:
neighbor.lan_prune_delay_present neighbor.lan_prune_delay_present
A flag indicating if the LAN Prune Delay option was present in A flag indicating if the LAN Prune Delay option was present
the Hello message. in the Hello message.
neighbor.tracking_support neighbor.tracking_support
A flag storing the value of the T bit in the LAN Prune Delay A flag storing the value of the T bit in the LAN Prune Delay
option if it is present in the Hello message. This indicates option if it is present in the Hello message. This
the neighbor's capability to disable Join message suppression. indicates the neighbor's capability to disable Join message
suppression.
neighbor.propagation_delay neighbor.propagation_delay
The Propagation Delay field of the LAN Prune Delay option (if The Propagation Delay field of the LAN Prune Delay option
present) in the Hello message. (if present) in the Hello message.
neighbor.override_interval neighbor.override_interval
The Override_Interval field of the LAN Prune Delay option (if The Override_Interval field of the LAN Prune Delay option
present) in the Hello message. (if present) in the Hello message.
The additional state described above is deleted along with the DR The additional state described above is deleted along with the DR
neighbor state when the neighbor timeout expires. neighbor state when the neighbor timeout expires.
Just like the DR_Priority option, the information provided in the LAN Just like the DR Priority option, the information provided in the LAN
Prune Delay option is not used unless all neighbors on a link Prune Delay option is not used unless all neighbors on a link
advertise the option. The function below computes this state: advertise the option. The function below computes this state:
bool bool
lan_delay_enabled(I) { lan_delay_enabled(I) {
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.lan_prune_delay_present == false ) { if ( neighbor.lan_prune_delay_present == false ) {
return false return false
} }
} }
skipping to change at page 34, line 25 skipping to change at page 34, line 29
The Propagation Delay inserted by a router in the LAN Prune Delay The Propagation Delay inserted by a router in the LAN Prune Delay
option expresses the expected message propagation delay on the link option expresses the expected message propagation delay on the link
and SHOULD be configurable by the system administrator. It is used and SHOULD be configurable by the system administrator. It is used
by upstream routers to figure out how long they should wait for a by upstream routers to figure out how long they should wait for a
Join override message before pruning an interface. Join override message before pruning an interface.
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 their router. Such delays may cause received messages to be
processed later as well as triggered messages to be sent later than processed later as well as triggered messages to be sent later than
intended. Setting this Propagation Delay to too low a value may intended. Setting this Propagation Delay to too low a value may
result in temporary forwarding outages because a downstream router result in temporary forwarding outages because a downstream router
will not be able to override a neighbor's Prune message before the will not be able to override a neighbor's Prune message before the
upstream neighbor stops forwarding. upstream neighbor stops forwarding.
When all routers on a link are in a position to negotiate a When all routers on a link are in a position to negotiate a
Propagation Delay different from the default, the largest value from Propagation Delay different from the default, the largest value from
those advertised by each neighbor is chosen. The function for those advertised by each neighbor is chosen. The function for
computing the Effective Propagation Delay of interface I is: computing the Effective Propagation Delay of interface I is:
time_interval time_interval
skipping to change at page 34, line 50 skipping to change at page 35, line 6
delay = Propagation_Delay(I) delay = Propagation_Delay(I)
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.propagation_delay > delay ) { if ( neighbor.propagation_delay > delay ) {
delay = neighbor.propagation_delay delay = neighbor.propagation_delay
} }
} }
return delay return delay
} }
To avoid synchronization of override messages when multiple To avoid synchronization of override messages when multiple
downstream routers share a multi-access link, sending of such downstream routers share a multi-access link, the sending of such
messages is delayed by a small random amount of time. The period of messages is delayed by a small random amount of time. The period of
randomization should represent the size of the PIM router population randomization should represent the size of the PIM router population
on the link. Each router expresses its view of the amount of on the link. Each router expresses its view of the amount of
randomization necessary in the Override Interval field of the LAN randomization necessary in the Override Interval field of the LAN
Prune Delay option. Prune Delay option.
When all routers on a link are in a position to negotiate an Override When all routers on a link are in a position to negotiate an Override
Interval different from the default, the largest value from those Interval different from the default, the largest value from those
advertised by each neighbor is chosen. The function for computing advertised by each neighbor is chosen. The function for computing
the Effective Override Interval of interface I is: the Effective Override Interval of interface I is:
skipping to change at page 35, line 28 skipping to change at page 36, line 6
delay = Override_Interval(I) delay = Override_Interval(I)
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.override_interval > delay ) { if ( neighbor.override_interval > delay ) {
delay = neighbor.override_interval delay = neighbor.override_interval
} }
} }
return delay return delay
} }
Although the mechanisms are not specified in this document, it is Although the mechanisms are not specified in this document, it is
possible for upstream routers to explicitly track the join membership possible for upstream routers to explicitly track the join
of individual downstream routers if Join suppression is disabled. A membership of individual downstream routers if Join suppression is
router can advertise its willingness to disable Join suppression by disabled. A router can advertise its willingness to disable Join
using the T bit in the LAN Prune Delay Hello option. Unless all PIM suppression by using the T bit in the LAN Prune Delay Hello option.
routers on a link negotiate this capability, explicit tracking and Unless all PIM routers on a link negotiate this capability, explicit
the disabling of the Join suppression mechanism are not possible. tracking and the disabling of the Join suppression mechanism are not
The function for computing the state of Suppression on interface I possible. The function for computing the state of Suppression on
is: interface I is:
bool bool
Suppression_Enabled(I) { Suppression_Enabled(I) {
if ( lan_delay_enabled(I) == false ) { if ( lan_delay_enabled(I) == false ) {
return true return true
} }
for each neighbor on interface I { for each neighbor on interface I {
if ( neighbor.tracking_support == false ) { if ( neighbor.tracking_support == false ) {
return true return true
} }
} }
return false return false
} }
Note that the setting of Suppression_Enabled(I) affects the value of Note that the setting of Suppression_Enabled(I) affects the value of
t_suppressed (see Section 4.10). t_suppressed (see Section 4.11).
4.3.4. Maintaining Secondary Address Lists 4.3.4. Maintaining Secondary Address Lists
Communication of a router's interface secondary addresses to its PIM Communication of a router's interface secondary addresses to its PIM
neighbors is necessary to provide the neighbors with a mechanism for neighbors is necessary to provide the neighbors with a mechanism for
mapping next_hop information obtained through their MRIB to a primary mapping next_hop information obtained through their MRIB to a primary
address that can be used as a destination for Join/Prune messages. address that can be used as a destination for Join/Prune messages.
The mapping is performed through the NBR macro. The primary address The mapping is performed through the NBR macro. The primary address
of a PIM neighbor is obtained from the source IP address used in its of a PIM neighbor is obtained from the source IP address used in its
PIM Hello messages. Secondary addresses are carried within the Hello PIM Hello messages. Secondary addresses are carried within the Hello
message in an Address List Hello option. The primary address of the message in an Address List Hello option. The primary address of the
source interface of the router MUST NOT be listed within the Address source interface of the router MUST NOT be listed within the Address
List Hello option. List Hello option.
In addition to the information recorded for the DR Election, the In addition to the information recorded for the DR Election, the
following per neighbor information is obtained from the Address List following per-neighbor information is obtained from the Address List
Hello option: Hello option:
neighbor.secondary_address_list neighbor.secondary_address_list
The list of secondary addresses used by the PIM neighbor on The list of secondary addresses used by the PIM neighbor on
the interface through which the Hello message was transmitted. the interface through which the Hello message was
transmitted.
When processing a received PIM Hello message containing an Address When processing a received PIM Hello message containing an Address
List Hello option, the list of secondary addresses in the message List Hello option, the list of secondary addresses in the message
completely replaces any previously associated secondary addresses for completely replaces any previously associated secondary addresses for
that neighbor. If a received PIM Hello message does not contain an that neighbor. If a received PIM Hello message does not contain an
Address List Hello option, then all secondary addresses associated Address List Hello option, then all secondary addresses associated
with the neighbor MUST be deleted. If a received PIM Hello message with the neighbor MUST be deleted. If a received PIM Hello message
contains an Address List Hello option that includes the primary contains an Address List Hello option that includes the primary
address of the sending router in the list of secondary addresses address of the sending router in the list of secondary addresses
(although this is not expected), then the addresses listed in the (although this is not expected), then the addresses listed in the
skipping to change at page 37, line 13 skipping to change at page 37, line 39
destination addresses of the packet header. destination addresses of the packet header.
4.4. PIM Register Messages 4.4. PIM Register Messages
The Designated Router (DR) on a LAN or point-to-point link The Designated Router (DR) on a LAN or point-to-point link
encapsulates multicast packets from local sources to the RP for the encapsulates multicast packets from local sources to the RP for the
relevant group unless it recently received a Register-Stop message relevant group unless it recently received a Register-Stop message
for that (S,G) or (*,G) from the RP. When the DR receives a for that (S,G) or (*,G) from the RP. When the DR receives a
Register-Stop message from the RP, it starts a Register-Stop Timer to Register-Stop message from the RP, it starts a Register-Stop Timer to
maintain this state. Just before the Register-Stop Timer expires, maintain this state. Just before the Register-Stop Timer expires,
the DR sends a Null-Register Message to the RP to allow the RP to the DR sends a Null-Register message to the RP to allow the RP to
refresh the Register-Stop information at the DR. If the Register- refresh the Register-Stop information at the DR. If the
Stop Timer actually expires, the DR will resume encapsulating packets Register-Stop Timer actually expires, the DR will resume
from the source to the RP. encapsulating packets from the source to the RP.
4.4.1. Sending Register Messages from the DR 4.4.1. Sending Register Messages from the DR
Every PIM-SM router has the capability to be a DR. The state machine Every PIM-SM router has the capability to be a DR. The state machine
below is used to implement Register functionality. For the purposes below is used to implement Register functionality. For the purposes
of specification, we represent the mechanism to encapsulate packets of specification, we represent the mechanism to encapsulate packets
to the RP as a Register-Tunnel interface, which is added to or to the RP as a Register-Tunnel interface, which is added to or
removed from the (S,G) olist. The tunnel interface then takes part removed from the (S,G) olist. The tunnel interface then takes part
in the normal packet forwarding rules as specified in Section 4.2. in the normal packet forwarding rules as specified in Section 4.2.
If register state is maintained, it is maintained only for directly If register state is maintained, it is maintained only for directly
connected sources and is per-(S,G). There are four states in the connected sources and is per-(S,G). There are four states in the
DR's per-(S,G) Register state machine: DR's per-(S,G) Register state machine:
Join (J) Join (J)
The register tunnel is "joined" (the join is actually implicit, The register tunnel is "joined" (the join is actually
but the DR acts as if the RP has joined the DR on the tunnel implicit, but the DR acts as if the RP has joined the DR on
interface). the tunnel interface).
Prune (P) Prune (P)
The register tunnel is "pruned" (this occurs when a Register- The register tunnel is "pruned" (this occurs when a
Stop is received). Register-Stop is received).
Join-Pending (JP) Join-Pending (JP)
The register tunnel is pruned but the DR is contemplating adding The register tunnel is pruned but the DR is contemplating
it back. adding it back.
NoInfo (NI) NoInfo (NI)
No information. This is the initial state, and the state when No information. This is the initial state, and the state
the router is not the DR. when the router is not the DR.
In addition, a Register-Stop Timer (RST) is kept if the state machine In addition, a Register-Stop Timer (RST) is kept if the state machine
is not in the NoInfo state. is not in the NoInfo state.
Figure 1: Per-(S,G) register state machine at a DR in tabular form Figure 1: Per-(S,G) Register State Machine at a DR
+----------++----------------------------------------------------------+ +----------++----------------------------------------------------------+
| || Event | | || Event |
| ++----------+-----------+-----------+-----------+-----------+ | ++----------+-----------+-----------+-----------+-----------+
|Prev State||Register- | Could | Could | Register- | RP changed| |Prev State||Register- | Could | Could | Register- | RP changed|
| ||Stop Timer| Register | Register | Stop | | | ||Stop Timer| Register | Register | Stop | |
| ||expires | ->True | ->False | received | | | ||expires | ->True | ->False | received | |
+----------++----------+-----------+-----------+-----------+-----------+ +----------++----------+-----------+-----------+-----------+-----------+
|NoInfo ||- | -> J state| - | - | - | |NoInfo ||- | -> J state| - | - | - |
|(NI) || | add reg | | | | |(NI) || | add reg | | | |
skipping to change at page 38, line 52 skipping to change at page 40, line 12
| ||Register | | | | | | ||Register | | | | |
+----------++----------+-----------+-----------+-----------+-----------+ +----------++----------+-----------+-----------+-----------+-----------+
Notes: Notes:
(*) The Register-Stop Timer is set to a random value chosen (*) The Register-Stop Timer is set to a random value chosen
uniformly from the interval ( 0.5 * Register_Suppression_Time, uniformly from the interval ( 0.5 * Register_Suppression_Time,
1.5 * Register_Suppression_Time) minus Register_Probe_Time. 1.5 * Register_Suppression_Time) minus Register_Probe_Time.
Subtracting off Register_Probe_Time is a bit unnecessary because Subtracting off Register_Probe_Time is a bit unnecessary because
it is really small compared to Register_Suppression_Time, but it is really small compared to Register_Suppression_Time, but
this was in the old spec and is kept for compatibility. this was in the old specification and is kept for compatibility.
(**) The Register-Stop Timer is set to Register_Probe_Time. (**) The Register-Stop Timer is set to Register_Probe_Time.
The following three actions are defined: The following three actions are defined:
Add Register Tunnel Add Register Tunnel
A Register-Tunnel virtual interface, VI, is created (if it doesn't A Register-Tunnel virtual interface, VI, is created (if it doesn't
already exist) with its encapsulation target being RP(G). already exist) with its encapsulation target being RP(G).
DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel
skipping to change at page 39, line 34 skipping to change at page 40, line 43
deleted. deleted.
Update Register Tunnel Update Register Tunnel
This action occurs when RP(G) changes. This action occurs when RP(G) changes.
VI_old is the Register-Tunnel virtual interface with encapsulation VI_old is the Register-Tunnel virtual interface with encapsulation
target old_RP(G). A Register-Tunnel virtual interface, VI_new, is target old_RP(G). A Register-Tunnel virtual interface, VI_new, is
created (if it doesn't already exist) with its encapsulation created (if it doesn't already exist) with its encapsulation
target being new_RP(G). DownstreamJPState(S,G,VI_old) is set to target being new_RP(G). DownstreamJPState(S,G,VI_old) is set to
NoInfo state and DownstreamJPState(S,G,VI_new) is set to Join NoInfo state, and DownstreamJPState(S,G,VI_new) is set to Join
state. If DownstreamJPState(S,G,VI_old) is NoInfo for all (S,G), state. If DownstreamJPState(S,G,VI_old) is NoInfo for all (S,G),
then VI_old can be deleted. then VI_old can be deleted.
Note that we cannot simply change the encapsulation target of Note that we cannot simply change the encapsulation target of
VI_old because not all groups using that encapsulation tunnel will VI_old because not all groups using that encapsulation tunnel will
have moved to the same new RP. have moved to the same new RP.
CouldRegister(S,G) CouldRegister(S,G)
The macro "CouldRegister" in the state machine is defined as: The macro "CouldRegister" in the state machine is defined as:
bool CouldRegister(S,G) { bool CouldRegister(S,G) {
return ( I_am_DR( RPF_interface(S) ) AND return ( I_am_DR( RPF_interface(S) ) AND
KeepaliveTimer(S,G) is running AND KeepaliveTimer(S,G) is running AND
DirectlyConnected(S) == TRUE ) DirectlyConnected(S) == TRUE )
} }
Note that on reception of a packet at the DR from a directly Note that on reception of a packet at the DR from a directly
connected source, KeepaliveTimer(S,G) needs to be set by the connected source, KeepaliveTimer(S,G) needs to be set by the
packet forwarding rules before computing CouldRegister(S,G) in the packet forwarding rules before computing CouldRegister(S,G) in the
register state machine, or the first packet from a source won't be register state machine, or the first packet from a source won't be
registered. registered.
Encapsulating Data Packets in the Register Tunnel Encapsulating Data Packets in the Register Tunnel
Conceptually, the Register Tunnel is an interface with a smaller Conceptually, the Register Tunnel is an interface with a smaller
MTU than the underlying IP interface towards the RP. IP MTU than the underlying IP interface towards the RP. IP
fragmentation on packets forwarded on the Register Tunnel is fragmentation on packets forwarded on the Register Tunnel is
performed based upon this smaller MTU. The encapsulating DR may performed based upon this smaller MTU. The encapsulating DR may
perform Path MTU Discovery to the RP to determine the effective perform Path MTU Discovery to the RP to determine the effective
MTU of the tunnel. Fragmentation for the smaller MTU should take MTU of the tunnel. Fragmentation for the smaller MTU should take
both the outer IP header and the PIM register header overhead into both the outer IP header and the PIM register header overhead into
account. If a multicast packet is fragmented on the way into the account. If a multicast packet is fragmented on the way into the
Register Tunnel, each fragment is encapsulated individually so it Register Tunnel, each fragment is encapsulated individually so it
contains IP, PIM, and inner IP headers. contains IP, PIM, and inner IP headers.
In IPv6, the DR MUST perform Path MTU discovery, and an ICMP In IPv6, the DR MUST perform Path MTU Discovery, and an ICMP
Packet Too Big message MUST be sent by the encapsulating DR if it Packet Too Big message MUST be sent by the encapsulating DR if it
receives a packet that will not fit in the effective MTU of the receives a packet that will not fit in the effective MTU of the
tunnel. If the MTU between the DR and the RP results in the tunnel. If the MTU between the DR and the RP results in the
effective tunnel MTU being smaller than 1280 (the IPv6 minimum effective tunnel MTU being smaller than 1280 (the IPv6 minimum
MTU), the DR MUST send Fragmentation Required messages with an MTU MTU), the DR MUST send Fragmentation Required messages with an MTU
value of 1280 and MUST fragment its PIM register messages as value of 1280 and MUST fragment its PIM register messages as
required, using an IPv6 fragmentation header between the outer required, using an IPv6 fragmentation header between the outer
IPv6 header and the PIM Register header. IPv6 header and the PIM Register header.
The TTL of a forwarded data packet is decremented before it is The TTL of a forwarded data packet is decremented before it is
encapsulated in the Register Tunnel. The encapsulating packet encapsulated in the Register Tunnel. The encapsulating packet
uses the normal TTL that the router would use for any locally- uses the normal TTL that the router would use for any locally
generated IP packet. generated IP packet.
The IP ECN bits should be copied from the original packet to the The IP Explicit Congestion Notification (ECN) bits should be
IP header of the encapsulating packet. They SHOULD NOT be set copied from the original packet to the IP header of the
independently by the encapsulating router. encapsulating packet. They SHOULD NOT be set independently by the
encapsulating router.
The Diffserv Code Point (DSCP) should be copied from the original The Diffserv Code Point (DSCP) should be copied from the original
packet to the IP header of the encapsulating packet. It MAY be packet to the IP header of the encapsulating packet. It MAY be
set independently by the encapsulating router, based upon static set independently by the encapsulating router, based upon static
configuration or traffic classification. See [12] for more configuration or traffic classification. See [12] for more
discussion on setting the DSCP on tunnels. discussion on setting the DSCP on tunnels.
Handling Register-Stop(*,G) Messages at the DR Handling Register-Stop(*,G) Messages at the DR
An old RP might send a Register-Stop message with the source An old RP might send a Register-Stop message with the source
skipping to change at page 41, line 26 skipping to change at page 43, line 13
that become active after the Register-Stop(*,G) was received. that become active after the Register-Stop(*,G) was received.
4.4.2. Receiving Register Messages at the RP 4.4.2. Receiving Register Messages at the RP
When an RP receives a Register message, the course of action is When an RP receives a Register message, the course of action is
decided according to the following pseudocode: decided according to the following pseudocode:
packet_arrives_on_rp_tunnel( pkt ) { packet_arrives_on_rp_tunnel( pkt ) {
if( outer.dst is not one of my addresses ) { if( outer.dst is not one of my addresses ) {
drop the packet silently. drop the packet silently.
# Note: this may be a spoofing attempt # Note: This may be a spoofing attempt.
} }
if( I_am_RP(G) AND outer.dst == RP(G) ) { if( I_am_RP(G) AND outer.dst == RP(G) ) {
sentRegisterStop = FALSE; sentRegisterStop = FALSE;
if ( SPTbit(S,G) OR if ( SPTbit(S,G) OR
( SwitchToSptDesired(S,G) AND ( SwitchToSptDesired(S,G) AND
( inherited_olist(S,G) == NULL ))) { ( inherited_olist(S,G) == NULL ))) {
send Register-Stop(S,G) to outer.src send Register-Stop(S,G) to outer.src
sentRegisterStop = TRUE; sentRegisterStop = TRUE;
} }
if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) { if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
skipping to change at page 42, line 4 skipping to change at page 43, line 39
} }
if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) { if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
decapsulate and forward the inner packet to decapsulate and forward the inner packet to
inherited_olist(S,G,rpt) # Note (+) inherited_olist(S,G,rpt) # Note (+)
} }
} else { } else {
send Register-Stop(S,G) to outer.src send Register-Stop(S,G) to outer.src
# Note (*) # Note (*)
} }
} }
outer.dst is the IP destination address of the encapsulating header. outer.dst is the IP destination address of the encapsulating header.
outer.src is the IP source address of the encapsulating header, i.e., outer.src is the IP source address of the encapsulating header, i.e.,
the DR's address. the DR's address.
I_am_RP(G) is true if the group-to-RP mapping indicates that this I_am_RP(G) is true if the group-to-RP mapping indicates that this
router is the RP for the group. router is the RP for the group.
Note (*): This may block traffic from S for Register_Suppression_Time Note (*): This may block traffic from S for Register_Suppression_Time
if the DR learned about a new group-to-RP mapping before the RP if the DR learned about a new group-to-RP mapping before
did. However, this doesn't matter unless we figure out some way the RP did. However, this doesn't matter unless we figure
for the RP also to accept (*,G) joins when it doesn't yet realize out some way for the RP also to accept (*,G) joins when it
that it is about to become the RP for G. This will all get sorted doesn't yet realize that it is about to become the RP
out once the RP learns the new group-to-rp mapping. We decided to for G. This will all get sorted out once the RP learns the
do nothing about this and just accept the fact that PIM may suffer new group-to-RP mapping. We decided to do nothing about
interrupted (*,G) connectivity following an RP change. this and just accept the fact that PIM may suffer
interrupted (*,G) connectivity following an RP change.
Note (+): Implementations SHOULD NOT make this a special case, but Note (+): Implementations SHOULD NOT make this a special case, but
SHOULD arrange that this path rejoin the normal packet forwarding SHOULD arrange that this path rejoin the normal packet
path. All of the appropriate actions from the "On receipt of data forwarding path. All of the appropriate actions from the
from S to G on interface iif" pseudocode in Section 4.2 should be "On receipt of data from S to G on interface iif"
performed. pseudocode in Section 4.2 should be performed.
KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the
proper tunnel interface and the RP desires to switch to the SPT or proper tunnel interface and the RP desires to switch to the SPT or
the SPTbit is already set. This may cause the upstream (S,G) state the SPTbit is already set. This may cause the upstream (S,G) state
machine to trigger a join if the inherited_olist(S,G) is not NULL. machine to trigger a join if the inherited_olist(S,G) is not NULL.
An RP should preserve (S,G) state that was created in response to a An RP should preserve (S,G) state that was created in response to a
Register message for at least ( 3 * Register_Suppression_Time ); Register message for at least ( 3 * Register_Suppression_Time );
otherwise, the RP may stop joining (S,G) before the DR for S has otherwise, the RP may stop joining (S,G) before the DR for S has
restarted sending registers. Traffic would then be interrupted until restarted sending registers. Traffic would then be interrupted until
skipping to change at page 42, line 47 skipping to change at page 44, line 35
Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 * Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
Register_Suppression_Time + Register_Probe_Time ). Register_Suppression_Time + Register_Probe_Time ).
When forwarding a packet from the Register Tunnel, the TTL of the When forwarding a packet from the Register Tunnel, the TTL of the
original data packet is decremented after it is decapsulated. original data packet is decremented after it is decapsulated.
The IP ECN bits should be copied from the IP header of the Register The IP ECN bits should be copied from the IP header of the Register
packet to the decapsulated packet. packet to the decapsulated packet.
The Diffserv Code Point (DSCP) should be copied from the IP header of The DSCP should be copied from the IP header of the Register packet
the Register packet to the decapsulated packet. The RP MAY retain to the decapsulated packet. The RP MAY retain the DSCP of the inner
the DSCP of the inner packet or re-classify the packet and apply a packet or re-classify the packet and apply a different DSCP.
different DSCP. Scenarios where each of these might be useful are Scenarios where each of these might be useful are discussed in [12].
discussed in [12].
4.5. PIM Join/Prune Messages 4.5. PIM Join/Prune Messages
A PIM Join/Prune message consists of a list of groups and a list of A PIM Join/Prune message consists of a list of groups and a list of
Joined and Pruned sources for each group. When processing a received Joined and Pruned sources for each group. When processing a received
Join/Prune message, each Joined or Pruned source for a Group is Join/Prune message, each Joined or Pruned source for a group is
effectively considered individually, and applies to one or more of effectively considered individually, and applies to one or more of
the following state machines. When considering a Join/Prune message the following state machines. When considering a Join/Prune message
whose Upstream Neighbor Address field addresses this router, (*,G) whose Upstream Neighbor Address field addresses this router, (*,G)
Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream
state machines, while (S,G), and (S,G,rpt) Joins and Prunes can only state machines, while (S,G), and (S,G,rpt) Joins and Prunes can only
affect their respective downstream state machines. When considering affect their respective downstream state machines. When considering
a Join/Prune message whose Upstream Neighbor Address field addresses a Join/Prune message whose Upstream Neighbor Address field addresses
another router, most Join or Prune messages could affect each another router, most Join or Prune messages could affect each
upstream state machine. upstream state machine.
skipping to change at page 43, line 50 skipping to change at page 46, line 6
the RP is). If the RP in the message does not match RP(G), the the RP is). If the RP in the message does not match RP(G), the
Join(*,G) should be silently dropped. (Note that other source list Join(*,G) should be silently dropped. (Note that other source list
entries, such as (S,G,rpt) or (S,G), in the same Group-Specific Set entries, such as (S,G,rpt) or (S,G), in the same Group-Specific Set
should still be processed.) If a router has no RP information (e.g., should still be processed.) If a router has no RP information (e.g.,
has not recently received a BSR message), then it may choose to has not recently received a BSR message), then it may choose to
accept Join(*,G) and treat the RP in the message as RP(G). Received accept Join(*,G) and treat the RP in the message as RP(G). Received
Prune(*,G) messages are processed even if the RP in the message does Prune(*,G) messages are processed even if the RP in the message does
not match RP(G). not match RP(G).
The per-interface state machine for receiving (*,G) Join/Prune The per-interface state machine for receiving (*,G) Join/Prune
Messages is given below. There are three states: messages is given below. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (*,G) Join state and no timers running. The interface has no (*,G) Join state and no timers running.
Join (J) Join (J)
The interface has (*,G) Join state, which will cause the The interface has (*,G) Join state, which will cause the
router to forward packets destined for G from this interface router to forward packets destined for G from this interface
except if there is also (S,G,rpt) prune information (see except if there is also (S,G,rpt) prune information (see
Section 4.5.3) or the router lost an assert on this interface. Section 4.5.3) or the router lost an assert on this
interface.
Prune-Pending (PP) Prune-Pending (PP)
The router has received a Prune(*,G) on this interface from a The router has received a Prune(*,G) on this interface from
downstream neighbor and is waiting to see whether the prune a downstream neighbor and is waiting to see whether the
will be overridden by another downstream router. For prune will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions
like the Join state. exactly like the Join state.
In addition, the state machine uses two timers: In addition, the state machine uses two timers:
Expiry Timer (ET) Expiry Timer (ET)
This timer is restarted when a valid Join(*,G) is received. This timer is restarted when a valid Join(*,G) is received.
Expiry of the Expiry Timer causes the interface state to Expiry of the Expiry Timer causes the interface state to
revert to NoInfo for this group. revert to NoInfo for this group.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(*,G) is received. Expiry This timer is set when a valid Prune(*,G) is received.
of the Prune-Pending Timer causes the interface state to Expiry of the Prune-Pending Timer causes the interface state
revert to NoInfo for this group. to revert to NoInfo for this group.
Figure 2: Downstream per-interface (*,G) state machine in tabular form Figure 2: Downstream Per-Interface (*,G) State Machine
+------------++--------------------------------------------------------+ +------------++--------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+-------------+-------------+ | ++-------------+--------------+-------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer| |Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(*,G) | Prune(*,G) | Pending | Expires | | ||Join(*,G) | Prune(*,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
+------------++-------------+--------------+-------------+-------------+ +------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
skipping to change at page 46, line 12 skipping to change at page 48, line 9
address should be the same as the source address it chose for the address should be the same as the source address it chose for the
Hello message it sent over that interface. However, on point-to- Hello message it sent over that interface. However, on point-to-
point links it is RECOMMENDED that for backwards compatibility PIM point links it is RECOMMENDED that for backwards compatibility PIM
Join/Prune messages with an upstream neighbor address field of all Join/Prune messages with an upstream neighbor address field of all
zeros also be accepted. zeros also be accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I
to the Join state. The Expiry Timer (ET) is started and set transitions to the Join state. The Expiry Timer (ET) is
to the HoldTime from the triggering Join/Prune message. started and set to the HoldTime from the triggering
Join/Prune message.
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join state, the following events may trigger a transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (*,G) downstream state machine on interface I remains in The (*,G) downstream state machine on interface I remains in
Join state, and the Expiry Timer (ET) is restarted, set to Join state, and the Expiry Timer (ET) is restarted. The ET
maximum of its current value and the HoldTime from the is set to the maximum of its current value and the HoldTime
triggering Join/Prune message. from the triggering Join/Prune message.
Receive Prune(*,G) Receive Prune(*,G)
A Prune(*,G) is received on interface I with its Upstream A Prune(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I
to the Prune-Pending state. The Prune-Pending Timer is transitions to the Prune-Pending state. The
started. It is set to the J/P_Override_Interval(I) if the Prune-Pending Timer is started. It is set to the
router has more than one neighbor on that interface; J/P_Override_Interval(I) if the router has more than one
otherwise, it is set to zero, causing it to expire neighbor on that interface; otherwise, it is set to zero,
immediately. causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,G) downstream state machine on The Expiry Timer for the (*,G) downstream state machine on
interface I expires. interface I expires.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I
to the NoInfo state. transitions to the NoInfo state.
Transitions from Prune-Pending State Transitions from Prune-Pending State
When in Prune-Pending state, the following events may trigger a When in Prune-Pending state, the following events may trigger a
transition: transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I
to the Join state. The Prune-Pending Timer is canceled transitions to the Join state. The Prune-Pending Timer is
(without triggering an expiry event). The Expiry Timer is canceled (without triggering an expiry event). The
restarted, set to maximum of its current value and the Expiry Timer (ET) is restarted and is then set to the
HoldTime from the triggering Join/Prune message. maximum of its current value and the HoldTime from the
triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (*,G) downstream state machine on The Expiry Timer for the (*,G) downstream state machine on
interface I expires. interface I expires.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I
to the NoInfo state. transitions to the NoInfo state.
Prune-Pending Timer Expires Prune-Pending Timer Expires
The Prune-Pending Timer for the (*,G) downstream state machine The Prune-Pending Timer for the (*,G) downstream state
on interface I expires. machine on interface I expires.
The (*,G) downstream state machine on interface I transitions The (*,G) downstream state machine on interface I
to the NoInfo state. A PruneEcho(*,G) is sent onto the subnet transitions to the NoInfo state. A PruneEcho(*,G) is sent
connected to interface I. onto the subnet connected to interface I.
The action "Send PruneEcho(*,G)" is triggered when the router The action "Send PruneEcho(*,G)" is triggered when the
stops forwarding on an interface as a result of a prune. A router stops forwarding on an interface as a result of a
PruneEcho(*,G) is simply a Prune(*,G) message sent by the prune. A PruneEcho(*,G) is simply a Prune(*,G) message sent
upstream router on a LAN with its own address in the Upstream by the upstream router on a LAN with its own address in the
Neighbor Address field. Its purpose is to add additional Upstream Neighbor Address field. Its purpose is to add
reliability so that if a Prune that should have been additional reliability so that if a Prune that should have
overridden by another router is lost locally on the LAN, then been overridden by another router is lost locally on the
the PruneEcho may be received and cause the override to LAN, then the PruneEcho may be received and cause the
happen. A PruneEcho(*,G) need not be sent on an interface override to happen. A PruneEcho(*,G) need not be sent on an
that contains only a single PIM neighbor during the time this interface that contains only a single PIM neighbor during
state machine was in Prune-Pending state. the time this state machine was in Prune-Pending state.
4.5.2. Receiving (S,G) Join/Prune Messages 4.5.2. Receiving (S,G) Join/Prune Messages
The per-interface state machine for receiving (S,G) Join/Prune The per-interface state machine for receiving (S,G) Join/Prune
messages is given below and is almost identical to that for (*,G) messages is given below and is almost identical to that for (*,G)
messages. There are three states: messages. There are three states:
NoInfo (NI) NoInfo (NI)
The interface has no (S,G) Join state and no (S,G) timers The interface has no (S,G) Join state and no (S,G) timers
running. running.
Join (J) Join (J)
The interface has (S,G) Join state, which will cause the The interface has (S,G) Join state, which will cause the
router to forward packets from S destined for G from this router to forward packets from S destined for G from this
interface if the (S,G) state is active (the SPTbit is set) interface if the (S,G) state is active (the SPTbit is set)
except if the router lost an assert on this interface. except if the router lost an assert on this interface.
Prune-Pending (PP) Prune-Pending (PP)
The router has received a Prune(S,G) on this interface from a The router has received a Prune(S,G) on this interface from
downstream neighbor and is waiting to see whether the prune a downstream neighbor and is waiting to see whether the
will be overridden by another downstream router. For prune will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions
like the Join state. exactly like the Join state.
In addition, there are two timers: In addition, there are two timers:
Expiry Timer (ET) Expiry Timer (ET)
This timer is set when a valid Join(S,G) is received. Expiry This timer is set when a valid Join(S,G) is received.
of the Expiry Timer causes this state machine to revert to Expiry of the Expiry Timer causes this state machine to
NoInfo state. revert to NoInfo state.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(S,G) is received. Expiry This timer is set when a valid Prune(S,G) is received.
of the Prune-Pending Timer causes this state machine to revert Expiry of the Prune-Pending Timer causes this state machine
to NoInfo state. to revert to NoInfo state.
Figure 3: Downstream per-interface (S,G) state machine in tabular form Figure 3: Downstream Per-Interface (S,G) State Machine
+------------++--------------------------------------------------------+ +------------++--------------------------------------------------------+
| || Event | | || Event |
| ++-------------+--------------+-------------+-------------+ | ++-------------+--------------+-------------+-------------+
|Prev State ||Receive | Receive | Prune- | Expiry Timer| |Prev State ||Receive | Receive | Prune- | Expiry Timer|
| ||Join(S,G) | Prune(S,G) | Pending | Expires | | ||Join(S,G) | Prune(S,G) | Pending | Expires |
| || | | Timer | | | || | | Timer | |
| || | | Expires | | | || | | Expires | |
+------------++-------------+--------------+-------------+-------------+ +------------++-------------+--------------+-------------+-------------+
| ||-> J state | -> NI state | - | - | | ||-> J state | -> NI state | - | - |
skipping to change at page 49, line 47 skipping to change at page 52, line 9
address SHOULD be the same as the source address it chose for the address SHOULD be the same as the source address it chose for the
Hello message it sent over that interface. However, on point-to- Hello message it sent over that interface. However, on point-to-
point links it is RECOMMENDED that for backwards compatibility PIM point links it is RECOMMENDED that for backwards compatibility PIM
Join/Prune messages with an upstream neighbor address field of all Join/Prune messages with an upstream neighbor address field of all
zeros also be accepted. zeros also be accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following event may trigger a transition: When in NoInfo state, the following event may trigger a transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its Upstream A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I
to the Join state. The Expiry Timer (ET) is started and set transitions to the Join state. The Expiry Timer (ET) is
to the HoldTime from the triggering Join/Prune message. started and set to the HoldTime from the triggering
Join/Prune message.
Transitions from Join State Transitions from Join State
When in Join state, the following events may trigger a transition: When in Join 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 its Upstream A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G) downstream state machine on interface I remains in The (S,G) downstream state machine on interface I remains in
Join state, and the Expiry Timer (ET) is restarted, set to Join state. The Expiry Timer (ET) is restarted and is then
maximum of its current value and the HoldTime from the set to the maximum of its current value and the HoldTime
triggering Join/Prune message. from the triggering Join/Prune message.
Receive Prune(S,G) Receive Prune(S,G)
A Prune(S,G) is received on interface I with its Upstream A Prune(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I
to the Prune-Pending state. The Prune-Pending Timer is transitions to the Prune-Pending state. The
started. It is set to the J/P_Override_Interval(I) if the Prune-Pending Timer is started. It is set to the
router has more than one neighbor on that interface; J/P_Override_Interval(I) if the router has more than one
otherwise, it is set to zero, causing it to expire neighbor on that interface; otherwise, it is set to zero,
immediately. causing it to expire immediately.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G) downstream state machine on The Expiry Timer for the (S,G) downstream state machine on
interface I expires. interface I expires.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I
to the NoInfo state. transitions to the NoInfo state.
Transitions from Prune-Pending State Transitions from Prune-Pending State
When in Prune-Pending state, the following events may trigger a When in Prune-Pending state, the following events may trigger a
transition: transition:
Receive Join(S,G) Receive Join(S,G)
A Join(S,G) is received on interface I with its Upstream A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I
to the Join state. The Prune-Pending Timer is canceled transitions to the Join state. The Prune-Pending Timer is
(without triggering an expiry event). The Expiry Timer is canceled (without triggering an expiry event). The
restarted, set to maximum of its current value and the Expiry Timer (ET) is restarted and is then set to the
HoldTime from the triggering Join/Prune message. maximum of its current value and the HoldTime from the
triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G) downstream state machine on The Expiry Timer for the (S,G) downstream state machine on
interface I expires. interface I expires.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I
to the NoInfo state. transitions to the NoInfo state.
Prune-Pending Timer Expires Prune-Pending Timer Expires
The Prune-Pending Timer for the (S,G) downstream state machine The Prune-Pending Timer for the (S,G) downstream state
on interface I expires. machine on interface I expires.
The (S,G) downstream state machine on interface I transitions The (S,G) downstream state machine on interface I
to the NoInfo state. A PruneEcho(S,G) is sent onto the subnet transitions to the NoInfo state. A PruneEcho(S,G) is sent
connected to interface I. onto the subnet connected to interface I.
The action "Send PruneEcho(S,G)" is triggered when the router The action "Send PruneEcho(S,G)" is triggered when the
stops forwarding on an interface as a result of a prune. A router stops forwarding on an interface as a result of a
PruneEcho(S,G) is simply a Prune(S,G) message sent by the prune. A PruneEcho(S,G) is simply a Prune(S,G) message sent
upstream router on a LAN with its own address in the Upstream by the upstream router on a LAN with its own address in the
Neighbor Address field. Its purpose is to add additional Upstream Neighbor Address field. Its purpose is to add
reliability so that if a Prune that should have been additional reliability so that if a Prune that should have
overridden by another router is lost locally on the LAN, then been overridden by another router is lost locally on the
the PruneEcho may be received and cause the override to LAN, then the PruneEcho may be received and cause the
happen. A PruneEcho(S,G) need not be sent on an interface override to happen. A PruneEcho(S,G) need not be sent on an
that contains only a single PIM neighbor during the time this interface that contains only a single PIM neighbor during
state machine was in Prune-Pending state. the time this state machine was in Prune-Pending state.
4.5.3. Receiving (S,G,rpt) Join/Prune Messages 4.5.3. Receiving (S,G,rpt) Join/Prune Messages
The per-interface state machine for receiving (S,G,rpt) Join/Prune The per-interface state machine for receiving (S,G,rpt) Join/Prune
messages is given below. There are five states: messages is given below. There are five states:
NoInfo (NI) NoInfo (NI)
The interface has no (S,G,rpt) Prune state and no (S,G,rpt) The interface has no (S,G,rpt) Prune state and no (S,G,rpt)
timers running. timers running.
Prune (P) Prune (P)
The interface has (S,G,rpt) Prune state, which will cause the The interface has (S,G,rpt) Prune state, which will cause
router not to forward packets from S destined for G from this the router not to forward packets from S destined for G from
interface even though the interface has active (*,G) Join this interface even though the interface has active (*,G)
state. Join state.
Prune-Pending (PP) Prune-Pending (PP)
The router has received a Prune(S,G,rpt) on this interface The router has received a Prune(S,G,rpt) on this interface
from a downstream neighbor and is waiting to see whether the from a downstream neighbor and is waiting to see whether the
prune will be overridden by another downstream router. For prune will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions
like the NoInfo state. exactly like the NoInfo state.
PruneTmp (P') PruneTmp (P')
This state is a transient state that for forwarding purposes This state is a transient state that for forwarding purposes
behaves exactly like the Prune state. A (*,G) Join has been behaves exactly like the Prune state. A (*,G) Join has been
received (which may cancel the (S,G,rpt) Prune). As we parse received (which may cancel the (S,G,rpt) Prune). As we
the Join/Prune message from top to bottom, we first enter this parse the Join/Prune message from top to bottom, we first
state if the message contains a (*,G) Join. Later in the enter this state if the message contains a (*,G) Join.
message, we will normally encounter an (S,G,rpt) prune to Later in the message, we will normally encounter an
reinstate the Prune state. However, if we reach the end of (S,G,rpt) prune to reinstate the Prune state. However, if
the message without encountering such an (S,G,rpt) prune, then we reach the end of the message without encountering such an
we will revert to NoInfo state in this state machine. (S,G,rpt) prune, then we will revert to NoInfo state in this
state machine.
As no time is spent in this state, no timers can expire. As no time is spent in this state, no timers can expire.
Prune-Pending-Tmp (PP') Prune-Pending-Tmp (PP')
This state is a transient state that is identical to P' except This state is a transient state that is identical to P'
that it is associated with the PP state rather than the P except that it is associated with the PP state rather than
state. For forwarding purposes, PP' behaves exactly like PP the P state. For forwarding purposes, PP' behaves exactly
state. like the PP state.
In addition, there are two timers: In addition, there are two timers:
Expiry Timer (ET) Expiry Timer (ET)
This timer is set when a valid Prune(S,G,rpt) is received. This timer is set when a valid Prune(S,G,rpt) is received.
Expiry of the Expiry Timer causes this state machine to revert Expiry of the Expiry Timer causes this state machine to
to NoInfo state. revert to NoInfo state.
Prune-Pending Timer (PPT) Prune-Pending Timer (PPT)
This timer is set when a valid Prune(S,G,rpt) is received. This timer is set when a valid Prune(S,G,rpt) is received.
Expiry of the Prune-Pending Timer causes this state machine to Expiry of the Prune-Pending Timer causes this state machine
move on to Prune state. to move on to Prune state.
Figure 4: Downstream per-interface (S,G,rpt) state machine Figure 4: Downstream Per-Interface (S,G,rpt) State Machine
in tabular form
+----------++----------------------------------------------------------+ +----------++----------------------------------------------------------+
| || Event | | || Event |
| ++---------+----------+----------+--------+--------+--------+ | ++---------+----------+----------+--------+--------+--------+
|Prev ||Receive | Receive | Receive | End of | Prune- | Expiry | |Prev ||Receive | Receive | Receive | End of | Prune- | Expiry |
|State ||Join(*,G)| Join | Prune | Message| Pending| Timer | |State ||Join(*,G)| Join | Prune | Message| Pending| Timer |
| || | (S,G,rpt)| (S,G,rpt)| | Timer | Expires| | || | (S,G,rpt)| (S,G,rpt)| | Timer | Expires|
| || | | | | Expires| | | || | | | | Expires| |
+----------++---------+----------+----------+--------+--------+--------+ +----------++---------+----------+----------+--------+--------+--------+
| ||- | - | -> PP | - | - | - | | ||- | - | -> PP | - | - | - |
skipping to change at page 54, line 19 skipping to change at page 57, line 19
address should be the same as the source address it chose for the address should be the same as the source address it chose for the
Hello message it sent over that interface. However, on point-to- Hello message it sent over that interface. However, on point-to-
point links it is RECOMMENDED that PIM Join/Prune messages with an point links it is RECOMMENDED that PIM Join/Prune messages with an
upstream neighbor address field of all zeros also be accepted. upstream neighbor address field of all zeros also be accepted.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo (NI) state, the following event may trigger a When in NoInfo (NI) state, the following event may trigger a
transition: transition:
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its Upstream A Prune(S,G,rpt) is received on interface I with its
Neighbor Address set to the router's primary IP address on I. Upstream Neighbor Address set to the router's primary IP
address on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the Prune-Pending state. The Expiry Timer (ET) transitions to the Prune-Pending state. The Expiry Timer
is started and set to the HoldTime from the triggering (ET) is started and set to the HoldTime from the triggering
Join/Prune message. The Prune-Pending Timer is started. It Join/Prune message. The Prune-Pending Timer is started. It
is set to the J/P_Override_Interval(I) if the router has more is set to the J/P_Override_Interval(I) if the router has
than one neighbor on that interface; otherwise, it is set to more than one neighbor on that interface; otherwise, it is
zero, causing it to expire immediately. set to zero, causing it to expire immediately.
Transitions from Prune-Pending State Transitions from Prune-Pending State
When in Prune-Pending (PP) state, the following events may trigger a When in Prune-Pending (PP) state, the following events may trigger a
transition: transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to Prune-Pending-Tmp state whilst the remainder of transitions to the Prune-Pending-Tmp state whilst the
the compound Join/Prune message containing the Join(*,G) is remainder of the compound Join/Prune message containing the
processed. Join(*,G) is processed.
Receive Join(S,G,rpt) Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its Upstream A Join(S,G,rpt) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to NoInfo state. ET and PPT are canceled. transitions to the NoInfo state. The ET and PPT are
canceled.
Prune-Pending Timer Expires Prune-Pending Timer Expires
The Prune-Pending Timer for the (S,G,rpt) downstream state The Prune-Pending Timer for the (S,G,rpt) downstream state
machine on interface I expires. machine on interface I expires.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the Prune state. transitions to the Prune state.
Transitions from Prune State Transitions from Prune State
When in Prune (P) state, the following events may trigger a When in Prune (P) state, the following events may trigger a
transition: transition:
Receive Join(*,G) Receive Join(*,G)
A Join(*,G) is received on interface I with its Upstream A Join(*,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to PruneTmp state whilst the remainder of the transitions to the PruneTmp state whilst the remainder of
compound Join/Prune message containing the Join(*,G) is the compound Join/Prune message containing the Join(*,G) is
processed. processed.
Receive Join(S,G,rpt) Receive Join(S,G,rpt)
A Join(S,G,rpt) is received on interface I with its Upstream A Join(S,G,rpt) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address on I. Neighbor Address set to the router's primary IP address
on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to NoInfo state. ET and PPT are canceled. transitions to the NoInfo state. The ET and PPT are
canceled.
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
A Prune(S,G,rpt) is received on interface I with its Upstream A Prune(S,G,rpt) is received on interface I with its
Neighbor Address set to the router's primary IP address on I. Upstream Neighbor Address set to the router's primary IP
address on I.
The (S,G,rpt) downstream state machine on interface I remains The (S,G,rpt) downstream state machine on interface I
in Prune state. The Expiry Timer (ET) is restarted, set to remains in Prune state. The Expiry Timer (ET) is restarted
maximum of its current value and the HoldTime from the and is then set to the maximum of its current value and the
triggering Join/Prune message. HoldTime from the triggering Join/Prune message.
Expiry Timer Expires Expiry Timer Expires
The Expiry Timer for the (S,G,rpt) downstream state machine on The Expiry Timer for the (S,G,rpt) downstream state machine
interface I expires. on interface I expires.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the NoInfo state. transitions to the NoInfo state.
Transitions from Prune-Pending-Tmp State Transitions from Prune-Pending-Tmp State
When in Prune-Pending-Tmp (PP') state and processing a compound When in Prune-Pending-Tmp (PP') state and processing a compound
Join/Prune message, the following events may trigger a transition: Join/Prune message, the following events may trigger a transition:
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt) that The compound Join/Prune message contains a Prune(S,G,rpt)
is received on interface I with its Upstream Neighbor Address that is received on interface I with its Upstream Neighbor
set to the router's primary IP address on I. Address set to the router's primary IP address on I.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune-Pending state. The Expiry Timer transitions back to the Prune-Pending state. The
(ET) is restarted, set to maximum of its current value and the Expiry Timer (ET) is restarted and is then set to the
HoldTime from the triggering Join/Prune message. maximum of its current value and the HoldTime from the
triggering Join/Prune message.
End of Message End of Message
The end of the compound Join/Prune message is reached. The end of the compound Join/Prune message is reached.
The (S,G,rpt) downstream state machine on interface I The (S,G,rpt) downstream state machine on interface I
transitions to the NoInfo state. ET and PPT are canceled. transitions to the NoInfo state. The ET and PPT are
canceled.
Transitions from PruneTmp State Transitions from PruneTmp State
When in PruneTmp (P') state and processing a compound Join/Prune When in PruneTmp (P') state and processing a compound Join/Prune
message, the following events may trigger a transition: message, the following events may trigger a transition:
Receive Prune(S,G,rpt) Receive Prune(S,G,rpt)
The compound Join/Prune message contains a Prune(S,G,rpt). The compound Join/Prune message contains a Prune(S,G,rpt).
The (S,G,rpt) downstream state machine on interface I
transitions back to the Prune state. The Expiry Timer (ET) is
restarted, set to maximum of its current value and the
HoldTime from the triggering Join/Prune message.
End of Message The (S,G,rpt) downstream state machine on interface I
The end of the compound Join/Prune message is reached. transitions back to the Prune state. The Expiry Timer (ET)
is restarted and is then set to the maximum of its current
value and the HoldTime from the triggering Join/Prune
message.
The (S,G,rpt) downstream state machine on interface I End of Message
transitions to the NoInfo state. ET is canceled. The end of the compound Join/Prune message is reached.
Notes: The (S,G,rpt) downstream state machine on interface I
transitions to the NoInfo state. ET is canceled.
Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream state Note: Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream
machine. state machine.
4.5.4. Sending (*,G) Join/Prune Messages 4.5.4. Sending (*,G) Join/Prune Messages
The per-interface state machines for (*,G) hold join state from The per-interface state machines for (*,G) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(*,G) upstream towards the RP. needs to propagate a Join(*,G) upstream towards the RP.
If a router wishes to propagate a Join(*,G) upstream, it must also If a router wishes to propagate a Join(*,G) upstream, it must also
watch for messages on its upstream interface from other routers on watch for messages on its upstream interface from other routers on
that subnet, and these may modify its behavior. If it sees a that subnet, and these may modify its behavior. If it sees a
skipping to change at page 57, line 21 skipping to change at page 61, line 30
to refresh the state by sending a Join(*,G) almost immediately. to refresh the state by sending a Join(*,G) almost immediately.
If a (*,G) Assert occurs on the upstream interface, and this changes If a (*,G) Assert occurs on the upstream interface, and this changes
this router's idea of the upstream neighbor, it should be prepared to this router's idea of the upstream neighbor, it should be prepared to
ensure that the Assert winner is aware of downstream routers by ensure that the Assert winner is aware of downstream routers by
sending a Join(*,G) almost immediately. sending a Join(*,G) almost immediately.
In addition, if the MRIB changes to indicate that the next hop In addition, if the MRIB changes to indicate that the next hop
towards the RP has changed, and either the upstream interface changes towards the RP has changed, and either the upstream interface changes
or there is no Assert winner on the upstream interface, the router or there is no Assert winner on the upstream interface, the router
should prune off from the old next hop and join towards the new next should prune off from the old next hop and join towards the new
hop. next hop.
The upstream (*,G) state machine only contains two states: The upstream (*,G) state machine only contains two states:
Not Joined Not Joined
The downstream state machines indicate that the router does not The downstream state machines indicate that the router does
need to join the RP tree for this group. not need to join the RP tree for this group.
Joined Joined
The downstream state machines indicate that the router should join The downstream state machines indicate that the router
the RP tree for this group. should join the RP tree for this group.
In addition, one timer JT(*,G) is kept that is used to trigger the In addition, one timer JT(*,G) is kept that is used to trigger the
sending of a Join(*,G) to the upstream next hop towards the RP, sending of a Join(*,G) to the upstream next hop towards the RP,
RPF'(*,G). RPF'(*,G).
Figure 5: Upstream (*,G) state machine in tabular form Figure 5: Upstream (*,G) State Machine
+-------------------++-------------------------------------------------+ +-------------------++-------------------------------------------------+
| || Event | | || Event |
| Prev State ++------------------------+------------------------+ | Prev State ++------------------------+------------------------+
| || JoinDesired(*,G) | JoinDesired(*,G) | | || JoinDesired(*,G) | JoinDesired(*,G) |
| || ->True | ->False | | || ->True | ->False |
+-------------------++------------------------+------------------------+ +-------------------++------------------------+------------------------+
| || -> J state | - | | || -> J state | - |
| NotJoined (NJ) || Send Join(*,G); | | | NotJoined (NJ) || Send Join(*,G); | |
| || Set Join Timer to | | | || set Join Timer to | |
| || t_periodic | | | || t_periodic | |
+-------------------++------------------------+------------------------+ +-------------------++------------------------+------------------------+
| Joined (J) || - | -> NJ state | | Joined (J) || - | -> NJ state |
| || | Send Prune(*,G); | | || | Send Prune(*,G); |
| || | Cancel Join Timer | | || | cancel Join Timer |
+-------------------++------------------------+------------------------+ +-------------------++------------------------+------------------------+
In addition, we have the following transitions, which occur within In addition, we have the following transitions, which occur within
the Joined state: the Joined state:
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+----------------+-----------------+-----------------+-----------------+ +----------------+-----------------+-----------------+-----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) | |Timer Expires | See Join(*,G) | See Prune(*,G) | RPF'(*,G) |
| | to RPF'(*,G) | to RPF'(*,G) | changes due to | | | to RPF'(*,G) | to RPF'(*,G) | changes due to |
| | | | an Assert | | | | | an Assert |
+----------------+-----------------+-----------------+-----------------+ +----------------+-----------------+-----------------+-----------------+
|Send | Increase Join | Decrease Join | Decrease Join | |Send | Increase Join | Decrease Join | Decrease Join |
|Join(*,G); Set | Timer to | Timer to | Timer to | |Join(*,G); set | Timer to | Timer to | Timer to |
|Join Timer to | t_joinsuppress | t_override | t_override | |Join Timer to | t_joinsuppress | t_override | t_override |
|t_periodic | | | | |t_periodic | | | |
+----------------+-----------------+-----------------+-----------------+ +----------------+-----------------+-----------------+-----------------+
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+----------------------------------+-----------------------------------+ +----------------------------------+-----------------------------------+
| RPF'(*,G) changes not | RPF'(*,G) GenID changes | | RPF'(*,G) changes not | RPF'(*,G) GenID changes |
| due to an Assert | | | due to an Assert | |
+----------------------------------+-----------------------------------+ +----------------------------------+-----------------------------------+
| Send Join(*,G) to new | Decrease Join Timer to | | Send Join(*,G) to new | Decrease Join Timer to |
| next hop; Send | t_override | | next hop; send | t_override |
| Prune(*,G) to old next | | | Prune(*,G) to old next | |
| hop; Set Join Timer to | | | hop; set Join Timer to | |
| t_periodic | | | t_periodic | |
+----------------------------------+-----------------------------------+ +----------------------------------+-----------------------------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(*,G) { bool JoinDesired(*,G) {
if (immediate_olist(*,G) != NULL) if (immediate_olist(*,G) != NULL)
return TRUE return TRUE
else else
return FALSE return FALSE
} }
skipping to change at page 59, line 24 skipping to change at page 63, line 24
would cause it to forward traffic for G using shared tree state. would cause it to forward traffic for G using shared tree state.
Note that although JoinDesired is true, the router's sending of a Note that although JoinDesired is true, the router's sending of a
Join(*,G) message may be suppressed by another router sending a Join(*,G) message may be suppressed by another router sending a
Join(*,G) onto the upstream interface. Join(*,G) onto the upstream interface.
Transitions from NotJoined State Transitions from NotJoined State
When the upstream (*,G) state machine is in NotJoined state, the When the upstream (*,G) state machine is in NotJoined state, the
following event may trigger a state transition: following event may trigger a state transition:
JoinDesired(*,G) becomes True JoinDesired(*,G) becomes True
The macro JoinDesired(*,G) becomes True, e.g., because the The macro JoinDesired(*,G) becomes True, e.g., because the
downstream state for (*,G) has changed so that at least one downstream state for (*,G) has changed so that at least one
interface is in immediate_olist(*,G). interface is in immediate_olist(*,G).
The upstream (*,G) state machine transitions to Joined state. The upstream (*,G) state machine transitions to the Joined
Send Join(*,G) to the appropriate upstream neighbor, which is state. Send Join(*,G) to the appropriate upstream neighbor,
RPF'(*,G). Set the Join Timer (JT) to expire after t_periodic which is RPF'(*,G). Set the Join Timer (JT) to expire after
seconds. t_periodic seconds.
Transitions from Joined State Transitions from Joined State
When the upstream (*,G) state machine is in Joined state, the When the upstream (*,G) state machine is in Joined state, the
following events may trigger state transitions: following events may trigger state transitions:
JoinDesired(*,G) becomes False JoinDesired(*,G) becomes False
The macro JoinDesired(*,G) becomes False, e.g., because the The macro JoinDesired(*,G) becomes False, e.g., because the
downstream state for (*,G) has changed so no interface is in downstream state for (*,G) has changed so no interface is in
immediate_olist(*,G). immediate_olist(*,G).
The upstream (*,G) state machine transitions to NotJoined The upstream (*,G) state machine transitions to the
state. Send Prune(*,G) to the appropriate upstream neighbor, NotJoined state. Send Prune(*,G) to the appropriate
which is RPF'(*,G). Cancel the Join Timer (JT). upstream neighbor, which is RPF'(*,G). Cancel the
Join Timer (JT).
Join Timer Expires Join Timer Expires
The Join Timer (JT) expires, indicating time to send a The Join Timer (JT) expires, indicating time to send a
Join(*,G) Join(*,G).
Send Join(*,G) to the appropriate upstream neighbor, which is
RPF'(*,G). Restart the Join Timer (JT) to expire after
t_periodic seconds.
See Join(*,G) to RPF'(*,G) Send Join(*,G) to the appropriate upstream neighbor, which
This event is only relevant if RPF_interface(RP(G)) is a is RPF'(*,G). Restart the Join Timer (JT) to expire after
shared medium. This router sees another router on t_periodic seconds.
RPF_interface(RP(G)) send a Join(*,G) to RPF'(*,G). This
causes this router to suppress its own Join.
The upstream (*,G) state machine remains in Joined state. See Join(*,G) to RPF'(*,G)
This event is only relevant if RPF_interface(RP(G)) is a
shared medium. This router sees another router on
RPF_interface(RP(G)) send a Join(*,G) to RPF'(*,G). This
causes this router to suppress its own Join.
Let t_joinsuppress be the minimum of t_suppressed and the The upstream (*,G) state machine remains in Joined state.
HoldTime from the Join/Prune message triggering this event. If
the Join Timer is set to expire in less than t_joinsuppress
seconds, reset it so that it expires after t_joinsuppress
seconds. If the Join Timer is set to expire in more than
t_joinsuppress seconds, leave it unchanged.
See Prune(*,G) to RPF'(*,G) Let t_joinsuppress be the minimum of t_suppressed and the
This event is only relevant if RPF_interface(RP(G)) is a HoldTime from the Join/Prune message triggering this event.
shared medium. This router sees another router on If the Join Timer is set to expire in less than
RPF_interface(RP(G)) send a Prune(*,G) to RPF'(*,G). As this t_joinsuppress seconds, reset it so that it expires after
router is in Joined state, it must override the Prune after a t_joinsuppress seconds. If the Join Timer is set to expire
short random interval. in more than t_joinsuppress seconds, leave it unchanged.
The upstream (*,G) state machine remains in Joined state. If See Prune(*,G) to RPF'(*,G)
the Join Timer is set to expire in more than t_override This event is only relevant if RPF_interface(RP(G)) is a
seconds, reset it so that it expires after t_override seconds. shared medium. This router sees another router on
If the Join Timer is set to expire in less than t_override RPF_interface(RP(G)) send a Prune(*,G) to RPF'(*,G). As
seconds, leave it unchanged. this router is in Joined state, it must override the Prune
after a short random interval.
RPF'(*,G) changes due to an Assert The upstream (*,G) state machine remains in Joined state.
The current next hop towards the RP changes due to an If the Join Timer is set to expire in more than
Assert(*,G) on the RPF_interface(RP(G)). t_override seconds, reset it so that it expires after
t_override seconds. If the Join Timer is set to expire in
less than t_override seconds, leave it unchanged.
The upstream (*,G) state machine remains in Joined state. If RPF'(*,G) changes due to an Assert
the Join Timer is set to expire in more than t_override The current next hop towards the RP changes due to an
seconds, reset it so that it expires after t_override seconds. Assert(*,G) on the RPF_interface(RP(G)).
If the Join Timer is set to expire in less than t_override
seconds, leave it unchanged.
RPF'(*,G) changes not due to an Assert The upstream (*,G) state machine remains in Joined state.
An event occurred that caused the next hop towards the RP for If the Join Timer is set to expire in more than
G to change. This may be caused by a change in the MRIB t_override seconds, reset it so that it expires after
routing database or the group-to-RP mapping. Note that this t_override seconds. If the Join Timer is set to expire in
transition does not occur if an Assert is active and the less than t_override seconds, leave it unchanged.
upstream interface does not change.
The upstream (*,G) state machine remains in Joined state. Send RPF'(*,G) changes not due to an Assert
Join(*,G) to the new upstream neighbor, which is the new value An event occurred that caused the next hop towards the RP
of RPF'(*,G). Send Prune(*,G) to the old upstream neighbor, for G to change. This may be caused by a change in the MRIB
which is the old value of RPF'(*,G). Use the new value of routing database or the group-to-RP mapping. Note that this
RP(G) in the Prune(*,G) message or all zeros if RP(G) becomes transition does not occur if an Assert is active and the
unknown (old value of RP(G) may be used instead to improve upstream interface does not change.
behavior in routers implementing older versions of this spec).
Set the Join Timer (JT) to expire after t_periodic seconds.
RPF'(*,G) GenID changes The upstream (*,G) state machine remains in Joined state.
The Generation ID of the router that is RPF'(*,G) changes. Send Join(*,G) to the new upstream neighbor, which is the
This normally means that this neighbor has lost state, and so new value of RPF'(*,G). Send Prune(*,G) to the old upstream
the state must be refreshed. neighbor, which is the old value of RPF'(*,G). Use the new
value of RP(G) in the Prune(*,G) message or all zeros if
RP(G) becomes unknown (old value of RP(G) may be used
instead to improve behavior in routers implementing older
versions of this specification). Set the Join Timer (JT) to
expire after t_periodic seconds.
The upstream (*,G) state machine remains in Joined state. If RPF'(*,G) GenID changes
the Join Timer is set to expire in more than t_override The Generation ID of the router that is RPF'(*,G) changes.
seconds, reset it so that it expires after t_override seconds. This normally means that this neighbor has lost state, and
so the state must be refreshed.
The upstream (*,G) state machine remains in Joined state.
If the Join Timer is set to expire in more than
t_override seconds, reset it so that it expires after
t_override seconds.
4.5.5. Sending (S,G) Join/Prune Messages 4.5.5. Sending (S,G) Join/Prune Messages
The per-interface state machines for (S,G) hold join state from The per-interface state machines for (S,G) hold join state from
downstream PIM routers. This state then determines whether a router downstream PIM routers. This state then determines whether a router
needs to propagate a Join(S,G) upstream towards the source. needs to propagate a Join(S,G) upstream towards the source.
If a router wishes to propagate a Join(S,G) upstream, it must also If a router wishes to propagate a Join(S,G) upstream, it must also
watch for messages on its upstream interface from other routers on watch for messages on its upstream interface from other routers on
that subnet, and these may modify its behavior. If it sees a that subnet, and these may modify its behavior. If it sees a
skipping to change at page 62, line 5 skipping to change at page 66, line 17
ensure that the Assert winner is aware of downstream routers by ensure that the Assert winner is aware of downstream routers by
scheduling a Join(S,G) to be sent almost immediately. scheduling a Join(S,G) to be sent almost immediately.
In addition, if MRIB changes cause the next hop towards the source to In addition, if MRIB changes cause the next hop towards the source to
change, and either the upstream interface changes or there is no change, and either the upstream interface changes or there is no
Assert winner on the upstream interface, the router should send a Assert winner on the upstream interface, the router should send a
prune to the old next hop and a join to the new next hop. prune to the old next hop and a join to the new next hop.
The upstream (S,G) state machine only contains two states: The upstream (S,G) state machine only contains two states:
Not Joined Not Joined
The downstream state machines and local membership information do The downstream state machines and local membership
not indicate that the router needs to join the shortest-path tree information do not indicate that the router needs to join
for this (S,G). the shortest-path tree for this (S,G).
Joined Joined
The downstream state machines and local membership information The downstream state machines and local membership
indicate that the router should join the shortest-path tree for information indicate that the router should join the
this (S,G). shortest-path tree for this (S,G).
In addition, one timer JT(S,G) is kept that is used to trigger the In addition, one timer JT(S,G) is kept that is used to trigger the
sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G). sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G).
Figure 6: Upstream (S,G) state machine in tabular form Figure 6: Upstream (S,G) State Machine
+-------------------+--------------------------------------------------+ +-------------------+--------------------------------------------------+
| | Event | | | Event |
| Prev State +-------------------------+------------------------+ | Prev State +-------------------------+------------------------+
| | JoinDesired(S,G) | JoinDesired(S,G) | | | JoinDesired(S,G) | JoinDesired(S,G) |
| | ->True | ->False | | | ->True | ->False |
+-------------------+-------------------------+------------------------+ +-------------------+-------------------------+------------------------+
| NotJoined (NJ) | -> J state | - | | NotJoined (NJ) | -> J state | - |
| | Send Join(S,G); | | | | Send Join(S,G); | |
| | Set Join Timer to | | | | set Join Timer to | |
| | t_periodic | | | | t_periodic | |
+-------------------+-------------------------+------------------------+ +-------------------+-------------------------+------------------------+
| Joined (J) | - | -> NJ state | | Joined (J) | - | -> NJ state |
| | | Send Prune(S,G); | | | | Send Prune(S,G); |
| | | Set SPTbit(S,G) to | | | | set SPTbit(S,G) to |
| | | FALSE; Cancel Join | | | | FALSE; cancel Join |
| | | Timer | | | | Timer |
+-------------------+-------------------------+------------------------+ +-------------------+-------------------------+------------------------+
In addition, we have the following transitions, which occur within In addition, we have the following transitions, which occur within
the Joined state: the Joined state:
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+-----------------+-----------------+-----------------+----------------+ +-----------------+-----------------+-----------------+----------------+
| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune | | Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to | | | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
| | | | RPF'(S,G) | | | | | RPF'(S,G) |
+-----------------+-----------------+-----------------+----------------+ +-----------------+-----------------+-----------------+----------------+
skipping to change at page 62, line 49 skipping to change at page 67, line 15
the Joined state: the Joined state:
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+-----------------+-----------------+-----------------+----------------+ +-----------------+-----------------+-----------------+----------------+
| Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune | | Timer Expires | See Join(S,G) | See Prune(S,G) | See Prune |
| | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to | | | to RPF'(S,G) | to RPF'(S,G) | (S,G,rpt) to |
| | | | RPF'(S,G) | | | | | RPF'(S,G) |
+-----------------+-----------------+-----------------+----------------+ +-----------------+-----------------+-----------------+----------------+
| Send | Increase Join | Decrease Join | Decrease Join | | Send | Increase Join | Decrease Join | Decrease Join |
| Join(S,G); Set | Timer to | Timer to | Timer to | | Join(S,G); set | Timer to | Timer to | Timer to |
| Join Timer to | t_joinsuppress | t_override | t_override | | Join Timer to | t_joinsuppress | t_override | t_override |
| t_periodic | | | | | t_periodic | | | |
+-----------------+-----------------+-----------------+----------------+ +-----------------+-----------------+-----------------+----------------+
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+-----------------+-----------------+----------------+-----------------+ +-----------------+-----------------+----------------+-----------------+
| See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) | | See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) |
| to RPF'(S,G) | changes not | GenID changes | changes due to | | to RPF'(S,G) | changes not | GenID changes | changes due to |
| | due to an | | an Assert | | | due to an | | an Assert |
| | Assert | | | | | Assert | | |
+-----------------+-----------------+----------------+-----------------+ +-----------------+-----------------+----------------+-----------------+
| Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join | | Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
| Timer to | to new next | Timer to | Timer to | | Timer to | to new next | Timer to | Timer to |
skipping to change at page 63, line 14 skipping to change at page 67, line 30
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+-----------------+-----------------+----------------+-----------------+ +-----------------+-----------------+----------------+-----------------+
| See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) | | See Prune(*,G) | RPF'(S,G) | RPF'(S,G) | RPF'(S,G) |
| to RPF'(S,G) | changes not | GenID changes | changes due to | | to RPF'(S,G) | changes not | GenID changes | changes due to |
| | due to an | | an Assert | | | due to an | | an Assert |
| | Assert | | | | | Assert | | |
+-----------------+-----------------+----------------+-----------------+ +-----------------+-----------------+----------------+-----------------+
| Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join | | Decrease Join | Send Join(S,G) | Decrease Join | Decrease Join |
| Timer to | to new next | Timer to | Timer to | | Timer to | to new next | Timer to | Timer to |
| t_override | hop; Send | t_override | t_override | | t_override | hop; send | t_override | t_override |
| | Prune(S,G) to | | | | | Prune(S,G) to | | |
| | old next hop; | | | | | old next hop; | | |
| | Set Join Timer | | | | | set Join Timer | | |
| | to t_periodic | | | | | to t_periodic | | |
+-----------------+-----------------+----------------+-----------------+ +-----------------+-----------------+----------------+-----------------+
This state machine uses the following macro: This state machine uses the following macro:
bool JoinDesired(S,G) { bool JoinDesired(S,G) {
return( immediate_olist(S,G) != NULL return( immediate_olist(S,G) != NULL
OR ( KeepaliveTimer(S,G) is running OR ( KeepaliveTimer(S,G) is running
AND inherited_olist(S,G) != NULL ) ) AND inherited_olist(S,G) != NULL ) )
} }
skipping to change at page 63, line 42 skipping to change at page 68, line 10
join state, or the (S,G) Keepalive Timer and active non-source- join state, or the (S,G) Keepalive Timer and active non-source-
specific state. Note that although JoinDesired is true, the router's specific state. Note that although JoinDesired is true, the router's
sending of a Join(S,G) message may be suppressed by another router sending of a Join(S,G) message may be suppressed by another router
sending a Join(S,G) onto the upstream interface. sending a Join(S,G) onto the upstream interface.
Transitions from NotJoined State Transitions from NotJoined State
When the upstream (S,G) state machine is in NotJoined state, the When the upstream (S,G) state machine is in NotJoined state, the
following event may trigger a state transition: following event may trigger a state transition:
JoinDesired(S,G) becomes True JoinDesired(S,G) becomes True
The macro JoinDesired(S,G) becomes True, e.g., because the The macro JoinDesired(S,G) becomes True, e.g., because the
downstream state for (S,G) has changed so that at least one downstream state for (S,G) has changed so that at least one
interface is in inherited_olist(S,G). interface is in inherited_olist(S,G).
The upstream (S,G) state machine transitions to Joined state. The upstream (S,G) state machine transitions to the Joined
Send Join(S,G) to the appropriate upstream neighbor, which is state. Send Join(S,G) to the appropriate upstream neighbor,
RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic which is RPF'(S,G). Set the Join Timer (JT) to expire after
seconds. t_periodic seconds.
Transitions from Joined State Transitions from Joined State
When the upstream (S,G) state machine is in Joined state, the When the upstream (S,G) state machine is in Joined state, the
following events may trigger state transitions: following events may trigger state transitions:
JoinDesired(S,G) becomes False JoinDesired(S,G) becomes False
The macro JoinDesired(S,G) becomes False, e.g., because the The macro JoinDesired(S,G) becomes False, e.g., because the
downstream state for (S,G) has changed so no interface is in downstream state for (S,G) has changed so no interface is in
inherited_olist(S,G). inherited_olist(S,G).
The upstream (S,G) state machine transitions to NotJoined The upstream (S,G) state machine transitions to the
state. Send Prune(S,G) to the appropriate upstream neighbor, NotJoined state. Send Prune(S,G) to the appropriate
which is RPF'(S,G). Cancel the Join Timer (JT), and set upstream neighbor, which is RPF'(S,G). Cancel the
SPTbit(S,G) to FALSE. Join Timer (JT), and set SPTbit(S,G) to FALSE.
Join Timer Expires Join Timer Expires
The Join Timer (JT) expires, indicating time to send a The Join Timer (JT) expires, indicating time to send a
Join(S,G) Join(S,G).
Send Join(S,G) to the appropriate upstream neighbor, which is Send Join(S,G) to the appropriate upstream neighbor, which
RPF'(S,G). Restart the Join Timer (JT) to expire after is RPF'(S,G). Restart the Join Timer (JT) to expire after
t_periodic seconds. t_periodic seconds.
See Join(S,G) to RPF'(S,G) See Join(S,G) to RPF'(S,G)
This event is only relevant if RPF_interface(S) is a shared This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) medium. This router sees another router on RPF_interface(S)
send a Join(S,G) to RPF'(S,G). This causes this router to send a Join(S,G) to RPF'(S,G). This causes this router to
suppress its own Join. suppress its own Join.
The upstream (S,G) state machine remains in Joined state. The upstream (S,G) state machine remains in Joined state.
Let t_joinsuppress be the minimum of t_suppressed and the Let t_joinsuppress be the minimum of t_suppressed and the
HoldTime from the Join/Prune message triggering this event. HoldTime from the Join/Prune message triggering this event.
If the Join Timer is set to expire in less than t_joinsuppress If the Join Timer is set to expire in less than
seconds, reset it so that it expires after t_joinsuppress t_joinsuppress seconds, reset it so that it expires after
seconds. If the Join Timer is set to expire in more than t_joinsuppress seconds. If the Join Timer is set to expire
t_joinsuppress seconds, leave it unchanged. in more than t_joinsuppress seconds, leave it unchanged.
See Prune(S,G) to RPF'(S,G) See Prune(S,G) to RPF'(S,G)
This event is only relevant if RPF_interface(S) is a shared This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) medium. This router sees another router on RPF_interface(S)
send a Prune(S,G) to RPF'(S,G). As this router is in Joined send a Prune(S,G) to RPF'(S,G). As this router is in Joined
state, it must override the Prune after a short random state, it must override the Prune after a short random
interval. interval.
The upstream (S,G) state machine remains in Joined state. If The upstream (S,G) state machine remains in Joined state.
the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than
seconds, reset it so that it expires after t_override seconds. t_override seconds, reset it so that it expires after
t_override seconds.
See Prune(S,G,rpt) to RPF'(S,G) See Prune(S,G,rpt) to RPF'(S,G)
This event is only relevant if RPF_interface(S) is a shared This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) medium. This router sees another router on RPF_interface(S)
send a Prune(S,G,rpt) to RPF'(S,G). If the upstream router is send a Prune(S,G,rpt) to RPF'(S,G). If the upstream router
an RFC-2362-compliant PIM router, then the Prune(S,G,rpt) will is an RFC-2362-compliant PIM router, then the Prune(S,G,rpt)
cause it to stop forwarding. For backwards compatibility, will cause it to stop forwarding. For backwards
this router should override the prune so that forwarding compatibility, this router should override the prune so that
continues. forwarding continues.
The upstream (S,G) state machine remains in Joined state. If The upstream (S,G) state machine remains in Joined state.
the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than
seconds, reset it so that it expires after t_override seconds. t_override seconds, reset it so that it expires after
t_override seconds.
See Prune(*,G) to RPF'(S,G) See Prune(*,G) to RPF'(S,G)
This event is only relevant if RPF_interface(S) is a shared This event is only relevant if RPF_interface(S) is a shared
medium. This router sees another router on RPF_interface(S) medium. This router sees another router on RPF_interface(S)
send a Prune(*,G) to RPF'(S,G). If the upstream router is an send a Prune(*,G) to RPF'(S,G). If the upstream router is
RFC-2362-compliant PIM router, then the Prune(*,G) will cause an RFC-2362-compliant PIM router, then the Prune(*,G) will
it to stop forwarding. For backwards compatibility, this cause it to stop forwarding. For backwards compatibility,
router should override the prune so that forwarding continues. this router should override the prune so that forwarding
continues.
The upstream (S,G) state machine remains in Joined state. If The upstream (S,G) state machine remains in Joined state.
the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than
seconds, reset it so that it expires after t_override seconds. t_override seconds, reset it so that it expires after
t_override seconds.
RPF'(S,G) changes due to an Assert RPF'(S,G) changes due to an Assert
The current next hop towards S changes due to an Assert(S,G) The current next hop towards S changes due to an Assert(S,G)
on the RPF_interface(S). on the RPF_interface(S).
The upstream (S,G) state machine remains in Joined state. If The upstream (S,G) state machine remains in Joined state.
the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than
seconds, reset it so that it expires after t_override seconds. t_override seconds, reset it so that it expires after
If the Join Timer is set to expire in less than t_override t_override seconds. If the Join Timer is set to expire in
seconds, leave it unchanged. less than t_override seconds, leave it unchanged.
RPF'(S,G) changes not due to an Assert RPF'(S,G) changes not due to an Assert
An event occurred that caused the next hop towards S to An event occurred that caused the next hop towards S to
change. Note that this transition does not occur if an Assert change. Note that this transition does not occur if an
is active and the upstream interface does not change. Assert is active and the upstream interface does not change.
The upstream (S,G) state machine remains in Joined state. Send The upstream (S,G) state machine remains in Joined state.
Join(S,G) to the new upstream neighbor, which is the new value Send Join(S,G) to the new upstream neighbor, which is the
of RPF'(S,G). Send Prune(S,G) to the old upstream neighbor, new value of RPF'(S,G). Send Prune(S,G) to the old upstream
which is the old value of RPF'(S,G). Set the Join Timer (JT) neighbor, which is the old value of RPF'(S,G). Set the
to expire after t_periodic seconds. Join Timer (JT) to expire after t_periodic seconds.
RPF'(S,G) GenID changes RPF'(S,G) GenID changes
The Generation ID of the router that is RPF'(S,G) changes. The Generation ID of the router that is RPF'(S,G) changes.
This normally means that this neighbor has lost state, and so This normally means that this neighbor has lost state, and
the state must be refreshed. so the state must be refreshed.
The upstream (S,G) state machine remains in Joined state. If The upstream (S,G) state machine remains in Joined state.
the Join Timer is set to expire in more than t_override If the Join Timer is set to expire in more than
seconds, reset it so that it expires after t_override seconds. t_override seconds, reset it so that it expires after
t_override seconds.
4.5.6. (S,G,rpt) Periodic Messages 4.5.6. (S,G,rpt) Periodic Messages
(S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP (S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP
tree with the RPT bit set, either to modify the results of (*,G) tree with the RPT bit set, either to modify the results of (*,G)
Joins, or to override the behavior of other upstream LAN peers. The Joins, or to override the behavior of other upstream LAN peers. The
next section describes the rules for sending triggered messages. next section describes the rules for sending triggered messages.
This section describes the rules for including a Prune(S,G,rpt) This section describes the rules for including a Prune(S,G,rpt)
message with a Join(*,G). message with a Join(*,G).
skipping to change at page 66, line 41 skipping to change at page 71, line 26
decide whether to include a Prune(S,G,rpt) in the compound Join/Prune decide whether to include a Prune(S,G,rpt) in the compound Join/Prune
message: message:
if( SPTbit(S,G) == TRUE ) { if( SPTbit(S,G) == TRUE ) {
# Note: If receiving (S,G) on the SPT, we only prune off the # Note: If receiving (S,G) on the SPT, we only prune off the
# shared tree if the RPF neighbors differ. # shared tree if the RPF neighbors differ.
if( RPF'(*,G) != RPF'(S,G) ) { if( RPF'(*,G) != RPF'(S,G) ) {
add Prune(S,G,rpt) to compound message add Prune(S,G,rpt) to compound message
} }
} else if ( inherited_olist(S,G,rpt) == NULL ) { } else if ( inherited_olist(S,G,rpt) == NULL ) {
# Note: all (*,G) olist interfaces received RPT prunes for (S,G). # Note: All (*,G) olist interfaces received RPT prunes for (S,G).
add Prune(S,G,rpt) to compound message add Prune(S,G,rpt) to compound message
} else if ( RPF'(*,G) != RPF'(S,G,rpt) { } else if ( RPF'(*,G) != RPF'(S,G,rpt) {
# Note: we joined the shared tree, but there was an (S,G) assert # Note: We joined the shared tree, but there was an (S,G) assert
# and the source tree RPF neighbor is different. # and the source tree RPF neighbor is different.
add Prune(S,G,rpt) to compound message add Prune(S,G,rpt) to compound message
} }
Note that Join(S,G,rpt) is normally sent not as a periodic message, Note that Join(S,G,rpt) is normally sent not as a periodic message,
but only as a triggered message. but only as a triggered message.
4.5.7. State Machine for (S,G,rpt) Triggered Messages 4.5.7. State Machine for (S,G,rpt) Triggered Messages
The state machine for (S,G,rpt) triggered messages is required per- The state machine for (S,G,rpt) triggered messages is required
(S,G) when there is (*,G) join state at a router, and the router or per-(S,G) when there is (*,G) join state at a router, and the router
any of its upstream LAN peers wishes to prune S off the RP tree. or any of its upstream LAN peers wishes to prune S off the RP tree.
There are three states in the state machine. One of the states is There are three states in the state machine. One of the states is
when there is no (*,G) join state at this router. If there is (*,G) when there is no (*,G) join state at this router. If there is (*,G)
join state at the router, then the state machine must be at one of join state at the router, then the state machine must be at one of
the other two states. The three states are: the other two states. The three states are:
Pruned(S,G,rpt) Pruned(S,G,rpt)
(*,G) Joined, but (S,G,rpt) pruned (*,G) Joined, but (S,G,rpt) pruned.
NotPruned(S,G,rpt) NotPruned(S,G,rpt)
(*,G) Joined, and (S,G,rpt) not pruned (*,G) Joined, and (S,G,rpt) not pruned.
RPTNotJoined(G) RPTNotJoined(G)
(*,G) has not been joined. (*,G) has not been joined.
In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which
is used to delay triggered Join(S,G,rpt) messages to prevent is used to delay triggered Join(S,G,rpt) messages to prevent
implosions of triggered messages. implosions of triggered messages.
Figure 7: Upstream (S,G,rpt) state machine for triggered messages Figure 7: Upstream (S,G,rpt) State Machine for Triggered Messages
in tabular form
+------------++--------------------------------------------------------+ +------------++--------------------------------------------------------+
| || Event | | || Event |
| ++--------------+--------------+-------------+------------+ | ++--------------+--------------+-------------+------------+
|Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ | |Prev State || PruneDesired | PruneDesired | RPTJoin | inherited_ |
| || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist | | || (S,G,rpt) | (S,G,rpt) | Desired(G) | olist |
| || ->True | ->False | ->False | (S,G,rpt) | | || ->True | ->False | ->False | (S,G,rpt) |
| || | | | ->non-NULL | | || | | | ->non-NULL |
+------------++--------------+--------------+-------------+------------+ +------------++--------------+--------------+-------------+------------+
|RPTNotJoined|| -> P state | - | - | -> NP state| |RPTNotJoined|| -> P state | - | - | -> NP state|
|(G) (NJ) || | | | | |(G) (NJ) || | | | |
+------------++--------------+--------------+-------------+------------+ +------------++--------------+--------------+-------------+------------+
|Pruned || - | -> NP state | -> NJ state | - | |Pruned || - | -> NP state | -> NJ state | - |
|(S,G,rpt) || | Send Join | | | |(S,G,rpt) || | Send Join | | |
|(P) || | (S,G,rpt) | | | |(P) || | (S,G,rpt) | | |
+------------++--------------+--------------+-------------+------------+ +------------++--------------+--------------+-------------+------------+
|NotPruned || -> P state | - | -> NJ state | - | |NotPruned || -> P state | - | -> NJ state | - |
|(S,G,rpt) || Send Prune | | Cancel OT | | |(S,G,rpt) || Send Prune | | Cancel OT | |
|(NP) || (S,G,rpt); | | | | |(NP) || (S,G,rpt); | | | |
| || Cancel OT | | | | | || cancel OT | | | |
+------------++--------------+--------------+-------------+------------+ +------------++--------------+--------------+-------------+------------+
Additionally, we have the following transitions within the Additionally, we have the following transitions within the
NotPruned(S,G,rpt) state, which are all used for prune override NotPruned(S,G,rpt) state, which are all used for prune override
behavior. behavior.
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In NotPruned(S,G,rpt) State | | In NotPruned(S,G,rpt) State |
+----------+--------------+--------------+--------------+--------------+ +----------+--------------+--------------+--------------+--------------+
|Override | See Prune | See Join | See Prune | RPF' | |Override | See Prune | See Join | See Prune | RPF' |
|Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> | |Timer | (S,G,rpt) to | (S,G,rpt) to | (S,G) to | (S,G,rpt) -> |
|expires | RPF' | RPF' | RPF' | RPF' (*,G) | |expires | RPF' | RPF' | RPF' | RPF' (*,G) |
| | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | | | | (S,G,rpt) | (S,G,rpt) | (S,G,rpt) | |
+----------+--------------+--------------+--------------+--------------+ +----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, | |Send Join | OT = min(OT, | Cancel OT | OT = min(OT, | OT = min(OT, |
|(S,G,rpt);| t_override) | | t_override) | t_override) | |(S,G,rpt);| t_override) | | t_override) | t_override) |
|Leave OT | | | | | |leave OT | | | | |
|unset | | | | | |unset | | | | |
+----------+--------------+--------------+--------------+--------------+ +----------+--------------+--------------+--------------+--------------+
Note that the min function in the above state machine considers a Note that the min function in the above state machine considers a
non-running timer to have an infinite value (e.g., min(not-running, non-running timer to have an infinite value (e.g., min(not-running,
t_override) = t_override). t_override) = t_override).
This state machine uses the following macros: This state machine uses the following macros:
bool RPTJoinDesired(G) { bool RPTJoinDesired(G) {
skipping to change at page 68, line 51 skipping to change at page 74, line 7
} }
PruneDesired(S,G,rpt) can only be true if RPTJoinDesired(G) is true. PruneDesired(S,G,rpt) can only be true if RPTJoinDesired(G) is true.
If RPTJoinDesired(G) is true, then PruneDesired(S,G,rpt) is true If RPTJoinDesired(G) is true, then PruneDesired(S,G,rpt) is true
either if there are no outgoing interfaces that S would be forwarded either if there are no outgoing interfaces that S would be forwarded
on, or if the router has active (S,G) forwarding state but RPF'(*,G) on, or if the router has active (S,G) forwarding state but RPF'(*,G)
!= RPF'(S,G). != RPF'(S,G).
The state machine contains the following transition events: The state machine contains the following transition events:
See Join(S,G,rpt) to RPF'(S,G,rpt) See Join(S,G,rpt) to RPF'(S,G,rpt)
This event is only relevant in the "Not Pruned" state. This event is only relevant in the "Not Pruned" state.
The router sees a Join(S,G,rpt) from someone else to The router sees a Join(S,G,rpt) from someone else to
RPF'(S,G,rpt), which is the correct upstream neighbor. If we're RPF'(S,G,rpt), which is the correct upstream neighbor. If
in "NotPruned" state and the (S,G,rpt) Override Timer is running, we're in "NotPruned" state and the (S,G,rpt) Override Timer
then this is because we have been triggered to send our own is running, then this is because we have been triggered to
Join(S,G,rpt) to RPF'(S,G,rpt). Someone else beat us to it, so send our own Join(S,G,rpt) to RPF'(S,G,rpt). Someone else
there's no need to send our own Join. beat us to it, so there's no need to send our own Join.
The action is to cancel the Override Timer. The action is to cancel the Override Timer.
See Prune(S,G,rpt) to RPF'(S,G,rpt) See Prune(S,G,rpt) to RPF'(S,G,rpt)
This event is only relevant in the "NotPruned" state. This event is only relevant in the "NotPruned" state.
The router sees a Prune(S,G,rpt) from someone else to The router sees a Prune(S,G,rpt) from someone else to
RPF'(S,G,rpt), which is the correct upstream neighbor. If we're RPF'(S,G,rpt), which is the correct upstream neighbor. If
in the "NotPruned" state, then we want to continue to receive we're in the "NotPruned" state, then we want to continue to
traffic from S destined for G, and that traffic is being supplied receive traffic from S destined for G, and that traffic is
by RPF'(S,G,rpt). Thus, we need to override the Prune. being supplied by RPF'(S,G,rpt). Thus, we need to override
the Prune.
The action is to set the (S,G,rpt) Override Timer to the The action is to set the (S,G,rpt) Override Timer to the
randomized prune-override interval, t_override. However, if the randomized prune-override interval, t_override. However, if
Override Timer is already running, we only set the timer if doing the Override Timer is already running, we only set the timer
so would set it to a lower value. At the end of this interval, if if doing so would set it to a lower value. At the end of
no one else has sent a Join, then we will do so. this interval, if no one else has sent a Join, then we will
do so.
See Prune(S,G) to RPF'(S,G,rpt) See Prune(S,G) to RPF'(S,G,rpt)
This event is only relevant in the "NotPruned" state. This event is only relevant in the "NotPruned" state.
This transition and action are the same as the above transition This transition and action are the same as the above
and action, except that the Prune does not have the RPT bit set. transition and action, except that the Prune does not have
This transition is necessary to be compatible with routers the RPT bit set. This transition is necessary to be
implemented from RFC2362 that don't maintain separate (S,G) and compatible with routers implemented from RFC 2362 that don't
(S,G,rpt) state. maintain separate (S,G) and (S,G,rpt) state.
The (S,G,rpt) prune Override Timer expires The (S,G,rpt) prune Override Timer expires
This event is only relevant in the "NotPruned" state. This event is only relevant in the "NotPruned" state.
When the Override Timer expires, we must send a Join(S,G,rpt) to When the Override Timer expires, we must send a
RPF'(S,G,rpt) to override the Prune message that caused the timer Join(S,G,rpt) to RPF'(S,G,rpt) to override the Prune message
to be running. We only send this if RPF'(S,G,rpt) equals that caused the timer to be running. We only send this if
RPF'(*,G); if this were not the case, then the Join might be sent RPF'(S,G,rpt) equals RPF'(*,G); if this were not the case,
to a router that does not have (*,G) Join state, and so the then the Join might be sent to a router that does not have
behavior would not be well defined. If RPF'(S,G,rpt) is not the (*,G) Join state, and so the behavior would not be well
same as RPF'(*,G), then it may stop forwarding S. However, if defined. If RPF'(S,G,rpt) is not the same as RPF'(*,G),
this happens, then the router will send an AssertCancel(S,G), then it may stop forwarding S. However, if this happens,
which would then cause RPF'(S,G,rpt) to become equal to RPF'(*,G) then the router will send an AssertCancel(S,G), which would
(see below). then cause RPF'(S,G,rpt) to become equal to RPF'(*,G) (see
below).
RPF'(S,G,rpt) changes to become equal to RPF'(*,G) RPF'(S,G,rpt) changes to become equal to RPF'(*,G)
This event is only relevant in the "NotPruned" state. This event is only relevant in the "NotPruned" state.
RPF'(S,G,rpt) can only be different from RPF'(*,G) if an (S,G) RPF'(S,G,rpt) can only be different from RPF'(*,G) if an
Assert has happened, which means that traffic from S is arriving (S,G) Assert has happened, which means that traffic from S
on the SPT, and so Prune(S,G,rpt) will have been sent to is arriving on the SPT, and so Prune(S,G,rpt) will have been
RPF'(*,G). When RPF'(S,G,rpt) changes to become equal to sent to RPF'(*,G). When RPF'(S,G,rpt) changes to become
RPF'(*,G), we need to trigger a Join(S,G,rpt) to RPF'(*,G) to equal to RPF'(*,G), we need to trigger a Join(S,G,rpt) to
cause that router to start forwarding S again. RPF'(*,G) to cause that router to start forwarding S again.
The action is to set the (S,G,rpt) Override Timer to the The action is to set the (S,G,rpt) Override Timer to the
randomized prune-override interval t_override. However, if the randomized prune-override interval t_override. However, if
timer is already running, we only set the timer if doing so would the timer is already running, we only set the timer if doing
set it to a lower value. At the end of this interval, if no one so would set it to a lower value. At the end of this
else has sent a Join, then we will do so. interval, if no one else has sent a Join, then we will
do so.
PruneDesired(S,G,rpt)->TRUE PruneDesired(S,G,rpt)->TRUE
See macro above. This event is relevant in the "NotPruned" and See macro above. This event is relevant in the "NotPruned"
"RPTNotJoined(G)" states. and "RPTNotJoined(G)" states.
The router wishes to receive traffic for G, but does not wish to The router wishes to receive traffic for G but does not wish
receive traffic from S destined for G. This causes the router to to receive traffic from S destined for G. This causes the
transition into the Pruned state. router to transition into the Pruned state.
If the router was previously in NotPruned state, then the action If the router was previously in NotPruned state, then the
is to send a Prune(S,G,rpt) to RPF'(S,G,rpt), and to cancel the action is to send a Prune(S,G,rpt) to RPF'(S,G,rpt), and to
Override Timer. If the router was previously in RPTNotJoined(G) cancel the Override Timer. If the router was previously in
state, then there is no need to trigger an action in this state RPTNotJoined(G) state, then there is no need to trigger an
machine because sending a Prune(S,G,rpt) is handled by the rules action in this state machine because sending a
for sending the Join(*,G). Prune(S,G,rpt) is handled by the rules for sending the
Join(*,G).
PruneDesired(S,G,rpt)->FALSE PruneDesired(S,G,rpt)->FALSE
See macro above. This transition is only relevant in the "Pruned" See macro above. This transition is only relevant in the
state. "Pruned" state.
If the router is in the Pruned(S,G,rpt) state, and If the router is in the Pruned(S,G,rpt) state, and
PruneDesired(S,G,rpt) changes to FALSE, this could be because the PruneDesired(S,G,rpt) changes to FALSE, this could be
router no longer has RPTJoinDesired(G) true, or it now wishes to because the router no longer has RPTJoinDesired(G) true, or
receive traffic from S again. If it is the former, then this it now wishes to receive traffic from S again. If it is the
transition should not happen, but instead the former, then this transition should not happen, but instead
"RPTJoinDesired(G)->FALSE" transition should happen. Thus, this the "RPTJoinDesired(G)->FALSE" transition should happen.
transition should be interpreted as "PruneDesired(S,G,rpt)->FALSE Thus, this transition should be interpreted as
AND RPTJoinDesired(G)==TRUE". "PruneDesired(S,G,rpt)->FALSE AND RPTJoinDesired(G)==TRUE".
The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt). The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).
RPTJoinDesired(G)->FALSE RPTJoinDesired(G)->FALSE
This event is relevant in the "Pruned" and "NotPruned" states. This event is relevant in the "Pruned" and "NotPruned"
states.
The router no longer wishes to receive any traffic destined for G The router no longer wishes to receive any traffic destined
on the RP Tree. This causes a transition to the RPTNotJoined(G) for G on the RP Tree. This causes a transition to the
state, and the Override Timer is canceled if it was running. Any RPTNotJoined(G) state, and the Override Timer is canceled if
further actions are handled by the appropriate upstream state it was running. Any further actions are handled by the
machine for (*,G). appropriate upstream state machine for (*,G).
inherited_olist(S,G,rpt) becomes non-NULL inherited_olist(S,G,rpt) becomes non-NULL
This transition is only relevant in the RPTNotJoined(G) state. This transition is only relevant in the RPTNotJoined(G)
state.
The router has joined the RP tree (handled by the (*,G) upstream The router has joined the RP tree (handled by the (*,G)
state machine as appropriate) and wants to receive traffic from S. upstream state machine as appropriate) and wants to receive
This does not trigger any events in this state machine, but traffic from S. This does not trigger any events in this
causes a transition to the NotPruned(S,G,rpt) state. state machine, but causes a transition to the
NotPruned(S,G,rpt) state.
4.6. PIM Assert Messages 4.6. PIM Assert Messages
Where multiple PIM routers peer over a shared LAN, it is possible for Where multiple PIM routers peer over a shared LAN, it is possible for
more than one upstream router to have valid forwarding state for a more than one upstream router to have valid forwarding state for a
packet, which can lead to packet duplication (see Section 3.6). PIM packet, which can lead to packet duplication (see Section 3.6). PIM
does not attempt to prevent this from occurring. Instead, it detects does not attempt to prevent this from occurring. Instead, it detects
when this has happened and elects a single forwarder amongst the when this has happened and elects a single forwarder amongst the
upstream routers to prevent further duplication. This election is upstream routers to prevent further duplication. This election is
performed using PIM Assert messages. Assert messages are also performed using PIM Assert messages. Assert messages are also
received by downstream routers on the LAN, and these cause subsequent received by downstream routers on the LAN, and these cause subsequent
Join/Prune messages to be sent to the upstream router that won the Join/Prune messages to be sent to the upstream router that won the
Assert. Assert.
In general, a PIM Assert message should only be accepted for In general, a PIM Assert message should only be accepted for
processing if it comes from a known PIM neighbor. A PIM router hears processing if it comes from a known PIM neighbor. A PIM router hears
about PIM neighbors through PIM Hello messages. If a router receives about PIM neighbors through PIM Hello messages. If a router receives
an Assert message from a particular IP source address and it has not an Assert message from a particular IP source address and it has not
seen a PIM Hello message from that source address, then the Assert seen a PIM Hello message from that source address, then the Assert
message SHOULD be discarded without further processing. In addition, message SHOULD be discarded without further processing. In addition,
if the Hello message from a neighbor was authenticated (see Section if the Hello message from a neighbor was authenticated (see
6.3), then all Assert messages from that neighbor MUST also be Section 6.3), then all Assert messages from that neighbor MUST also
authenticated. be authenticated.
We note that some older PIM implementations incorrectly fail to send We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND Hello messages on point-to-point interfaces, so we also RECOMMEND
that a configuration option be provided to allow interoperation with that a configuration option be provided to allow interoperation with
such older routers, but that this configuration option SHOULD NOT be such older routers, but that this configuration option SHOULD NOT be
enabled by default. enabled by default.
4.6.1. (S,G) Assert Message State Machine 4.6.1. (S,G) Assert Message State Machine
The (S,G) Assert state machine for interface I is shown in Figure 8. The (S,G) Assert state machine for interface I is shown in Figure 8.
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
responsible for forwarding traffic from S destined for G out of now responsible for forwarding traffic from S destined for G
interface I. Irrespective of whether it is the DR for I, while a out of interface I. Irrespective of whether it is the DR
router is the assert winner, it is also responsible for forwarding for I, while a router is the assert winner, it is also
traffic onto I on behalf of local hosts on I that have made responsible for forwarding traffic onto I on behalf of local
membership requests that specifically refer to S (and G). hosts on I that have made membership requests that
specifically refer to S (and G).
I am Assert Loser (L) I am Assert Loser (L)
This router has lost an (S,G) assert on interface I. It must not This router has lost an (S,G) assert on interface I. It
forward packets from S destined for G onto interface I. If it is must not forward packets from S destined for G onto
the DR on I, it is no longer responsible for forwarding traffic interface I. If it is the DR on I, it is no longer
onto I to satisfy local hosts with membership requests that responsible for forwarding traffic onto I to satisfy local
specifically refer to S and G. hosts with membership requests that specifically refer to S
and G.
In addition, there is also an Assert Timer (AT) that is used to time In addition, there is also an Assert Timer (AT) that is used to
out asserts on the assert losers and to resend asserts on the assert time out asserts on the assert losers and to resend asserts on the
winner. assert winner.
Figure 8: Per-interface (S,G) Assert State machine in tabular form Figure 8: Per-Interface (S,G) Assert State Machine
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
+---------------+-------------------+------------------+---------------+ +---------------+-------------------+------------------+---------------+
| Receive | Receive Assert | Data arrives | Receive | | Receive | Receive Assert | Data arrives | Receive |
| Inferior | with RPTbit | from S to G on | Acceptable | | Inferior | with RPTbit | from S to G on | Acceptable |
| Assert with | set and | I and | Assert with | | Assert with | set and | I and | Assert with |
| RPTbit clear | CouldAssert | CouldAssert | RPTbit clear | | RPTbit clear | CouldAssert | CouldAssert | RPTbit clear |
| | (S,G,I) | (S,G,I) | and AssTrDes | | | (S,G,I) | (S,G,I) | and AssTrDes |
| | | | (S,G,I) | | | | | (S,G,I) |
skipping to change at page 74, line 12 skipping to change at page 79, line 34
An "acceptable assert" is one that has a better metric than An "acceptable assert" is one that has a better metric than
my_assert_metric(S,G,I). An assert is never considered acceptable my_assert_metric(S,G,I). An assert is never considered acceptable
if its metric is infinite. if its metric is infinite.
An "inferior assert" is one with a worse metric than An "inferior assert" is one with a worse metric than
my_assert_metric(S,G,I). An assert is never considered inferior my_assert_metric(S,G,I). An assert is never considered inferior
if my_assert_metric(S,G,I) is infinite. if my_assert_metric(S,G,I) is infinite.
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(S,G,I) = CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I) AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) ) AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G) (-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) ) (+) joins(S,G) (+) pim_include(S,G) ) )
CouldAssert(S,G,I) is true for downstream interfaces that would be in CouldAssert(S,G,I) is true for downstream interfaces that would be in
the inherited_olist(S,G) if (S,G) assert information was not taken the inherited_olist(S,G) if (S,G) assert information was not taken
into account. into account.
AssertTrackingDesired(S,G,I) = AssertTrackingDesired(S,G,I) =
(I in ( joins(*,G) (-) prunes(S,G,rpt) (I in ( joins(*,G) (-) prunes(S,G,rpt)
(+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G) (-) lost_assert(*,G)
(+) joins(S,G) ) ) (+) joins(S,G) ) )
OR (local_receiver_include(S,G,I) == TRUE OR (local_receiver_include(S,G,I) == TRUE
AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me))) AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me)))
OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE)) OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE))
OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE) OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE)
AND (SPTbit(S,G) == FALSE)) AND (SPTbit(S,G) == FALSE))
AssertTrackingDesired(S,G,I) is true on any interface in which an AssertTrackingDesired(S,G,I) is true on any interface in which an
(S,G) assert might affect our behavior. (S,G) assert might affect the router's behavior on that interface.
The first three lines of AssertTrackingDesired account for (*,G) join The first three lines of AssertTrackingDesired account for (*,G) join
and local membership information received on I that might cause the and local membership information received on I that might cause the
router to be interested in asserts on I. router to be interested in asserts on I.
The 4th line accounts for (S,G) join information received on I that The 4th line accounts for (S,G) join information received on I that
might cause the router to be interested in asserts on I. might cause the router to be interested in asserts on I.
The 5th and 6th lines account for (S,G) local membership information The 5th and 6th lines account for (S,G) local membership information
on I. Note that we can't use the pim_include(S,G) macro since it on I. Note that we can't use the pim_include(S,G) macro, since it
uses lost_assert(S,G,I) and would result in the router forgetting uses lost_assert(S,G,I) and would result in the router forgetting
that it lost an assert if the only reason it was interested was local that it lost an assert if the only reason it was interested was local
membership. The AssertWinner(S,G,I) check forces an assert winner to membership. The AssertWinner(S,G,I) check forces an assert winner to
keep on being responsible for forwarding as long as local receivers keep on being responsible for forwarding as long as local receivers
are present. Removing this check would make the assert winner give are present. Removing this check would make the assert winner
up forwarding as soon as the information that originally caused it to give up forwarding as soon as the information that originally caused
forward went away, and the task of forwarding for local receivers it to forward went away, and the task of forwarding for local
would revert back to the DR. receivers would revert back to the DR.
The last three lines account for the fact that a router must keep The last three lines account for the fact that a router must keep
track of assert information on upstream interfaces in order to send track of assert information on upstream interfaces in order to send
joins and prunes to the proper neighbor. joins and prunes to the proper neighbor.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following events may trigger transitions: When in NoInfo state, the following events may trigger transitions:
Receive Inferior Assert with RPTbit cleared Receive Inferior Assert with RPTbit cleared
An assert is received for (S,G) with the RPT bit cleared that An assert is received for (S,G) with the RPT bit cleared
is inferior to our own assert metric. The RPT bit cleared that is inferior to our own assert metric. The RPT bit
indicates that the sender of the assert had (S,G) forwarding cleared indicates that the sender of the assert had (S,G)
state on this interface. If the assert is inferior to our forwarding state on this interface. If the assert is
metric, then we must also have (S,G) forwarding state (i.e., inferior to our metric, then we must also have (S,G)
CouldAssert(S,G,I)==TRUE) as (S,G) asserts beat (*,G) asserts, forwarding state (i.e., CouldAssert(S,G,I)==TRUE) as (S,G)
and so we should be the assert winner. We transition to the asserts have priority over (*,G) asserts, and so we should
"I am Assert Winner" state and perform Actions A1 (below). be the assert winner. We transition to the "I am Assert
Winner" state and perform Actions A1 (below).
Receive Assert with RPTbit set AND CouldAssert(S,G,I)==TRUE Receive Assert with RPTbit set AND CouldAssert(S,G,I)==TRUE
An assert is received for (S,G) on I with the RPT bit set An assert is received for (S,G) on I with the RPT bit set
(it's a (*,G) assert). CouldAssert(S,G,I) is TRUE only if we (it is a (*,G) assert). CouldAssert(S,G,I) is TRUE only if
have (S,G) forwarding state on this interface, so we should be we have (S,G) forwarding state on this interface, so we
the assert winner. We transition to the "I am Assert Winner" should be the assert winner. We transition to the "I am
state and perform Actions A1 (below). Assert Winner" state and perform Actions A1 (below).
An (S,G) data packet arrives on interface I, AND An (S,G) data packet arrives on interface I, AND
CouldAssert(S,G,I)==TRUE CouldAssert(S,G,I)==TRUE
An (S,G) data packet arrived on a downstream interface that is An (S,G) data packet arrived on a downstream interface that
in our (S,G) outgoing interface list. We optimistically is in our (S,G) outgoing interface list. We optimistically
assume that we will be the assert winner for this (S,G), and assume that we will be the assert winner for this (S,G), and
so we transition to the "I am Assert Winner" state and perform so we transition to the "I am Assert Winner" state and
Actions A1 (below), which will initiate the assert negotiation perform Actions A1 (below), which will initiate the assert
for (S,G). negotiation for (S,G).
Receive Acceptable Assert with RPT bit clear AND Receive Acceptable Assert with RPT bit clear AND
AssertTrackingDesired(S,G,I)==TRUE AssertTrackingDesired(S,G,I)==TRUE
We're interested in (S,G) Asserts, either because I is a We're interested in (S,G) Asserts, either because I is a
downstream interface for which we have (S,G) or (*,G) downstream interface for which we have (S,G) or (*,G)
forwarding state, or because I is the upstream interface for S forwarding state, or because I is the upstream interface for
and we have (S,G) forwarding state. The received assert has a S and we have (S,G) forwarding state. The received assert
better metric than our own, so we do not win the Assert. We has a better metric than our own, so we do not win the
transition to "I am Assert Loser" and perform Actions A6 Assert. We transition to "I am Assert Loser" and perform
(below). Actions A6 (below).
Transitions from "I am Assert Winner" State Transitions from "I am Assert 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:
Assert Timer Expires Assert Timer Expires
The (S,G) Assert Timer expires. As we're in the Winner state, The (S,G) Assert Timer expires. As we're in the Winner
we must still have (S,G) forwarding state that is actively state, we must still have (S,G) forwarding state that is
being kept alive. We resend the (S,G) Assert and restart the actively being kept alive. We resend the (S,G) Assert and
Assert Timer (Actions A3 below). Note that the assert restart the Assert Timer (Actions A3 below). Note that the
winner's Assert Timer is engineered to expire shortly before assert winner's Assert Timer is engineered to expire shortly
timers on assert losers; this prevents unnecessary thrashing before timers on assert losers; this prevents unnecessary
of the forwarder and periodic flooding of duplicate packets. thrashing of the forwarder and periodic flooding of
duplicate packets.
Receive Inferior Assert Receive Inferior Assert
We receive an (S,G) assert or (*,G) assert mentioning S that We receive an (S,G) assert or (*,G) assert mentioning S that
has a worse metric than our own. Whoever sent the assert is has a worse metric than our own. Whoever sent the assert is
in error, and so we resend an (S,G) Assert and restart the in error, and so we resend an (S,G) Assert and restart the
Assert Timer (Actions A3 below). Assert Timer (Actions A3 below).
Receive Preferred Assert Receive Preferred Assert
We receive an (S,G) assert that has a better metric than our We receive an (S,G) assert that has a better metric than our
own. We transition to "I am Assert Loser" state and perform own. We transition to "I am Assert Loser" state and perform
Actions A2 (below). Note that this may affect the value of Actions A2 (below). Note that this may affect the value of
JoinDesired(S,G) and PruneDesired(S,G,rpt), which could cause JoinDesired(S,G) and PruneDesired(S,G,rpt), which could
transitions in the upstream (S,G) or (S,G,rpt) state machines. cause transitions in the upstream (S,G) or (S,G,rpt) state
machines.
CouldAssert(S,G,I) -> FALSE CouldAssert(S,G,I) -> FALSE
Our (S,G) forwarding state or RPF interface changed so as to Our (S,G) forwarding state or RPF interface changed so as to
make CouldAssert(S,G,I) become false. We can no longer make CouldAssert(S,G,I) become false. We can no longer
perform the actions of the assert winner, and so we transition perform the actions of the assert winner, and so we
to NoInfo state and perform Actions A4 (below). This includes transition to NoInfo state and perform Actions A4 (below).
sending a "canceling assert" with an infinite metric. This includes sending a "canceling assert" with an infinite
metric.
Transitions from "I am Assert Loser" State Transitions from "I am Assert Loser" State
When in "I am Assert Loser" state, the following transitions can When in "I am Assert Loser" state, the following transitions can
occur: occur:
Receive Preferred Assert Receive Preferred Assert
We receive an assert that is better than that of the current We receive an assert that is better than that of the current
assert winner. We stay in Loser state and perform Actions A2 assert winner. We stay in Loser state and perform
below. Actions A2 below.
Receive Acceptable Assert with RPTbit clear from Current Winner Receive Acceptable Assert with RPTbit clear from Current Winner
We receive an assert from the current assert winner that is We receive an assert from the current assert winner that is
better than our own metric for this (S,G) (although the metric better than our own metric for this (S,G) (although the
may be worse than the winner's previous metric). We stay in metric may be worse than the winner's previous metric). We
Loser state and perform Actions A2 below. stay in Loser state and perform Actions A2 below.
Receive Inferior Assert or Assert Cancel from Current Winner Receive Inferior Assert or Assert Cancel from Current Winner
We receive an assert from the current assert winner that is We receive an assert from the current assert winner that is
worse than our own metric for this group (typically, because worse than our own metric for this group (typically, because
the winner's metric became worse or because it is an assert the winner's metric became worse or because it is an assert
cancel). We transition to NoInfo state, deleting the (S,G) cancel). We transition to NoInfo state, deleting the (S,G)
assert information and allowing the normal PIM Join/Prune assert information and allowing the normal PIM Join/Prune
mechanisms to operate. Usually, we will eventually re-assert mechanisms to operate. Usually, we will eventually
and win when data packets from S have started flowing again. re-assert and win when data packets from S have started
flowing again.
Assert Timer Expires Assert Timer Expires
The (S,G) Assert Timer expires. We transition to NoInfo The (S,G) Assert Timer expires. We transition to NoInfo
state, deleting the (S,G) assert information (Actions A5 state, deleting the (S,G) assert information (Actions A5
below). below).
Current Winner's GenID Changes or NLT Expires Current Winner's GenID Changes or NLT Expires
The Neighbor Liveness Timer associated with the current winner The Neighbor Liveness Timer associated with the current
expires or we receive a Hello message from the current winner winner expires or we receive a Hello message from the
reporting a different GenID from the one it previously current winner reporting a different GenID from the one it
reported. This indicates that the current winner's interface previously reported. This indicates that the current
or router has gone down (and may have come back up), and so we winner's interface or router has gone down (and may have
must assume it no longer knows it was the winner. We come back up), and so we must assume that it no longer knows
transition to the NoInfo state, deleting this (S,G) assert it was the winner. We transition to the NoInfo state,
information (Actions A5 below). deleting this (S,G) assert information (Actions A5 below).
AssertTrackingDesired(S,G,I)->FALSE AssertTrackingDesired(S,G,I)->FALSE
AssertTrackingDesired(S,G,I) becomes FALSE. Our forwarding AssertTrackingDesired(S,G,I) becomes FALSE. Our forwarding
state has changed so that (S,G) Asserts on interface I are no state has changed so that (S,G) Asserts on interface I are
longer of interest to us. We transition to the NoInfo state, no longer of interest to us. We transition to the NoInfo
deleting the (S,G) assert information. state, deleting the (S,G) assert information.
My metric becomes better than the assert winner's metric My metric becomes better than the assert winner's metric
my_assert_metric(S,G,I) has changed so that now my assert my_assert_metric(S,G,I) has changed so that now my assert
metric for (S,G) is better than the metric we have stored for metric for (S,G) is better than the metric we have stored
current assert winner. This might happen when the underlying for the current assert winner. This might happen when the
routing metric changes, or when CouldAssert(S,G,I) becomes underlying routing metric changes, or when
true; for example, when SPTbit(S,G) becomes true. We CouldAssert(S,G,I) becomes true, for example, when
transition to NoInfo state, delete this (S,G) assert state SPTbit(S,G) becomes true. We transition to NoInfo state,
(Actions A5 below), and allow the normal PIM Join/Prune delete this (S,G) assert state (Actions A5 below), and allow
mechanisms to operate. Usually, we will eventually re-assert the normal PIM Join/Prune mechanisms to operate. Usually,
and win when data packets from S have started flowing again. we will eventually re-assert and win when data packets from
S have started flowing again.
RPF_interface(S) stops being interface I RPF_interface(S) stops being interface I
Interface I used to be the RPF interface for S, and now it is Interface I used to be the RPF interface for S, and now it
not. We transition to NoInfo state, deleting this (S,G) is not. We transition to NoInfo state, deleting this (S,G)
assert state (Actions A5 below). assert state (Actions A5 below).
Receive Join(S,G) on Interface I Receive Join(S,G) on Interface I
We receive a Join(S,G) that has the Upstream Neighbor Address We receive a Join(S,G) that has the Upstream Neighbor
field set to my primary IP address on interface I. The action Address field set to my primary IP address on interface I.
is to transition to NoInfo state, delete this (S,G) assert The action is to transition to NoInfo state, delete this
state (Actions A5 below), and allow the normal PIM Join/Prune (S,G) assert state (Actions A5 below), and allow the normal
mechanisms to operate. If whoever sent the Join was in error, PIM Join/Prune mechanisms to operate. If whoever sent the
then the normal assert mechanism will eventually re-apply, and Join was in error, then the normal assert mechanism will
we will lose the assert again. However, whoever sent the eventually re-apply, and we will lose the assert again.
assert may know that the previous assert winner has died, and However, whoever sent the assert may know that the previous
so we may end up being the new forwarder. assert winner has died, and so we may end up being the new
forwarder.
(S,G) Assert State machine Actions (S,G) Assert State Machine Actions
A1: Send Assert(S,G). A1: Send Assert(S,G).
Set Assert Timer to (Assert_Time - Assert_Override_Interval). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
Store self as AssertWinner(S,G,I). Store self as AssertWinner(S,G,I).
Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I). Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I).
A2: Store new assert winner as AssertWinner(S,G,I) and assert A2: Store new assert winner as AssertWinner(S,G,I) and assert
winner metric as AssertWinnerMetric(S,G,I). winner metric as AssertWinnerMetric(S,G,I).
Set Assert Timer to Assert_Time. Set Assert Timer to Assert_Time.
A3: Send Assert(S,G). A3: Send Assert(S,G).
Set Assert Timer to (Assert_Time - Assert_Override_Interval). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A4: Send AssertCancel(S,G). A4: Send AssertCancel(S,G).
Delete assert info (AssertWinner(S,G,I) and Delete assert information (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return to their default AssertWinnerMetric(S,G,I) will then return to their default
values). values).
A5: Delete assert info (AssertWinner(S,G,I) and A5: Delete assert information (AssertWinner(S,G,I) and
AssertWinnerMetric(S,G,I) will then return to their default AssertWinnerMetric(S,G,I) will then return to their default
values). values).
A6: Store new assert winner as AssertWinner(S,G,I) and assert A6: Store new assert winner as AssertWinner(S,G,I) and assert
winner metric as AssertWinnerMetric(S,G,I). winner metric as AssertWinnerMetric(S,G,I).
Set Assert Timer to Assert_Time. Set Assert Timer to Assert_Time.
If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) == If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) ==
Joined) set SPTbit(S,G) to TRUE. Joined) set SPTbit(S,G) to TRUE.
Note that some of these actions may cause the value of Note that some of these actions may cause the value of
JoinDesired(S,G), PruneDesired(S,G,rpt), or RPF'(S,G) to change, JoinDesired(S,G), PruneDesired(S,G,rpt), or RPF'(S,G) to change,
which could cause further transitions in other state machines. which could cause further transitions in other state machines.
4.6.2. (*,G) Assert Message State Machine 4.6.2. (*,G) Assert Message State Machine
The (*,G) Assert state machine for interface I is shown in Figure 9. The (*,G) Assert state machine for interface I is shown in Figure 9.
There are three states: There are three states:
NoInfo (NI) NoInfo (NI)
This router has no (*,G) assert state on interface I. This router has no (*,G) assert state on interface I.
I am Assert Winner (W) I am Assert Winner (W)
This router has won an (*,G) assert on interface I. It is now This router has won a (*,G) assert on interface I. It is
responsible for forwarding traffic destined for G onto interface I now responsible for forwarding traffic destined for G onto
with the exception of traffic for which it has (S,G) "I am Assert interface I with the exception of traffic for which it has
Loser" state. Irrespective of whether it is the DR for I, it is (S,G) "I am Assert Loser" state. Irrespective of whether it
also responsible for handling the membership requests for G from is the DR for I, it is also responsible for handling the
local hosts on I. membership requests for G from local hosts on I.
I am Assert Loser (L) I am Assert Loser (L)
This router has lost an (*,G) assert on interface I. It must not This router has lost a (*,G) assert on interface I. It must
forward packets for G onto interface I with the exception of not forward packets for G onto interface I with the
traffic from sources for which it has (S,G) "I am Assert Winner" exception of traffic from sources for which it has (S,G) "I
state. If it is the DR, it is no longer responsible for handling am Assert Winner" state. If it is the DR, it is no longer
the membership requests for group G from local hosts on I. responsible for handling the membership requests for group G
from local hosts on I.
In addition, there is also an Assert Timer (AT) that is used to time In addition, there is also an Assert Timer (AT) that is used to time
out asserts on the assert losers and to resend asserts on the assert out asserts on the assert losers and to resend asserts on the assert
winner. winner.
When an Assert message is received with a source address other than When an Assert message is received with a source address other than
zero, a PIM implementation must first match it against the possible zero, a PIM implementation must first match it against the possible
events in the (S,G) assert state machine and process any transitions events in the (S,G) assert state machine and process any transitions
and actions, before considering whether the Assert message matches and actions, before considering whether the Assert message matches
against the (*,G) assert state machine. against the (*,G) assert state machine.
skipping to change at page 80, line 20 skipping to change at page 87, line 5
Another example: if the (S,G) assert state machine is in "L" state Another example: if the (S,G) assert state machine is in "L" state
when an assert message is received, and the assert metric in the when an assert message is received, and the assert metric in the
message is worse than my_assert_metric(S,G,I), then the (S,G) assert message is worse than my_assert_metric(S,G,I), then the (S,G) assert
state machine will transition to NoInfo state. In such a case, if state machine will transition to NoInfo state. In such a case, if
the (*,G) assert state machine were in NoInfo state, it might appear the (*,G) assert state machine were in NoInfo state, it might appear
that it would transition to "W" state, but this is not the case that it would transition to "W" state, but this is not the case
because this message already triggered a transition in the (S,G) because this message already triggered a transition in the (S,G)
assert state machine. assert state machine.
Figure 9: Per-interface (*,G) Assert State machine in tabular form Figure 9: Per-Interface (*,G) Assert State Machine
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| In NoInfo (NI) State | | In NoInfo (NI) State |
+-----------------------+-----------------------+----------------------+ +-----------------------+-----------------------+----------------------+
| Receive Inferior | Data arrives for G | Receive Acceptable | | Receive Inferior | Data arrives for G | Receive Acceptable |
| Assert with RPTbit | on I and | Assert with RPTbit | | Assert with RPTbit | on I and | Assert with RPTbit |
| set and | CouldAssert | set and AssTrDes | | set and | CouldAssert | set and AssTrDes |
| CouldAssert(*,G,I) | (*,G,I) | (*,G,I) | | CouldAssert(*,G,I) | (*,G,I) | (*,G,I) |
+-----------------------+-----------------------+----------------------+ +-----------------------+-----------------------+----------------------+
| -> W state | -> W state | -> L state | | -> W state | -> W state | -> L state |
skipping to change at page 81, line 33 skipping to change at page 88, line 18
| (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) on | | (*,G,I) -> | better than | (RP(G)) stops | Join(*,G) on |
| FALSE | Winner's | being I | Interface I | | FALSE | Winner's | being I | Interface I |
| | metric | | | | | metric | | |
+----------------+----------------+-----------------+------------------+ +----------------+----------------+-----------------+------------------+
| -> NI state | -> NI state | -> NI state | -> NI State | | -> NI state | -> NI state | -> NI state | -> NI State |
| [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] | | [Actions A5] | [Actions A5] | [Actions A5] | [Actions A5] |
+----------------+----------------+-----------------+------------------+ +----------------+----------------+-----------------+------------------+
The state machine uses the following macros: The state machine uses the following macros:
CouldAssert(*,G,I) = CouldAssert(*,G,I) =
( I in ( joins(*,G) (+) pim_include(*,G)) ) ( I in ( joins(*,G) (+) pim_include(*,G)) )
AND (RPF_interface(RP(G)) != I) AND (RPF_interface(RP(G)) != I)
CouldAssert(*,G,I) is true on downstream interfaces for which we have CouldAssert(*,G,I) is true on downstream interfaces for which we have
(*,G) join state, or local members that requested any traffic (*,G) join state, or local members that requested any traffic
destined for G. destined for G.
AssertTrackingDesired(*,G,I) = AssertTrackingDesired(*,G,I) =
CouldAssert(*,G,I) CouldAssert(*,G,I)
OR (local_receiver_include(*,G,I)==TRUE OR (local_receiver_include(*,G,I)==TRUE
AND (I_am_DR(I) OR AssertWinner(*,G,I) == me)) AND (I_am_DR(I) OR AssertWinner(*,G,I) == me))
OR (RPF_interface(RP(G)) == I AND RPTJoinDesired(G)) OR (RPF_interface(RP(G)) == I AND RPTJoinDesired(G))
AssertTrackingDesired(*,G,I) is true on any interface on which an AssertTrackingDesired(*,G,I) is true on any interface on which a
(*,G) assert might affect our behavior. (*,G) assert might affect the router's behavior on that interface.
Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in
the state machine table to refer to AssertTrackingDesired(*,G,I). the state machine table to refer to AssertTrackingDesired(*,G,I).
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. winner.
An "acceptable assert" is one that has a better metric than An "acceptable assert" is one that has a better metric than
skipping to change at page 82, line 24 skipping to change at page 89, line 11
An "inferior assert" is one with a worse metric than An "inferior assert" is one with a worse metric than
my_assert_metric(*,G,I). An assert is never considered inferior my_assert_metric(*,G,I). An assert is never considered inferior
if my_assert_metric(*,G,I) is infinite. if my_assert_metric(*,G,I) is infinite.
Transitions from NoInfo State Transitions from NoInfo State
When in NoInfo state, the following events trigger transitions, but When in NoInfo state, the following events trigger transitions, but
only if the (S,G) assert state machine is in NoInfo state before and only if the (S,G) assert state machine is in NoInfo state before and
after consideration of the received message: after consideration of the received message:
Receive Inferior Assert with RPTbit set AND Receive Inferior Assert with RPTbit set AND
CouldAssert(*,G,I)==TRUE CouldAssert(*,G,I)==TRUE
An Inferior (*,G) assert is received for G on Interface I. If An Inferior (*,G) assert is received for G on Interface I.
CouldAssert(*,G,I) is TRUE, then I is our downstream If CouldAssert(*,G,I) is TRUE, then I is our downstream
interface, and we have (*,G) forwarding state on this interface, and we have (*,G) forwarding state on this
interface, so we should be the assert winner. We transition interface, so we should be the assert winner. We transition
to the "I am Assert Winner" state and perform Actions A1 to the "I am Assert Winner" state and perform Actions A1
(below). (below).
A data packet destined for G arrives on interface I, AND A data packet destined for G arrives on interface I, AND
CouldAssert(*,G,I)==TRUE CouldAssert(*,G,I)==TRUE
A data packet destined for G arrived on a downstream interface A data packet destined for G arrived on a downstream
that is in our (*,G) outgoing interface list. We therefore interface that is in our (*,G) outgoing interface list. We
believe we should be the forwarder for this (*,G), and so we therefore believe we should be the forwarder for this (*,G),
transition to the "I am Assert Winner" state and perform and so we transition to the "I am Assert Winner" state and
Actions A1 (below). perform Actions A1 (below).
Receive Acceptable Assert with RPT bit set AND Receive Acceptable Assert with RPT bit set AND
AssertTrackingDesired(*,G,I)==TRUE AssertTrackingDesired(*,G,I)==TRUE
We're interested in (*,G) Asserts, either because I is a We're interested in (*,G) Asserts, either because I is a
downstream interface for which we have (*,G) forwarding state, downstream interface for which we have (*,G) forwarding
or because I is the upstream interface for RP(G) and we have state, or because I is the upstream interface for RP(G) and
(*,G) forwarding state. We get a (*,G) Assert that has a we have (*,G) forwarding state. We get a (*,G) Assert that
better metric than our own, so we do not win the Assert. We has a better metric than our own, so we do not win the
transition to "I am Assert Loser" and perform Actions A2 Assert. We transition to "I am Assert Loser" and perform
(below). Actions A2 (below).
Transitions from "I am Assert Winner" State Transitions from "I am Assert 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, but only if the (S,G) assert state machine is in NoInfo transitions, but only if the (S,G) assert state machine is in NoInfo
state before and after consideration of the received message: state before and after consideration of the received message:
Receive Inferior Assert Receive Inferior Assert
We receive a (*,G) assert that has a worse metric than our We receive a (*,G) assert that has a worse metric than our
own. Whoever sent the assert has lost, and so we resend a own. Whoever sent the assert has lost, and so we resend a
(*,G) Assert and restart the Assert Timer (Actions A3 below). (*,G) Assert and restart the Assert Timer (Actions A3
below).
Receive Preferred Assert Receive Preferred Assert
We receive a (*,G) assert that has a better metric than our We receive a (*,G) assert that has a better metric than our
own. We transition to "I am Assert Loser" state and perform own. We transition to "I am Assert Loser" state and perform
Actions A2 (below). Actions A2 (below).
When in "I am Assert Winner" state, the following events trigger When in "I am Assert Winner" state, the following events trigger
transitions: transitions:
Assert Timer Expires Assert Timer Expires
The (*,G) Assert Timer expires. As we're in the Winner state, The (*,G) Assert Timer expires. As we're in the Winner
then we must still have (*,G) forwarding state that is state, then we must still have (*,G) forwarding state that
actively being kept alive. To prevent unnecessary thrashing is actively being kept alive. To prevent unnecessary
of the forwarder and periodic flooding of duplicate packets, thrashing of the forwarder and periodic flooding of
we resend the (*,G) Assert and restart the Assert Timer duplicate packets, we resend the (*,G) Assert and restart
(Actions A3 below). the Assert Timer (Actions A3 below).
CouldAssert(*,G,I) -> FALSE CouldAssert(*,G,I) -> FALSE
Our (*,G) forwarding state or RPF interface changed so as to Our (*,G) forwarding state or RPF interface changed so as to
make CouldAssert(*,G,I) become false. We can no longer make CouldAssert(*,G,I) become false. We can no longer
perform the actions of the assert winner, and so we transition perform the actions of the assert winner, and so we
to NoInfo state and perform Actions A4 (below). transition to NoInfo state and perform Actions A4 (below).
Transitions from "I am Assert Loser" State Transitions from "I am Assert Loser" State
When in "I am Assert Loser" state, the following events trigger When in "I am Assert Loser" state, the following events trigger
transitions, but only if the (S,G) assert state machine is in NoInfo transitions, but only if the (S,G) assert state machine is in NoInfo
state before and after consideration of the received message: state before and after consideration of the received message:
Receive Preferred Assert with RPTbit set Receive Preferred Assert with RPTbit set
We receive a (*,G) assert that is better than that of the We receive a (*,G) assert that is better than that of the
current assert winner. We stay in Loser state and perform current assert winner. We stay in Loser state and perform
Actions A2 below. Actions A2 below.
Receive Acceptable Assert from Current Winner with RPTbit set Receive Acceptable Assert from Current Winner with RPTbit set
We receive a (*,G) assert from the current assert winner that We receive a (*,G) assert from the current assert winner
is better than our own metric for this group (although the that is better than our own metric for this group (although
metric may be worse than the winner's previous metric). We the metric may be worse than the winner's previous metric).
stay in Loser state and perform Actions A2 below. We stay in Loser state and perform Actions A2 below.
Receive Inferior Assert or Assert Cancel from Current Winner Receive Inferior Assert or Assert Cancel from Current Winner
We receive an assert from the current assert winner that is We receive an assert from the current assert winner that is
worse than our own metric for this group (typically because worse than our own metric for this group (typically because
the winner's metric became worse or is now an assert cancel). the winner's metric became worse or is now an assert
We transition to NoInfo state, delete this (*,G) assert state cancel). We transition to NoInfo state, delete this (*,G)
(Actions A5), and allow the normal PIM Join/Prune mechanisms assert state (Actions A5), and allow the normal PIM
to operate. Usually, we will eventually re-assert and win Join/Prune mechanisms to operate. Usually, we will
when data packets for G have started flowing again. eventually re-assert and win when data packets for G have
started flowing again.
When in "I am Assert Loser" state, the following events trigger When in "I am Assert Loser" state, the following events trigger
transitions: transitions:
Assert Timer Expires Assert Timer Expires
The (*,G) Assert Timer expires. We transition to NoInfo state The (*,G) Assert Timer expires. We transition to NoInfo
and delete this (*,G) assert info (Actions A5). state and delete this (*,G) assert information (Actions A5).
Current Winner's GenID Changes or NLT Expires Current Winner's GenID Changes or NLT Expires
The Neighbor Liveness Timer associated with the current winner The Neighbor Liveness Timer associated with the current
expires or we receive a Hello message from the current winner winner expires or we receive a Hello message from the
reporting a different GenID from the one it previously current winner reporting a different GenID from the one it
reported. This indicates that the current winner's interface previously reported. This indicates that the current
or router has gone down (and may have come back up), and so we winner's interface or router has gone down (and may have
must assume it no longer knows it was the winner. We come back up), and so we must assume that it no longer knows
transition to the NoInfo state, deleting the (*,G) assert it was the winner. We transition to the NoInfo state,
information (Actions A5). deleting the (*,G) assert information (Actions A5).
AssertTrackingDesired(*,G,I)->FALSE AssertTrackingDesired(*,G,I)->FALSE
AssertTrackingDesired(*,G,I) becomes FALSE. Our forwarding AssertTrackingDesired(*,G,I) becomes FALSE. Our forwarding
state has changed so that (*,G) Asserts on interface I are no state has changed so that (*,G) Asserts on interface I are
longer of interest to us. We transition to NoInfo state and no longer of interest to us. We transition to NoInfo state
delete this (*,G) assert info (Actions A5). and delete this (*,G) assert information (Actions A5).
My metric becomes better than the assert winner's metric My metric becomes better than the assert winner's metric
My routing metric, rpt_assert_metric(G,I), has changed so that My routing metric, rpt_assert_metric(G,I), has changed so
now my assert metric for (*,G) is better than the metric we that now my assert metric for (*,G) is better than the
have stored for current assert winner. We transition to metric we have stored for the current assert winner. We
NoInfo state, delete this (*,G) assert state (Actions A5), and transition to NoInfo state, delete this (*,G) assert state
allow the normal PIM Join/Prune mechanisms to operate. (Actions A5), and allow the normal PIM Join/Prune mechanisms
Usually, we will eventually re-assert and win when data to operate. Usually, we will eventually re-assert and win
packets for G have started flowing again. when data packets for G have started flowing again.
RPF_interface(RP(G)) stops being interface I RPF_interface(RP(G)) stops being interface I
Interface I used to be the RPF interface for RP(G), and now it Interface I used to be the RPF interface for RP(G), and now
is not. We transition to NoInfo state and delete this (*,G) it is not. We transition to NoInfo state and delete this
assert state (Actions A5). (*,G) assert state (Actions A5).
Receive Join(*,G) on interface I Receive Join(*,G) on interface I
We receive a Join(*,G) that has the Upstream Neighbor Address We receive a Join(*,G) that has the Upstream Neighbor
field set to my primary IP address on interface I. The action Address field set to my primary IP address on interface I.
is to transition to NoInfo state, delete this (*,G) assert The action is to transition to NoInfo state, delete this
state (Actions A5), and allow the normal PIM Join/Prune (*,G) assert state (Actions A5), and allow the normal PIM
mechanisms to operate. If whoever sent the Join was in error, Join/Prune mechanisms to operate. If whoever sent the Join
then the normal assert mechanism will eventually re-apply, and was in error, then the normal assert mechanism will
we will lose the assert again. However, whoever sent the eventually re-apply, and we will lose the assert again.
assert may know that the previous assert winner has died, so However, whoever sent the assert may know that the previous
we may end up being the new forwarder. assert winner has died, so we may end up being the new
forwarder.
(*,G) Assert State machine Actions (*,G) Assert State Machine Actions
A1: Send Assert(*,G). A1: Send Assert(*,G).
Set Assert Timer to (Assert_Time - Assert_Override_Interval). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
Store self as AssertWinner(*,G,I). Store self as AssertWinner(*,G,I).
Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I). Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I).
A2: Store new assert winner as AssertWinner(*,G,I) and assert A2: Store new assert winner as AssertWinner(*,G,I) and assert
winner metric as AssertWinnerMetric(*,G,I). winner metric as AssertWinnerMetric(*,G,I).
Set Assert Timer to Assert_Time. Set Assert Timer to Assert_Time.
A3: Send Assert(*,G) A3: Send Assert(*,G).
Set Assert Timer to (Assert_Time - Assert_Override_Interval). Set Assert Timer to (Assert_Time - Assert_Override_Interval).
A4: Send AssertCancel(*,G). A4: Send AssertCancel(*,G).
Delete assert info (AssertWinner(*,G,I) and Delete assert information (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return to their default AssertWinnerMetric(*,G,I) will then return to their default
values). values).
A5: Delete assert info (AssertWinner(*,G,I) and A5: Delete assert information (AssertWinner(*,G,I) and
AssertWinnerMetric(*,G,I) will then return to their default AssertWinnerMetric(*,G,I) will then return to their default
values). values).
Note that some of these actions may cause the value of Note that some of these actions may cause the value of
JoinDesired(*,G) or RPF'(*,G)) to change, which could cause further JoinDesired(*,G) or RPF'(*,G) to change, which could cause further
transitions in other state machines. transitions in other state machines.
4.6.3. Assert Metrics 4.6.3. Assert Metrics
Assert metrics are defined as: Assert metrics are defined as:
struct assert_metric { struct assert_metric {
rpt_bit_flag; rpt_bit_flag;
metric_preference; metric_preference;
route_metric; route_metric;
ip_address; ip_address;
}; };
When comparing assert_metrics, the rpt_bit_flag, metric_preference, When comparing assert_metrics, the rpt_bit_flag, metric_preference,
and route_metric field are compared in order, where the first lower and route_metric fields are compared in order, where the first lower
value wins. If all fields are equal, the primary IP address of the value wins. If all fields are equal, the primary IP address of the
router that sourced the Assert message is used as a tie-breaker, with router that sourced the Assert message is used as a tie-breaker, with
the highest IP address winning. the highest IP address winning.
An assert metric for (S,G) to include in (or compare against) an An assert metric for (S,G) to include in (or compare against) an
Assert message sent on interface I should be computed using the Assert message sent on interface I should be computed using the
following pseudocode: following pseudocode:
assert_metric assert_metric
my_assert_metric(S,G,I) { my_assert_metric(S,G,I) {
skipping to change at page 86, line 46 skipping to change at page 94, line 27
rpt_assert_metric(G,I) { rpt_assert_metric(G,I) {
return {1,MRIB.pref(RP(G)),MRIB.metric(RP(G)),my_ip_address(I)} return {1,MRIB.pref(RP(G)),MRIB.metric(RP(G)),my_ip_address(I)}
} }
MRIB.pref(X) and MRIB.metric(X) are the routing preference and MRIB.pref(X) and MRIB.metric(X) are the routing preference and
routing metrics associated with the route to a particular (unicast) routing metrics associated with the route to a particular (unicast)
destination X, as determined by the MRIB. my_ip_address(I) is simply destination X, as determined by the MRIB. my_ip_address(I) is simply
the router's primary IP address that is associated with the local the router's primary IP address that is associated with the local
interface I. interface I.
infinite_assert_metric() gives the assert metric we need to send an infinite_assert_metric() is an assert metric that the router uses for
assert but don't match either (S,G) or (*,G) forwarding state: an Assert that does not match either (S,G) or (*,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.4. AssertCancel Messages 4.6.4. AssertCancel Messages
An AssertCancel message is simply an RPT Assert message but with An AssertCancel message is simply an RPT Assert message but with an
infinite metric. It is sent by the assert winner when it deletes the infinite metric. It is sent by the assert winner when it deletes the
forwarding state that had caused the assert to occur. Other routers forwarding state that had caused the assert to occur. Other routers
will see this metric, and it will cause any other router that has will see this metric, and it will cause any other router that has
forwarding state to send its own assert, and to take over forwarding. forwarding state to send its own assert, and to take over forwarding.
An AssertCancel(S,G) is an infinite metric assert with the RPT bit An AssertCancel(S,G) is an infinite metric assert with the RPT bit
set that names S as the source. set that names S as the source.
An AssertCancel(*,G) is an infinite metric assert with the RPT bit An AssertCancel(*,G) is an infinite metric assert with the RPT bit
set and the source set to zero. set and the source set to zero.
skipping to change at page 87, line 34 skipping to change at page 95, line 15
AssertCancel messages are simply an optimization. The original AssertCancel messages are simply an optimization. The original
Assert timeout mechanism will allow a subnet to eventually become Assert timeout mechanism will allow a subnet to eventually become
consistent; the AssertCancel mechanism simply causes faster consistent; the AssertCancel mechanism simply causes faster
convergence. No special processing is required for an AssertCancel convergence. No special processing is required for an AssertCancel
message, since it is simply an Assert message from the current message, since it is simply an Assert message from the current
winner. winner.
4.6.5. Assert State Macros 4.6.5. Assert State Macros
The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and
lost_assert(*,G,I) are used in the olist computations of Section 4.1, lost_assert(*,G,I) are used in the olist computations of Section 4.1
and are defined as: and are defined as:
bool lost_assert(S,G,rpt,I) { bool lost_assert(S,G,rpt,I) {
if ( RPF_interface(RP(G)) == I OR if ( RPF_interface(RP(G)) == I OR
( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) { ( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) {
return FALSE return FALSE
} else { } else {
return ( AssertWinner(S,G,I) != NULL AND return ( AssertWinner(S,G,I) != NULL AND
AssertWinner(S,G,I) != me ) AssertWinner(S,G,I) != me )
} }
skipping to change at page 88, line 15 skipping to change at page 95, line 39
if ( RPF_interface(S) == I ) { if ( RPF_interface(S) == I ) {
return FALSE return FALSE
} else { } else {
return ( AssertWinner(S,G,I) != NULL AND return ( AssertWinner(S,G,I) != NULL AND
AssertWinner(S,G,I) != me AND AssertWinner(S,G,I) != me AND
(AssertWinnerMetric(S,G,I) is better (AssertWinnerMetric(S,G,I) is better
than spt_assert_metric(S,I) ) than spt_assert_metric(S,I) )
} }
} }
Note: the term "AssertWinnerMetric(S,G,I) is better than Note: The term "AssertWinnerMetric(S,G,I) is better than
spt_assert_metric(S,I)" is required to correctly handle the spt_assert_metric(S,I)" is required to correctly handle the
transition phase when a router has (S,G) join state, but has not yet transition phase when a router has (S,G) join state but has not yet
set the SPTbit. In this case, it needs to ignore the assert state if set the SPTbit. In this case, it needs to ignore the assert state if
it will win the assert once the SPTbit is set. it will win the assert once the SPTbit is set.
bool lost_assert(*,G,I) { bool lost_assert(*,G,I) {
if ( RPF_interface(RP(G)) == I ) { if ( RPF_interface(RP(G)) == I ) {
return FALSE return FALSE
} else { } else {
return ( AssertWinner(*,G,I) != NULL AND return ( AssertWinner(*,G,I) != NULL AND
AssertWinner(*,G,I) != me ) AssertWinner(*,G,I) != me )
} }
} }
skipping to change at page 89, line 24 skipping to change at page 96, line 39
to the reader in understanding and implementing this part of the to the reader in understanding and implementing this part of the
protocol. protocol.
1. Behavior: Downstream neighbors send Join(*,G) and Join(S,G) 1. Behavior: Downstream neighbors send Join(*,G) and Join(S,G)
periodic messages to the appropriate RPF' neighbor, i.e., the RPF periodic messages to the appropriate RPF' neighbor, i.e., the RPF
neighbor as modified by the assert process. They are not always neighbor as modified by the assert process. They are not always
sent to the RPF neighbor as indicated by the MRIB. Normal sent to the RPF neighbor as indicated by the MRIB. Normal
suppression and override rules apply. suppression and override rules apply.
Rationale: By sending the periodic and triggered Join messages to Rationale: By sending the periodic and triggered Join messages to
the RPF' neighbor instead of to the RPF neighbor, the downstream the RPF' neighbor instead of the RPF neighbor, the downstream
router avoids re-triggering the Assert process with every Join. router avoids re-triggering the Assert process with every Join.
A side effect of sending Joins to the Assert winner is that A side effect of sending Joins to the Assert winner is that
traffic will not switch back to the "normal" RPF neighbor until traffic will not switch back to the "normal" RPF neighbor until
the Assert times out. This will not happen until data stops the Assert times out. This will not happen until data stops
flowing, if item 8, below, is implemented. flowing, if item 8, below, is implemented.
2. Behavior: The assert winner for (*,G) acts as the local DR for 2. Behavior: The assert winner for (*,G) acts as the local DR for
(*,G) on behalf of IGMP/MLD members. (*,G) on behalf of IGMP/MLD members.
Rationale: This is required to allow a single router to merge PIM Rationale: This is required to allow a single router to merge
and IGMP/MLD joins and leaves. Without this, overrides don't PIM and IGMP/MLD joins and leaves. Without this, overrides
work. don't work.
3. Behavior: The assert winner for (S,G) acts as the local DR for 3. Behavior: The assert winner for (S,G) acts as the local DR for
(S,G) on behalf of IGMPv3 members. (S,G) on behalf of IGMPv3 members.
Rationale: Same rationale as for item 2. Rationale: Same rationale as for item 2.
4. Behavior: (S,G) and (*,G) prune overrides are sent to the RPF' 4. Behavior: (S,G) and (*,G) prune overrides are sent to the RPF'
neighbor and not to the regular RPF neighbor. neighbor and not to the regular RPF neighbor.
Rationale: Same rationale as for item 1. Rationale: Same rationale as for item 1.
5. Behavior: An (S,G,rpt) prune override is not sent (at all) if 5. Behavior: An (S,G,rpt) prune override is not sent (at all) if
RPF'(S,G,rpt) != RPF'(*,G). RPF'(S,G,rpt) != RPF'(*,G).
Rationale: This avoids keeping state alive on the (S,G) tree when Rationale: This avoids keeping state alive on the (S,G) tree when
only (*,G) downstream members are left. Also, it avoids sending only (*,G) downstream members are left. Also, it avoids sending
(S,G,rpt) joins to a router that is not on the (*,G) tree. This (S,G,rpt) joins to a router that is not on the (*,G) tree. This
behavior might be confusing although this specification does behavior might be confusing, although this specification does
indicate that such a join SHOULD be dropped. indicate that such a join SHOULD be dropped.
6. Behavior: An assert loser that receives a Join(S,G) with an 6. Behavior: An assert loser that receives a Join(S,G) with an
Upstream Neighbor Address that is its primary IP address on that Upstream Neighbor Address that is its primary IP address on that
interface expires the (S,G) Assert Timer. interface expires the (S,G) Assert Timer.
Rationale: This is necessary in order to have rapid convergence Rationale: This is necessary in order to have rapid convergence
in the event that the downstream router that initially sent a in the event that the downstream router that initially sent a
join to the prior Assert winner has undergone a topology change. join to the prior Assert winner has undergone a topology change.
7. Behavior: An assert loser that receives a Join(*,G) with an 7. Behavior: An assert loser that receives a Join(*,G) with an
Upstream Neighbor Address that is its primary IP address on that Upstream Neighbor Address that is its primary IP address on that
interface cancels the (*,G) Assert Timer and all (S,G) assert interface expires the (*,G) Assert Timer and all (S,G) assert
timers that do not have corresponding Prune(S,G,rpt) messages in timers that do not have corresponding Prune(S,G,rpt) messages in
the compound Join/Prune message. the compound Join/Prune message.
Rationale: Same rationale as for item 6. Rationale: Same rationale as for item 6.
8. Behavior: An assert winner for (*,G) or (S,G) sends a canceling 8. Behavior: An assert winner for (*,G) or (S,G) sends a canceling
assert when it is about to stop forwarding on a (*,G) or an (S,G) assert when it is about to stop forwarding on a (*,G) or an (S,G)
entry. This behavior does not apply to (S,G,rpt). entry. This behavior does not apply to (S,G,rpt).
Rationale: This allows switching back to the shared tree after Rationale: This allows switching back to the shared tree after
skipping to change at page 90, line 46 skipping to change at page 98, line 12
downstream routers on the shared tree from keeping SPT state downstream routers on the shared tree from keeping SPT state
alive. alive.
9. Behavior: Resend the assert messages before timing out an assert. 9. Behavior: Resend the assert messages before timing out an assert.
(This behavior is optional.) (This behavior is optional.)
Rationale: This prevents the periodic duplicates that would Rationale: This prevents the periodic duplicates that would
otherwise occur each time that an assert times out and is then otherwise occur each time that an assert times out and is then
re-established. re-established.
10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G) 10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G),
we need to trigger a Join(S,G,rpt) to RPF'(*,G). we need to trigger a Join(S,G,rpt) to RPF'(*,G).
Rationale: This allows switching back to the RPT after the last Rationale: This allows switching back to the RPT after the last
SPT member leaves. SPT member leaves.
4.7. PIM Bootstrap and RP Discovery 4.7. PIM Bootstrap and RP Discovery
For correct operation, every PIM router within a PIM domain must be For correct operation, every PIM router within a PIM domain must be
able to map a particular multicast group address to the same RP. If able to map a particular multicast group address to the same RP. If
this is not the case, then black holes may appear, where some this is not the case, then black holes may appear, where some
skipping to change at page 91, line 26 skipping to change at page 98, line 39
border has been configured so that a range of multicast groups will border has been configured so that a range of multicast groups will
not be forwarded across that border. For more information on not be forwarded across that border. For more information on
Administratively Scoped IP Multicast, see RFC 2365. The modified Administratively Scoped IP Multicast, see RFC 2365. The modified
criteria for admin-scoped regions are that the region is convex with criteria for admin-scoped regions are that the region is convex with
respect to forwarding based on the MRIB, and that all PIM routers respect to forwarding based on the MRIB, and that all PIM routers
within the scope region map scoped groups to the same RP within that within the scope region map scoped groups to the same RP within that
region. region.
This specification does not mandate the use of a single mechanism to This specification does not mandate the use of a single mechanism to
provide routers with the information to perform the group-to-RP provide routers with the information to perform the group-to-RP
mapping. Currently four mechanisms are possible, and all four have mapping. Currently, four mechanisms are possible, and all four have
associated problems: associated problems:
Static Configuration Static Configuration
A PIM router MUST support the static configuration of group-to- A PIM router MUST support the static configuration of group-to-
RP mappings. Such a mechanism is not robust to failures, but RP mappings. Such a mechanism is not robust to failures but
does at least provide a basic interoperability mechanism. does at least provide a basic interoperability mechanism.
Embedded-RP Embedded-RP
Embedded-RP defines an address allocation policy in which the Embedded-RP defines an address allocation policy in which the
address of the Rendezvous Point (RP) is encoded in an IPv6 address of the Rendezvous Point (RP) is encoded in an IPv6
multicast group address [17]. multicast group address [16].
Cisco's Auto-RP Cisco's Auto-RP
Auto-RP uses a PIM Dense-Mode multicast group to announce group- Auto-RP uses a PIM Dense-Mode (PIM-DM) multicast group to
to-RP mappings from a central location. This mechanism is not announce group-to-RP mappings from a central location. This
useful if PIM Dense-Mode is not being run in parallel with PIM mechanism is not useful if PIM Dense Mode is not being run in
Sparse-Mode, and was only intended for use with PIM Sparse-Mode parallel with PIM Sparse Mode; it was only intended for use
Version 1. No standard specification currently exists. with PIM Sparse Mode Version 1. No standard specification
currently exists.
BootStrap Router (BSR) Bootstrap Router (BSR)
RFC 2362 specifies a bootstrap mechanism based on the automatic RFC 2362 specifies a bootstrap mechanism based on the automatic
election of a bootstrap router (BSR). Any router in the domain election of a BSR. Any router in the domain that is configured
that is configured to be a possible RP reports its candidacy to to be a possible RP reports its candidacy to the BSR, and then
the BSR, and then a domain-wide flooding mechanism distributes a domain-wide flooding mechanism distributes the BSR's chosen
the BSR's chosen set of RPs throughout the domain. As specified set of RPs throughout the domain. As specified in RFC 2362,
in RFC 2362, BSR is flawed in its handling of admin-scoped the BSR mechanism is flawed in its handling of admin-scoped
regions that are smaller than a PIM domain, but the mechanism regions that are smaller than a PIM domain, but the mechanism
does work for global-scoped groups. does work for global-scoped groups.
As far as PIM-SM is concerned, the only important requirement is that As far as PIM-SM is concerned, the only important requirement is that
all routers in the domain (or admin scope zone for scoped regions) all routers in the domain (or admin scope zone for scoped regions)
receive the same set of group-range-to-RP mappings. This may be receive the same set of group-range-to-RP mappings. This may be
achieved through the use of any of these mechanisms, or through achieved through the use of any of these mechanisms, or through
alternative mechanisms not currently specified. alternative mechanisms not currently specified.
It must be operationally ensured that any RP address configured, It must be operationally ensured that any RP address configured,
learned, or advertised is reachable from all routers in the PIM learned, or advertised is reachable from all routers in the PIM
domain. domain.
4.7.1. Group-to-RP Mapping 4.7.1. Group-to-RP Mapping
Using one of the mechanisms described above, a PIM router receives Using one of the mechanisms described above, a PIM router receives
one or more possible group-range-to-RP mappings. Each mapping one or more possible group-range-to-RP mappings. Each mapping
specifies a range of multicast groups (expressed as a group and mask) specifies a range of multicast groups (expressed as a group and mask)
and the RP to which such groups should be mapped. Each mapping may and the RP to which such groups should be mapped. Each mapping may
also have an associated priority. It is possible to receive multiple also have an associated priority. It is possible to receive multiple
mappings, all of which might match the same multicast group; this is mappings, all of which might match the same multicast group; this is
the common case with BSR. The algorithm for performing the group-to- the common case with the BSR mechanism. The algorithm for performing
RP mapping is as follows: the group-to-RP mapping is as follows:
1. Perform longest match on group-range to obtain a list of RPs. 1. Perform longest match on group range to obtain a list of RPs.
2. From this list of matching RPs, find the ones with highest 2. From this list of matching RPs, find the ones with highest
priority. priority.
Eliminate any RPs from the list that have lower priorities. Eliminate any RPs from the list that have lower priorities.
3. If only one RP remains in the list, use that RP. 3. If only one RP remains in the list, use that RP.
4. If multiple RPs are in the list, use the PIM hash function to 4. If multiple RPs are in the list, use the PIM hash function to
choose one. choose one.
Thus, if two or more group-range-to-RP mappings cover a particular Thus, if two or more group-range-to-RP mappings cover a particular
group, the one with the longest mask is the mapping to use. If the group, the one with the longest mask is the mapping to use. If the
mappings have the same mask length, then the one with the highest mappings have the same mask length, then the one with the highest
priority is chosen. If there is more than one matching entry with priority is chosen. If there is more than one matching entry with
the same longest mask and the priorities are identical, then a hash the same longest mask and the priorities are identical, then a hash
function (see Section 4.7.2) is applied to choose the RP. function (see Section 4.7.2) is applied to choose the RP.
This algorithm is invoked by a DR when it needs to determine an RP This algorithm is invoked by a DR when it needs to determine an RP
for a given group, e.g., upon reception of a packet or IGMP/MLD for a given group, e.g., upon reception of a packet or IGMP/MLD
membership indication for a group for which the DR does not know the membership indication for a group for which the DR does not know
RP. the RP.
Furthermore, the mapping function is invoked by all routers upon Furthermore, the mapping function is invoked by all routers upon
receiving a (*,G) Join/Prune message. receiving a (*,G) Join/Prune message.
Note that if the set of possible group-range-to-RP mappings changes, Note that if the set of possible group-range-to-RP mappings changes,
each router will need to check whether any existing groups are each router will need to check whether any existing groups are
affected. This may, for example, cause a DR or acting DR to re-join a affected. This may, for example, cause a DR or acting DR to re-join
group, or cause it to restart register encapsulation to the new RP. a group, or cause it to restart register encapsulation to the new RP.
Implementation note: the bootstrap mechanism described in RFC 2362 Implementation note: The bootstrap mechanism described in RFC 2362
omitted step 1 above. However, of the implementations we are aware omitted step 1 above. However, of the implementations we are
of, approximately half performed step 1 anyway. Note that aware of, approximately half performed step 1 anyway. Note that
implementations of BSR that omit step 1 will not correctly implementations of BSR that omit step 1 will not correctly
interoperate with implementations of this specification when used interoperate with implementations of this specification when used
with the BSR mechanism described in [11]. with the BSR mechanism described in [11].
4.7.2. Hash Function 4.7.2. Hash Function
The hash function is used by all routers within a domain, to map a The hash function is used by all routers within a domain, to map a
group to one of the RPs from the matching set of group-range-to-RP group to one of the RPs from the matching set of group-range-to-RP
mappings (this set all have the same longest mask length and same mappings (this set of mappings all have the same longest mask length
highest priority). The algorithm takes as input the group address, and same highest priority). The algorithm takes as input the group
and the addresses of the candidate RPs from the mappings, and gives address, and the addresses of the candidate RPs from the mappings,
as output one RP address to be used. and gives as output one RP address to be used.
The protocol requires that all routers hash to the same RP within a The protocol requires that all routers hash to the same RP within a
domain (except for transients). The following hash function must be domain (except for transients). The following hash function must be
used in each router: used in each router:
1. For RP addresses in the matching group-range-to-RP mappings, 1. For RP addresses in the matching group-range-to-RP mappings,
compute a value: compute a value:
Value(G,M,C(i))= Value(G,M,C(i))=
(1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
where C(i) is the RP address and M is a hash-mask. If BSR is where C(i) is the RP address and M is a hash-mask. If BSR is
being used, the hash-mask is given in the Bootstrap messages. If being used, the hash-mask is given in the Bootstrap messages. If
BSR is not being used, the alternative mechanism that supplies BSR is not being used, the alternative mechanism that supplies
the group-range-to-RP mappings may supply the value, or else it the group-range-to-RP mappings may supply the value, or else it
defaults to a mask with the most significant 30 bits being one defaults to a mask with the most significant 30 bits being one
for IPv4 and the most significant 126 bits being one for IPv6. for IPv4 and the most significant 126 bits being one for IPv6.
The hash-mask allows a small number of consecutive groups (e.g., The hash-mask allows a small number of consecutive groups
4) to always hash to the same RP. For instance, hierarchically- (e.g., 4) to always hash to the same RP. For instance,
encoded data can be sent on consecutive group addresses to get hierarchically encoded data can be sent on consecutive group
the same delay and fate-sharing characteristics. addresses to get the same delay and fate-sharing characteristics.
For address families other than IPv4, a 32-bit digest to be used For address families other than IPv4, a 32-bit digest to be used
as C(i) and G must first be derived from the actual RP or group as C(i) and G must first be derived from the actual RP or group
address. Such a digest method must be used consistently address. Such a digest method must be used consistently
throughout the PIM domain. For IPv6 addresses, it is RECOMMENDED throughout the PIM domain. For IPv6 addresses, it is RECOMMENDED
to use the equivalent IPv4 address for an IPv4-compatible to use the equivalent IPv4 address for an IPv4-compatible
address, and the exclusive-or of each 32-bit segment of the address, and the exclusive-or of each 32-bit segment of the
address for all other IPv6 addresses. For example, the digest of address for all other IPv6 addresses. For example, the digest of
the IPv6 address 3ffe:b00:c18:1::10 would be computed as the IPv6 address 3ffe:b00:c18:1::10 would be computed as
0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010, where ^ 0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010,
represents the exclusive-or operation. where the '^' symbol represents the exclusive-or operation.
2. The candidate RP with the highest resulting hash value is then 2. The candidate RP with the highest resulting hash value is then
the RP chosen by this Hash Function. If more than one RP has the the RP chosen by this hash function. If more than one RP has the
same highest hash value, the RP with the highest IP address is same highest hash value, the RP with the highest IP address is
chosen. chosen.
4.8. Source-Specific Multicast 4.8. Source-Specific Multicast
The Source-Specific Multicast (SSM) service model [6] can be The Source-Specific Multicast (SSM) service model [6] can be
implemented with a strict subset of the PIM-SM protocol mechanisms. implemented with a strict subset of the PIM-SM protocol mechanisms.
Both regular IP Multicast and SSM semantics can coexist on a single Both regular IP Multicast and SSM semantics can coexist on a single
router, and both can be implemented using the PIM-SM protocol. A router, and both can be implemented using the PIM-SM protocol. A
range of multicast addresses, currently 232.0.0.0/8 in IPv4 and range of multicast addresses, currently 232.0.0.0/8 in IPv4 and
FF3x::/32 for IPv6, is reserved for SSM, and the choice of semantics ff3x::/32 for IPv6, is reserved for SSM, and the choice of semantics
is determined by the multicast group address in both data packets and is determined by the multicast group address in both data packets and
PIM messages. PIM messages.
4.8.1. Protocol Modifications for SSM Destination Addresses 4.8.1. Protocol Modifications for SSM Destination Addresses
The following rules override the normal PIM-SM behavior for a The following rules override the normal PIM-SM behavior for a
multicast address G in the SSM range: multicast address G in the SSM range:
o A router MUST NOT send a (*,G) Join/Prune message for any reason. o A router MUST NOT send a (*,G) Join/Prune message for any reason.
o A router MUST NOT send an (S,G,rpt) Join/Prune message for any o A router MUST NOT send an (S,G,rpt) Join/Prune message for any
reason. reason.
o A router MUST NOT send a Register message for any packet that is o A router MUST NOT send a Register message for any packet that is
destined to an SSM address. destined to an SSM address.
o A router MUST NOT forward packets based on (*,G) or (S,G,rpt) o A router MUST NOT forward packets based on (*,G) or (S,G,rpt)
state. The (*,G)- and (S,G,rpt)-related state summarization macros state. The (*,G)- and (S,G,rpt)-related state summarization
are NULL for any SSM address, for the purposes of packet macros are NULL for any SSM address, for the purposes of packet
forwarding. forwarding.
o A router acting as an RP MUST NOT forward any Register-encapsulated o A router acting as an RP MUST NOT forward any Register-
packet that has an SSM destination address, and SHOULD respond with encapsulated packet that has an SSM destination address and SHOULD
a Register-Stop message to such a Register message. respond with a Register-Stop message to such a Register message.
o A router MAY optimize out the creation and maintenance of (S,G,rpt) o A router MAY optimize out the creation and maintenance of
and (*,G) state for SSM destination addresses -- this state is not (S,G,rpt) and (*,G) state for SSM destination addresses -- this
needed for SSM packets. state is not needed for SSM packets.
The last three rules are present to deal with SSM-unaware "legacy" The last three rules are present to deal with SSM-unaware "legacy"
routers that may be sending (*,G) and (S,G,rpt) Join/Prunes, or routers that may be sending (*,G) and (S,G,rpt) Join/Prunes, or
Register messages for SSM destination addresses. Note that this Register messages for SSM destination addresses. Note that this
specification does not attempt to aid an SSM-unaware "legacy" router specification does not attempt to aid an SSM-unaware "legacy" router
with SSM operations. with SSM operations.
4.8.2. PIM-SSM-Only Routers 4.8.2. PIM-SSM-Only Routers
An implementer may choose to implement only the subset of PIM Sparse- An implementer may choose to implement only the subset of PIM
Mode that provides SSM forwarding semantics. Sparse Mode that provides SSM forwarding semantics.
A PIM-SSM-only router MUST implement the following portions of this A PIM-SSM-only router MUST implement the following portions of this
specification: specification:
o Upstream (S,G) state machine (Section 4.5.5) o Upstream (S,G) state machine (Section 4.5.5)
o Downstream (S,G) state machine (Section 4.5.2)
o (S,G) Assert state machine (Section 4.6.1) o Downstream (S,G) state machine (Section 4.5.2)
o Hello messages, neighbor discovery, and DR election (Section 4.3) o (S,G) Assert state machine (Section 4.6.1)
o Hello messages, neighbor discovery, and DR election (Section 4.3)
o Packet forwarding rules (Section 4.2) o Packet forwarding rules (Section 4.2)
A PIM-SSM-only router does not need to implement the following A PIM-SSM-only router does not need to implement the following
protocol elements: protocol elements:
o Register state machine (Section 4.4) o Register state machine (Section 4.4)
o (*,G) and (S,G,rpt) Downstream state machines (Sections 4.5.2, o (*,G) and (S,G,rpt) downstream state machines (Sections 4.5.1 and
4.5.4, and 4.5.1) 4.5.3)
o (*,G) and (S,G,rpt) Upstream state machines (Sections 4.5.6, 4.5.8, o (*,G) and (S,G,rpt) upstream state machines (Sections 4.5.4,
and 4.5.5) 4.5.6, and 4.5.7)
o (*,G) Assert state machine (Section 4.6.2) o (*,G) Assert state machine (Section 4.6.2)
o Bootstrap RP Election (Section 4.7) o Bootstrap RP election (Section 4.7)
o Keepalive Timer o Keepalive Timer
o SPTbit (Section 4.2.2) o SPTbit (Section 4.2.2)
The Keepalive Timer should be treated as always running, and SPTbit The Keepalive Timer should be treated as always running, and the
should be treated as always being set for an SSM address. SPTbit should be treated as always being set for an SSM address.
Additionally, the Packet forwarding rules of Section 4.2 can be Additionally, the packet forwarding rules of Section 4.2 can be
simplified in a PIM-SSM-only router: simplified in a PIM-SSM-only router:
oiflist = NULL oiflist = NULL
if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) { if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
oiflist = inherited_olist(S,G) oiflist = inherited_olist(S,G)
} else if( iif is in inherited_olist(S,G) ) { } else if( iif is in inherited_olist(S,G) ) {
send Assert(S,G) on iif send Assert(S,G) on iif
} }
oiflist = oiflist (-) iif oiflist = oiflist (-) iif
forward packet on all interfaces in oiflist forward packet on all interfaces in oiflist
This is nothing more than the reduction of the normal PIM-SM This is nothing more than the reduction of the normal PIM-SM
forwarding rule, with all (S,G,rpt) and (*,G) clauses replaced with forwarding rule, with all (S,G,rpt) and (*,G) clauses replaced
NULL. with NULL.
4.9. PIM Packet Formats 4.9. PIM Packet Formats
This section describes the details of the packet formats for PIM This section describes the details of the packet formats for PIM
control messages. control messages.
All PIM control messages have IP protocol number 103. All PIM control messages have IP protocol number 103.
PIM messages are either unicast (e.g., Registers and Register-Stop) PIM messages are either unicast (e.g., Registers and Register-Stop)
or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g., or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g.,
Join/Prune, Asserts, etc.). The source address used for unicast Join/Prune, Asserts). The source address used for unicast messages
messages is a domain-wide reachable address; the source address used is a domain-wide reachable address; the source address used for
for multicast messages is the link-local address of the interface on multicast messages is the link-local address of the interface on
which the message is being sent. which the message is being sent.
The IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13'. The IPv6 'ALL-PIM- The IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13'. The IPv6
ROUTERS' group is 'ff02::d'. 'ALL-PIM-ROUTERS' group is 'ff02::d'.
The PIM header common to all PIM messages is: The PIM header common to all PIM messages is:
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
PIM Version number is 2. PIM Version number is 2.
Type Type
Types for specific PIM messages. PIM Types are: Types for specific PIM messages. PIM Types are:
Message Type Destination Message Type Destination
--------------------------------------------------------------------- ---------------------------------------------------------------------
0 = Hello Multicast to ALL-PIM-ROUTERS 0 = Hello Multicast to ALL-PIM-ROUTERS
1 = Register Unicast to RP 1 = Register Unicast to RP
2 = Register-Stop Unicast to source of Register 2 = Register-Stop Unicast to source of Register
packet packet
3 = Join/Prune Multicast to ALL-PIM-ROUTERS 3 = Join/Prune Multicast to ALL-PIM-ROUTERS
4 = Bootstrap Multicast to ALL-PIM-ROUTERS 4 = Bootstrap Multicast to ALL-PIM-ROUTERS
5 = Assert Multicast to ALL-PIM-ROUTERS 5 = Assert Multicast to ALL-PIM-ROUTERS
skipping to change at page 97, line 32 skipping to change at page 105, line 4
1 = Register Unicast to RP 1 = Register Unicast to RP
2 = Register-Stop Unicast to source of Register 2 = Register-Stop Unicast to source of Register
packet packet
3 = Join/Prune Multicast to ALL-PIM-ROUTERS 3 = Join/Prune Multicast to ALL-PIM-ROUTERS
4 = Bootstrap Multicast to ALL-PIM-ROUTERS 4 = Bootstrap Multicast to ALL-PIM-ROUTERS
5 = Assert Multicast to ALL-PIM-ROUTERS 5 = Assert Multicast to ALL-PIM-ROUTERS
6 = Graft (used in PIM-DM only) Unicast to RPF'(S) 6 = Graft (used in PIM-DM only) Unicast to RPF'(S)
7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft 7 = Graft-Ack (used in PIM-DM only) Unicast to source of Graft
packet packet
8 = Candidate-RP-Advertisement Unicast to Domain's BSR 8 = Candidate-RP-Advertisement Unicast to Domain's BSR
Reserved Reserved
Set to zero on transmission. Ignored upon receipt. Set to zero on transmission. Ignored upon receipt.
Checksum Checksum
The checksum is a standard IP checksum, i.e., the 16-bit one's The checksum is a standard IP checksum, i.e., the 16-bit one's
complement of the one's complement sum of the entire PIM complement of the one's complement sum of the entire PIM
message, excluding the "Multicast data packet" section of the message, excluding the "Multicast data packet" section of the
Register message. For computing the checksum, the checksum Register message. For computing the checksum, the checksum
field is zeroed. If the packet's length is not an integral field is zeroed. If the packet's length is not an integral
number of 16-bit words, the packet is padded with a trailing number of 16-bit words, the packet is padded with a trailing
byte of zero before performing the checksum. byte of zero before performing the checksum.
For IPv6, the checksum also includes the IPv6 "pseudo-header", For IPv6, the checksum also includes the IPv6 "pseudo-header",
as specified in RFC 2460, Section 8.1 [5]. This "pseudo-header" as specified in RFC 2460, Section 8.1 [5]. This
is prepended to the PIM header for the purposes of calculating "pseudo-header" is prepended to the PIM header for the purposes
the checksum. The "Upper-Layer Packet Length" in the pseudo- of calculating the checksum. The "Upper-Layer Packet Length"
header is set to the length of the PIM message, except in in the pseudo-header is set to the length of the PIM message,
Register messages where it is set to the length of the PIM except in Register messages where it is set to the length of
register header (8). The Next Header value used in the pseudo- the PIM register header (8). The Next Header value used in the
header is 103. pseudo-header is 103.
If a message is received with an unrecognized PIM Ver or Type field, If a message is received with an unrecognized PIM Ver or Type field,
or if a message's destination does not correspond to the table above, or if a message's destination does not correspond to the table above,
the message MUST be discarded, and an error message SHOULD be logged the message MUST be discarded, and an error message SHOULD be logged
to the administrator in a rate-limited manner. to the administrator in a rate-limited manner.
4.9.1. Encoded Source and Group Address Formats 4.9.1. Encoded Source and Group Address Formats
Encoded-Unicast Address Encoded Unicast Address
An Encoded-Unicast address takes the following format: An encoded unicast address takes 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
The PIM address family of the 'Unicast Address' field of this The PIM address family of the 'Unicast Address' field of this
address. address.
Values 0-127 are as assigned by the IANA for Internet Address Values 0-127 are as assigned by the IANA for Internet Address
Families in [7]. Values 128-250 are reserved to be assigned by Families in [7]. Values 128-250 are reserved to be assigned by
the IANA for PIM-specific Address Families. Values 251 though the IANA for PIM-specific Address Families. Values 251 through
255 are designated for private use. As there is no assignment 255 are designated for Private Use. As there is no assignment
authority for this space, collisions should be expected. authority for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family.
value '0' is reserved for this field and represents the native The value '0' is reserved for this field and represents the
encoding of the Address Family. native encoding of the Address Family.
Unicast Address Unicast Address
The unicast address as represented by the given Address Family The unicast address as represented by the given Address Family
and Encoding Type. and Encoding Type.
Encoded-Group Address Encoded Group Address
Encoded-Group addresses take the following format: Encoded group addresses take 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
Described above. Described above.
Encoding Type Encoding Type
Described above. Described above.
[B]idirectional PIM [B]idirectional PIM
Indicates the group range should use Bidirectional PIM [13]. Indicates that the group range uses Bidirectional PIM [13].
For PIM-SM defined in this specification, this bit MUST be zero. For PIM-SM as defined in this specification, this bit MUST be
zero.
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Admin Scope [Z]one Admin Scope [Z]one
indicates the group range is an admin scope zone. This is used Indicates that the group range is an admin scope zone. This is
in the Bootstrap Router Mechanism [11] only. For all other used in the Bootstrap Router mechanism [11] only. For all
purposes, this bit is set to zero and ignored on receipt. other purposes, this bit 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 one bits that are left justified and used as a mask; contiguous one bits that are left-justified and used as a mask;
when combined with the group address, it describes a range of when combined with the group address, it describes a range of
groups. It is less than or equal to the address length in bits groups. It is less than or equal to the address length in bits
for the given Address Family and Encoding Type. If the message for the given Address Family and Encoding Type. If the message
is sent for a single group, then the Mask length must equal the is sent for a single group, then the Mask length must equal the
address length in bits for the given Address Family and Encoding address length in bits for the given Address Family and
Type (e.g., 32 for IPv4 native encoding, 128 for IPv6 native Encoding Type (e.g., 32 for IPv4 native encoding, 128 for IPv6
encoding). native encoding).
Group multicast Address Group multicast Address
Contains the group address. Contains the group address.
Encoded-Source Address Encoded Source Address
Encoded-Source address takes the following format: An encoded source address takes 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Addr Family Addr Family
Described above. Described above.
Encoding Type Encoding Type
Described above. Described above.
Reserved Reserved
Transmitted as zero, ignored on receipt. Transmitted as zero, ignored on receipt.
S The Sparse bit is a 1-bit value, set to 1 for PIM-SM. It is S The Sparse bit is a 1-bit value, set to 1 for PIM-SM. It is
used for PIM version 1 compatibility. used for PIM Version 1 compatibility.
W The WC (or WildCard) bit is a 1-bit value for use with PIM W The WC (or WildCard) bit is a 1-bit value for use with PIM
Join/Prune messages (see Section 4.9.5.1). Join/Prune messages (see Section 4.9.5.1).
R The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use R The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
with PIM Join/Prune messages (see Section 4.9.5.1). If the WC with PIM Join/Prune messages (see Section 4.9.5.1). If the
bit is 1, the RPT bit MUST be 1. WC bit is 1, the RPT bit MUST be 1.
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 one bits left justified used as a mask which, contiguous one bits that are left-justified and used as a mask;
combined with the Source Address, describes a source subnet. when combined with the source address, it describes a source
The mask length MUST be equal to the mask length in bits for the subnet. The mask length MUST be equal to the mask length in
given Address Family and Encoding Type (32 for IPv4 native and bits for the given Address Family and Encoding Type (32 for
128 for IPv6 native). A router SHOULD ignore any messages IPv4 native and 128 for IPv6 native). A router SHOULD ignore
received with any other mask length. any messages received with any other mask length.
Source Address Source Address
The source address. The source address.
4.9.2. Hello Message Format 4.9.2. Hello Message Format
It is sent periodically by routers on all interfaces. A Hello message is sent periodically by routers on all interfaces.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength | | OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue | | OptionValue |
| ... | | ... |
skipping to change at page 101, line 30 skipping to change at page 108, line 42
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionType | OptionLength | | OptionType | OptionLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OptionValue | | OptionValue |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described in Section 4.9. Described in Section 4.9.
OptionType OptionType
The type of the option given in the following OptionValue field. The type of the option given in the following OptionValue
field.
OptionLength OptionLength
The length of the OptionValue field in bytes. The length of the OptionValue field in bytes.
OptionValue OptionValue
A variable length field, carrying the value of the option. A variable-length field, carrying the value of the option.
The Option fields may contain the following values: The Option fields may contain the following values:
o OptionType 1: Holdtime o OptionType 1: Holdtime
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holdtime | | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Holdtime is the amount of time a receiver must keep the neighbor Holdtime is the amount of time a receiver must keep the neighbor
reachable, in seconds. If the Holdtime is set to '0xffff', the reachable, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message never times out the neighbor. This may be receiver of this message never times out the neighbor. This may
used with dial-on-demand links, to avoid keeping the link up with be used with dial-on-demand links, to avoid keeping the link up
periodic Hello messages. with periodic Hello messages.
An implementation MAY provide a configuration mechanism to reject a An implementation MAY provide a configuration mechanism to reject
Hello message with holdtime 0xffff, and/or provide a mechanism to a Hello message with holdtime 0xffff, and/or provide a mechanism
remove a neighbor. to remove a neighbor.
Hello messages with a Holdtime value set to '0' are also sent by a Hello messages with a Holdtime value set to '0' are also sent by a
router on an interface about to go down or changing IP address (see router on an interface about to go down or changing IP address
Section 4.3.1). These are effectively goodbye messages, and the (see Section 4.3.1). These are effectively goodbye messages, and
receiving routers SHOULD immediately time out the neighbor the receiving routers SHOULD immediately time out the neighbor
information for the sender. information for the sender.
o OptionType 2: LAN Prune Delay o OptionType 2: LAN Prune Delay
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| Propagation_Delay | Override_Interval | |T| Propagation_Delay | Override_Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAN Prune Delay option is used to tune the prune propagation The LAN Prune Delay option is used to tune the prune propagation
delay on multi-access LANs. The T bit specifies the ability of the delay on multi-access LANs. The T bit specifies the ability of
sending router to disable join suppression. Propagation_Delay and the sending router to disable Join suppression. Propagation_Delay
Override_Interval are time intervals in units of milliseconds. A and Override_Interval are time intervals in units of milliseconds.
router originating a LAN Prune Delay option on interface I sets the A router originating a LAN Prune Delay option on interface I sets
Propagation_Delay field to the configured value of the Propagation_Delay field to the configured value of
Propagation_Delay(I) and the value of the Override_Interval field Propagation_Delay(I) and the value of the Override_Interval field
to the value of Override_Interval(I). On a receiving router, the to the value of Override_Interval(I). On a receiving router, the
values of the fields are used to tune the value of the values of the fields are used to tune the value of the
Effective_Override_Interval(I) and its derived timer values. Effective_Override_Interval(I) and its derived timer values.
Section 4.3.3 describes how these values affect the behavior of a Section 4.3.3 describes how these values affect the behavior of a
router. router.
o OptionType 3 to 16: reserved to be defined in future versions of o OptionTypes 3 through 16: Reserved; to be defined in future
this document. versions of this document.
o OptionType 18: deprecated and should not be used. o OptionType 18: Deprecated and should not be used.
o OptionType 19: DR Priority o OptionType 19: DR Priority
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 = 19 | Length = 4 | | Type = 19 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DR Priority | | DR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DR Priority is a 32-bit unsigned number and should be considered in DR Priority is a 32-bit unsigned number and should be considered
the DR election as described in Section 4.3.2. in the DR election as described in Section 4.3.2.
o OptionType 20: Generation ID o OptionType 20: Generation ID
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 32-bit value for the interface on which Generation ID is a random 32-bit value for the interface on which
the Hello message is sent. The Generation ID is regenerated the Hello message is sent. The Generation ID is regenerated
whenever PIM forwarding is started or restarted on the interface. whenever PIM forwarding is started or restarted on the interface.
o OptionType 24: Address List o OptionType 24: Address List
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 = 24 | Length = <Variable> | | Type = 24 | Length = <Variable> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address 1 (Encoded-Unicast format) | | Secondary Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Address N (Encoded-Unicast format) | | Secondary Address N (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the Address List Hello option are described in The contents of the Address List Hello option are described in
Section 4.3.4. All addresses within a single Address List must Section 4.3.4. All addresses within a single Address List must
belong to the same address family. belong to the same address family.
OptionTypes 17 through 65000 are assigned by the IANA. OptionTypes OptionTypes 17 through 65000 are assigned by the IANA.
65001 through 65535 are reserved for Private Use, as defined in [9]. OptionTypes 65001 through 65535 are reserved for Private Use,
as defined in [9].
Unknown options MUST be ignored and MUST NOT prevent a neighbor Unknown options MUST be ignored and MUST NOT prevent a neighbor
relationship from being formed. The "Holdtime" option MUST be relationship from being formed. The Holdtime option MUST be
implemented; the "DR Priority" and "Generation ID" options SHOULD be implemented; the DR Priority and Generation ID options SHOULD be
implemented. The "Address List" option MUST be implemented for IPv6. implemented. The Address List option MUST be implemented for IPv6.
4.9.3. Register Message Format 4.9.3. Register Message Format
A Register message is sent by the DR to the RP when a multicast A Register message is sent by the DR to the RP when a multicast
packet needs to be transmitted on the RP-tree. The IP source address packet needs to be transmitted on the RP-tree. The IP source address
is set to the address of the DR, the destination address to the RP's is set to the address of the DR, the destination address to the RP's
address. The IP TTL of the PIM packet is the system's normal unicast address. The IP TTL of the PIM packet is the system's normal
TTL. unicast TTL.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|N| Reserved2 | |B|N| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Multicast data packet . . Multicast data packet .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described in Section 4.9. Note that in order to reduce Described in Section 4.9. Note that in order to reduce
encapsulation overhead, the checksum for Registers is done only encapsulation overhead, the checksum for Registers is done only
on the first 8 bytes of the packet, including the PIM header and on the first 8 bytes of the packet, including the PIM header
the next 4 bytes, excluding the data packet portion. For and the next 4 bytes, excluding the data packet portion. For
interoperability reasons, a message carrying a checksum interoperability reasons, a message carrying a checksum
calculated over the entire PIM Register message should also be calculated over the entire PIM Register message should also be
accepted. When calculating the checksum, the IPv6 pseudoheader accepted. When calculating the checksum, the IPv6
"Upper-Layer Packet Length" is set to 8. pseudo-header "Upper-Layer Packet Length" is set to 8.
B The Border bit. This specification deprecates the Border bit. A B The Border bit. This specification deprecates the Border bit.
router MUST set B bit to 0 on tranmission and MUST ignore this A router MUST set the B bit to 0 on transmission and MUST
bit on reception. ignore this bit on reception.
N The Null-Register bit. Set to 1 by a DR that is probing the RP N The Null-Register bit. Set to 1 by a DR that is probing the RP
before expiring its local Register-Suppression Timer. Set to 0 before expiring its local Register-Suppression Timer. Set to 0
otherwise. otherwise.
Reserved2 Reserved2
Transmitted as zero, ignored on receipt. Transmitted as zero, ignored on receipt.
Multicast data packet Multicast data packet
The original packet sent by the source. This packet must be of The original packet sent by the source. This packet must be of
the same address family as the encapsulating PIM packet, e.g., the same address family as the encapsulating PIM packet, e.g.,
an IPv6 data packet must be encapsulated in an IPv6 PIM packet. an IPv6 data packet must be encapsulated in an IPv6 PIM packet.
Note that the TTL of the original packet is decremented before Note that the TTL of the original packet is decremented before
encapsulation, just like any other packet that is forwarded. In encapsulation, just like any other packet that is forwarded.
addition, the RP decrements the TTL after decapsulating, before In addition, the RP decrements the TTL after decapsulating,
forwarding the packet down the shared tree. before forwarding the packet down the shared tree.
For (S,G) Null-Registers, the Multicast data packet portion
contains a dummy IP header with S as the source address, G as
the destination address. When generating an IPv4 Null-Register
message, the fields in the dummy IPv4 header SHOULD be filled in
according to the following table. Other IPv4 header fields may
contain any value that is valid for that field.
Field Value For (S,G) Null-Registers, the Multicast data packet portion
--------------------------------------- contains a dummy IP header with S as the source address
IP Version 4 and G as the destination address. When generating an IPv4
Header Length 5 Null-Register message, the fields in the dummy IPv4 header
Checksum Header checksum SHOULD be filled in according to the following table. Other
Fragmentation offset 0 IPv4 header fields may contain any value that is valid for
More Fragments 0 that field.
Total Length 20
IP Protocol 103 (PIM)
On receipt of an (S,G) Null-Register, if the Header Checksum Field Value
field is non-zero, the recipient SHOULD check the checksum and ---------------------------------------
discard null registers that have a bad checksum. The recipient IP Version 4
SHOULD NOT check the value of any individual fields; a correct Header Length 5
IP header checksum is sufficient. If the Header Checksum field Checksum Header checksum
is zero, the recipient MUST NOT check the checksum. Fragmentation offset 0
More Fragments 0
Total Length 20
IP Protocol 103 (PIM)
On receipt of an (S,G) Null-Register, if the Header Checksum
field is non-zero, the recipient SHOULD check the checksum and
discard Null-Registers that have a bad checksum. The recipient
SHOULD NOT check the value of any individual fields; a correct
IP header checksum is sufficient. If the Header Checksum field
is zero, the recipient MUST NOT check the checksum.
With IPv6, an implementation generates a dummy IP header With IPv6, an implementation generates a dummy IP header
followed by a dummy PIM header with values according to the followed by a dummy PIM header with values according to the
following table in addition to the source and group. Other IPv6 following table in addition to the source and group. Other
header fields may contain any value that is valid for that IPv6 header fields may contain any value that is valid for that
field. field.
Header Field Value Header Field Value
-------------------------------------- --------------------------------------
IP Version 6 IP Version 6
Next Header 103 (PIM) Next Header 103 (PIM)
Length 4 Length 4
PIM Version 0 PIM Version 0
PIM Type 0 PIM Type 0
PIM Reserved 0 PIM Reserved 0
PIM Checksum PIM checksum including PIM Checksum PIM checksum, including
IPv6 "pseudo-header"; IPv6 "pseudo-header";
see Section 4.9 see Section 4.9
On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM
header is present, the recipient SHOULD check the checksum and header is present, the recipient SHOULD check the checksum and
discard Null-Registers that have a bad checksum. discard Null-Registers that have a bad checksum.
4.9.4. Register-Stop Message Format 4.9.4. Register-Stop Message Format
A Register-Stop is unicast from the RP to the sender of the Register A Register-Stop is unicast from the RP to the sender of the Register
message. The IP source address is the address to which the register message. The IP source address is the address to which the register
was addressed. The IP destination address is the source address of was addressed. The IP destination address is the source address of
the register message. the register message.
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
skipping to change at page 108, line 21 skipping to change at page 114, line 4
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) | | Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described in Section 4.9. Described in Section 4.9.
Group Address Group Address
The group address from the multicast data packet in the The group address from the multicast data packet in the
Register. Format described in Section 4.9.1. Note that for Register. The format for this address is described in
Register-Stops the Mask Len field contains the full address Section 4.9.1. Note that for Register-Stops the Mask Len field
length * 8 (e.g., 32 for IPv4 native encoding), if the message contains the full address length * 8 (e.g., 32 for IPv4 native
is sent for a single group. encoding), if the message is sent for a single group.
Source Address Source Address
The host address of the source from the multicast data packet in The host address of the source from the multicast data packet
the register. The format for this address is given in the in the register. The format for this address is given in the
Encoded-Unicast address in Section 4.9.1. A special wild card encoded unicast address in Section 4.9.1. A special wildcard
value consisting of an address field of all zeros can be used to value consisting of an address field of all zeros can be used
indicate any source. to indicate any source.
4.9.5. Join/Prune Message Format 4.9.5. Join/Prune Message Format
A Join/Prune message is sent by routers towards upstream sources and A Join/Prune message is sent by routers towards upstream sources and
RPs. Joins are sent to build shared trees (RP trees) or source trees RPs. Joins are sent to build shared trees (RP trees) or source trees
(SPT). Prunes are sent to prune source trees when members leave (SPT). Prunes are sent to prune source trees when members leave
groups as well as sources that do not use the shared tree. groups as well as sources that do not use the shared tree.
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
skipping to change at page 110, line 5 skipping to change at page 116, line 5
| Joined Source Address n (Encoded-Source format) | | Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) | | Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) | | Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum PIM Version, Type, Reserved, Checksum
Described in Section 4.9. Described in Section 4.9.
Unicast Upstream Neighbor Address Unicast Upstream Neighbor Address
The primary address of the upstream neighbor that is the target The primary address of the upstream neighbor that is the target
of the message. The format for this address is given in the of the message. The format for this address is given in the
Encoded-Unicast address in Section 4.9.1. encoded unicast address in Section 4.9.1.
Reserved Reserved
Transmitted as zero, ignored on receipt. Transmitted as zero, ignored on receipt.
Holdtime Holdtime
The amount of time a receiver MUST keep the Join/Prune state The amount of time a receiver MUST keep the Join/Prune state
alive, in seconds. If the Holdtime is set to '0xffff', the alive, in seconds. If the Holdtime is set to '0xffff', the
receiver of this message SHOULD hold the state until canceled by receiver of this message SHOULD hold the state until canceled
the appropriate canceling Join/Prune message, or timed out by the appropriate canceling Join/Prune message, or timed out
according to local policy. This may be used with dial-on-demand according to local policy. This may be used with dial-on-
links, to avoid keeping the link up with periodic Join/Prune demand links, to avoid keeping the link up with periodic
messages. Join/Prune messages.
Note that the HoldTime MUST be larger than the Note that the HoldTime MUST be larger than the
J/P_Override_Interval(I). J/P_Override_Interval(I).
Number of Groups Number of Groups
The number of multicast group sets contained in the message. The number of multicast group sets contained in the message.
Multicast group address Multicast group address
For format description, see Section 4.9.1. For format description, see Section 4.9.1.
Number of Joined Sources Number of Joined Sources
Number of joined source addresses listed for a given group. Number of joined source addresses listed for a given group.
Joined Source Address 1 .. n Joined Source Address 1 .. n
This list contains the sources for a given group that the This list contains the sources for a given group that the
sending router will forward multicast datagrams from if received sending router will forward multicast datagrams from if
on the interface on which the Join/Prune message is sent. received on the interface on which the Join/Prune message
is sent.
See Encoded-Source-Address format in Section 4.9.1. See Section 4.9.1 for the format description for the
encoded source address.
Number of Pruned Sources Number of Pruned Sources
Number of pruned source addresses listed for a group. Number of pruned source addresses listed for a group.
Pruned Source Address 1 .. n Pruned Source Address 1 .. n
This list contains the sources for a given group that the This list contains the sources for a given group that the
sending router does not want to forward multicast datagrams from sending router does not want to forward multicast datagrams
when received on the interface on which the Join/Prune message from when received on the interface on which the Join/Prune
is sent. message is sent.
Within one PIM Join/Prune message, all the Multicast Group Addresses, Within one PIM Join/Prune message, all the Multicast Group addresses,
Joined Source addresses, and Pruned Source addresses MUST be of the Joined Source addresses, and Pruned Source addresses MUST be of the
same address family. It is NOT PERMITTED to mix IPv4 and IPv6 same address family. It is NOT PERMITTED to mix IPv4 and IPv6
addresses within the same message. In addition, the address family addresses within the same message. In addition, the address family
of the fields in the message SHOULD be the same as the IP source and of the fields in the message SHOULD be the same as the IP source and
destination addresses of the packet. This permits maximum destination addresses of the packet. This permits maximum
implementation flexibility for dual-stack IPv4/IPv6 routers. If a implementation flexibility for dual-stack IPv4/IPv6 routers. If a
router receives a message with mixed family addresses, it SHOULD only router receives a message with mixed family addresses, it SHOULD only
process the addresses that are of the same family as the unicast process the addresses that are of the same family as the unicast
upstream neighbor address. upstream neighbor address.
4.9.5.1. Group Set Source List Rules 4.9.5.1. Group Set Source List Rules
As described above, Join/Prune messages are composed of one or more As described above, Join/Prune messages are composed of one or more
group sets. Each set contains two source lists, the Joined Sources group sets. Each set contains two source lists: the Joined Sources
and the Pruned Sources. This section describes the different types and the Pruned Sources. This section describes the different types
of group sets and source list entries that can exist in a Join/Prune of group sets and source list entries that can exist in a Join/Prune
message. message.
There is one valid group set type: There is one valid group set type:
Group-Specific Set Group-Specific Set
A Group-Specific Set is represented by a valid IP multicast A Group-Specific Set is represented by a valid IP multicast
address in the group address field and the full length of the IP address in the group address field and the full length of the
address in the mask length field of the Multicast Group Address. IP address in the mask length field of the Multicast Group
Each Join/Prune message SHOULD NOT contain more than one group- Address. Each Join/Prune message SHOULD NOT contain more than
specific set for the same IP multicast address. Each group- one group-specific set for the same IP multicast address. Each
specific set may contain (*,G), (S,G,rpt), and (S,G) source list group-specific set may contain (*,G), (S,G,rpt), and (S,G)
entries in the Joined or Pruned lists. source list entries in the Joined or Pruned lists.
(*,G) (*,G)
The (*,G) source list entry is used in Join/Prune messages The (*,G) source list entry is used in Join/Prune messages
sent towards the RP for the specified group. It expresses sent towards the RP for the specified group. It expresses
interest (or lack thereof) in receiving traffic sent to the interest (or lack thereof) in receiving traffic sent to the
group through the Rendezvous-Point shared tree. There MUST group through the RP shared tree. There MUST only be one
only be one such entry in both the Joined and Pruned lists of such entry in both the Joined and Pruned lists of a group-
a group-specific set. specific set.
(*,G) source list entries have the Source-Address set to the (*,G) source list entries have the Source-Address set to the
address of the RP for group G, the Source-Address Mask-Len set address of the RP for group G, the Source-Address Mask-Len
to the full length of the IP address, and both the WC and RPT set to the full length of the IP address, and both the WC
bits of the Encoded-Source-Address set. and RPT bits of the encoded-source-address set.
(S,G,rpt) (S,G,rpt)
The (S,G,rpt) source list entry is used in Join/Prune messages The (S,G,rpt) source list entry is used in Join/Prune
sent towards the RP for the specified group. It expresses messages sent towards the RP for the specified group. It
interest (or lack thereof) in receiving traffic through the expresses interest (or lack thereof) in receiving traffic
shared tree sent by the specified source to this group. For through the shared tree sent by the specified source to this
each source address, the entry MUST exist in only one of the group. For each source address, the entry MUST exist in
Joined and Pruned source lists of a group-specific set, but only one of the Joined and Pruned source lists of a group-
not both. specific set, but not both.
(S,G,rpt) source list entries have the Source-Address set to (S,G,rpt) source list entries have the Source-Address set to
the address of the source S, the Source-Address Mask-Len set the address of the source S, the Source-Address Mask-Len set
to the full length of the IP address, and the WC bit cleared to the full length of the IP address, and the WC bit cleared
and the RPT bit set in the Encoded-Source-Address. and the RPT bit set in the encoded source address.
(S,G) (S,G)
The (S,G) source list entry is used in Join/Prune messages The (S,G) source list entry is used in Join/Prune messages
sent towards the specified source. It expresses interest (or sent towards the specified source. It expresses interest
lack thereof) in receiving traffic through the shortest path (or lack thereof) in receiving traffic through the shortest
tree sent by the source to the specified group. For each path tree sent by the source to the specified group. For
source address, the entry MUST exist in only one of the Joined each source address, the entry MUST exist in only one of the
and Pruned source lists of a group-specific set, but not both. Joined and Pruned source lists of a group-specific set, but
not both.
(S,G) source list entries have the Source-Address set to the (S,G) source list entries have the Source-Address set to the
address of the source S, the Source-Address Mask-Len set to address of the source S, the Source-Address Mask-Len set to
the full length of the IP address, and both the WC and RPT the full length of the IP address, and both the WC and RPT
bits of the Encoded-Source-Address cleared. bits of the encoded source address cleared.
The rules described above are sufficient to prevent invalid The rules described above are sufficient to prevent invalid
combinations of source list entries in group-specific sets. There combinations of source list entries in group-specific sets. There
are, however, a number of combinations that have a valid are, however, a number of combinations that have a valid
interpretation but that are not generated by the protocol as interpretation but that are not generated by the protocol as
described in this specification: described in this specification:
o Combining a (*,G) Join and an (S,G,rpt) Join entry in the same o Combining a (*,G) Join and an (S,G,rpt) Join entry in the same
message is redundant as the (*,G) entry covers the information message is redundant, as the (*,G) entry covers the information
provided by the (S,G,rpt) entry. provided by the (S,G,rpt) entry.
o The same applies for a (*,G) Prune and an (S,G,rpt) Prune. o The same applies for a (*,G) Prune and an (S,G,rpt) Prune.
o The combination of a (*,G) Prune and an (S,G,rpt) Join is also not o The combination of a (*,G) Prune and an (S,G,rpt) Join is also not
generated. (S,G,rpt) Joins are only sent when the router is generated. (S,G,rpt) Joins are only sent when the router is
receiving all traffic for a group on the shared tree and it wishes receiving all traffic for a group on the shared tree and it wishes
to indicate a change for the particular source. As a (*,G) prune to indicate a change for the particular source. As a (*,G) prune
indicates that the router no longer wishes to receive shared tree indicates that the router no longer wishes to receive shared tree
traffic, the (S,G,rpt) Join would be meaningless. traffic, the (S,G,rpt) Join would be meaningless.
o As Join/Prune messages are targeted to a single PIM neighbor, o As Join/Prune messages are targeted to a single PIM neighbor,
including both an (S,G) Join and an (S,G,rpt) Prune in the same including both an (S,G) Join and an (S,G,rpt) Prune in the same
message is usually redundant. The (S,G) Join informs the neighbor message is usually redundant. The (S,G) Join informs the neighbor
that the sender wishes to receive the particular source on the that the sender wishes to receive the particular source on the
shortest path tree. It is therefore unnecessary for the router to shortest path tree. It is therefore unnecessary for the router to
say that it no longer wishes to receive it on the shared tree. say that it no longer wishes to receive it on the shared tree.
However, there is a valid interpretation for this combination of However, there is a valid interpretation for this combination of
entries. A downstream router may have to instruct its upstream entries. A downstream router may have to instruct its upstream
only to start forwarding a specific source once it has started only to start forwarding a specific source once it has started
receiving the source on the shortest-path tree. receiving the source on the shortest-path tree.
o The combination of an (S,G) Prune and an (S,G,rpt) Join could o The combination of an (S,G) Prune and an (S,G,rpt) Join could
possibly be used by a router to switch from receiving a particular possibly be used by a router to switch from receiving a particular
source on the shortest-path tree back to receiving it on the shared source on the shortest-path tree back to receiving it on the
tree (provided that the RPF neighbor for the shortest-path and shared tree (provided that the RPF neighbor for the shortest-path
shared trees is common). However, Sparse-Mode PIM does not provide and shared trees is common). However, Sparse-Mode PIM does not
a mechanism for explicitly switching back to the shared tree. provide a mechanism for explicitly switching back to the shared
tree.
The rules are summarized in the tables below. The rules are summarized in the table below.
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
| ||Join | Prune | Join | Prune | Join | Prune | | ||Join | Prune | Join | Prune | Join | Prune |
| ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) | | ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||- | no | ? | yes | yes | yes | |Join ||- | no | ? | yes | yes | yes |
|(*,G) || | | | | | | |(*,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||no | - | ? | ? | yes | yes | |Prune ||no | - | ? | ? | yes | yes |
|(*,G) || | | | | | | |(*,G) || | | | | | |
skipping to change at page 114, line 29 skipping to change at page 120, line 4
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | ? | no | - | yes | ? | |Prune ||yes | ? | no | - | yes | ? |
|(S,G,rpt) || | | | | | | |(S,G,rpt) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Join ||yes | yes | yes | yes | - | no | |Join ||yes | yes | yes | yes | - | no |
|(S,G) || | | | | | | |(S,G) || | | | | | |
+----------++------+-------+-----------+-----------+-------+-------+ +----------++------+-------+-----------+-----------+-------+-------+
|Prune ||yes | yes | ? | ?