idnits 2.17.1 draft-ietf-pim-bidir-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1865. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 243 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 488: '..._Capable PIM-Hello option that MUST be...' RFC 2119 keyword, line 608: '...) or Prune(*,G) it MUST first check to...' RFC 2119 keyword, line 611: '...(G) the Join or Prune MUST be silently...' RFC 2119 keyword, line 615: '...message) then it MAY choose to accept ...' RFC 2119 keyword, line 892: '...nterface then it MUST advertise the MR...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 October 2005) is 6758 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1784, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1803, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2283 (ref. '6') (Obsoleted by RFC 2858) -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. '8') (Obsoleted by RFC 4601, RFC 5059) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PIM WG 2 INTERNET-DRAFT Mark Handley/UCL 3 draft-ietf-pim-bidir-08.txt Isidor Kouvelas/Cisco 4 Tony Speakman/Cisco 5 Lorenzo Vicisano/Cisco 6 22 October 2005 7 Expires: April 2006 9 Bi-directional Protocol Independent Multicast (BIDIR-PIM) 11 Status of this Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have 15 been or will be disclosed, and any of which he or she becomes aware will 16 be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a product of the IETF PIM WG. Comments should be 34 addressed to the authors, or the mailing list at pim@ietf.org. 36 Abstract 38 This document discusses Bi-directional PIM, a variant of PIM 39 Sparse-Mode that builds bi-directional shared trees connecting 40 multicast sources and receivers. Bi-directional trees are 41 built using a fail-safe Designated Forwarder (DF) election 42 mechanism operating on each link of a multicast topology. 43 With the assistance of the DF, multicast data is natively 44 forwarded from sources to the Rendezvous-Point and hence along 45 the shared tree to receivers without requiring source-specific 46 state. The DF election takes place at RP discovery time and 47 provides the route to the RP thus eliminating the requirement 48 for data-driven protocol events. 50 Table of Contents 52 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 5 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . 6 55 2.2. Pseudocode Notation. . . . . . . . . . . . . . . . . 8 56 3. Protocol Specification. . . . . . . . . . . . . . . . . 8 57 3.1. BIDIR-PIM Protocol State . . . . . . . . . . . . . . 9 58 3.1.1. General Purpose State . . . . . . . . . . . . . . 9 59 3.1.2. RPA State . . . . . . . . . . . . . . . . . . . . 10 60 3.1.3. Group State . . . . . . . . . . . . . . . . . . . 10 61 3.1.4. State Summarization Macros. . . . . . . . . . . . 11 62 3.2. PIM Neighbor Discovery . . . . . . . . . . . . . . . 12 63 3.3. Data Packet Forwarding Rules . . . . . . . . . . . . 13 64 3.3.1. Upstream Forwarding at RP . . . . . . . . . . . . 14 65 3.3.2. Source-Only Branches. . . . . . . . . . . . . . . 14 66 3.3.3. Directly Connected Sources. . . . . . . . . . . . 15 67 3.4. PIM Join/Prune Messages. . . . . . . . . . . . . . . 15 68 3.4.1. Receiving (*,G) Join/Prune Messages . . . . . . . 15 69 3.4.2. Sending Join/Prune Messages . . . . . . . . . . . 18 70 3.5. Designated Forwarder (DF) Election . . . . . . . . . 21 71 3.5.1. DF Requirements . . . . . . . . . . . . . . . . . 21 72 3.5.2. DF Election description . . . . . . . . . . . . . 22 73 3.5.2.1. Bootstrap Election . . . . . . . . . . . . . . 22 74 3.5.2.2. Loser Metric Changes . . . . . . . . . . . . . 23 75 3.5.2.3. Winner Metric Changes. . . . . . . . . . . . . 24 76 3.5.2.4. Winner Loses Path. . . . . . . . . . . . . . . 24 77 3.5.2.5. Late Router Starting Up. . . . . . . . . . . . 24 78 3.5.2.6. Winner Dies. . . . . . . . . . . . . . . . . . 25 79 3.5.3. Election Protocol Specification . . . . . . . . . 25 80 3.5.3.1. Election State . . . . . . . . . . . . . . . . 25 81 3.5.3.2. Election Messages. . . . . . . . . . . . . . . 26 82 3.5.3.3. Election Events. . . . . . . . . . . . . . . . 27 83 3.5.3.4. Election Actions . . . . . . . . . . . . . . . 28 84 3.5.3.5. Election State Transitions . . . . . . . . . . 29 85 3.5.4. Election Reliability Enhancements . . . . . . . . 32 86 3.5.5. Missing Pass. . . . . . . . . . . . . . . . . . . 32 87 3.5.6. Periodic Winner Announcement. . . . . . . . . . . 32 88 3.6. Timers, Counters and Constants . . . . . . . . . . . 32 89 3.7. BIDIR-PIM Packet Formats . . . . . . . . . . . . . . 36 90 3.7.1. DF Election Packet Formats. . . . . . . . . . . . 36 91 3.7.2. Backoff Message . . . . . . . . . . . . . . . . . 37 92 3.7.3. Pass Message. . . . . . . . . . . . . . . . . . . 38 93 3.7.4. Bidir Capable PIM-Hello Option. . . . . . . . . . 39 94 4. RP Discovery. . . . . . . . . . . . . . . . . . . . . . 39 95 5. Security Considerations . . . . . . . . . . . . . . . . 39 96 5.1. Attacks Based on Forged Messages . . . . . . . . . . 39 97 5.1.1. Election of an Incorrect DF . . . . . . . . . . . 40 98 5.1.2. Preventing Election Convergence . . . . . . . . . 41 99 5.2. Non-cryptographic Authentication Mechanisms. . . . . 41 100 5.2.1. Basic Access Control. . . . . . . . . . . . . . . 41 101 5.3. Authentication Using IPsec . . . . . . . . . . . . . 41 102 5.4. Denial of Service Attacks. . . . . . . . . . . . . . 41 103 6. Change history. . . . . . . . . . . . . . . . . . . . . 42 104 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . 42 105 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 42 106 9. Normative References. . . . . . . . . . . . . . . . . . 43 107 10. Informative References . . . . . . . . . . . . . . . . 43 108 11. Index. . . . . . . . . . . . . . . . . . . . . . . . . 45 109 12. Full Copyright Statement . . . . . . . . . . . . . . . 46 111 List of Figures 113 Figure 1. Downstream group per-interface state- 114 machine. . . . . . . . . . . . . . . . . . . . . 16 115 Figure 3. Designated Forwarder election state- 116 machine. . . . . . . . . . . . . . . . . . . . . 29 118 1. Introduction 120 This document specifies Bi-directional PIM (BIDIR-PIM), a variant of PIM 121 Sparse-Mode (PIM-SM) [4] that builds bi-directional shared trees 122 connecting multicast sources and receivers. 124 PIM-SM constructs uni-directional shared trees that are used to forward 125 data from senders to receivers of a multicast group. PIM-SM also allows 126 the construction of source specific trees, but this capability is not 127 related to the protocol described in this document. 129 The shared tree for each multicast group is rooted at a multicast router 130 called the Rendezvous Point (RP). Different multicast groups can use 131 separate RPs within a PIM domain. 133 In unidirectional PIM-SM, there are two possible methods for 134 distributing data packets on the shared tree. These differ in the way 135 packets are forwarded from a source to the RP: 137 o Initially when a source starts transmitting, its first hop router 138 encapsulates data packets in special control messages (Registers) 139 which are unicast to the RP. After reaching the RP the packets are 140 decapsulated and distributed on the shared tree. 142 o A transition from the above distribution mode can be made at a later 143 stage. This is achieved by building source specific state on all 144 routers along the path between the source and the RP. This state is 145 then used to natively forward packets from that source. 147 Both these mechanisms suffer from problems. Encapsulation results in 148 significant processing, bandwidth and delay overheads. Forwarding using 149 source specific state has additional protocol and memory requirements. 151 Bi-directional PIM dispenses with both encapsulation and source state by 152 allowing packets to be natively forwarded from a source to the RP using 153 shared tree state. In contrast to PIM-SM this mode of forwarding does 154 not require any data-driven events. 156 The protocol specification in this document assumes familiarity with the 157 PIM-SM specification in [4]. Portions of the BIDIR-PIM protocol 158 operation that are identical to that of PIM-SM are only defined by 159 reference. 161 2. Terminology 163 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 164 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 165 "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate 166 requirement levels for compliant BIDIR-PIM implementations. 168 2.1. Definitions 170 This specification uses a number of terms to refer to the roles of 171 routers participating in BIDIR-PIM. The following terms have special 172 significance for BIDIR-PIM: 174 MRIB Multicast Routing Information Base. This is the multicast 175 topology table, which is typically derived from the unicast 176 routing table, or routing protocols such as MBGP that carry 177 multicast-specific topology information. It is used by PIM for 178 establishing the RPF interface (used in the forwarding rules). In 179 PIM-SM the MRIB is also used to make decisions regarding where to 180 forward Join/Prune messages whereas in BIDIR-PIM it is used as a 181 source for routing metrics for the DF election process. 183 Rendezvous Point Address (RPA): 184 An RPA is an address that is used as the root of the distribution 185 tree for a range of multicast groups. The RPA must be routable 186 from all routers in the PIM domain. The RPA does not need to 187 correspond to an address for an interface of a real router. In 188 this respect BIDIR-PIM differs from PIM-SM which requires an 189 actual router to be configured as the Rendezvous Point (RP). Join 190 messages from receivers for a BIDIR-PIM group propagate hop-by-hop 191 towards the RPA. 193 Rendezvous Point Link (RPL): 194 An RPL for a particular RPA is the physical link to which the RPA 195 belongs. In BIDIR-PIM all multicast traffic to groups mapping to a 196 specific RPA is forwarded on the RPL of that RPA. The RPL is 197 special within a BIDIR-PIM domain as it is the only link on which 198 a Designated Forwarder election does not take place (see DF 199 definition below). 201 Upstream 202 Towards the root (RPA) of the tree. The direction used by packets 203 traveling from sources to the RPL. 205 Downstream 206 Away from the root of the tree. The direction on which packets 207 travel from the RPL to receivers. 209 Designated Forwarder (DF): 210 The protocol presented in this document is largely based on the 211 concept of a Designated Forwarder (DF). A single DF exists for 212 each RPA on every link within a BIDIR-PIM domain (this includes 213 both multi-access and point-to-point links). The only exception is 214 the RPL on which no DF exists. The DF is the router on the link 215 with the best route to the RPA (determined by comparing MRIB 216 provided metrics). A DF for a given RPA is in charge of forwarding 217 downstream traffic onto its link, and forwarding upstream traffic 218 from its link towards the RPL. It does this for all the bi- 219 directional groups that map to the RPA. The DF on a link is also 220 responsible for processing Join messages from downstream routers 221 on the link as well as ensuring that packets are forwarded to 222 local receivers (discovered through a local membership mechanism 223 such as MLD [3] or IGMP [2]). 225 RPF Interface 226 RPF stands for "Reverse Path Forwarding". The RPF Interface of a 227 router with respect to an address is the interface that the MRIB 228 indicates should be used to reach that address. In the case of a 229 BIDIR-PIM multicast group, the RPF interface is determined by 230 looking up the RPA in the MRIB. The RPF information determines the 231 interface of the router that would be used to send packets towards 232 the RPL for the group. 234 RPF Neighbor 235 The RPF Neighbor of a router with respect to an address is the 236 neighbor that the MRIB indicates should be used to reach that 237 address. Note that in BIDIR-PIM, the RPF neighbor for a group is 238 not necessarily the router on the RPF interface that Join messages 239 for that group would be directed to (Join messages are only 240 directed to the DF on the RPF interface for the group). 242 TIB Tree Information Base. This is the collection of state at a PIM 243 router that has been created by receiving PIM Join/Prune messages, 244 PIM DF election messages and IGMP or MLD information from local 245 hosts. It essentially stores the state of all multicast 246 distribution trees at that router. 248 MFIB Multicast Forwarding Information Base. The TIB holds all the 249 state that is necessary to forward multicast packets at a router. 250 However, although this specification defines forwarding in terms 251 of the TIB, to actually forward packets using the TIB is very 252 inefficient. Instead a real router implementation will normally 253 build an efficient MFIB from the TIB state to perform forwarding. 254 How this is done is implementation-specific, and is not discussed 255 in this document. 257 2.2. Pseudocode Notation 259 We use set notation in several places in this specification. 261 A (+) B 262 is the union of two sets A and B. 264 A (-) B 265 is the elements of set A that are not in set B. 267 NULL 268 is the empty set or list. 270 In addition we use C-like syntax: 272 = denotes assignment of a variable. 274 == denotes a comparison for equality. 276 != denotes a comparison for inequality. 278 Braces { and } are used for grouping. 280 3. Protocol Specification 282 The specification of BIDIR-PIM is broken into several parts: 284 o Section 3.1 details the protocol state stored. 286 o Section 3.2 defines the BIDIR-PIM extensions to the PIM-SM [4] 287 neighbour discovery mechanism. 289 o Section 3.3 specifies the data packet forwarding rules. 291 o Section 3.4 specifies the BIDIR-PIM Join/Prune generation and 292 processing rules. 294 o Designated Forwarder (DF) election is specified in Section 3.5. 296 o PIM packet formats are specified in Section 3.7. 298 o A summary of BIDIR-PIM timers and their default values is given in 299 Section 3.6. 301 3.1. BIDIR-PIM Protocol State 303 This section specifies all the protocol state that a BIDIR-PIM 304 implementation should maintain in order to function correctly. We term 305 this state the Tree Information Base or TIB, as it holds the state of 306 all the multicast distribution trees at this router. In this 307 specification we define PIM mechanisms in terms of the TIB. However, 308 only a very simple implementation would actually implement packet 309 forwarding operations in terms of this state. Most implementations will 310 use this state to build a multicast forwarding table, which would then 311 be updated when the relevant state in the TIB changes. 313 Although we specify precisely the state to be kept, this does not mean 314 that an implementation of BIDIR-PIM needs to hold the state in this 315 form. This is actually an abstract state definition, which is needed in 316 order to specify the router's behavior. A BIDIR-PIM implementation is 317 free to hold whatever internal state it requires, and will still be 318 conformant with this specification so long as it results in the same 319 externally visible protocol behavior as an abstract router that holds 320 the following state. 322 We divide TIB state into two sections: 324 RPA state 325 State that maintains the DF election information for each RPA. 327 Group state 328 State that maintains a group-specific tree for groups that map to a 329 given RPA. 331 The state that should be kept is described below. Of course, 332 implementations will only maintain state when it is relevant to 333 forwarding operations - for example, the "NoInfo" state might be assumed 334 from the lack of other state information, rather than being held 335 explicitly. 337 3.1.1. General Purpose State 339 A router holds the following state that is not specific to a RPA or 340 group: 342 Neighbor State: 344 For each neighbor: 346 o Neighbor's Gen ID. 348 o Neighbor liveness timer (NLT) 350 o Other information from neighbor's Hello 352 For more information on Hello information look at section 3.2 as well as 353 the PIM-SM specification in [4]. 355 3.1.2. RPA State 357 A router maintains a multicast-group to RPA mapping which is built 358 through static configuration or by using an automatic RP discovery 359 mechanism like BSR or AUTO-RP (see section 4). For each BIDIR-PIM RPA a 360 router holds the following state: 362 o RPA (actual address) 364 Designated Forwarder (DF) State: 366 For each router interface: 368 Acting DF information: 370 o DF IP Address 372 o DF metric 374 Election information: 376 o Election State 378 o DF election-Timer (DFT) 380 o Message-Count (MC) 382 Current best offer: 384 o IP address of best offering router 386 o Best offering router metric 388 Designated Forwarder state is described in section 3.5. 390 3.1.3. Group State 392 For every group G a router keeps the following state: 394 Group state: 396 For each interface: 398 Local Membership: 400 o State: One of {"NoInfo", "Include"} 402 PIM Join/Prune State: 404 o State: One of {"NoInfo" (NI), "Join" (J), 405 "PrunePending" (PP)} 407 o Prune Pending Timer (PPT) 409 o Join/Prune Expiry Timer (ET) 411 Not interface specific: 413 o Upstream Join/Prune Timer (JT) 415 o Last RPA Used 417 Local membership is the result of the local membership mechanism (such 418 as IGMP [2]) running on that interface. This information is used by the 419 pim_include(*,G) macro described in section 3.1.4. 421 PIM Join/Prune state is the result of receiving PIM (*,G) Join/Prune 422 messages on this interface, and is specified in section 3.4.1. The state 423 is used by the macros that calculate the outgoing interface list in 424 section 3.1.4, and in the JoinDesired(G) macro (defined in section 425 3.4.2) that is used in deciding whether a Join(*,G) should be sent 426 upstream. 428 The upstream Join/Prune timer is used to send out periodic Join(*,G) 429 messages, and to override Prune(*,G) messages from peers on an upstream 430 LAN interface. 432 The last RPA used must be stored because if the group to RPA mapping 433 changes (see RP Set changes in [4]) then state must be torn down and 434 rebuilt for groups whose RPA changes. 436 3.1.4. State Summarization Macros 438 Using this state, we define the following "macro" definitions which we 439 will use in the descriptions of the state machines and pseudocode in the 440 following sections. 442 olist(G) = 443 RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G) 445 RPF_interface(RPA) is the interface the MRIB indicates would be used to 446 route packets to RPA. The olist(G) is the list of interfaces on which 447 packets to group G must be forwarded. 449 The macro pim_include(G) indicates the interfaces to which traffic might 450 be forwarded because of hosts that are local members on that interface. 452 pim_include(G) = 453 { all interfaces I such that: 454 I_am_DF(RPA(G),I) AND local_receiver_include(G,I) } 456 The clause "I_am_DF(RPA,I)" is TRUE if the router is in the Win or 457 Backoff states in the DF election state machine (described in section 458 3.5) for the given RPA on interface I. Otherwise it is FALSE. 460 The clause "local_receiver_include(G,I)" is true if the IGMP module, MLD 461 module or other local membership mechanism has determined that there are 462 local members on interface I that desire to receive traffic sent to 463 group G. 465 The set "joins(G)" is the set of all interfaces on which the router has 466 received (*,G) Joins: 468 joins(G) = 469 { all interfaces I such that 470 I_am_DF(RPA(G),I) AND 471 DownstreamJPState(G,I) is either Joined or PrunePending } 473 DownstreamJPState(G,I) is the state of the finite state machine in 474 section 3.4.1. 476 RPF_DF(RPA) is the neighbor that Join messages must be sent to in order 477 to build the group shared tree rooted at the RPL for the given RPA. This 478 is the Designated-Forwarder on the RPF_interface(RPA). 480 3.2. PIM Neighbor Discovery 482 PIM routers exchange PIM-Hello messages with their neighboring PIM 483 routers. These messages are used to update the Neighbor State described 484 in section 3.1. The procedures for generating and processing Hello 485 messages as well as maintaining Neighbor State are specified in the PIM- 486 SM [4] documentation. 488 Bidir PIM introduces the Bidir_Capable PIM-Hello option that MUST be 489 included in all Hello messages from a Bidir-PIM capable router. The 490 Bidir_Capable option advertises the router's ability to participate in 491 the Bidir-PIM protocol. The format of the Bidir_Capable option is 492 described in section 3.7. 494 If a Bidir PIM router receives a PIM-Hello message that does not contain 495 the Bidir_Capable option from one of its neighbours, the error must be 496 logged to the router administrator in a rate-limited manner. 498 3.3. Data Packet Forwarding Rules 500 For groups mapping to a given RPA, the following responsibilities are 501 uniquely assigned to the DF for that RPA on each link: 503 o The DF is the only router that forwards packets traveling downstream 504 onto the link. 506 o The DF is the only router that picks-up upstream traveling packets off 507 the link to forward towards the RPL. 509 Non-DF routers on a link, that use that link as their RPF interface to 510 reach the RPA, may perform the following forwarding actions for 511 bidirectional groups: 513 o Forward packets from the link towards downstream receivers. 515 o Forward packets from downstream sources onto the link (provided they 516 are the DF for the downstream link from which the packet was picked- 517 up). 519 The BIDIR-PIM packet forwarding rules are defined below in pseudocode. 521 iif is the incoming interface of the packet. 522 G is the destination address of the packet (group address). 523 RPA is the Rendezvous Point Address for this group. 525 First we check to see whether the packet should be accepted based on TIB 526 state and the interface that the packet arrived on. A packet is accepted 527 if it arrives on the RPF_interface to reach the RPA (downstream 528 traveling packet) or if the router is the DF on the interface the packet 529 arrives (upstream traveling packet). 531 If the packet should be forwarded we build an outgoing interface list 532 for the packet. 534 Finally we remove the incoming interface from the outgoing interface 535 list we've created, and if the resulting outgoing interface list is not 536 empty, we forward the packet out of those interfaces. 538 On receipt of data to G on interface iif: 540 if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) { 541 oiflist = olist(G) (-) iif 542 forward packet on all interfaces in oiflist 543 } 545 3.3.1. Upstream Forwarding at RP 547 When configuring a BIDIR-PIM domain it is possible to assign the 548 Rendezvous Point Address (RPA) such that it does not belong to a 549 physical box but instead is simply a routable address. Routers that have 550 interfaces on the RPL that the RPA belongs to will upstream forward 551 traffic onto the link. Joins from receivers in the domain will propagate 552 hop-by-hop till they reach one of the routers connected to the RPL where 553 they will terminate (as there will be no DF elected on the RPL). 555 If instead the administrator chooses to configure the RPA to be the 556 address of a physical interface of a specific router then nothing 557 changes. That router must still upstream forward traffic on to the RPL 558 and behave no differently than any other router with an interface on the 559 RPL. 561 To configure a BIDIR-PIM network to operate in a mode similar to that of 562 PIM-SM where a single router (the RP) is acting as the root of the 563 distribution tree, the RPA can be configured to be the loopback 564 interface of a router. 566 3.3.2. Source-Only Branches 568 Source-only branches of the distribution tree for a group G are branches 569 which do not lead to any receivers, but which are used to forward 570 packets traveling upstream from sources towards the RPL. Routers along 571 source-only branches only have the RPF_interface to the RPA in their 572 olist for G and hence do not need to maintain any group specific state. 573 Upstream forwarding can be performed using only RPA specific state. An 574 implementation may decide to maintain group state for source-only 575 branches for accounting or performance reasons. However, doing so 576 requires data-driven events (to discover the groups with active sources) 577 thus sacrificing one of the main benefits of Bidir PIM. 579 3.3.3. Directly Connected Sources 581 A major advantage of using a Designated Forwarder in BIDIR-PIM compared 582 to PIM-SM is that special treatment is no longer required for sources 583 that are directly connected to a router. Data from such sources does not 584 need to be differentiated from other multicast traffic and will 585 automatically be picked up by the DF and forwarded upstream. This 586 removes the need for performing a directly-connected-source check for 587 data to groups that do not have existing state. 589 3.4. PIM Join/Prune Messages 591 BIDIR-PIM Join/Prune messages are used to construct group specific 592 distribution trees between receivers and the RPL. Joins are originated 593 by last-hop routers that are elected as the DF on an interface with 594 directly connected receivers. The Joins propagate hop-by-hop towards the 595 RPA till they reach a router connected to the RPL. 597 A BIDIR-PIM Join/Prune message consists of a list of Joined and Pruned 598 Groups. When processing a received Join/Prune message, each Joined or 599 Pruned Group is effectively considered individually by applying the 600 following state machines. When considering a Join/Prune message whose 601 PIM Destination field addresses this router, (*,G) Joins and Prunes can 602 affect the downstream state machine. When considering a Join/Prune 603 message whose PIM Destination field addresses another router, most Join 604 or Prune entries could affect the upstream state machine. 606 3.4.1. Receiving (*,G) Join/Prune Messages 608 When a router receives a Join(*,G) or Prune(*,G) it MUST first check to 609 see whether the RP address in the message matches RPA(G) (the router's 610 idea of what the Rendezvous Point Address is). If the RP address in the 611 message does not match RPA(G) the Join or Prune MUST be silently 612 dropped. 614 If a router has no RPA information for the group (e.g. has not recently 615 received a BSR message) then it MAY choose to accept Join(*,G) or 616 Prune(*,G) and treat the RP address in the message as RPA(G). If the 617 newly discovered RPA did not previously exist for any other group, a DF 618 election has to be initiated. 620 Note that a router will process a Join(*,G) targeted to itself even if 621 it is not the DF for RP(G) on the interface on which the message was 622 received. This is an optimisation to eliminate the Join delay of one 623 Join period (t_periodic) in the case where a new DF processes the 624 received Pass and Join messages in reverse order. The BIDIR-PIM 625 forwarding logic will ensure that data packets are not forwarded on such 626 an interface while the router is no the DF (unless it is the 627 RPF_interface towards the RPA). 629 The per-interface state-machine for receiving (*,G) Join/Prune Messages 630 is given below. There are three states: 632 NoInfo (NI) 633 The interface has no (*,G) Join state and no timers running. 635 Join (J) 636 The interface has (*,G) Join state. If the router is the DF on 637 this interface (I_am_DF(RPA(G),I) is TRUE), the Join state 638 will cause us to forward packets destined for G on this 639 interface. 641 PrunePending (PP) 642 The router has received a Prune(*,G) on this interface from a 643 downstream neighbor and is waiting to see whether the prune 644 will be overridden by another downstream router. For 645 forwarding purposes, the PrunePending state functions exactly 646 like the Join state. 648 In addition the state-machine uses two timers: 650 ExpiryTimer (ET) 651 This timer is restarted when a valid Join(*,G) is received. 652 Expiry of the ExpiryTimer causes the interface state to revert 653 to NoInfo for this group. 655 PrunePendingTimer (PPT) 656 This timer is set when a valid Prune(*,G) is received. Expiry 657 of the PrunePendingTimer causes the interface state to revert 658 to NoInfo for this group. 660 Figure 1: Downstream group per-interface state-machine in tabular form 662 +----------------+------------------------------------------------------+ 663 | | Prev State | 664 | Event +----------------+------------------+------------------+ 665 | | NoInfo (NI) | Join (J) | Prune Pending | 666 | | | | (PP) | 667 +----------------+----------------+------------------+------------------+ 668 | | -> J state | -> J state | -> J state | 669 | Receive | start Expiry | restart Expiry | restart Expiry | 670 | Join(*,G) | Timer | Timer | Timer; stop | 671 | | | | Prune Pending | 672 | | | | Timer | 673 +----------------+----------------+------------------+------------------+ 674 | Receive | - | -> PP state | -> PP state | 675 | Prune(*,G) | | start Prune | | 676 | | | Pending Timer | | 677 +----------------+----------------+------------------+------------------+ 678 | Prune Pending | - | - | -> NI state | 679 | Timer Expires | | | Send Prune- | 680 | | | | Echo(*,G) | 681 +----------------+----------------+------------------+------------------+ 682 | Expiry Timer | - | -> NI state | -> NI state | 683 | Expires | | | | 684 +----------------+----------------+------------------+------------------+ 685 | Stop Being DF | - | -> NI state | -> NI state | 686 | on I | | | | 687 +----------------+----------------+------------------+------------------+ 689 The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" imply 690 receiving a Join or Prune targeted to this router's address on the 691 received interface. If the destination address is not correct, these 692 state transitions in this state machine must not occur, although seeing 693 such a packet may cause state transitions in other state machines. 695 On unnumbered interfaces on point-to-point links, the router's address 696 should be the same as the source address it chose for the Hello packet 697 it sent over that interface. However, on point-to-point links we also 698 RECOMMEND that PIM messages with a destination address of all zeros are 699 also accepted. 701 The transition event "Stop being DF" implies a DF re-election taking 702 place on this router interface for RPA(G) and the router changing status 703 from being the active DF to being a non-DF router (the value of the 704 I_am_DF macro changing to FALSE). 706 When ExpiryTimer is started or restarted, it is set to the HoldTime from 707 the triggering received Join/Prune message. 709 When PrunePendingTimer is started, it is set to the 710 J/P_Override_Interval if the router has more than one neighbor on that 711 interface; otherwise it is set to zero causing it to expire immediately. 713 The action "Send PruneEcho(*,G)" is triggered when the router stops 714 forwarding on an interface as a result of a prune. A PruneEcho(*,G) is 715 simply a Prune(*,G) message sent by the upstream router to itself on a 716 LAN. Its purpose is to add additional reliability so that if a Prune 717 that should have been overridden by another router is lost locally on 718 the LAN, then the PruneEcho may be received and cause the override to 719 happen. A PruneEcho(*,G) need not be sent when the router has only one 720 neighbour on the link. 722 3.4.2. Sending Join/Prune Messages 724 The downstream per-interface state-machines described above hold join 725 state from downstream PIM routers. This state then determines whether a 726 router needs to propagate a Join(*,G) upstream towards the RPA. Such 727 Join(*,G) messages are sent on the RPF_interface towards the RPA and are 728 targeted at the DF on that interface. 730 If a router wishes to propagate a Join(*,G) upstream, it must also watch 731 for messages on its upstream interface from other routers on that 732 subnet, and these may modify its behavior. If it sees a Join(*,G) to 733 the correct upstream neighbor, it should suppress its own Join(*,G). If 734 it sees a Prune(*,G) to the correct upstream neighbor, it should be 735 prepared to override that prune by sending a Join(*,G) almost 736 immediately. Finally, if it sees the Generation ID (see PIM-SM 737 specification [4]) of the correct upstream neighbor change, it knows 738 that the upstream neighbor has lost state, and it should be prepared to 739 refresh the state by sending a Join(*,G) almost immediately. 741 In addition changes in the next hop towards the RPA trigger a prune off 742 from the old next hop, and join towards the new next hop. Such a change 743 can be caused by the following two events: 745 o The MRIB indicates that the RPF Interface towards the RPA has 746 changed. In this case the DF on the new RPF_interface becomes 747 the new RPF Neighbour. 749 o There is a DF re-election on the RPF_interface and a new router 750 emerges as the DF. 752 The upstream (*,G) state-machine only contains two states: 754 Not Joined 755 The downstream state-machines indicate that the router does not 756 need to join the RPA tree for this group. 758 Joined 759 The downstream state-machines indicate that the router would like 760 to join the RPA tree for this group. 762 In addition, one timer JT(G) is kept which is used to trigger the 763 sending of a Join(*,G) to the upstream next hop towards the RPA (the DF 764 on the RPF_interface for RPA(G)). 766 +-----------------------------------+ 767 | Figures omitted from text version | 768 +-----------------------------------+ 770 Figure 2: Upstream group state-machine 772 In tabular form, the state machine is: 774 +----------------------+------------------------------------------------+ 775 | | Event | 776 | Prev State +------------------------+-----------------------+ 777 | | JoinDesired(G) | JoinDesired(G) | 778 | | ->True | ->False | 779 +----------------------+------------------------+-----------------------+ 780 | | -> J state | - | 781 | NotJoined (NJ) | Send Join(*,G); | | 782 | | Set Timer to | | 783 | | t_periodic | | 784 +----------------------+------------------------+-----------------------+ 785 | Joined (J) | - | -> NJ state | 786 | | | Send Prune(*,G) | 787 +----------------------+------------------------+-----------------------+ 789 In addition, we have the following transitions which occur within the 790 Joined state: 792 +-----------------------------------------------------------------------+ 793 | In Joined (J) State | 794 +-----------------+-----------------+-----------------+-----------------+ 795 |Timer Expires | See Join(*,G) | See Prune(*,G) | RPF_DF(RPA(G)) | 796 | | to | to | GenID changes | 797 | | RPF_DF(RPA(G)) | RPF_DF(RPA(G)) | | 798 +-----------------+-----------------+-----------------+-----------------+ 799 |Send | Increase Timer | Decrease Timer | Decrease Timer | 800 |Join(*,G); Set | to | to t_override | to t_override | 801 |Timer to | t_suppressed | | | 802 |t_periodic | | | | 803 +-----------------+-----------------+-----------------+-----------------+ 805 +-----------------------------------------------------------------------+ 806 | In Joined (J) State | 807 +-------------------------------------+---------------------------------+ 808 | Change of RPF_DF(RPA(G)) | RPF_DF(RPA(G)) GenID | 809 | | changes | 810 +-------------------------------------+---------------------------------+ 811 | Send Join(*,G) to new | Decrease Timer to | 812 | DF; Send Prune(*,G) to | t_override | 813 | old DF; set Timer to | | 814 | t_periodic | | 815 +-------------------------------------+---------------------------------+ 816 This state machine uses the following macro: 818 bool JoinDesired(G) { 819 if (olist(G) (-) RPF_interface(RPA(G))) != NULL 820 return TRUE 821 else 822 return FALSE 823 } 825 3.5. Designated Forwarder (DF) Election 827 This section presents a fail-safe mechanism for electing a per-RPA 828 designated router on each link in a BIDIR-PIM domain. We call this 829 router the Designated Forwarder (DF). The DF election does not take 830 place on the RPL for a RPA. 832 3.5.1. DF Requirements 834 The DF election chooses the best router on a link to assume the 835 responsibility of forwarding traffic between the RPL and the link for 836 the range of multicast groups served by the RPA. Different multicast 837 groups that share a common RPA share the same upstream direction. 838 Hence, the election of an upstream forwarder on each link does not have 839 to be a group specific decision but instead can be RPA-specific. As the 840 number of RPAs is typically small, the number of elections that have to 841 be performed is significantly reduced by this observation. 843 To optimise tree creation, it is desirable that the winner of the 844 election process should be the router on the link with the "best" 845 unicast routing metric (as reported by the MRIB) to reach the RPA. When 846 comparing metrics from different unicast routing protocols, we use the 847 same comparison rules used by the PIM-SM assert process [4]. 849 The election process needs to take place when information on a new RPA 850 initially becomes available. The result can be re-used as new bidir 851 groups that map to the same RPA are encountered. There are however some 852 conditions under which an update to the election is required: 854 o There is a change in unicast metric to reach the RPA for any of 855 the routers on the link. 857 o The interface on which the RPA is reachable (RPF Interface) 858 changes to an interface for which the router was previously the 859 DF. 861 o A new PIM neighbor starts up on a link that must participate in 862 the elections and be informed of current outcome. 864 o The elected DF fails (detected through neighbor information 865 timeout or MRIB RPF change at downstream router). 867 The election process has to be robust enough to ensure with very high 868 probability that all routers on the link have a consistent view of the 869 DF. This is because with the forwarding rules described in section 3.3 870 if multiple routers end-up thinking that they should be responsible for 871 forwarding, loops may result. To reduce the possibility of this 872 occurrence to a minimum, the election algorithm has been biased towards 873 discarding DF information and suspending forwarding during periods of 874 ambiguity. 876 3.5.2. DF Election description 878 This section gives an outline of the DF election process. It does not 879 provide the definitive specification for the DF election. If any 880 discrepancy exists between section 3.5.3 and this section, the 881 specification in section 3.5.3 is to be assumed correct. 883 To perform the election of the DF for a particular RPA, routers on a 884 link need to exchange their unicast routing metric information for 885 reaching the RPA. Routers advertise their own metrics in Offer, Winner, 886 Backoff and Pass messages. The advertised metric is calculated using the 887 RPF Interface and metric to reach the RPA available through the MRIB. 888 When a router is participating in a DF election for an RPA on the 889 interface that its MRIB indicates as the RPF Interface then that router 890 MUST always advertise an infinite metric in its election messages. When 891 a router is participating in a DF election on an interface other than 892 the MRIB indicated RPF Interface then it MUST advertise the MRIB 893 provided metrics in its election messages. 895 In the election protocol described below, many message exchanges are 896 repeated Election_Robustness times for reliability. In all those cases 897 the message retransmissions are spaced in time by a small random 898 interval. All of the following description is specific to the election 899 on a single link for a single RPA. 901 3.5.2.1. Bootstrap Election 903 Initially when no DF has been elected, routers finding out about a new 904 RPA start participating in the election by sending Offer messages. 905 Offer messages include the router's metric to reach the RPA. Offers are 906 periodically retransmitted with a period of Offer_Interval. 908 If a router hears a better offer than its own from a neighbor, it stops 909 participating in the election for a period of Election_Robustness * 910 Offer_Interval thus giving a chance to the neighbour with the better 911 metric to be elected DF. If during this period no winner is elected, the 912 router restarts the election from the beginning. If at any point during 913 the initial election a router receives an out of order offer with worse 914 metrics than its own, then it restarts the election from the beginning. 916 The result should be that all routers except the best candidate stop 917 advertising their offers. 919 A router assumes the role of the DF after having advertised its metrics 920 Election_Robustness times without receiving any offer from any other 921 neighbor. At that point it transmits a Winner message which declares to 922 every other router on the link the identity of the winner and the 923 metrics it is using. 925 Routers receiving a winner message stop participating in the election 926 and record the identity and metrics of the winner. If the local metrics 927 are better than those of the winner then the router records the identity 928 of the winner (accepting it as the acting DF) but re-initiates the 929 election to try and take over. 931 3.5.2.2. Loser Metric Changes 933 Whenever the unicast metric to a RPA changes at a non-DF router to a 934 value that is better than that previously advertised by the acting DF, 935 the router with the new better metric should take action to eventually 936 assume forwarding responsibility. When the metric change is detected, 937 the non-DF router with the now better metric restarts the DF election 938 process by sending Offer messages with this new metric. Note that at 939 any point during an election if no response is received after 940 Election_Robustness retransmissions of an offer, a router assumes the 941 role of the DF following the usual Winner announcement procedure. 943 Upon receipt of an offer that is worse than its current metric, the DF 944 will respond with a Winner message declaring its status and advertising 945 its better metric. Upon receiving the Winner message, the originator of 946 the Offer records the identity of the DF and aborts the election. 948 Upon receipt of an offer that is better than its current metric, the DF 949 records the identity and metrics of the offering router and responds 950 with a Backoff message. This instructs the offering router to hold off 951 for a short period of time while the unicast routing stabilises and 952 other routers get a chance to put in their offers. The Backoff message 953 includes the offering router's new metric and address. All routers on 954 the link that have pending offers with metrics worse than those in the 955 backoff message (including the original offering router) will hold 956 further offers for a period of time defined in the Backoff message. 958 If during the Backoff_Period, a third router sends a new better offer, 959 the Backoff message is repeated for the new offer and the Backoff_Period 960 restarted. 962 Before the Backoff_Period expires, the acting DF nominates the router 963 having made the best offer as the new DF using a Pass message. This 964 message includes the IDs and metrics of both the old and new DFs. The 965 old DF stops performing its tasks at the time the Pass message 966 transmission is made. The new DF assumes the role of the DF as soon as 967 it receives the Pass message. All other routers on the link take note of 968 the new DF and its metric. Note that this event constitutes an RPF 969 Neighbour change which may trigger Join messages to the new DF (see 970 section 3.4). 972 3.5.2.3. Winner Metric Changes 974 If the DF's routing metric to reach the RPA changes to a worse value, it 975 sends a set of Election_Robustness randomly spaced Winner messages on 976 the link, advertising the new metric. Routers that receive this 977 announcement but have a better metric may respond with an Offer message 978 which results in the same handoff procedure described above. All 979 routers assume the DF has not changed until they see a Pass or Winner 980 message indicating the change. 982 There is no pressure to make this handoff quickly if the acting DF still 983 has a path to the RPL. The old path may now be suboptimal but it will 984 still work while the re-election is in progress. 986 3.5.2.4. Winner Loses Path 988 If a router's RPF Interface to the RPA switches to be on a link for 989 which it is acting as the DF, then it can no longer provide forwarding 990 services for that link. It therefore immediately stops being the DF and 991 restarts the election. As its path to the RPA is through the link, an 992 infinite metric is used in the Offer message it sends. 994 3.5.2.5. Late Router Starting Up 996 A late router starting up after the DF election process has completed 997 will have no immediate knowledge of the election outcome. As a result, 998 it will start advertising its metric in Offer messages. As soon as this 999 happens, the currently elected DF will respond with a Winner message if 1000 its metric is better than the metric in the Offer message, or with a 1001 Backoff message if its metric is worse than the metric in the Offer 1002 message. 1004 3.5.2.6. Winner Dies 1006 Whenever the DF dies, a new DF has to be elected. The speed at which 1007 this can be achieved depends on whether there are any downstream routers 1008 on the link. 1010 If there are downstream routers, typically their MRIB reported next-hop 1011 before the DF dies will be the DF itself. They will therefore notice 1012 either a change in the metric for the route to the RPA or a change in 1013 next-hop away from the DF and can restart the election by transmitting 1014 Offer messages. If according to the MRIB the RPA is now reachable 1015 through the same link via another upstream router, an infinite metric 1016 will be used in the Offer. 1018 If no downstream routers are present, the only way for other upstream 1019 routers to detect a DF failure is by the timeout of the PIM neighbor 1020 information, which will take significantly longer. 1022 3.5.3. Election Protocol Specification 1024 This section provides the definitive specification for the DF election 1025 process. If any discrepancy exists between section 3.5.2 and this 1026 section, the specification in this section is to be assumed correct. 1028 3.5.3.1. Election State 1030 The DF election state is maintained per RPA for each multicast enabled 1031 interface I on the router as introduced in section 3.1. 1033 The state machine has the following four states: 1035 Offer 1036 Initial election state. When in the Offer state a router 1037 thinks it can eventually become the winner and periodically 1038 generates Offer messages. 1040 Lose In this state the router knows that there either is a 1041 different election winner or that no router on the link has a 1042 path to the RPA. 1044 Winner 1045 The router is the acting DF without any contest. 1047 Backoff 1048 The router is the acting DF but another router has made a bid 1049 to take over. 1051 In the state machine a router is considered to be an acting DF if it is 1052 in the Win or Backoff states. 1054 The operation of the election protocol makes use of the variables and 1055 timers described below: 1057 Acting DF information 1058 Used to store the identity and advertised metrics of the 1059 election winner that is the currently acting DF. 1061 DF election-Timer (DFT) 1062 Used to schedule transmission of Offer, Winner and Pass 1063 messages. 1065 Message-Count (MC) 1066 Used to maintain the number of times an Offer or Winner 1067 message has been transmitted. 1069 Best-Offer 1070 Used by the DF to record the identity and advertised metrics 1071 of the router that has made the last offer, for use when 1072 sending the Path message. 1074 3.5.3.2. Election Messages 1076 The election process uses the following PIM control messages, the packet 1077 format of which is described in section 3.7: 1079 Offer (OfferingID, Metric) 1080 Sent by routers that believe they have a better metric to the 1081 RPA than the metric that has been on offer so far. 1083 Winner (DF-ID, DF-Metric) 1084 Sent by a router when assuming the role of the DF or when re- 1085 asserting in response to worse offers. 1087 Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric, 1088 BackoffInterval) 1089 Used by the DF to acknowledge better offers. It instructs 1090 other routers with equal or worse offers to wait till the DF 1091 passes responsibility to the sender of the offer. 1093 Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric) 1094 Used by the old DF to pass forwarding responsibility to a 1095 router that has previously made an offer. The Old-DF-Metric 1096 is the current metric of the DF at the time the pass is sent. 1098 Note that when a router is participating in a DF election for an RPA on 1099 the interface that its MRIB indicates as the RPF Interface then that 1100 router MUST always advertise an infinite metric in its election 1101 messages. When a router is participating in a DF election on an 1102 interface other than the MRIB indicated RPF Interface then it MUST 1103 advertise the MRIB provided metrics in its election messages. 1105 3.5.3.3. Election Events 1107 During protocol operation the following events can take place: 1109 Control message reception 1110 Reception of one of the four control DF election messages 1111 (Offer, Winner, Backoff and Pass). When a control message is 1112 received and actions are specified on a condition that metrics 1113 are Better or Worse the comparison must be performed as 1114 follows: 1116 o On receipt of an Offer or Winner message compare our current 1117 metrics for the RPA with the metrics advertised for the 1118 sender of the message. 1120 o On receipt of a Backoff or Pass message compare our current 1121 metrics for the RPA with the metrics advertised for the 1122 target of the message. 1124 Path to RPA lost 1125 Losing the path to the RPA can happen in two ways. The first 1126 happens when the route learned through the MRIB is withdrawn 1127 and the MRIB no longer reports an available route to reach the 1128 RPA. The second case happens when the next-hop information 1129 reported by the MRIB changes to indicate a next-hop that is 1130 reachable through the router interface under consideration. 1131 Clearly as the router is using the interface as its RPF 1132 Interface it cannot offer forwarding services towards the RPL 1133 to other routers on that link. 1135 Metric reported by the MRIB to reach the RPA changes 1136 This event is triggered when the MRIB supplied information for 1137 the RPA changes and the new information provides a path to the 1138 RPA. If the new MRIB information either reports no route or 1139 reports a next-hop interface through the interface for which 1140 the DF election is taking place then the "Path to RPA lost" 1141 event triggers instead. In specific states the event may be 1142 further filtered by specifying whether it is expected of the 1143 metric to become better or worse and which stored metric the 1144 new MRIB information must be compared against. The new 1145 information must be compared with either the router's old 1146 metric, the stored DF metric or the stored Best Offer metric. 1148 Election-Timer (DFT) Expiration 1149 Expiration of the DFT election timer can cause message 1150 transmission and state transitions. The event might be further 1151 qualified by specifying the value of the Message Count (MC) as 1152 well as the current existence of a path to the RPA (as defined 1153 above). 1155 Detection of DF failure 1156 Detection of DF failure can occur through the timeout of PIM 1157 neighbor state. 1159 3.5.3.4. Election Actions 1161 The DF election state machine action descriptions use the following 1162 notation in addition to the pseudocode notation described earlier in 1163 this spec. 1165 ?= denotes the operation of lowering a timer to a new value. If 1166 the timer is not running then it is started using the new 1167 value. If the timer is running with an expiration lower than 1168 the new value, then the timer is not altered. 1170 When an action of "set DF to Sender or Target" is encountered during 1171 receipt of a Winner, Pass or Backoff message it means the following: 1173 o On receipt of a Winner message set the DF to be the originator of 1174 the message and record its metrics. 1176 o On receipt of a Pass message set the DF to be the target of the 1177 message and record its metrics. 1179 o On receipt of a Backoff message set the DF to be the originator 1180 of the message and record its metrics. 1182 3.5.3.5. Election State Transitions 1184 When a Designated Forwarder election is initiated the starting state is 1185 the Offer state, the message counter (MC) is set to zero and the DF 1186 election Timer (DFT) is set to OPlow (see section 3.6 for a definition 1187 of timer values). 1189 Figure 3: Designated Forwarder election state-machine in tabular form 1191 +-------------++--------------------------------------------------------+ 1192 | || Event | 1193 | Prev State ++------------------+------------------+------------------+ 1194 | || Recv better | Recv better | Recv better | 1195 | || Pass / Win | Backoff | Offer | 1196 +-------------++------------------+------------------+------------------+ 1197 | || -> Lose | - | - | 1198 | Offer || DF = Sender or | DFT = BOperiod | DFT = OPhigh; | 1199 | || Target; Stop | + OPlow; MC = | MC = 0 | 1200 | || DFT | 0 | | 1201 +-------------++------------------+------------------+------------------+ 1202 | || - | - | -> Offer | 1203 | Lose || DF = Sender or | DF = Sender | DFT = OPhigh; | 1204 | || Target | | MC = 0 | 1205 +-------------++------------------+------------------+------------------+ 1206 | || -> Lose | -> Lose | -> Backoff | 1207 | || DF = Sender or | DF = Sender; | Set Best to | 1208 | Win || Target; Stop | Stop DFT | Sender; Send | 1209 | || DFT | | Backoff; DFT = | 1210 | || | | BOperiod | 1211 +-------------++------------------+------------------+------------------+ 1212 | || -> Lose | -> Lose | - | 1213 | || DF = Sender or | DF = Sender; | Set Best to | 1214 | Backoff || Target; Stop | Stop DFT | Sender; Send | 1215 | || DFT | | Backoff; DFT = | 1216 | || | | BOperiod | 1217 +-------------++------------------+------------------+------------------+ 1218 +-----------++----------------------------------------------------------+ 1219 | || Event | 1220 | ++-------------+--------------+--------------+--------------+ 1221 |Prev State ||Recv Backoff | Recv Pass | Recv Worse | Recv worse | 1222 | ||for us | for us | Pass / Win / | Offer | 1223 | || | | Backoff | | 1224 +-----------++-------------+--------------+--------------+--------------+ 1225 | ||- | -> Win | - | - | 1226 | ||DFT = | Stop DFT | Set DF to | DFT ?= | 1227 |Offer ||BOperiod + | | Sender or | OPlow; MC = | 1228 | ||OPlow; MC = | | Target; DFT | 0 | 1229 | ||0 | | ?= OPlow; MC | | 1230 | || | | = 0 | | 1231 +-----------++-------------+--------------+--------------+--------------+ 1232 | ||-> Offer | -> Offer | -> Offer | -> Offer | 1233 | ||DF = Sender; | DF = Sender; | DF = Sender | DFT = OPlow; | 1234 |Lose ||DFT = OPlow; | DFT = OPlow; | or Target; | MC = 0 | 1235 | ||MC = 0 | MC = 0 | DFT = OPlow; | | 1236 | || | | MC = 0 | | 1237 +-----------++-------------+--------------+--------------+--------------+ 1238 | ||-> Offer | -> Offer | -> Offer | - | 1239 | ||DF = Sender; | DF = Sender; | DF = Sender | Send Winner | 1240 |Win ||DFT = OPlow; | DFT = OPlow; | or Target; | | 1241 | ||MC = 0 | MC = 0 | DFT = OPlow; | | 1242 | || | | MC = 0 | | 1243 +-----------++-------------+--------------+--------------+--------------+ 1244 | ||-> Offer | -> Offer | -> Offer | -> Win | 1245 | ||DF = Sender; | DF = Sender; | DF = Sender | Send Winner; | 1246 |Backoff ||DFT = OPlow; | DFT = OPlow; | or Target; | Stop DFT | 1247 | ||MC = 0 | MC = 0 | DFT = OPlow; | | 1248 | || | | MC = 0 | | 1249 +-----------++-------------+--------------+--------------+--------------+ 1251 +-----------------------------------------------------------------------+ 1252 | In Offer State | 1253 +-----------------------+-----------------------+-----------------------+ 1254 | DFT Expires and MC | DFT Expires and MC | DFT Expires and MC | 1255 | is less than | is equal to | is equal to | 1256 | Robustness | Robustness and we | Robustness and | 1257 | | have path to RPA | there is no path | 1258 | | | to RPA | 1259 +-----------------------+-----------------------+-----------------------+ 1260 | - | -> Win | -> Lose | 1261 | Send Offer; DFT = | Send Winner | Set DF to None | 1262 | OPlow; MC = MC + 1 | | | 1263 +-----------------------+-----------------------+-----------------------+ 1264 +-----------------------------------------------------------------------+ 1265 | In Offer State | 1266 +-----------------------------------------------------------------------+ 1267 | Metric changes and is now worse | 1268 +-----------------------------------------------------------------------+ 1269 | DFT ?= OPlow | 1270 | MC = 0 | 1271 +-----------------------------------------------------------------------+ 1273 +-----------------------------------------------------------------------+ 1274 | In Lose State | 1275 +--------------------------------+--------------------------------------+ 1276 | Detect DF Failure | Metric changes and now | 1277 | | is better than DF | 1278 +--------------------------------+--------------------------------------+ 1279 | -> Offer | -> Offer | 1280 | DF = None; DFT = | DFT = OPlow_int; MC = 0 | 1281 | OPlow_int; MC = 0 | | 1282 +--------------------------------+--------------------------------------+ 1284 +-----------------------------------------------------------------------+ 1285 | In Win State | 1286 +-----------------------+------------------------+----------------------+ 1287 | Metric changes and | Timer Expires and | Path to RPA lost | 1288 | is now worse | MC is less than | | 1289 | | Robustness | | 1290 +-----------------------+------------------------+----------------------+ 1291 | - | - | -> Offer | 1292 | DFT = OPlow; MC = | Send Winner; DFT = | Set DF to None; | 1293 | 0 | OPlow; MC = MC + 1 | DFT = OPlow; MC = | 1294 | | | 0 | 1295 +-----------------------+------------------------+----------------------+ 1297 +-----------------------------------------------------------------------+ 1298 | In Backoff State | 1299 +-----------------------+------------------------+----------------------+ 1300 | Metric changes and | Timer Expires | Path to RPA lost | 1301 | is now better than | | | 1302 | Best | | | 1303 +-----------------------+------------------------+----------------------+ 1304 | -> Win | -> Lose | -> Offer | 1305 | Stop Timer | Send Pass; Set DF | Set DF to None; | 1306 | | to stored Best | DFT = OPlow; MC = | 1307 | | | 0 | 1308 +-----------------------+------------------------+----------------------+ 1309 3.5.4. Election Reliability Enhancements 1311 For the correct operation of BIDIR-PIM it is very important to avoid 1312 situations where two routers consider themselves to be Designated 1313 Forwarders for the same link. The two precautions below are not required 1314 for correct operation but can help diagnose anomalies and correct them. 1316 3.5.5. Missing Pass 1318 After a DF has been elected, a router whose metrics change to become 1319 better than the DF will attempt to take over. If during the re-election 1320 the acting DF has a condition that causes it to lose all of the election 1321 messages (like a CPU overload), the new candidate will transmit three 1322 offers and assume the role of the forwarder resulting in two DFs on the 1323 link. This situation is pathological and should be corrected by fixing 1324 the overloaded router. It is desirable that such an event can be 1325 detected by a network administrator. 1327 When a router becomes the DF for a link without receiving a Pass message 1328 from the known old DF, the PIM neighbor information for the old DF can 1329 be marked to this effect. Upon receiving the next PIM Hello message from 1330 the old DF, the router can retransmit Winner messages for all the RPAs 1331 for which it is acting as the DF. The anomaly may also be logged by the 1332 router in a rate-limited manner to alert the operator. 1334 3.5.6. Periodic Winner Announcement 1336 An additional degree of safety can be achieved by having the DF for each 1337 RPA periodically announce its status in a Winner message. Transmission 1338 of the periodic Winner message can be restricted to occur only for RPAs 1339 which have active groups, thus avoiding the periodic control traffic in 1340 areas of the network without senders or receivers for a particular RPA. 1342 3.6. Timers, Counters and Constants 1344 BIDIR-PIM maintains the following timers, as discussed in section 3.1. 1345 All timers are countdown timers - they are set to a value and count down 1346 to zero, at which point they typically trigger an action. Of course 1347 they can just as easily be implemented as count-up timers, where the 1348 absolute expiry time is stored and compared against a real-time clock, 1349 but the language in this specification assumes that they count downwards 1350 to zero. 1352 Per Rendezvous-Point Address (RPA): 1354 Per interface (I): 1356 DF Election Timer: DFT(RPA,I) 1358 Per Group (G): 1360 Upstream Join Timer: JT(G) 1362 Per interface (I): 1364 Join Expiry Timer: ET(G,I) 1366 PrunePending Timer: PPT(G,I) 1368 When timers are started or restarted, they are set to default values. 1369 This section summarizes those default values. 1371 Timer Name: DF Election Timer (DFT) 1373 +--------------------+-------------------------+------------------------+ 1374 | Value Name | Value | Explanation | 1375 +--------------------+-------------------------+------------------------+ 1376 | Offer_Period | 100 ms | Interval to wait | 1377 | | | between repeated | 1378 | | | Offer and Winner | 1379 | | | messages. | 1380 +--------------------+-------------------------+------------------------+ 1381 | Backoff_Period | 1 sec | Period that acting | 1382 | | | DF waits between | 1383 | | | receiving a better | 1384 | | | Offer and sending | 1385 | | | the Pass message | 1386 | | | to transfer DF | 1387 | | | responsibility. | 1388 +--------------------+-------------------------+------------------------+ 1389 | OPlow | rand(0.5, 1) * | Range of actual | 1390 | | Offer_Period | randomised value | 1391 | | | used between | 1392 | | | repeated messages. | 1393 +--------------------+-------------------------+------------------------+ 1394 | OPhigh | Election_Robustness | Interval to wait | 1395 | | * Offer_Period | in order to give a | 1396 | | | chance to a router | 1397 | | | with a better | 1398 | | | Offer to become | 1399 | | | the DF. | 1400 +--------------------+-------------------------+------------------------+ 1402 Timer Names: Join Expiry Timer (ET(G,I)) 1404 +----------------+----------------+-------------------------------------+ 1405 | Value Name | Value | Explanation | 1406 +----------------+----------------+-------------------------------------+ 1407 | J/P HoldTime | from message | Hold Time from Join/Prune Message | 1408 +----------------+----------------+-------------------------------------+ 1409 Timer Names: Prune Pending Timer (PPT(G,I)) 1411 +--------------------------+--------------------+-----------------------+ 1412 | Value Name | Value | Explanation | 1413 +--------------------------+--------------------+-----------------------+ 1414 | J/P Override Interval | Default: 3 secs | Short period after | 1415 | | | a join or prune to | 1416 | | | allow other | 1417 | | | routers on the LAN | 1418 | | | to override the | 1419 | | | join or prune | 1420 +--------------------------+--------------------+-----------------------+ 1422 Note that the value of the J/P Override Interval is interface specific 1423 and depends on both the Propagation_Delay and the Override_Interval 1424 values that may change when Hello messages are received [4]. 1426 Timer Names: Upstream Join Timer (JT(G)) 1428 +-------------+--------------------+-------------------------------------+ 1429 |Value Name | Value | Explanation | 1430 +-------------+--------------------+-------------------------------------+ 1431 |t_periodic | Default: 60 secs | Period between Join/Prune Messages | 1432 +-------------+--------------------+-------------------------------------+ 1433 |t_suppressed | rand(1.1 * | Suppression period when someone | 1434 | | t_periodic, 1.4 * | else sends a J/P message so we | 1435 | | t_periodic) | don't need to do so. | 1436 +-------------+--------------------+-------------------------------------+ 1437 |t_override | rand(0, 0.9 * J/P | Randomized delay to prevent | 1438 | | Override Interval) | response implosion when sending a | 1439 | | | join message to override someone | 1440 | | | else's prune message. | 1441 +-------------+--------------------+-------------------------------------+ 1443 For more information about these values refer to the PIM-SM [4] 1444 documentation. 1446 Constant Name: DF Election Robustness 1448 +--------------------------+-------------------+------------------------+ 1449 | Constant Name | Value | Explanation | 1450 +--------------------------+-------------------+------------------------+ 1451 | Election_Robustness | Default: 3 | Minimum number of | 1452 | | | election messages | 1453 | | | that must be lost | 1454 | | | in order for | 1455 | | | election to fail. | 1456 +--------------------------+-------------------+------------------------+ 1458 3.7. BIDIR-PIM Packet Formats 1460 This section describes the details of the packet formats for BIDIR-PIM 1461 control messages. BIDIR-PIM shares a number of control messages in 1462 common with PIM-SM [4]. These include the Hello and Join/Prune messages 1463 as well as the format for the Encoded-Unicast address. For details on 1464 the format of these packets please refer to the PIM-SM documentation. 1465 Here we will only define the additional packets that are introduced by 1466 BIDIR-PIM. These are the packets used in the DF election process as 1467 well as the Bidir_Capable PIM-Hello option. 1469 3.7.1. DF Election Packet Formats 1471 All PIM control messages have IP protocol number 103. 1473 BIDIR-PIM messages are multicast with TTL 1 to the `ALL-PIM-ROUTERS' 1474 group The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6 `ALL- 1475 PIM-ROUTERS' group is `ff02::d'. 1477 All DF election BIDIR-PIM control messages share the common header 1478 below: 1480 0 1 2 3 1481 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 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 |PIM Ver| Type |Subtype| Rsvd | Checksum | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Encoded-Unicast-RP-Address 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1487 | Sender Metric Preference | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Sender Metric | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 PIM Ver 1492 PIM Version number is 2. 1494 Type All DF-Election PIM control messages share the PIM message Type of 1495 10. 1497 Subtype 1498 Subtypes for DF election messages are: 1500 1 = Offer 1501 2 = Winner 1502 3 = Backoff 1503 4 = Pass 1505 Rsvd Set to zero on transmission. Ignored upon receipt. 1507 Checksum 1508 The checksum is standard IP checksum, i.e. the 16-bit one's 1509 complement of the one's complement sum of the entire PIM message. 1510 For computing the checksum, the checksum field is zeroed. 1512 RP-Address 1513 The bidir RPA for which the election is taking place (note that the 1514 length of this field will be different than 32 bits depending on 1515 the family and encoding of the address). 1517 Sender Metric Preference 1518 Preference value assigned to the unicast routing protocol that the 1519 message sender used to obtain the route to the RPA. 1521 Sender Metric 1522 The unicast routing table metric used by the message sender to 1523 reach the RPA. The metric is in units applicable to the unicast 1524 routing protocol used. 1526 In addition to the fields defined above the Backoff and Pass messages 1527 have the extra fields described below. 1529 3.7.2. Backoff Message 1531 The Backoff message uses the following fields in addition to the common 1532 election message format described above. 1534 0 1 2 3 1535 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 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Encoded-Unicast-Offering-Address 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1539 | Offering Metric Preference | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Offering Metric | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Interval | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 Offering Address 1547 The address of the router that made the last (best) Offer (note 1548 that the length of this field will be different than 32 bits 1549 depending on the family and encoding of the address). 1551 Offering Metric Preference 1552 Preference value assigned to the unicast routing protocol that the 1553 offering router used to obtain the route to the RPA. 1555 Offering Metric 1556 The unicast routing table metric used by the offering router to 1557 reach the RPA. The metric is in units applicable to the unicast 1558 routing protocol used. 1560 Interval 1561 The backoff interval in milliseconds to be used by routers with 1562 worse metrics than the offering router. 1564 3.7.3. Pass Message 1566 The Pass message uses the following fields in addition to the common 1567 election fields described above. 1569 0 1 2 3 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Encoded-Unicast-New-Winner-Address 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1574 | New Winner Metric Preference | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | New Winner Metric | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 New Winner Address 1579 The address of the router that made the last (best) Offer (note 1580 that the length of this field will be different than 32 bits 1581 depending on the family and encoding of the address). 1583 New Winner Metric Preference 1584 Preference value assigned to the unicast routing protocol that the 1585 offering router used to obtain the route to the RPA. 1587 New Winner Metric 1588 The unicast routing table metric used by the offering router to 1589 reach the RPA. The metric is in units applicable to the unicast 1590 routing protocol used. 1592 3.7.4. Bidir Capable PIM-Hello Option 1594 BIDIR-PIM introduces one new PIM-Hello option. 1596 o OptionType 22: Bidir Capable 1598 0 1 2 3 1599 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 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Type = 22 | Length = 0 | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 4. RP Discovery 1606 Routers discover that a range of multicast group addresses operates in 1607 bi-directional mode and the address of the Rendezvous-Point address 1608 (RPA) serving the group range either through static configuration or 1609 using an automatic RP discovery mechanism like the PIM Bootstrap 1610 mechanism (BSR) [9] or Auto-RP. 1612 5. Security Considerations 1614 The IPsec [5] authentication header MAY be used to provide data 1615 integrity protection and group-wise data origin authentication of BIDIR- 1616 PIM protocol messages. Authentication of BIDIR-PIM messages can protect 1617 against unwanted behaviour caused by unauthorized or altered BIDIR-PIM 1618 messages. 1620 5.1. Attacks Based on Forged Messages 1622 As in PIM Sparse-Mode, the extent of possible damage depends on the type 1623 of counterfeit messages accepted. BIDIR-PIM only uses link-local 1624 multicast messages sent to the ALL_PIM_ROUTERS address, hence attacks 1625 can only be carried out by directly connected nodes, or with the 1626 complicity of directly connected routers. 1628 Some of the BIDIR-PIM protocol messages (Join/Prune and Hello) are 1629 identical, both in format and functionality, to the respective messages 1630 used in PIM-SM. Security considerations for these messages are to be 1631 found in [4]. Other messages (DF-election messages) are specific to 1632 BIDIR-PIM and will be discussed in the following paragraphs. 1634 By forging DF-election messages an attacker can disrupt the election of 1635 the Designated Forwarder on a link in two different ways: 1637 5.1.1. Election of an Incorrect DF 1639 An attacker can force its election as DF by participating in a regular 1640 election and advertising the best metric to reach the RPA. An attacker 1641 can also try to force the election of another router as DF by sending an 1642 Offer, Winner or Pass message and impersonating another router. In some 1643 cases (e.g. the Offer) multiple messages might be needed to carry out an 1644 attack. 1646 In the case of Offer or Winner messages the attacker will have to 1647 impersonate the node that it wants to have become the DF. In the case of 1648 the Pass it will have to impersonate the current DF. This type of attack 1649 causes the wrong DF to be recorded in all nodes apart from the one that 1650 is being impersonated. This node typically will be able to detect the 1651 anomaly and, possibly, restart a new election. 1653 A more sophisticated attacker might carry out a concurrent DoS attack on 1654 the node being impersonated, so that it will not be able to detect the 1655 forged packets and/or take countermeasures. 1657 All attacks based on impersonation can be detected by all routers and 1658 avoided if the source of DF-election messages can be authenticated. 1659 When authentication is available, spoofed messages MUST be discarded and 1660 a rate-limited warning message SHOULD be logged. 1662 A more subtle attacker could use MAC-level addresses to partition the 1663 set of recipients of DF-election messages and create an inconsistent DF 1664 view on the link. For example the attacker could use unicast MAC 1665 addresses for its forged DF-election messages. To prevent this type of 1666 attack, BIDIR-PIM routers SHOULD check the destination MAC address of 1667 received DF-election messages. This however is ineffective on links 1668 that do not support layer-2 multicast delivery. 1670 Source authentication is also sufficient to prevent this kind of attack. 1672 5.1.2. Preventing Election Convergence 1674 By forging DF election messages, an attacker can prevent the election 1675 from converging thus disrupting the establishment of multicast 1676 forwarding trees. There are many ways to achieve this. The simplest is 1677 by sending an infinite sequence of Offer messages (the metric used in 1678 the messages is not important). 1680 5.2. Non-cryptographic Authentication Mechanisms 1682 A BIDIR-PIM router SHOULD provide an option to limit the set of 1683 neighbors from which it will accept Join/Prune, Assert, and DF-election 1684 messages. Either static configuration of IP addresses or an IPsec 1685 security association may be used. Furthermore, a PIM router SHOULD NOT 1686 accept protocol messages from a router from which it has not yet 1687 received a valid Hello message. 1689 5.2.1. Basic Access Control 1691 In a PIM-SM domain, when all routers are trusted, it is possible to 1692 implement a basic form of access control for both sources and receivers: 1693 Receivers can be validated by the last-hop DR and sources can be 1694 validated by the first-hop DR and/or the RP. 1696 In BIDIR-PIM this is generally feasible only for receivers, as sources 1697 can send to the multicast group without the need for routers to detect 1698 their activity and create source-specific state. However it is possible 1699 to modify the standard BIDIR-PIM behaviour, in a backward compatible 1700 way, to allow per-source access control. The tradeoff would be protocol 1701 simplicity, memory and processing requirements. 1703 5.3. Authentication Using IPsec 1705 Just like for PIM-SM, the IPsec [5] transport mode using the 1706 Authentication Header (AH) is the recommended method to prevent the 1707 above attacks against BIDIR-PIM. 1709 It is recommended that IPsec authentication be applied to all BIDIR-PIM 1710 protocol messages. The specification on how this is done is to be found 1711 in [4]. specifically the authentication of PIM-SM link-local messages, 1712 described in [4] applies to all BIDIR-PIM messages as well. 1714 5.4. Denial of Service Attacks 1716 The denial of service attack based on forged Join described in [4] also 1717 apply to BIDIR-PIM. 1719 6. Change history 1721 >From 06 to 07: Minor corrections in response to WG last call comments. 1723 >From 05 to 06: 1725 Minor editorial corrections. 1727 >From 03 to 05: 1729 RP concept replaced by RP Address (RPA) and RP Link (RPL). No DF 1730 election on RPL. RP forwards upstream on RPL. Accept joins even if not 1731 DF but do not forward. Added event description for DF election state 1732 machine. Security considerations by Lorenzo.Removed comparison with 1733 Dino's draft. 1735 >From 02 to 03: 1737 Consistency fixes in DF election tables to match state transition 1738 diagram pointed out by Apoorva. 1740 >From 00 to 01: 1742 The differences between this version (-01) of the BIDIR-PIM 1743 specification and draft-ietf-pim-bidir-new-00.txt are mostly in the 1744 format of the information presented. As BIDIR-PIM has many similarities 1745 in operation to Sparse-Mode PIM, the earlier version of this spec relied 1746 heavily on the now obsolete PIM-SM [8] specification. This revision 1747 removes this dependency and instead references the new Sparse-Mode 1748 documentation [4] where necessary. In addition the method in which the 1749 protocol specification is presented has been updated to follow the 1750 format of [4]. 1752 7. Acknowledgments 1754 The bidir proposal in this draft is heavily based on the ideas and text 1755 presented by Estrin and Farinacci in [7]. The main difference between 1756 the two proposals is in the method chosen for upstream forwarding. 1758 We would also like to thank John Zwiebel at Procket, Deborah Estrin at 1759 ISI/USC as well as Nidhi Bhaskar, Yiqun Cai, Toerless Eckert, Apoorva 1760 Karan, Rajitha Sumanasekera and Beau Williamson at cisco for their 1761 contributions and comments to this draft. 1763 8. Authors' Addresses 1765 Mark Handley 1766 Computer Science Department 1767 University College London 1768 M.Handley@cs.ucl.ac.uk 1770 Isidor Kouvelas 1771 Cisco Systems 1772 kouvelas@cisco.com 1774 Tony Speakman 1775 Cisco Systems 1776 speakman@cisco.com 1778 Lorenzo Vicisano 1779 Cisco Systems 1780 lorenzo@cisco.com 1782 9. Normative References 1784 [1] S.E. Deering, "Host extensions for IP multicasting", RFC 1112, Aug 1785 1989. 1787 [2] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet 1788 Group Management Protocol, Version 3", RFC 3376. 1790 [3] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery 1791 (MLD) for IPv6", RFC 2710. 1793 [4] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas "Protocol 1794 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1795 Specification (Revised)", Work In Progress, , 2004. 1798 [5] S. Kent, R. Atkinson, "Security Architecture for the Internet 1799 Protocol.", RFC 2401. 1801 10. Informative References 1803 [6] T. Bates , R. Chandra , D. Katz , Y. Rekhter, "Multiprotocol 1804 Extensions for BGP-4", RFC 2283 1806 [7] D. Estrin, D. Farinacci, "Bi-directional Shared Trees in PIM-SM", 1807 , May 1999. 1809 [8] D. Estrin et al, "Protocol Independent Multicast-Sparse Mode (PIM- 1810 SM): Protocol Specification", RFC 2362, Nov 1999. 1812 [9] W. Fenner, M. Handley, R. Kermode and D. Thaler, "Bootstrap Router 1813 (BSR) Mechanism for PIM Sparse Mode", Work in progress , 2003. 1816 11. Index 1817 DF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7,21 1818 Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1819 DownstreamJPState(G,I) . . . . . . . . . . . . . . . . . . . . . . . 12 1820 ET(G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . . .11,16,34 1821 ET(RPA,I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1822 I_am_DF(RPA,I) . . . . . . . . . . . . . . . . . . . . . . . . .12,14,17 1823 J/P_HoldTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1824 J/P_Override_Interval. . . . . . . . . . . . . . . . . . . . . . . 18,35 1825 JoinDesired(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1826 joins(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1827 JT(*,G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1828 JT(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11,35 1829 local_receiver_include(G,I). . . . . . . . . . . . . . . . . . . . . 12 1830 MFIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1831 NLT(N,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1832 Offer_Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1833 olist(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . .12,14,20 1834 OT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1835 pim_include(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1836 PPT(G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . .11,16,35 1837 RPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1838 RPF_interface(RPA) . . . . . . . . . . . . . . . . . . . . . . . . 12,14 1839 RPL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1840 TIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1841 t_override . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20,35 1842 t_periodic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20,35 1843 t_suppressed . . . . . . . . . . . . . . . . . . . . . . . . . . . 20,35 1844 Upstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1845 The IETF takes no position regarding the validity or scope of any 1846 Intellectual Property Rights or other rights that might be claimed to 1847 pertain to the implementation or use of the technology described in this 1848 document or the extent to which any license under such rights might or 1849 might not be available; nor does it represent that it has made any 1850 independent effort to identify any such rights. Information on the 1851 procedures with respect to rights in RFC documents can be found in BCP 1852 78 and BCP 79. 1854 Copies of IPR disclosures made to the IETF Secretariat and any 1855 assurances of licenses to be made available, or the result of an attempt 1856 made to obtain a general license or permission for the use of such 1857 proprietary rights by implementers or users of this specification can be 1858 obtained from the IETF on-line IPR repository at 1859 http://www.ietf.org/ipr. 1861 The IETF invites any interested party to bring to its attention any 1862 copyrights, patents or patent applications, or other proprietary rights 1863 that may cover technology that may be required to implement this 1864 standard. Please address the information to the IETF at ietf- 1865 ipr@ietf.org. 1867 12. Full Copyright Statement 1869 Copyright (C) The Internet Society (2005). This document is subject to 1870 the rights, licenses and restrictions contained in BCP 78, and except as 1871 set forth therein, the authors retain all their rights. 1873 This document and the information contained herein are provided on an 1874 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1875 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1876 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1877 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1878 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1879 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.