idnits 2.17.1 draft-ietf-bfd-multipoint-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: BFD packets received on tails for a multicast group MUST be consumed by tails and MUST not be forwarded to receivers. Session of type MultipointTail MUST identify the packet as BFD with the help of destination UDP port number "3784" on IP multipoint path. For multipoint LSP, MultipointTail MUST use destination UDP port "3784" and IP "127.0.0.0/8" range. Packet identified as BFD packet MUST be consumed by MultipointTail and demultiplex as described in Section 4.13.2 -- The document date (May 6, 2015) is 3278 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) == Missing Reference: 'BFD' is mentioned on line 632, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Katz 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track D. Ward 5 Expires: November 7, 2015 Cisco Systems 6 S. Pallagatti, Ed. 7 Juniper Networks 8 May 6, 2015 10 BFD for Multipoint Networks 11 draft-ietf-bfd-multipoint-06 13 Abstract 15 This document describes extensions to the Bidirectional Forwarding 16 Detection (BFD) protocol for its use in multipoint and multicast 17 networks. Comments on this draft should be directed to rtg- 18 bfd@ietf.org. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 7, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 65 4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 4 66 4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 67 4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 68 4.4.1. New State Variables . . . . . . . . . . . . . . . . . 5 69 4.4.2. State Variable Initialization and Maintenance . . . . 6 70 4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 71 4.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 72 4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 73 4.8. Packet consumption on tails . . . . . . . . . . . . . . . 7 74 4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 75 4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 8 76 4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 77 4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 78 4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 9 79 4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 9 80 4.13. Base Specification Text Replacement . . . . . . . . . . . 10 81 4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 82 4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 12 83 4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 13 84 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 88 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The Bidirectional Forwarding Detection protocol [RFC5880] specifies a 94 method for verifying unicast connectivity between a pair of systems. 95 This document defines a method for using BFD to provide verification 96 of multipoint or multicast connectivity between a multipoint sender 97 (the "head") and a set of one or more multipoint receivers (the 98 "tails"). 100 As multipoint transmissions are inherently unidirectional, this 101 mechanism purports only to verify this unidirectional connectivity. 102 Although this seems in conflict with the "Bidirectional" in BFD, it 103 is a natural fit for that protocol. 105 This application of BFD allows for the tails to detect a lack of 106 connectivity from the head. Due to unidirectional nature, virtually 107 all options and timing parameters are controlled by the head. 109 As an option, the tail may notify the head of the lack of multipoint 110 connectivity. Details of tail notification to head are outside the 111 scope of this document. 113 Throughout this document, the term "multipoint" is defined as a 114 mechanism by which one or more systems receive packets sent by a 115 single sender. This specifically includes such things as IP 116 multicast and point-to-multipoint MPLS. 118 This document effectively modifies and adds to the base BFD 119 specification. It is the intention of the authors to fold these 120 extensions into the base specification at the appropriate time. 122 2. Goals 124 The primary goal of this mechanism is to allow tails to rapidly 125 detect the fact that multipoint connectivity from the head has 126 failed. 128 Another goal is for the mechanism to work on any multicast or 129 multipoint medium. 131 A further goal is to support multiple, overlapping multipoint paths, 132 as well as multipoint paths with multiple heads, and to allow point- 133 to-point BFD sessions to operate simultaneously among the systems 134 participating in Multipoint BFD. 136 A final goal is to integrate multipoint operation into the base 137 specification in such a way as to make it relatively easy to support 138 both multipoint and point-to-point operation in a single 139 implementation. 141 It is a non-goal for this protocol to verify point-to-point 142 connectivity between the head and any tails. This can be done 143 independently (and with no penalty in protocol overhead) by using 144 point-to-point BFD. 146 3. Overview 148 The heart of this protocol is the periodic transmission of BFD 149 Control packets along a multipoint path, from the head to all tails 150 on the tree. The contents of the BFD packets provide the means for 151 the tails to calculate the detection time for path failure. If no 152 BFD Control packets are received by a tail for a detection time, the 153 tail declares the path to have failed. For some applications this is 154 the only mechanism necessary; the head can remain ignorant of the 155 tails. 157 Head may wish to be alerted to the tails' connectivity (or lack 158 thereof). Details of how head keeps track of tails and how tails 159 alert it's connectivity to head are outside scope of this document. 161 Although this document describes a single head and a set of tails 162 spanned by a single multipoint path, the protocol is capable of 163 supporting (and discriminating between) more than one multipoint path 164 at both heads and tails. Furthermore, the same head and tail may 165 share multiple multipoint paths, and a multipoint path may have 166 multiple heads. 168 4. Protocol Details 170 This section describes the operation of Multipoint BFD in detail. 172 4.1. Multipoint BFD Control Packets 174 Multipoint BFD Control packets (packets sent by the head over a 175 multipoint path) are explicitly marked as such, via the setting of 176 the M bit. This means that Multipoint BFD does not depend on the 177 recipient of a packet to know whether the packet was received over a 178 multipoint path. This can be useful in scenarios where this 179 information may not be available to the recipient. 181 4.2. Session Model 183 Multipoint BFD is modeled as a set of sessions of different types. 184 The elements of procedure differ slightly for each type. 186 Point-to-point sessions, as described in [BFD], are of type 187 PointToPoint. 189 The head has a session of type MultipointHead that is bound to a 190 multipoint path. Multipoint BFD Control packets are sent by this 191 session over the multipoint path, and no BFD Control packets are 192 received by it. 194 Each tail has a session of type MultipointTail associated with a 195 multipoint path. These sessions receive BFD Control packets from the 196 head over multipoint path. 198 4.3. Session Failure Semantics 200 The semantics of session failure are subtle enough to warrant further 201 explanation. 203 MultipointHead sessions cannot fail (since they are controlled 204 administratively.) 206 If a MultipointTail session fails, it means that the tail definitely 207 has lost contact with the head (or the head has been administratively 208 disabled) and the tail should take appropriate action. 210 4.4. State Variables 212 Multipoint BFD introduces some new state variables, and modifies the 213 usage of a few existing ones. 215 4.4.1. New State Variables 217 A number of state variables are added to the base specification in 218 support of Multipoint BFD. 220 bfd.SessionType 222 The type of this session. Allowable values are: 224 PointToPoint: Classic point-to-point BFD. 226 MultipointHead: A session on the head responsible for the 227 periodic transmission of multipoint BFD Control packets 228 along the multipoint path. 230 MultipointTail: A multipoint session on a tail. 232 This variable MUST be initialized to the appropriate type when 233 the session is created, according to the rules in Section 4.13 235 bfd.SilentTail 236 Always set to 1, a tail will never transmit any BFD Control 237 packets to the head under any circumstances. Setting to 0 is 238 outside the scope of this document. 240 This variable is only pertinent when bfd.SessionType is 241 MultipointTail. 243 4.4.2. State Variable Initialization and Maintenance 245 Some state variables defined in section 6.8.1 of the [RFC5880] needs 246 to be initialized or manipulated differently depending on the session 247 type. 249 bfd.RequiredMinRxInterval 251 This variable MUST be set to 0 for session type MultipointHead. 253 bfd.DemandMode 255 This variable MUST be initialized to 1 for session type 256 MultipointHead and MUST be initialized to 0 for session type 257 MultipointTail. 259 4.5. State Machine 261 The BFD state machine works slightly differently in the multipoint 262 application. In particular, since there is a many-to-one mapping, 263 three-way handshakes for session establishment and teardown are 264 neither possible nor appropriate. As such there is no Init state. 265 Session of type MultipointHead MUST NOT send BFD control packets with 266 the State field being set to INIT, and must be ignored on receipt. 268 The following diagram provides an overview of the state machine for 269 session type MultipointTail. The notation on each arc represents the 270 state of the remote system (as received in the State field in the BFD 271 Control packet) or indicates the expiration of the Detection Timer. 273 DOWN, ADMIN DOWN, 274 +------+ TIMER +------+ 275 +----| |<---------------------| |----+ 276 DOWN,| | DOWN | | UP | |UP 277 ADMIN DOWN,+--->| |--------------------->| |<---+ 278 TIMER +------+ UP +------+ 280 Sessions of type MultipointHead never receive packets and have no 281 Detection Timer, and as such all state transitions are 282 administratively driven. 284 4.6. Session Establishment 286 Unlike Point-to-point BFD, Multipoint BFD provides a form of 287 discovery mechanism for tails to discover the head. The minimum 288 amount of a priori information required both on the head and tails is 289 the binding to the multipoint path over which BFD is running. The 290 head transmits Multipoint BFD packets on that tree, and the tails 291 listen for BFD packets on that tree. All other information MAY be 292 determined dynamically. 294 A session of type MultipointHead is created for each multipoint path 295 over which the head wishes to run BFD. This session runs in the 296 Active role. Except when terminating BFD service, this session is 297 always in state Up and always operates in Demand mode. No received 298 packets are ever demultiplexed to the MultipointHead session. In 299 this sense it is a degenerate form of a session. 301 Sessions on the tail MAY be established dynamically, based on the 302 receipt of a Multipoint BFD Control packet from the head, and are of 303 type MultipointTail. Tail sessions always take the Passive role. 305 4.7. Discriminators and Packet Demultiplexing 307 The use of Discriminators is somewhat different in Multipoint BFD 308 than in Point-to-point BFD. 310 The head sends Multipoint BFD Control packets over the MultipointHead 311 session with My Discr set to a value bound to the multipoint path, 312 and with Your Discr set to zero. 314 IP and MPLS multipoint tails MUST demultiplex BFD packets based on a 315 combination of the source address, My Discriminator and the identity 316 of the multipoint tree which the Multipoint BFD Control packet was 317 received from. Together they uniquely identify the head of the 318 multipoint path. Bootstrapping BFD session to a multipoint LSP in 319 case of penultimate hop popping is outside the scope of this 320 document. 322 Note that, unlike PointToPoint sessions, the discriminator values on 323 all multipoint session types MUST NOT be changed during the life of a 324 session. This is a side effect of the more complex demultiplexing 325 scheme. 327 4.8. Packet consumption on tails 329 BFD packets received on tails for a multicast group MUST be consumed 330 by tails and MUST not be forwarded to receivers. Session of type 331 MultipointTail MUST identify the packet as BFD with the help of 332 destination UDP port number "3784" on IP multipoint path. For 333 multipoint LSP, MultipointTail MUST use destination UDP port "3784" 334 and IP "127.0.0.0/8" range. Packet identified as BFD packet MUST be 335 consumed by MultipointTail and demultiplex as described in 336 Section 4.13.2 338 4.9. Bringing Up and Shutting Down Multipoint BFD Service 340 Because there is no three-way handshake in Multipoint BFD, a newly 341 started head (that does not have any previous state information 342 available) SHOULD start with bfd.SessionState set to Down and with 343 bfd.RequiredMinRxInterval set to zero in the MultipointHead session. 344 The session SHOULD remain in this state for a time equal to 345 (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that 346 all MultipointTail sessions are reset (so long as the restarted head 347 is using the same or larger value of bfd.DesiredMinTxInterval than it 348 did previously.) 350 Multipoint BFD service is brought up by administratively setting 351 bfd.SessionState to Up in the MultipointHead session. 353 A head may wish to shut down its BFD service in a controlled fashion. 354 This is desirable because the tails need not wait a detection time 355 prior to declaring the multipoint session to be down (and taking 356 whatever action is necessary in that case.) 358 To shut down a multipoint session a head MUST administratively set 359 bfd.SessionState in the MultipointHead session to either Down or 360 AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The 361 session SHOULD send BFD Control packets in this state for a period 362 equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). 364 The semantic difference between Down and AdminDown state is for 365 further discussion. 367 4.10. Timer Manipulation 369 Because of the one-to-many mapping, a session of type MultipointHead 370 SHOULD NOT initiate a Poll Sequence in conjunction with timer value 371 changes. However to indicate change in packet MultipointHead session 372 MUST send packet with P bit set. MultipointTail session MUST NOT 373 reply if packet has M, P bit set and bfd.RequiredMinRxInterval set to 374 0. 376 The MultipointHead MUST send bfd.DetectMult packets with P bit set at 377 the old transmit interval before using the higher value in order to 378 avoid false detection timeouts at the tails. MultipointHead May also 379 wait some amount of time before making the changes to the transmit 380 interval (through configuration). 382 Change in the value of bfd.RequiredMinRxInterval is outside the scope 383 of this document. 385 4.11. Detection Times 387 Multipoint BFD is inherently asymmetric. As such, each session type 388 has a different approach to detection times. 390 Since the MultipointHead session never receives packets, it does not 391 calculate a detection time. 393 MultipointTail sessions cannot influence the transmission rate of the 394 MultipointHead session using the Required Min Rx Interval field 395 because of its one-to-many nature. As such, the Detection Time 396 calculation for a MultipointTail session does not use 397 bfd.RequiredMinRxInterval in the calculation. The detection time is 398 calculated as the product of the last received values of Desired Min 399 TX Interval and Detect Mult. 401 The value of bfd.DetectMult may be changed at any time on any session 402 type. 404 4.12. State Maintenance for Down/AdminDown Sessions 406 The length of time session state is kept after the session goes down 407 determines how long the session will continue to send BFD Control 408 packets (since no packets can be sent after the session is 409 destroyed.) 411 4.12.1. MultipointHead Sessions 413 When a MultipointHead session transitions to states Down or 414 AdminDown, the state SHOULD be maintained for a period equal to 415 (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails 416 more quickly detect the session going down (by continuing to transmit 417 BFD Control packets with the new state.) 419 4.12.2. MultipointTail Sessions 421 MultipointTail sessions MAY be destroyed immediately upon leaving Up 422 state, since tail will transmit no packets. 424 Otherwise, MultipointTail sessions SHOULD be maintained as long as 425 BFD Control packets are being received by it (which by definition 426 will indicate that the head is not Up.) 428 4.13. Base Specification Text Replacement 430 The following sections are meant to replace the corresponding 431 sections in the base specification. 433 4.13.1. Reception of BFD Control Packets 435 The following procedure replaces section 6.8.6 of [RFC5880]. 437 When a BFD Control packet is received, the following procedure MUST 438 be followed, in the order specified. If the packet is discarded 439 according to these rules, processing of the packet MUST cease at that 440 point. 442 If the version number is not correct (1), the packet MUST be 443 discarded. 445 If the Length field is less than the minimum correct value (24 if 446 the A bit is clear, or 26 if the A bit is set), the packet MUST be 447 discarded. 449 If the Length field is greater than the payload of the 450 encapsulating protocol, the packet MUST be discarded. 452 If the Detect Mult field is zero, the packet MUST be discarded. 454 If the My Discriminator field is zero, the packet MUST be 455 discarded. 457 Demultiplex the packet to a session according to Section 4.13.2 458 below. The result is either a session of the proper type, or the 459 packet is discarded (and packet processing MUST cease.) 461 If the A bit is set and no authentication is in use (bfd.AuthType 462 is zero), the packet MUST be discarded. 464 If the A bit is clear and authentication is in use (bfd.AuthType 465 is nonzero), the packet MUST be discarded. 467 If the A bit is set, the packet MUST be authenticated under the 468 rules of section 6.7, based on the authentication type in use 469 (bfd.AuthType.) This may cause the packet to be discarded. 471 Set bfd.RemoteDiscr to the value of My Discriminator. 473 Set bfd.RemoteState to the value of the State (Sta) field. 475 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 477 Set bfd.RemoteMinRxInterval to the value of Required Min RX 478 Interval. 480 If the Required Min Echo RX Interval field is zero, the 481 transmission of Echo packets, if any, MUST cease. 483 If a Poll Sequence is being transmitted by the local system and 484 the Final (F) bit in the received packet is set, the Poll Sequence 485 MUST be terminated. 487 If bfd.SessionType is PointToPoint, update the transmit interval 488 as described in [RFC5880] section 6.8.2. 490 If bfd.SessionType is PointToPoint, update the Detection Time as 491 described in [RFC5880] section 6.8.4. Otherwise, update the 492 Detection Time as described in Section 4.11 above. 494 If bfd.SessionState is AdminDown 496 Discard the packet 498 If received state is AdminDown 500 If bfd.SessionState is not Down 502 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 504 Set bfd.SessionState to Down 506 Else 508 If bfd.SessionState is Down 510 If bfd.SessionType is PointToPoint 512 If received State is Down 514 Set bfd.SessionState to Init 516 Else if received State is Init 518 Set bfd.SessionState to Up 520 Else (bfd.SessionType is not PointToPoint) 522 If received State is Up 524 Set bfd.SessionState to Up 526 Else if bfd.SessionState is Init 528 If received State is Init or Up 530 Set bfd.SessionState to Up 532 Else (bfd.SessionState is Up) 534 If received State is Down 536 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 538 Set bfd.SessionState to Down 540 Check to see if Demand mode should become active or not (see 541 [RFC5880] section 6.6). 543 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 544 bfd.RemoteSessionState is Up, Demand mode is active on the remote 545 system and the local system MUST cease the periodic transmission 546 of BFD Control packets (see Section 4.13.3.) 548 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 549 bfd.RemoteSessionState is not Up, Demand mode is not active on the 550 remote system and the local system MUST send periodic BFD Control 551 packets (see see Section 4.13.3.) 553 If the packet was not discarded, it has been received for purposes 554 of the Detection Time expiration rules in [RFC5880] section 6.8.4. 556 4.13.2. Demultiplexing BFD Control Packets 558 This section is part of the replacement for [RFC5880] section 6.8.6, 559 separated for clarity. 561 If the Multipoint (M) bit is set 563 If the Your Discriminator field is nonzero, the packet MUST be 564 discarded. 566 Select a session as based on source address, My Discriminator 567 and the identity of the multipoint tree which the Multipoint 568 BFD Control packet was received. If a session is found, and 569 bfd.SessionType is not MultipointTail, the packet MUST be 570 discarded. If a session is not found, a new session of type 571 MultipointTail MAY be created, or the packet MAY be discarded. 572 This choice is outside the scope of this specification. 574 Else (Multipoint bit is clear) 576 If the Your Discriminator field is nonzero 578 Select a session based on the value of Your Discriminator. 579 If no session is found, the packet MUST be discarded. 581 Else (Your Discriminator is zero) 583 If the State field is not Down or AdminDown, the packet MUST 584 be discarded. 586 Otherwise, the session MUST be selected based on some 587 combination of other fields, possibly including source 588 addressing information, the My Discriminator field, and the 589 interface over which the packet was received. The exact 590 method of selection is application-specific and is thus 591 outside the scope of this specification. 593 If a matching session is found, and bfd.SessionType is not 594 PointToPoint, the packet MUST be discarded. 596 If a matching session is not found, a new session of type 597 PointToPoint may be created, or the packet may be discarded. 598 This choice is outside the scope of this specification. 600 If the State field is Init and bfd.SessionType is not 601 PointToPoint, the packet MUST be discarded. 603 4.13.3. Transmitting BFD Control Packets 605 The following procedure replaces section 6.8.7 of [RFC5880]. 607 BFD Control packets MUST be transmitted periodically at the rate 608 determined according to [RFC5880] section 6.8.2, except as specified 609 in this section. 611 A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr 612 is zero and the system is taking the Passive role. 614 A system MUST NOT transmit any BFD Control packets if bfd.SilentTail 615 is 1. 617 A system MUST NOT periodically transmit BFD Control packets if Demand 618 mode is active on the remote system (bfd.RemoteDemandMode is 1, 619 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 620 Sequence is not being transmitted. 622 A system MUST NOT periodically transmit BFD Control packets if 623 bfd.RemoteMinRxInterval is zero. 625 If bfd.SessionType is MultipointHead, the transmit interval MUST be 626 set to bfd.DesiredMinTxInterval (this should happen automatically, as 627 bfd.RemoteMinRxInterval will be zero.) 629 If bfd.SessionType is not MultipointHead, the transmit interval MUST 630 be recalculated whenever bfd.DesiredMinTxInterval changes, or 631 whenever bfd.RemoteMinRxInterval changes, and is equal to the greater 632 of those two values. See [BFD] sections 6.8.2 and 6.8.3 for details 633 on transmit timers. 635 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 636 MultipointTail. 638 A system MUST NOT set the Demand (D) bit if bfd.SessionType 639 PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and 640 bfd.RemoteSessionState is Up. 642 If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control 643 packet SHOULD be transmitted during the interval between periodic 644 Control packet transmissions when the contents of that packet would 645 differ from that in the previously transmitted packet (other than the 646 Poll and Final bits) in order to more rapidly communicate a change in 647 state. 649 The contents of transmitted BFD Control packets MUST be set as 650 follows: 652 Version 654 Set to the current version number (1). 656 Diagnostic (Diag) 658 Set to bfd.LocalDiag. 660 State (Sta) 662 Set to the value indicated by bfd.SessionState. 664 Poll (P) 666 Set to 1 if the local system is sending a Poll Sequence or is a 667 session of type MultipointHead soliciting the identities of the 668 tails, or 0 if not. 670 Final (F) 672 Set to 1 if the local system is responding to a Control packet 673 received with the Poll (P) bit set, or 0 if not. 675 Control Plane Independent (C) 677 Set to 1 if the local system's BFD implementation is 678 independent of the control plane (it can continue to function 679 through a disruption of the control plane.) 681 Authentication Present (A) 683 Set to 1 if authentication is in use on this session 684 (bfd.AuthType is nonzero), or 0 if not. 686 Demand (D) 688 Set to bfd.DemandMode if bfd.SessionState is Up and 689 bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is 690 MultipointHead. Otherwise it is set to 0. 692 Multipoint (M) 694 Set to 1 if bfd.SessionType is MultipointHead. Otherwise it is 695 set to 0. 697 Detect Mult 699 Set to bfd.DetectMult. 701 Length 703 Set to the appropriate length, based on the fixed header length 704 (24) plus any Authentication Section. 706 My Discriminator 708 Set to bfd.LocalDiscr. 710 Your Discriminator 712 Set to bfd.RemoteDiscr. 714 Desired Min TX Interval 716 Set to bfd.DesiredMinTxInterval. 718 Required Min RX Interval 720 Set to bfd.RequiredMinRxInterval. 722 Required Min Echo RX Interval 724 Set to 0 if bfd.SessionType is MultipointHead or 725 MultipointTail. 727 Authentication Section 729 Included and set according to the rules in section 6.7 if 730 authentication is in use (bfd.AuthType is nonzero.) Otherwise 731 this section is not present. 733 5. Assumptions 735 If authentication is in use, all tails must be configured to have a 736 common authentication key in order to receive the multipoint BFD 737 Control packets. 739 6. IANA Considerations 741 This document has no actions for IANA. 743 7. Security Considerations 745 Implementations that creates MultpointTail sessions dynamically upon 746 receipt of Multipoint BFD Control packets MUST implement protective 747 measures to prevent infinite number of MultipointTail session being 748 created. Below lists some points to be considered in such 749 implementations. 751 If a Multipoint BFD Control packet did not arrive on a multicast 752 tree (ex: on expected interface, with expected MPLS label, etc), 753 then a MultipointTail session should not be created. 755 If redundant streams are expected for a given multicast stream, 756 then the implementations should not create more MultipointTail 757 sessions than the number of streams. Additionally, when the 758 number of MultipointTail sessions exceeds the number of expected 759 streams, then the implementation should generate an alarm to users 760 to indicate the anomaly. 762 The implementation should have a reasonable upper bound on the 763 number of MultipointTail sessions that can be created, with the 764 upper bound potentially being computed based on the number of 765 multicast streams that the system is expecting. 767 8. Contributors 769 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 770 Systems provided the initial idea for this specification and 771 contributed to its development. 773 9. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, March 1997. 778 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 779 (BFD)", RFC 5880, June 2010. 781 Authors' Addresses 783 Dave Katz 784 Juniper Networks 785 1194 N. Mathilda Ave. 786 Sunnyvale, California 94089-1206 787 USA 789 Email: dkatz@juniper.net 791 Dave Ward 792 Cisco Systems 793 170 West Tasman Dr. 794 San Jose, California 95134 795 USA 797 Email: wardd@cisco.com 799 Santosh Pallagatti (editor) 800 Juniper Networks 801 Embassy Business Park 802 Bangalore, KA 560093 803 India 805 Email: santoshpk@juniper.net