draft-ietf-pim-rfc4601bis-00.txt   draft-ietf-pim-rfc4601bis-01.txt 
Network Working Group B. Fenner Network Working Group B. Fenner
Internet Draft AT&T Labs - Research Internet Draft AT&T Labs - Research
Intended Status: Draft Standard M. Handley Intended Status: Draft Standard M. Handley
Expires: April 1, 2012 UCL Expires: April 29, 2012 UCL
H. Holbrook H. Holbrook
Arastra Arastra
I. Kouvelas I. Kouvelas
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
Sep 29, 2011 October 27, 2011
Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised) Protocol Specification (Revised)
draft-ietf-pim-rfc4601bis-00 draft-ietf-pim-rfc4601bis-01
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2011. This Internet-Draft will expire on April 29, 2012.
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 optionally
creates shortest-path trees per source. creates shortest-path trees per source.
skipping to change at page 8, line 21 skipping to change at page 8, line 21
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. For as an introduction to how PIM-SM works, and it is NOT definitive.
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
skipping to change at page 17, line 6 skipping to change at page 17, line 6
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.6. 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 Section
4.5.2. The state is used by the macros that calculate the outgoing 4.5.1. The state is used by the macros that calculate the outgoing
interface list in Section 4.1.6, and in the JoinDesired(*,G) macro interface list in Section 4.1.5, and in the JoinDesired(*,G) macro
(defined in Section 4.5.6) that is used in deciding whether a (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.6. 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-Set changes
(Section 4.7), then state must be torn down and rebuilt for groups (Section 4.7), then state 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 re-
instantiate state by sending a Join(*,G). These mechanisms are instantiate state by sending a Join(*,G). These mechanisms are
specified in Section 4.5.6. 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:
skipping to change at page 19, line 9 skipping to change at page 19, line 9
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.6. 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 Section
4.5.3. The state is used by the macros that calculate the outgoing 4.5.2. The state is used by the macros that calculate the outgoing
interface list in Section 4.1.6, and in the JoinDesired(S,G) macro interface list in Section 4.1.5, and in the JoinDesired(S,G) macro
(defined in Section 4.5.7) that is used in deciding whether a (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.7. 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 re-
instantiate state by sending a Join(S,G). These mechanisms are instantiate state by sending a Join(S,G). These mechanisms are
specified in Section 4.5.7. 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. When the interval when the source-specific tree is being constructed.
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.
skipping to change at page 20, line 24 skipping to change at page 20, line 24
(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- Pending"} o State: One of {"NoInfo", "Pruned", "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)",
skipping to change at page 20, line 50 skipping to change at page 20, line 51
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.6. 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.4. 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.6, 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 Section
4.5.8. 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.9. 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
in the following sections. in the following sections.
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
skipping to change at page 23, line 10 skipping to change at page 23, line 10
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 }
DownstreamJPState(*,G,I) is the state of the finite state machine in DownstreamJPState(*,G,I) is the state of the finite state machine in
Section 4.5.2. Section 4.5.1.
The set "joins(S,G)" is the set of all interfaces on which the router The set "joins(S,G)" is the set of all interfaces on which the router
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.3. 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.4. 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
macro lost_assert(*,G,I) is defined in Section 4.6.5. macro lost_assert(*,G,I) is defined in Section 4.6.5.
lost_assert(*,G) = lost_assert(*,G) =
{ all interfaces I such that { all interfaces I such that
lost_assert(*,G,I) == TRUE } lost_assert(*,G,I) == TRUE }
The set "lost_assert(S,G,rpt)" is the set of all interfaces on which The set "lost_assert(S,G,rpt)" is the set of all interfaces on which
the router has received (*,G) joins but has lost an (S,G) assert. The the router has received (*,G) joins but has lost an (S,G) assert.
macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5. The macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5.
lost_assert(S,G,rpt) = lost_assert(S,G,rpt) =
{ all interfaces I such that { all interfaces I such that
lost_assert(S,G,rpt,I) == TRUE } lost_assert(S,G,rpt,I) == TRUE }
The set "lost_assert(S,G)" is the set of all interfaces on which the The set "lost_assert(S,G)" is the set of all interfaces on which the
router has received (S,G) joins but has lost an (S,G) assert. The router has received (S,G) joins but has lost an (S,G) assert. The
macro lost_assert(S,G,I) is defined in Section 4.6.5. macro lost_assert(S,G,I) is defined in Section 4.6.5.
lost_assert(S,G) = lost_assert(S,G) =
skipping to change at page 24, line 47 skipping to change at page 24, line 47
RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets
should be coming and to which joins should be sent on the RP tree and should be coming and to which joins should be sent on the RP tree and
SPT, respectively. SPT, respectively.
RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an
Assert(S,G) on RPF_interface(RP(G)). In such a case, packets from S Assert(S,G) on RPF_interface(RP(G)). In such a case, packets from S
will be originating from a different router than RPF'(*,G). If we will be originating from a different router than RPF'(*,G). If we
only have active (*,G) Join state, we need to accept packets from only have active (*,G) Join state, we need to accept packets from
RPF'(S,G,rpt) and add a Prune(S,G,rpt) to the periodic Join(*,G) RPF'(S,G,rpt) and add a Prune(S,G,rpt) to the periodic Join(*,G)
messages that we send to RPF'(*,G) (see Section 4.5.8). messages that we send to RPF'(*,G) (see Section 4.5.6).
The function MRIB.next_hop( S ) returns an address of the next-hop The function MRIB.next_hop( S ) returns an address of the next-hop
PIM neighbor toward the host S, as indicated by the current MRIB. If PIM neighbor toward the host S, as indicated by the current MRIB. If
S is directly adjacent, then MRIB.next_hop( S ) returns NULL. At the S is directly adjacent, then MRIB.next_hop( S ) returns NULL. At the
RP for G, MRIB.next_hop( RP(G)) returns NULL. RP for G, MRIB.next_hop( RP(G)) returns NULL.
The function NBR( I, A ) uses information gathered through PIM Hello The function NBR( I, A ) uses information gathered through PIM Hello
messages to map the IP address A of a directly connected PIM neighbor messages to map the IP address A of a directly connected PIM neighbor
router on interface I to the primary IP address of the same router router on interface I to the primary IP address of the same router
(Section 4.3.4). The primary IP address of a neighbor is the address (Section 4.3.4). The primary IP address of a neighbor is the address
skipping to change at page 26, line 29 skipping to change at page 26, line 29
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 FSM may cause an Assert(S,G)
# or Assert(*,G) message to be sent out interface iif. # 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
This pseudocode employs several "macro" definitions: This pseudocode employs several "macro" definitions:
DirectlyConnected(S) is TRUE if the source S is on any subnet that is DirectlyConnected(S) is TRUE if the source S is on any subnet that is
skipping to change at page 27, line 22 skipping to change at page 27, line 22
inherited_olist(S,G,rpt) is the outgoing interface list for packets inherited_olist(S,G,rpt) is the outgoing interface list for packets
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.7. Section 4.5.5.
Keepalive_Period is defined in Section 4.10. Keepalive_Period is defined in Section 4.10.
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
skipping to change at page 28, line 30 skipping to change at page 28, line 30
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
OR RPF_interface(S) != RPF_interface(RP(G)) OR RPF_interface(S) != RPF_interface(RP(G))
OR inherited_olist(S,G,rpt) == NULL OR inherited_olist(S,G,rpt) == NULL
OR ( ( RPF'(S,G) == RPF'(*,G) ) AND OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
( RPF'(S,G) != NULL ) ) ( RPF'(S,G) != NULL ) )
OR ( I_Am_Assert_Loser(S,G,iif) ) { OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
Set SPTbit(S,G) to TRUE Set SPTbit(S,G) to TRUE
} }
} }
Additionally, a router can set SPTbit(S,G) to TRUE in other cases, Additionally, a router can set SPTbit(S,G) to TRUE in other cases,
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.7 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 applies:
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. switch immediately. RPF'(S,G) != NULL check ensures that SPTbit
is set only if 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.7) 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 (DR) 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
skipping to change at page 35, line 33 skipping to change at page 35, line 33
} }
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 membership
of individual downstream routers if Join suppression is disabled. A of individual downstream routers if Join suppression is disabled. A
router can advertise its willingness to disable Join suppression by router can advertise its willingness to disable Join suppression by
using the T bit in the LAN Prune Delay Hello option. Unless all PIM using the T bit in the LAN Prune Delay Hello option. Unless all PIM
routers on a link negotiate this capability, explicit tracking and routers on a link negotiate this capability, explicit tracking and
the disabling of the Join suppression mechanism are not possible. The the disabling of the Join suppression mechanism are not possible.
function for computing the state of Suppression on interface I is: The function for computing the state of Suppression on 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
} }
skipping to change at page 43, line 25 skipping to change at page 43, line 25
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.
In general, a PIM Join/Prune message should only be accepted for In general, a PIM Join/Prune 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
a Join/Prune message from a particular IP source address and it has a Join/Prune message from a particular IP source address and it has
not seen a PIM Hello message from that source address, then the not seen a PIM Hello message from that source address, then the
Join/Prune message SHOULD be discarded without further processing. In Join/Prune message SHOULD be discarded without further processing.
addition, if the Hello message from a neighbor was authenticated In addition, if the Hello message from a neighbor was authenticated
using IPsec AH (see Section 6.3), then all Join/Prune messages from using IPsec AH (see Section 6.3), then all Join/Prune messages from
that neighbor MUST also be authenticated using IPsec AH. that neighbor MUST also be authenticated using IPsec AH.
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.5.1. Receiving (*,G) Join/Prune Messages 4.5.1. Receiving (*,G) Join/Prune Messages
skipping to change at page 44, line 10 skipping to change at page 44, line 10
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.4) 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 a
downstream neighbor and is waiting to see whether the prune downstream neighbor and is waiting to see whether the prune
will be overridden by another downstream router. For will be overridden by another downstream router. For
forwarding purposes, the Prune-Pending state functions exactly forwarding purposes, the Prune-Pending state functions exactly
like the Join state. like the Join state.
In addition, the state machine uses two timers: In addition, the state machine uses two timers:
skipping to change at page 59, line 14 skipping to change at page 59, line 14
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
} }
JoinDesired(*,G) is true when the router has forwarding state that JoinDesired(*,G) is true when the router has forwarding state that
would cause it to forward traffic for G using shared tree state. Note would cause it to forward traffic for G using shared tree state.
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
skipping to change at page 66, line 25 skipping to change at page 66, line 25
The upstream (S,G) state machine remains in Joined state. If The upstream (S,G) state machine remains in Joined state. If
the Join Timer is set to expire in more than t_override the Join Timer is set to expire in more than t_override
seconds, reset it so that it expires after t_override seconds. 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. This next section describes the rules for sending triggered messages.
section describes the rules for including a Prune(S,G,rpt) message This section describes the rules for including a Prune(S,G,rpt)
with a Join(*,G). message with a Join(*,G).
When a router is going to send a Join(*,G), it should use the When a router is going to send a Join(*,G), it should use the
following pseudocode, for each (S,G) for which it has state, to following pseudocode, for each (S,G) for which it has state, to
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) ) {
skipping to change at page 89, line 25 skipping to change at page 89, line 25
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 to the RPF neighbor, the downstream
router avoids re-triggering the Assert process with every Join. A router avoids re-triggering the Assert process with every Join.
side effect of sending Joins to the Assert winner is that traffic A side effect of sending Joins to the Assert winner is that
will not switch back to the "normal" RPF neighbor until the traffic will not switch back to the "normal" RPF neighbor until
Assert times out. This will not happen until data stops flowing, the Assert times out. This will not happen until data stops
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 PIM
and IGMP/MLD joins and leaves. Without this, overrides don't and IGMP/MLD joins and leaves. Without this, overrides don't
work. 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.
skipping to change at page 95, line 20 skipping to change at page 95, line 20
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 Sparse-
Mode that provides SSM forwarding semantics. 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.7) o Upstream (S,G) state machine (Section 4.5.5)
o Downstream (S,G) state machine (Section 4.5.3) o Downstream (S,G) state machine (Section 4.5.2)
o (S,G) Assert state machine (Section 4.6.1) o (S,G) Assert state machine (Section 4.6.1)
o Hello messages, neighbor discovery, and DR election (Section 4.3) 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:
 End of changes. 41 change blocks. 
58 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/