draft-ietf-pim-bidir-06.txt   draft-ietf-pim-bidir-07.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Mark Handley/UCL INTERNET-DRAFT Mark Handley/UCL
draft-ietf-pim-bidir-06.txt Isidor Kouvelas/Cisco draft-ietf-pim-bidir-07.txt Isidor Kouvelas/Cisco
Tony Speakman/Cisco Tony Speakman/Cisco
Lorenzo Vicisano/Cisco Lorenzo Vicisano/Cisco
12 April 2004 18 July 2004
Expires: October 2004 Expires: January 2005
Bi-directional Protocol Independent Multicast (BIDIR-PIM) Bi-directional Protocol Independent Multicast (BIDIR-PIM)
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 1, line 33 skipping to change at page 1, line 33
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the IETF PIM WG. Comments should be This document is a product of the IETF PIM WG. Comments should be
addressed to the authors, or the WG's mailing list at addressed to the authors, or the WG's mailing list at pim@ietf.org.
pim@catarina.usc.edu.
Abstract Abstract
This document discusses Bi-directional PIM, a variant of PIM This document discusses Bi-directional PIM, a variant of PIM
Sparse-Mode [4] that builds bi-directional shared trees Sparse-Mode that builds bi-directional shared trees connecting
connecting multicast sources and receivers. Bi-directional multicast sources and receivers. Bi-directional trees are
trees are built using a fail-safe Designated Forwarder (DF) built using a fail-safe Designated Forwarder (DF) election
election mechanism operating on each link of a multicast mechanism operating on each link of a multicast topology.
topology. With the assistance of the DF, multicast data is With the assistance of the DF, multicast data is natively
natively forwarded from sources to the Rendezvous-Point and forwarded from sources to the Rendezvous-Point and hence along
hence along the shared tree to receivers without requiring the shared tree to receivers without requiring source-specific
source-specific state. The DF election takes place at RP state. The DF election takes place at RP discovery time and
discovery time and provides the route to the RP thus provides the route to the RP thus eliminating the requirement
eliminating the requirement for data-driven protocol events. for data-driven protocol events.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . 6
2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 8 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 8
3. Protocol Specification. . . . . . . . . . . . . . . . . 8 3. Protocol Specification. . . . . . . . . . . . . . . . . 8
3.1. BIDIR-PIM Protocol State . . . . . . . . . . . . . . 9 3.1. BIDIR-PIM Protocol State . . . . . . . . . . . . . . 9
3.1.1. General Purpose State . . . . . . . . . . . . . . 9 3.1.1. General Purpose State . . . . . . . . . . . . . . 9
skipping to change at page 3, line 32 skipping to change at page 3, line 32
3.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . 15 3.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . 15
3.4.1. Receiving (*,G) Join/Prune Messages . . . . . . . 15 3.4.1. Receiving (*,G) Join/Prune Messages . . . . . . . 15
3.4.2. Sending Join/Prune Messages . . . . . . . . . . . 18 3.4.2. Sending Join/Prune Messages . . . . . . . . . . . 18
3.5. Designated Forwarder (DF) Election . . . . . . . . . 21 3.5. Designated Forwarder (DF) Election . . . . . . . . . 21
3.5.1. DF Requirements . . . . . . . . . . . . . . . . . 21 3.5.1. DF Requirements . . . . . . . . . . . . . . . . . 21
3.5.2. DF Election description . . . . . . . . . . . . . 22 3.5.2. DF Election description . . . . . . . . . . . . . 22
3.5.2.1. Bootstrap Election . . . . . . . . . . . . . . 22 3.5.2.1. Bootstrap Election . . . . . . . . . . . . . . 22
3.5.2.2. Loser Metric Changes . . . . . . . . . . . . . 23 3.5.2.2. Loser Metric Changes . . . . . . . . . . . . . 23
3.5.2.3. Winner Metric Changes. . . . . . . . . . . . . 24 3.5.2.3. Winner Metric Changes. . . . . . . . . . . . . 24
3.5.2.4. Winner Loses Path. . . . . . . . . . . . . . . 24 3.5.2.4. Winner Loses Path. . . . . . . . . . . . . . . 24
3.5.2.5. Late Router Starting Up. . . . . . . . . . . . 25 3.5.2.5. Late Router Starting Up. . . . . . . . . . . . 24
3.5.2.6. Winner Dies. . . . . . . . . . . . . . . . . . 25 3.5.2.6. Winner Dies. . . . . . . . . . . . . . . . . . 25
3.5.3. Election Protocol Specification . . . . . . . . . 25 3.5.3. Election Protocol Specification . . . . . . . . . 25
3.5.3.1. Election State . . . . . . . . . . . . . . . . 25 3.5.3.1. Election State . . . . . . . . . . . . . . . . 25
3.5.3.2. Election Messages. . . . . . . . . . . . . . . 26 3.5.3.2. Election Messages. . . . . . . . . . . . . . . 26
3.5.3.3. Election Events. . . . . . . . . . . . . . . . 27 3.5.3.3. Election Events. . . . . . . . . . . . . . . . 27
3.5.3.4. Election Actions . . . . . . . . . . . . . . . 28 3.5.3.4. Election Actions . . . . . . . . . . . . . . . 28
3.5.3.5. Election State Transitions . . . . . . . . . . 28 3.5.3.5. Election State Transitions . . . . . . . . . . 29
3.5.4. Election Reliability Enhancements . . . . . . . . 32 3.5.4. Election Reliability Enhancements . . . . . . . . 32
3.5.5. Missing Pass. . . . . . . . . . . . . . . . . . . 32 3.5.5. Missing Pass. . . . . . . . . . . . . . . . . . . 32
3.5.6. Periodic Winner Announcement. . . . . . . . . . . 32 3.5.6. Periodic Winner Announcement. . . . . . . . . . . 32
3.6. Timers Counters and Constants. . . . . . . . . . . . 32 3.6. Timers, Counters and Constants . . . . . . . . . . . 32
3.7. BIDIR PIM Packet Formats . . . . . . . . . . . . . . 36 3.7. BIDIR-PIM Packet Formats . . . . . . . . . . . . . . 36
3.7.1. DF Election Packet Formats. . . . . . . . . . . . 36 3.7.1. DF Election Packet Formats. . . . . . . . . . . . 36
3.7.2. Backoff Message . . . . . . . . . . . . . . . . . 37 3.7.2. Backoff Message . . . . . . . . . . . . . . . . . 37
3.7.3. Pass Message. . . . . . . . . . . . . . . . . . . 38 3.7.3. Pass Message. . . . . . . . . . . . . . . . . . . 38
3.7.4. Bidir Capable PIM-Hello Option. . . . . . . . . . 39 3.7.4. Bidir Capable PIM-Hello Option. . . . . . . . . . 39
4. RP Discovery. . . . . . . . . . . . . . . . . . . . . . 39 4. RP Discovery. . . . . . . . . . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . 39 5. Security Considerations . . . . . . . . . . . . . . . . 39
5.1. Attacks Based on Forged Messages . . . . . . . . . . 39 5.1. Attacks Based on Forged Messages . . . . . . . . . . 39
5.1.1. Election of an Incorrect DF . . . . . . . . . . . 40 5.1.1. Election of an Incorrect DF . . . . . . . . . . . 40
5.1.2. Preventing Election Convergence . . . . . . . . . 41 5.1.2. Preventing Election Convergence . . . . . . . . . 41
5.2. Non-cryptographic Authentication Mechanisms. . . . . 41 5.2. Non-cryptographic Authentication Mechanisms. . . . . 41
5.2.1. Basic Access Control. . . . . . . . . . . . . . . 41 5.2.1. Basic Access Control. . . . . . . . . . . . . . . 41
5.3. Authentication Using IPsec . . . . . . . . . . . . . 41 5.3. Authentication Using IPsec . . . . . . . . . . . . . 41
5.4. Denial of Service Attacks. . . . . . . . . . . . . . 41 5.4. Denial of Service Attacks. . . . . . . . . . . . . . 41
6. Change history. . . . . . . . . . . . . . . . . . . . . 42 6. Change history. . . . . . . . . . . . . . . . . . . . . 42
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 42 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 42
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 42 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 42
9. Normative References. . . . . . . . . . . . . . . . . . 43 9. Normative References. . . . . . . . . . . . . . . . . . 43
10. Informative References . . . . . . . . . . . . . . . . 43 10. Informative References . . . . . . . . . . . . . . . . 43
11. Index. . . . . . . . . . . . . . . . . . . . . . . . . 45 11. Index. . . . . . . . . . . . . . . . . . . . . . . . . 45
List of Figures
Figure 1. Downstream group per-interface state-
machine. . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 3. Designated Forwarder election state-
machine. . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document specifies Bi-directional PIM (BIDIR-PIM), a variant of PIM This document specifies Bi-directional PIM (BIDIR-PIM), a variant of PIM
Sparse-Mode (PIM-SM) [4] that builds bi-directional shared trees Sparse-Mode (PIM-SM) [4] that builds bi-directional shared trees
connecting multicast sources and receivers. connecting multicast sources and receivers.
PIM-SM constructs uni-directional shared trees that are used to forward PIM-SM constructs uni-directional shared trees that are used to forward
data from senders to receivers of a multicast group. PIM-SM also allows data from senders to receivers of a multicast group. PIM-SM also allows
the construction of source specific trees, but this capability is not the construction of source specific trees, but this capability is not
related to the protocol described in this document. related to the protocol described in this document.
skipping to change at page 6, line 24 skipping to change at page 6, line 24
MRIB Multicast Routing Information Base. This is the multicast MRIB Multicast Routing Information Base. This is the multicast
topology table, which is typically derived from the unicast topology table, which is typically derived from the unicast
routing table, or routing protocols such as MBGP that carry routing table, or routing protocols such as MBGP that carry
multicast-specific topology information. It is used by PIM for multicast-specific topology information. It is used by PIM for
establishing the RPF interface (used in the forwarding rules). In establishing the RPF interface (used in the forwarding rules). In
PIM-SM the MRIB is also used to make decisions regarding where to PIM-SM the MRIB is also used to make decisions regarding where to
forward Join/Prune messages whereas in BIDIR-PIM it is used as a forward Join/Prune messages whereas in BIDIR-PIM it is used as a
source for routing metrics for the DF election process. source for routing metrics for the DF election process.
Rendezvous Point Address (RPA): Rendezvous Point Address (RPA):
An RPA is an address that has been configured to be used as the An RPA is an address that is used as the root of the distribution
root of the distribution tree for a range of multicast groups. The tree for a range of multicast groups. The RPA must be routable
RPA must be routable from all routers in the PIM domain. The RPA from all routers in the PIM domain. The RPA does not need to
does not need to correspond to an address for an interface of a correspond to an address for an interface of a real router. In
real router. In this respect BIDIR-PIM differs from PIM-SM that this respect BIDIR-PIM differs from PIM-SM which requires an
requires an actual router to be configured as the Rendezvous Point actual router to be configured as the Rendezvous Point (RP). Join
(RP). Join messages from receivers for a BIDIR-PIM group propagate messages from receivers for a BIDIR-PIM group propagate hop-by-hop
hop-by-hop towards the RPA. towards the RPA.
Rendezvous Point Link (RPL): Rendezvous Point Link (RPL):
An RPL for a particular RPA is the physical link to which the RPA An RPL for a particular RPA is the physical link to which the RPA
belongs. In BIDIR-PIM all multicast traffic to groups mapping to a belongs. In BIDIR-PIM all multicast traffic to groups mapping to a
specific RPA is forwarded on the RPL of that RPA. The RPL is specific RPA is forwarded on the RPL of that RPA. The RPL is
special within a BIDIR-PIM domain as it is the only link on which special within a BIDIR-PIM domain as it is the only link on which
a Designated Forwarder election does not take place (see DF a Designated Forwarder election does not take place (see DF
definition below). definition below).
Upstream Upstream
skipping to change at page 14, line 12 skipping to change at page 14, line 12
traveling packet) or if the router is the DF on the interface the packet traveling packet) or if the router is the DF on the interface the packet
arrives (upstream traveling packet). arrives (upstream traveling packet).
If the packet should be forwarded we build an outgoing interface list If the packet should be forwarded we build an outgoing interface list
for the packet. for the packet.
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 not list we've created, and if the resulting outgoing interface list is not
empty, we forward the packet out of those interfaces. empty, we forward the packet out of those interfaces.
On receipt on a data to G on interface iif: On receipt of data to G on interface iif:
if( iif == RPF_interface(RPA) || I_am_DF(RPA,I) ) { if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) {
oiflist = olist(G) (-) iif oiflist = olist(G) (-) iif
forward packet on all interfaces in oiflist forward packet on all interfaces in oiflist
} }
3.3.1. Upstream Forwarding at RP 3.3.1. Upstream Forwarding at RP
When configuring a BIDIR-PIM domain it is possible to assign the When configuring a BIDIR-PIM domain it is possible to assign the
Rendezvous Point Address (RPA) such that it does not belong to a Rendezvous Point Address (RPA) such that it does not belong to a
physical box but instead is simply a routable address. Routers that have physical box but instead is simply a routable address. Routers that have
interfaces on the RPL that the RPA belongs to will upstream forward interfaces on the RPL that the RPA belongs to will upstream forward
traffic onto the link. Joins from receivers in the domain will propagate traffic onto the link. Joins from receivers in the domain will propagate
hop-by-hop till they reach one of the routers connected to the RPL where hop-by-hop till they reach one of the routers connected to the RPL where
they will terminate (as there will be no DF elected on the RPL). they will terminate (as there will be no DF elected on the RPL).
If instead the administrator chooses to configure the RPA to be the If instead the administrator chooses to configure the RPA to be the
address of an interface of a specific router then nothing changes. That address of a physical interface of a specific router then nothing
router must still upstream forward traffic on to the RPL and behave no changes. That router must still upstream forward traffic on to the RPL
differently than any other router with an interface on the RPL. and behave no differently than any other router with an interface on the
RPL.
To configure a BIDIR-PIM network to operate in a mode similar to that of To configure a BIDIR-PIM network to operate in a mode similar to that of
PIM-SM where a single router (the RP) is acting as the root of the PIM-SM where a single router (the RP) is acting as the root of the
distribution tree, the RPA address can be configured to be the loopback distribution tree, the RPA can be configured to be the loopback
interface of a router. interface of a router.
3.3.2. Source-Only Branches 3.3.2. Source-Only Branches
Source-only branches of the distribution tree for a group G are branches Source-only branches of the distribution tree for a group G are branches
which do not lead to any receivers, but which are used to forward which do not lead to any receivers, but which are used to forward
packets traveling upstream from sources towards the RPL. Routers along packets traveling upstream from sources towards the RPL. Routers along
source-only branches only have the RPF_interface to the RPA in their source-only branches only have the RPF_interface to the RPA in their
olist for G and hence do not need to maintain any group specific state. olist for G and hence do not need to maintain any group specific state.
Upstream forwarding can be performed using only RPA specific state. An Upstream forwarding can be performed using only RPA specific state. An
implementation may decide to maintain group state for source-only implementation may decide to maintain group state for source-only
branches for accounting or performance reasons. However, doing so
requires data-driven events thus sacrificing one of tha main benefits of branches for accounting or performance reasons. However, doing so
Bidir PIM. requires data-driven events (to discover the groups with active sources)
thus sacrificing one of the main benefits of Bidir PIM.
3.3.3. Directly Connected Sources 3.3.3. Directly Connected Sources
A major advantage of using a Designated Forwarder in BIDIR-PIM compared A major advantage of using a Designated Forwarder in BIDIR-PIM compared
to PIM-SM is that special treatment is no longer required for sources to PIM-SM is that special treatment is no longer required for sources
that are directly connected to a router. Data from such sources does not that are directly connected to a router. Data from such sources does not
need to be differentiated from other multicast traffic and will need to be differentiated from other multicast traffic and will
automatically be picked up by the DF and forwarded upstream. This automatically be picked up by the DF and forwarded upstream. This
removes the need for performing a directly-connected-source check for removes the need for performing a directly-connected-source check for
data to groups that do not have existing state. data to groups that do not have existing state.
skipping to change at page 15, line 37 skipping to change at page 15, line 38
Groups. When processing a received Join/Prune message, each Joined or Groups. When processing a received Join/Prune message, each Joined or
Pruned Group is effectively considered individually by applying the Pruned Group is effectively considered individually by applying the
following state machines. When considering a Join/Prune message whose following state machines. When considering a Join/Prune message whose
PIM Destination field addresses this router, (*,G) Joins and Prunes can PIM Destination field addresses this router, (*,G) Joins and Prunes can
affect the downstream state machine. When considering a Join/Prune affect the downstream state machine. When considering a Join/Prune
message whose PIM Destination field addresses another router, most Join message whose PIM Destination field addresses another router, most Join
or Prune entries could affect the upstream state machine. or Prune entries could affect the upstream state machine.
3.4.1. Receiving (*,G) Join/Prune Messages 3.4.1. Receiving (*,G) Join/Prune Messages
When a router receives a Join(*,G) or Prune(*,G) it must first check to When a router receives a Join(*,G) or Prune(*,G) it MUST first check to
see whether the RP address in the message matches RPA(G) (the router's see whether the RP address in the message matches RPA(G) (the router's
idea of what the Rendezvous Point Address is). If the RP address in the idea of what the Rendezvous Point Address is). If the RP address in the
message does not match RPA(G) the Join or Prune MUST be silently message does not match RPA(G) the Join or Prune MUST be silently
dropped. dropped.
If a router has no RPA information for the group (e.g. has not recently
received a BSR message) then it MAY choose to accept Join(*,G) or
Prune(*,G) and treat the RP address in the message as RPA(G). If the
newly discovered RPA did not previously exist for any other group, a DF
election has to be initiated.
Note that a router will process a Join(*,G) targeted to itself even if
it is not the DF for RP(G) on the interface on which the message was
received. This is an optimisation to eliminate the Join delay of one
Join period (t_periodic) in the case where a new DF processes the
received Pass and Join messages in reverse order. The BIDIR-PIM
forwarding logic will ensure that data packets are not forwarded on such
an interface while the router is no the DF (unless it is the
RPF_interface towards the RPA).
The per-interface state-machine for receiving (*,G) Join/Prune Messages The per-interface state-machine for receiving (*,G) Join/Prune Messages
is given below. There are three states: 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. If the router is the DF on The interface has (*,G) Join state. If the router is the DF on
this interface (I_am_DF(RPA(G),I) is TRUE), the Join state this interface (I_am_DF(RPA(G),I) is TRUE), the Join state
will cause us to forward packets destined for G on this will cause us to forward packets destined for G on this
skipping to change at page 16, line 27 skipping to change at page 17, line 5
ExpiryTimer (ET) ExpiryTimer (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 ExpiryTimer causes the interface state to revert Expiry of the ExpiryTimer causes the interface state to revert
to NoInfo for this group. to NoInfo for this group.
PrunePendingTimer (PPT) PrunePendingTimer (PPT)
This timer is set when a valid Prune(*,G) is received. Expiry This timer is set when a valid Prune(*,G) is received. Expiry
of the PrunePendingTimer causes the interface state to revert of the PrunePendingTimer causes the interface state to revert
to NoInfo for this group. to NoInfo for this group.
+-----------------------------------+ Figure 1: Downstream group per-interface state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 1: Downstream group per-interface state-machine
In tabular form, the group per-interface state-machine is:
+----------+------------------------------------------------------------+ +----------------+------------------------------------------------------+
| | Event | | | Prev State |
| +----------+------------+-----------+------------+-----------+ | Event +----------------+------------------+------------------+
Prev State |Receive |Receive |Prune |Expiry Stop Being | | | NoInfo (NI) | Join (J) | Prune Pending |
| |Join(*,G) |Prune(*,G) |Pending |Timer DF on I | | | | | (PP) |
| | | |Timer |Expires | | +----------------+----------------+------------------+------------------+
| | | |Expires | | | | | -> J state | -> J state | -> J state |
+----------+----------+------------+-----------+------------+-----------+ | Receive | start Expiry | restart Expiry | restart Expiry |
| |-> J state|- |- |- + | | Join(*,G) | Timer | Timer | Timer; stop |
NoInfo |start | | | | | | | | | Prune Pending |
(NI) |Expiry | | | | | | | | | Timer |
| |Timer | | | | | +----------------+----------------+------------------+------------------+
+----------+----------+------------+-----------+------------+-----------+ | Receive | - | -> PP state | -> PP state |
| |-> J state|-> PP state |- |-> NI state +> NI state | | Prune(*,G) | | start Prune | |
Join (J) |restart |start Prune | | | | | | | Pending Timer | |
| |Expiry |Pending | | | | +----------------+----------------+------------------+------------------+
| |Timer |Timer | | | | | Prune Pending | - | - | -> NI state |
+----------+----------+------------+-----------+------------+-----------+ | Timer Expires | | | Send Prune- |
| |-> J state|-> PP state |-> NI state|-> NI state +> NI state | | | | | Echo(*,G) |
| |restart | |Send Prune-| | | +----------------+----------------+------------------+------------------+
Prune |Expiry | |Echo(*,G) | | | | Expiry Timer | - | -> NI state | -> NI state |
Pending |Timer; | | | | | | Expires | | | |
(PP) |stop Prune| | | | | +----------------+----------------+------------------+------------------+
| |Pending | | | | | | Stop Being DF | - | -> NI state | -> NI state |
| |Timer | | | | | | on I | | | |
+----------+----------+------------+-----------+------------+-----------+ +----------------+----------------+------------------+------------------+
The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply
receiving a Join or Prune targeted to this router's address on the receiving a Join or Prune targeted to this router's address on the
received interface. If the destination address is not correct, these received interface. If the destination address is not correct, these
state transitions in this state machine must not occur, although seeing state transitions in this state machine must not occur, although seeing
such a packet may cause state transitions in other state machines. such a packet may cause state transitions in other state machines.
On unnumbered interfaces on point-to-point links, the router's address On unnumbered interfaces on point-to-point links, the router's address
should be the same as the source address it chose for the hello packet should be the same as the source address it chose for the Hello packet
it sent over that interface. However on point-to-point links we also it sent over that interface. However, on point-to-point links we also
recommend that PIM messages with a destination address of all zeros are RECOMMEND that PIM messages with a destination address of all zeros are
also accepted. also accepted.
The transition event "Stop being DF" implies a DF re-election taking The transition event "Stop being DF" implies a DF re-election taking
place on this router interface for RPA(G) and the router changing status place on this router interface for RPA(G) and the router changing status
from being the active DF to being a non-DF router (the value of the from being the active DF to being a non-DF router (the value of the
I_am_DF macro changing to FALSE). I_am_DF macro changing to FALSE).
When ExpiryTimer is started or restarted, it is set to the HoldTime from When ExpiryTimer is started or restarted, it is set to the HoldTime from
the triggering received Join/Prune message. the triggering received Join/Prune message.
skipping to change at page 20, line 29 skipping to change at page 20, line 29
| | | Send Prune(*,G) | | | | Send Prune(*,G) |
+----------------------+------------------------+-----------------------+ +----------------------+------------------------+-----------------------+
In addition, we have the following transitions which occur within the In addition, we have the following transitions which occur within the
Joined state: Joined state:
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
|Timer Expires | See Join(*,G) | See Prune(*,G) | RPF_DF(RPA(G)) | |Timer Expires | See Join(*,G) | See Prune(*,G) | RPF_DF(RPA(G)) |
| | to | to | changes | | | to | to | GenID changes |
| | RPF_DF(RPA(G)) | RPF_DF(RPA(G)) | | | | RPF_DF(RPA(G)) | RPF_DF(RPA(G)) | |
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
|Send | Increase Timer | Decrease Timer | Decrease Timer | |Send | Increase Timer | Decrease Timer | Decrease Timer |
|Join(*,G); Set | to | to t_override | to t_override | |Join(*,G); Set | to | to t_override | to t_override |
|Timer to | t_suppressed | | | |Timer to | t_suppressed | | |
|t_periodic | | | | |t_periodic | | | |
+-----------------+-----------------+-----------------+-----------------+ +-----------------+-----------------+-----------------+-----------------+
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| In Joined (J) State | | In Joined (J) State |
skipping to change at page 24, line 36 skipping to change at page 24, line 36
the link, advertising the new metric. Routers that receive this the link, advertising the new metric. Routers that receive this
announcement but have a better metric may respond with an Offer message announcement but have a better metric may respond with an Offer message
which results in the same handoff procedure described above. All which results in the same handoff procedure described above. All
routers assume the DF has not changed until they see a Pass or Winner routers assume the DF has not changed until they see a Pass or Winner
message indicating the change. message indicating the change.
There is no pressure to make this handoff quickly if the acting DF still There is no pressure to make this handoff quickly if the acting DF still
has a path to the RPL. The old path may now be suboptimal but it will has a path to the RPL. The old path may now be suboptimal but it will
still work while the re-election is in progress. still work while the re-election is in progress.
If the routing metric at the DF changes to a better value, a single
Winner message is sent advertising the new metric.
3.5.2.4. Winner Loses Path 3.5.2.4. Winner Loses Path
If a router's RPF Interface to the RPA switches to be on a link for If a router's RPF Interface to the RPA switches to be on a link for
which it is acting as the DF, then it can no longer provide forwarding which it is acting as the DF, then it can no longer provide forwarding
services for that link. It therefore immediately stops being the DF and services for that link. It therefore immediately stops being the DF and
restarts the election. As its path to the RPA is through the link, an restarts the election. As its path to the RPA is through the link, an
infinite metric is used in the Offer message it sends. infinite metric is used in the Offer message it sends.
Note: At this stage the old DF will have a hint at a possible RPF
neighbor on the link indicated by the new MRIB next-hop. The old DF
could use this next-hop hint in a Pass message but this adds unnecessary
complication to the election process.
3.5.2.5. Late Router Starting Up 3.5.2.5. Late Router Starting Up
A late router starting up after the DF election process has completed A late router starting up after the DF election process has completed
will have no immediate knowledge of the election outcome. As a result, will have no immediate knowledge of the election outcome. As a result,
it will start advertising its metric in Offer messages. As soon as this it will start advertising its metric in Offer messages. As soon as this
happens, the currently elected DF will respond with a Winner message if happens, the currently elected DF will respond with a Winner message if
its metric is better than the metric in the Offer message, or with a its metric is better than the metric in the Offer message, or with a
Backoff message if its metric worse than the metric in the Offer Backoff message if its metric is worse than the metric in the Offer
message. message.
3.5.2.6. Winner Dies 3.5.2.6. Winner Dies
Whenever the DF dies, a new DF has to be elected. The speed at which Whenever the DF dies, a new DF has to be elected. The speed at which
this can be achieved depends on whether there are any downstream routers this can be achieved depends on whether there are any downstream routers
on the link. on the link.
If there are downstream routers, typically their MRIB reported next-hop If there are downstream routers, typically their MRIB reported next-hop
before the DF dies will be the DF itself. They will therefore notice before the DF dies will be the DF itself. They will therefore notice
skipping to change at page 26, line 7 skipping to change at page 25, line 47
The state machine has the following four states: The state machine has the following four states:
Offer Offer
Initial election state. When in the Offer state a router Initial election state. When in the Offer state a router
thinks it can eventually become the winner and periodically thinks it can eventually become the winner and periodically
generates Offer messages. generates Offer messages.
Lose In this state the router knows that there either is a Lose In this state the router knows that there either is a
different election winner or that no router on the link has a different election winner or that no router on the link has a
path to the RP. path to the RPA.
Winner Winner
The router is the acting DF without any contest. The router is the acting DF without any contest.
Backoff Backoff
The router is the acting DF but another router has made a bid The router is the acting DF but another router has made a bid
to take over. to take over.
In the state machine a router is considered to be an acting DF if it is In the state machine a router is considered to be an acting DF if it is
in the Win or Backoff states. in the Win or Backoff states.
skipping to change at page 26, line 36 skipping to change at page 26, line 32
DF election-Timer (DFT) DF election-Timer (DFT)
Used to schedule transmission of Offer, Winner and Pass Used to schedule transmission of Offer, Winner and Pass
messages. messages.
Message-Count (MC) Message-Count (MC)
Used to maintain the number of times an Offer or Winner Used to maintain the number of times an Offer or Winner
message has been transmitted. message has been transmitted.
Best-Offer Best-Offer
Used by the DF to record the identity and advertised metrics Used by the DF to record the identity and advertised metrics
of the router has made the last offer for use when sending the of the router that has made the last offer, for use when
Pass message. sending the Path message.
3.5.3.2. Election Messages 3.5.3.2. Election Messages
The election process uses the following PIM control messages the packet The election process uses the following PIM control messages, the packet
format of which is described in section 3.7: format of which is described in section 3.7:
Offer (OfferingID, Metric) Offer (OfferingID, Metric)
Sent by routers that believe they have a better metric to the Sent by routers that believe they have a better metric to the
RPA than the metric that has been on offer so far. RPA than the metric that has been on offer so far.
Winner (DF-ID, DF-Metric) Winner (DF-ID, DF-Metric)
Sent by a router when assuming the role of the DF or when re- Sent by a router when assuming the role of the DF or when re-
asserting in response to worse offers. asserting in response to worse offers.
skipping to change at page 29, line 12 skipping to change at page 29, line 12
o On receipt of a Backoff message set the DF to be the originator o On receipt of a Backoff message set the DF to be the originator
of the message and record its metrics. of the message and record its metrics.
3.5.3.5. Election State Transitions 3.5.3.5. Election State Transitions
When a Designated Forwarder election is initiated the starting state is When a Designated Forwarder election is initiated the starting state is
the Offer state, the message counter (MC) is set to zero and the DF the Offer state, the message counter (MC) is set to zero and the DF
election Timer (DFT) is set to OPlow (see section 3.6 for a definition election Timer (DFT) is set to OPlow (see section 3.6 for a definition
of timer values). of timer values).
+-----------------------------------+ Figure 3: Designated Forwarder election state-machine in tabular form
| Figures omitted from text version |
+-----------------------------------+
Figure 3: Designated Forwarder election state-machine
In tabular form, the state machine is:
+-------------++--------------------------------------------------------+ +-------------++--------------------------------------------------------+
| || Event | | || Event |
| Prev State ++------------------+------------------+------------------+ | Prev State ++------------------+------------------+------------------+
| || Recv better | Recv better | Recv better | | || Recv better | Recv better | Recv better |
| || Pass / Win | Backoff | Offer | | || Pass / Win | Backoff | Offer |
+-------------++------------------+------------------+------------------+ +-------------++------------------+------------------+------------------+
| || -> Lose | - | - | | || -> Lose | - | - |
| Offer || DF = Sender or | DFT = BOperiod | DFT = OPhigh; | | Offer || DF = Sender or | DFT = BOperiod | DFT = OPhigh; |
| || Target; Stop | + OPlow; MC = | MC = 0 | | || Target; Stop | + OPlow; MC = | MC = 0 |
skipping to change at page 32, line 38 skipping to change at page 32, line 38
router in a rate-limited manner to alert the operator. router in a rate-limited manner to alert the operator.
3.5.6. Periodic Winner Announcement 3.5.6. Periodic Winner Announcement
An additional degree of safety can be achieved by having the DF for each An additional degree of safety can be achieved by having the DF for each
RPA periodically announce its status in a Winner message. Transmission RPA periodically announce its status in a Winner message. Transmission
of the periodic Winner message can be restricted to occur only for RPAs of the periodic Winner message can be restricted to occur only for RPAs
which have active groups, thus avoiding the periodic control traffic in which have active groups, thus avoiding the periodic control traffic in
areas of the network without senders or receivers for a particular RPA. areas of the network without senders or receivers for a particular RPA.
3.6. Timers Counters and Constants 3.6. Timers, Counters and Constants
BIDIR-PIM maintains the following timers, as discussed in section 3.1. BIDIR-PIM maintains the following timers, as discussed in section 3.1.
All timers are countdown timers - they are set to a value and count down All timers are countdown timers - they are set to a value and count down
to zero, at which point they typically trigger an action. Of course to zero, at which point they typically trigger an action. Of course
they can just as easily be implemented as count-up timers, where the they can just as easily be implemented as count-up timers, where the
absolute expiry time is stored and compared against a real-time clock, absolute expiry time is stored and compared against a real-time clock,
but the language in this specification assumes that they count downwards but the language in this specification assumes that they count downwards
to zero. to zero.
Per Rendezvous-Point Address (RPA): Per Rendezvous-Point Address (RPA):
skipping to change at page 34, line 23 skipping to change at page 34, line 23
| | | messages. | | | | messages. |
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| Backoff_Period | 1 sec | Period that acting | | Backoff_Period | 1 sec | Period that acting |
| | | DF waits between | | | | DF waits between |
| | | receiving a better | | | | receiving a better |
| | | Offer and sending | | | | Offer and sending |
| | | the Pass message | | | | the Pass message |
| | | to transfer DF | | | | to transfer DF |
| | | responsibility. | | | | responsibility. |
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| OPLow | rand(0.5, 1) * | Range of actual | | OPlow | rand(0.5, 1) * | Range of actual |
| | Offer_Period | randomised value | | | Offer_Period | randomised value |
| | | used between | | | | used between |
| | | repeated messages. | | | | repeated messages. |
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
| OPHigh | Election_Robustness | Interval to wait | | OPhigh | Election_Robustness | Interval to wait |
| | * Offer_Period | in order to give a | | | * Offer_Period | in order to give a |
| | | chance to a router | | | | chance to a router |
| | | with a better | | | | with a better |
| | | Offer to become | | | | Offer to become |
| | | the DF. | | | | the DF. |
+--------------------+-------------------------+------------------------+ +--------------------+-------------------------+------------------------+
Timer Names: Join Expiry Timer (ET(G,I)) Timer Names: Join Expiry Timer (ET(G,I))
+----------------+----------------+-------------------------------------+ +----------------+----------------+-------------------------------------+
skipping to change at page 35, line 24 skipping to change at page 35, line 24
| | | to override the | | | | to override the |
| | | join or prune | | | | join or prune |
+--------------------------+--------------------+-----------------------+ +--------------------------+--------------------+-----------------------+
Note that the value of the J/P Override Interval is interface specific Note that the value of the J/P Override Interval is interface specific
and depends on both the Propagation_Delay and the Override_Interval and depends on both the Propagation_Delay and the Override_Interval
values that may change when Hello messages are received [4]. values that may change when Hello messages are received [4].
Timer Names: Upstream Join Timer (JT(G)) Timer Names: Upstream Join Timer (JT(G))
+-------------+--------------------+------------------------------------+ +-------------+--------------------+-------------------------------------+
|Value Name |Value |Explanation | |Value Name |Value |Explanation |
+-------------+--------------------+------------------------------------+ +-------------+--------------------+-------------------------------------+
|t_periodic |Default: 60 secs |Period between Join/Prune Messages | |t_periodic |Default: 60 secs |Period between Join/Prune Messages |
+-------------+--------------------+------------------------------------+ +-------------+--------------------+-------------------------------------+
|t_suppressed |rand(1.1 * |Suppression period when someone | |t_suppressed |rand(1.1 * |Suppression period when someone |
| |t_periodic, 1.4 * |else sends a J/P message so we | | |t_periodic, 1.4 * |else sends a J/P message so we |
| |t_periodic) |don't need to do so. | | |t_periodic) |don't need to do so. |
+-------------+--------------------+------------------------------------+ +-------------+--------------------+-------------------------------------+
|t_override |rand(0, 0.9 * J/P |Randomized delay to prevent | |t_override |rand(0, 0.9 * J/P |Randomized delay to prevent |
| |Override Interval) |response implosion when sending a | | |Override Interval) |response implosion when sending a |
| | |join message to override someone | | | |join message to override someone |
| | |else's prune message. | | | |else's prune message. |
+-------------+--------------------+------------------------------------+ +-------------+--------------------+-------------------------------------+
For more information about these values refer to the PIM-SM [4] For more information about these values refer to the PIM-SM [4]
documentation. documentation.
Constant Name: DF Election Robustness Constant Name: DF Election Robustness
+--------------------------+-------------------+------------------------+ +--------------------------+-------------------+------------------------+
| Constant Name | Value | Explanation | | Constant Name | Value | Explanation |
+--------------------------+-------------------+------------------------+ +--------------------------+-------------------+------------------------+
| Election_Robustness | Default: 3 | Minimum number of | | Election_Robustness | Default: 3 | Minimum number of |
| | | election messages | | | | election messages |
| | | that must be lost | | | | that must be lost |
| | | in order for | | | | in order for |
| | | election to fail. | | | | election to fail. |
+--------------------------+-------------------+------------------------+ +--------------------------+-------------------+------------------------+
3.7. BIDIR PIM Packet Formats 3.7. BIDIR-PIM Packet Formats
This section describes the details of the packet formats for BIDIR-PIM This section describes the details of the packet formats for BIDIR-PIM
control messages. BIDIR-PIM shares a number of control messages in control messages. BIDIR-PIM shares a number of control messages in
common with PIM-SM [4]. These include the Hello and Join/Prune messages common with PIM-SM [4]. These include the Hello and Join/Prune messages
as well as the format for the Encoded-Unicast address. For details on as well as the format for the Encoded-Unicast address. For details on
the format of these packets please refer to the PIM-SM documentation. the format of these packets please refer to the PIM-SM documentation.
Here we will only define the additional packets that are introduced by Here we will only define the additional packets that are introduced by
BIDIR-PIM. These are the packets used in the DF election process as BIDIR-PIM. These are the packets used in the DF election process as
well as the Bidir_Capable PIM-Hello option. well as the Bidir_Capable PIM-Hello option.
3.7.1. DF Election Packet Formats 3.7.1. DF Election Packet Formats
All PIM control messages have IP protocol number 103. All PIM control messages have IP protocol number 103.
BIDIR-PIM messages are multicast with TTL 1 to the `ALL-PIM-ROUTERS' BIDIR-PIM messages are multicast with TTL 1 to the `ALL-PIM-ROUTERS'
group `224.0.0.13'. group The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6 `ALL-
PIM-ROUTERS' group is `ff02::d'.
All DF election BIDIR-PIM control messages share the common header All DF election BIDIR-PIM control messages share the common header
below: below:
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 |Subtype| Rsvd | Checksum | |PIM Ver| Type |Subtype| Rsvd | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address | | Encoded-Unicast-RP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Sender Metric Preference | | Sender Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Metric | | Sender Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Ver PIM Ver
PIM Version number is 2. PIM Version number is 2.
Type All DF-Election PIM control messages share the PIM message Type of Type All DF-Election PIM control messages share the PIM message Type of
10. 10.
skipping to change at page 37, line 28 skipping to change at page 37, line 28
Rsvd Set to zero on transmission. Ignored upon receipt. Rsvd Set to zero on transmission. Ignored upon receipt.
Checksum Checksum
The checksum is standard IP checksum, i.e. the 16-bit one's The checksum is standard IP checksum, i.e. the 16-bit one's
complement of the one's complement sum of the entire PIM message. complement of the one's complement sum of the entire PIM message.
For computing the checksum, the checksum field is zeroed. For computing the checksum, the checksum field is zeroed.
RP-Address RP-Address
The bidir RPA for which the election is taking place (note that the The bidir RPA for which the election is taking place (note that the
length of this field is more than 32 bits). length of this field will be different than 32 bits depending on
the family and encoding of the address).
Sender Metric Preference Sender Metric Preference
Preference value assigned to the unicast routing protocol that the Preference value assigned to the unicast routing protocol that the
message sender used to obtain the route to the RPA. message sender used to obtain the route to the RPA.
Sender Metric Sender Metric
The unicast routing table metric used by the message sender to The unicast routing table metric used by the message sender to
reach the RPA. The metric is in units applicable to the unicast reach the RPA. The metric is in units applicable to the unicast
routing protocol used. routing protocol used.
skipping to change at page 38, line 8 skipping to change at page 38, line 8
have the extra fields described below. have the extra fields described below.
3.7.2. Backoff Message 3.7.2. Backoff Message
The Backoff message uses the following fields in addition to the common The Backoff message uses the following fields in addition to the common
election message format described above. election message format described above.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-Offering-Address | | Encoded-Unicast-Offering-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Offering Metric Preference | | Offering Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offering Metric | | Offering Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval | | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Offering Address Offering Address
The address of the router that made the last (best) Offer (note The address of the router that made the last (best) Offer (note
that the length of this field is more than 32 bits). that the length of this field will be different than 32 bits
depending on the family and encoding of the address).
Offering Metric Preference Offering Metric Preference
Preference value assigned to the unicast routing protocol that the Preference value assigned to the unicast routing protocol that the
offering router used to obtain the route to the RPA. offering router used to obtain the route to the RPA.
Offering Metric Offering Metric
The unicast routing table metric used by the offering router to The unicast routing table metric used by the offering router to
reach the RPA. The metric is in units applicable to the unicast reach the RPA. The metric is in units applicable to the unicast
routing protocol used. routing protocol used.
skipping to change at page 38, line 42 skipping to change at page 38, line 43
worse metrics than the offering router. worse metrics than the offering router.
3.7.3. Pass Message 3.7.3. Pass Message
The Pass message uses the following fields in addition to the common The Pass message uses the following fields in addition to the common
election fields described above. election fields described above.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-New-Winner-Address | | Encoded-Unicast-New-Winner-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| New Winner Metric Preference | | New Winner Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Winner Metric | | New Winner Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
New Winner Address New Winner Address
The address of the router that made the last (best) Offer (note The address of the router that made the last (best) Offer (note
that the length of this field is more than 32 bits). that the length of this field will be different than 32 bits
depending on the family and encoding of the address).
New Winner Metric Preference New Winner Metric Preference
Preference value assigned to the unicast routing protocol that the Preference value assigned to the unicast routing protocol that the
offering router used to obtain the route to the RPA. offering router used to obtain the route to the RPA.
New Winner Metric New Winner Metric
The unicast routing table metric used by the offering router to The unicast routing table metric used by the offering router to
reach the RPA. The metric is in units applicable to the unicast reach the RPA. The metric is in units applicable to the unicast
routing protocol used. routing protocol used.
skipping to change at page 39, line 35 skipping to change at page 39, line 36
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 = 22 | Length = 0 | | Type = 22 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. RP Discovery 4. RP Discovery
Routers discover that a range of multicast group addresses operates in Routers discover that a range of multicast group addresses operates in
bi-directional mode and the address of the Rendezvous-Point address bi-directional mode and the address of the Rendezvous-Point address
(RPA) serving the group range either through static configuration or (RPA) serving the group range either through static configuration or
using an automatic RP discovery mechanism like the PIM Bootsrtap using an automatic RP discovery mechanism like the PIM Bootstrap
mechanism (BSR). [9] or Auto-RP. mechanism (BSR) [9] or Auto-RP.
5. Security Considerations 5. Security Considerations
The IPsec [5] authentication header MAY be used to provide data The IPsec [5] authentication header MAY be used to provide data
integrity protection and group-wise data origin authentication of BIDIR- integrity protection and group-wise data origin authentication of BIDIR-
PIM protocol messages. Authentication of BIDIR-PIM messages can protect PIM protocol messages. Authentication of BIDIR-PIM messages can protect
against unwanted behaviour caused by unauthorized or altered BIDIR-PIM against unwanted behaviour caused by unauthorized or altered BIDIR-PIM
messages. messages.
5.1. Attacks Based on Forged Messages 5.1. Attacks Based on Forged Messages
As in PIM Sparse-Mode, the extent of possible damage depends on the type As in PIM Sparse-Mode, the extent of possible damage depends on the type
of counterfeit messages accepted. BIDIR-PIM only uses link-local of counterfeit messages accepted. BIDIR-PIM only uses link-local
multicast messages sent to the ALL_PIM_ROUTERS address, hence attacks multicast messages sent to the ALL_PIM_ROUTERS address, hence attacks
can only be carried out by directly connected nodes, or with the
can only be carried out by directly connected nodes, or with the
complicity of directly connected routers. complicity of directly connected routers.
Some of the BIDIR-PIM protocol messages (Join/Prune and Hello) are Some of the BIDIR-PIM protocol messages (Join/Prune and Hello) are
identical, both in format and functionality, to the respective messages identical, both in format and functionality, to the respective messages
used in PIM-SM. Security considerations for these messages are to be used in PIM-SM. Security considerations for these messages are to be
found in [4]. Other messages (DF-election messages) are specific to found in [4]. Other messages (DF-election messages) are specific to
BIDIR-PIM and will be discussed in the following paragraphs. BIDIR-PIM and will be discussed in the following paragraphs.
By forging DF-election messages an attacker can disrupt the election of By forging DF-election messages an attacker can disrupt the election of
the Designated Forwarder on a link in two different ways: the Designated Forwarder on a link in two different ways:
skipping to change at page 41, line 38 skipping to change at page 41, line 38
In BIDIR-PIM this is generally feasible only for receivers, as sources In BIDIR-PIM this is generally feasible only for receivers, as sources
can send to the multicast group without the need for routers to detect can send to the multicast group without the need for routers to detect
their activity and create source-specific state. However it is possible their activity and create source-specific state. However it is possible
to modify the standard BIDIR-PIM behaviour, in a backward compatible to modify the standard BIDIR-PIM behaviour, in a backward compatible
way, to allow per-source access control. The tradeoff would be protocol way, to allow per-source access control. The tradeoff would be protocol
simplicity, memory and processing requirements. simplicity, memory and processing requirements.
5.3. Authentication Using IPsec 5.3. Authentication Using IPsec
The IPsec [5] transport mode using the Authentication Header (AH) is the Just like for PIM-SM, the IPsec [5] transport mode using the
RECOMMENDED method to prevent the above attacks against BIDIR-PIM. Authentication Header (AH) is the recommended method to prevent the
above attacks against BIDIR-PIM.
It is RECOMMENDED that IPsec authentication be applied to all BIDIR-PIM It is recommended that IPsec authentication be applied to all BIDIR-PIM
protocol messages. The specification on how this is done is to be found protocol messages. The specification on how this is done is to be found
in [4]. specifically the authentication of PIM-SM link-local messages, in [4]. specifically the authentication of PIM-SM link-local messages,
described in [4] applies to all BIDIR-PIM messages as well. described in [4] applies to all BIDIR-PIM messages as well.
5.4. Denial of Service Attacks 5.4. Denial of Service Attacks
The denial of service attack based on forged Join described in [4] also The denial of service attack based on forged Join described in [4] also
apply to BIDIR-PIM. apply to BIDIR-PIM.
6. Change history 6. Change history
>From 06 to 07: Minor corrections in response to WG last call comments.
>From 05 to 06: >From 05 to 06:
Minor editorial corrections. Minor editorial corrections.
>From 03 to 05: >From 03 to 05:
RP concept replaced by RP Address (RPA) and RP Link (RPL). No DF RP concept replaced by RP Address (RPA) and RP Link (RPL). No DF
election on RPL. RP forwards upstream on RPL. Accept joins even if not election on RPL. RP forwards upstream on RPL. Accept joins even if not
DF but do not forward. Added event description for DF election state DF but do not forward. Added event description for DF election state
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/