idnits 2.17.1 draft-ietf-bfd-multipoint-08.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 (April 12, 2016) is 2908 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 633, 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: October 14, 2016 Cisco Systems 6 S. Pallagatti, Ed. 7 Individual contributor 8 April 12, 2016 10 BFD for Multipoint Networks 11 draft-ietf-bfd-multipoint-08 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 October 14, 2016. 43 Copyright Notice 45 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . 8 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 The Bidirectional Forwarding Detection protocol [RFC5880] specifies a 95 method for verifying unicast connectivity between a pair of systems. 96 This document defines a method for using BFD to provide verification 97 of multipoint or multicast connectivity between a multipoint sender 98 (the "head") and a set of one or more multipoint receivers (the 99 "tails"). 101 As multipoint transmissions are inherently unidirectional, this 102 mechanism purports only to verify this unidirectional connectivity. 103 Although this seems in conflict with the "Bidirectional" in BFD, it 104 is a natural fit for that protocol. 106 This application of BFD allows for the tails to detect a lack of 107 connectivity from the head. Due to unidirectional nature, virtually 108 all options and timing parameters are controlled by the head. 110 As an option, the tail may notify the head of the lack of multipoint 111 connectivity. Details of tail notification to head are outside the 112 scope of this document. 114 Throughout this document, the term "multipoint" is defined as a 115 mechanism by which one or more systems receive packets sent by a 116 single sender. This specifically includes such things as IP 117 multicast and point-to-multipoint MPLS. 119 This document effectively modifies and adds to the base BFD 120 specification. It is the intention of the authors to fold these 121 extensions into the base specification at the appropriate time. 123 2. Goals 125 The primary goal of this mechanism is to allow tails to rapidly 126 detect the fact that multipoint connectivity from the head has 127 failed. 129 Another goal is for the mechanism to work on any multicast or 130 multipoint medium. 132 A further goal is to support multiple, overlapping multipoint paths, 133 as well as multipoint paths with multiple heads, and to allow point- 134 to-point BFD sessions to operate simultaneously among the systems 135 participating in Multipoint BFD. 137 A final goal is to integrate multipoint operation into the base 138 specification in such a way as to make it relatively easy to support 139 both multipoint and point-to-point operation in a single 140 implementation. 142 It is a non-goal for this protocol to verify point-to-point 143 connectivity between the head and any tails. This can be done 144 independently (and with no penalty in protocol overhead) by using 145 point-to-point BFD. 147 3. Overview 149 The heart of this protocol is the periodic transmission of BFD 150 Control packets along a multipoint path, from the head to all tails 151 on the tree. The contents of the BFD packets provide the means for 152 the tails to calculate the detection time for path failure. If no 153 BFD Control packets are received by a tail for a detection time, the 154 tail declares the path to have failed. For some applications this is 155 the only mechanism necessary; the head can remain ignorant of the 156 tails. 158 Head may wish to be alerted to the tails' connectivity (or lack 159 thereof). Details of how head keeps track of tails and how tails 160 alert it's connectivity to head are outside scope of this document. 162 Although this document describes a single head and a set of tails 163 spanned by a single multipoint path, the protocol is capable of 164 supporting (and discriminating between) more than one multipoint path 165 at both heads and tails. Furthermore, the same head and tail may 166 share multiple multipoint paths, and a multipoint path may have 167 multiple heads. 169 4. Protocol Details 171 This section describes the operation of Multipoint BFD in detail. 173 4.1. Multipoint BFD Control Packets 175 Multipoint BFD Control packets (packets sent by the head over a 176 multipoint path) are explicitly marked as such, via the setting of 177 the M bit. This means that Multipoint BFD does not depend on the 178 recipient of a packet to know whether the packet was received over a 179 multipoint path. This can be useful in scenarios where this 180 information may not be available to the recipient. 182 4.2. Session Model 184 Multipoint BFD is modeled as a set of sessions of different types. 185 The elements of procedure differ slightly for each type. 187 Point-to-point sessions, as described in [BFD], are of type 188 PointToPoint. 190 The head has a session of type MultipointHead that is bound to a 191 multipoint path. Multipoint BFD Control packets are sent by this 192 session over the multipoint path, and no BFD Control packets are 193 received by it. 195 Each tail has a session of type MultipointTail associated with a 196 multipoint path. These sessions receive BFD Control packets from the 197 head over multipoint path. 199 4.3. Session Failure Semantics 201 The semantics of session failure are subtle enough to warrant further 202 explanation. 204 MultipointHead sessions cannot fail (since they are controlled 205 administratively.) 207 If a MultipointTail session fails, it means that the tail definitely 208 has lost contact with the head (or the head has been administratively 209 disabled) and the tail should take appropriate action. 211 4.4. State Variables 213 Multipoint BFD introduces some new state variables, and modifies the 214 usage of a few existing ones. 216 4.4.1. New State Variables 218 A number of state variables are added to the base specification in 219 support of Multipoint BFD. 221 bfd.SessionType 223 The type of this session. Allowable values are: 225 PointToPoint: Classic point-to-point BFD. 227 MultipointHead: A session on the head responsible for the 228 periodic transmission of multipoint BFD Control packets 229 along the multipoint path. 231 MultipointTail: A multipoint session on a tail. 233 This variable MUST be initialized to the appropriate type when 234 the session is created, according to the rules in Section 4.13 236 bfd.SilentTail 238 Always set to 1, a tail will never transmit any BFD Control 239 packets to the head under any circumstances. Setting to 0 is 240 outside the scope of this document. 242 This variable is only pertinent when bfd.SessionType is 243 MultipointTail. 245 4.4.2. State Variable Initialization and Maintenance 247 Some state variables defined in section 6.8.1 of the [RFC5880] needs 248 to be initialized or manipulated differently depending on the session 249 type. 251 bfd.RequiredMinRxInterval 253 This variable MUST be set to 0 for session type MultipointHead. 255 bfd.DemandMode 257 This variable MUST be initialized to 1 for session type 258 MultipointHead and MUST be initialized to 0 for session type 259 MultipointTail. 261 4.5. State Machine 263 The BFD state machine works slightly differently in the multipoint 264 application. In particular, since there is a many-to-one mapping, 265 three-way handshakes for session establishment and teardown are 266 neither possible nor appropriate. As such there is no Init state. 267 Session of type MultipointHead MUST NOT send BFD control packets with 268 the State field being set to INIT, and must be ignored on receipt. 270 The following diagram provides an overview of the state machine for 271 session type MultipointTail. The notation on each arc represents the 272 state of the remote system (as received in the State field in the BFD 273 Control packet) or indicates the expiration of the Detection Timer. 275 DOWN, ADMIN DOWN, 276 +------+ TIMER +------+ 277 +----| |<---------------------| |----+ 278 DOWN,| | DOWN | | UP | |UP 279 ADMIN DOWN,+--->| |--------------------->| |<---+ 280 TIMER +------+ UP +------+ 282 Sessions of type MultipointHead never receive packets and have no 283 Detection Timer, and as such all state transitions are 284 administratively driven. 286 4.6. Session Establishment 288 Unlike Point-to-point BFD, Multipoint BFD provides a form of 289 discovery mechanism for tails to discover the head. The minimum 290 amount of a priori information required both on the head and tails is 291 the binding to the multipoint path over which BFD is running. The 292 head transmits Multipoint BFD packets on that tree, and the tails 293 listen for BFD packets on that tree. All other information MAY be 294 determined dynamically. 296 A session of type MultipointHead is created for each multipoint path 297 over which the head wishes to run BFD. This session runs in the 298 Active role. Except when terminating BFD service, this session is 299 always in state Up and always operates in Demand mode. No received 300 packets are ever demultiplexed to the MultipointHead session. In 301 this sense it is a degenerate form of a session. 303 Sessions on the tail MAY be established dynamically, based on the 304 receipt of a Multipoint BFD Control packet from the head, and are of 305 type MultipointTail. Tail sessions always take the Passive role. 307 4.7. Discriminators and Packet Demultiplexing 309 The use of Discriminators is somewhat different in Multipoint BFD 310 than in Point-to-point BFD. 312 The head sends Multipoint BFD Control packets over the MultipointHead 313 session with My Discr set to a value bound to the multipoint path, 314 and with Your Discr set to zero. 316 IP and MPLS multipoint tails MUST demultiplex BFD packets based on a 317 combination of the source address, My Discriminator and the identity 318 of the multipoint tree which the Multipoint BFD Control packet was 319 received from. Together they uniquely identify the head of the 320 multipoint path. Bootstrapping BFD session to a multipoint LSP in 321 case of penultimate hop popping is outside the scope of this 322 document. 324 Note that, unlike PointToPoint sessions, the discriminator values on 325 all multipoint session types MUST NOT be changed during the life of a 326 session. This is a side effect of the more complex demultiplexing 327 scheme. 329 4.8. Packet consumption on tails 331 BFD packets received on tails for a multicast group MUST be consumed 332 by tails and MUST not be forwarded to receivers. Session of type 333 MultipointTail MUST identify the packet as BFD with the help of 334 destination UDP port number "3784" on IP multipoint path. For 335 multipoint LSP, MultipointTail MUST use destination UDP port "3784" 336 and IP "127.0.0.0/8" range. Packet identified as BFD packet MUST be 337 consumed by MultipointTail and demultiplex as described in 338 Section 4.13.2 340 4.9. Bringing Up and Shutting Down Multipoint BFD Service 342 Because there is no three-way handshake in Multipoint BFD, a newly 343 started head (that does not have any previous state information 344 available) SHOULD start with bfd.SessionState set to Down and with 345 bfd.RequiredMinRxInterval set to zero in the MultipointHead session. 346 The session SHOULD remain in this state for a time equal to 347 (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that 348 all MultipointTail sessions are reset (so long as the restarted head 349 is using the same or larger value of bfd.DesiredMinTxInterval than it 350 did previously.) 352 Multipoint BFD service is brought up by administratively setting 353 bfd.SessionState to Up in the MultipointHead session. 355 A head may wish to shut down its BFD service in a controlled fashion. 356 This is desirable because the tails need not wait a detection time 357 prior to declaring the multipoint session to be down (and taking 358 whatever action is necessary in that case.) 360 To shut down a multipoint session a head MUST administratively set 361 bfd.SessionState in the MultipointHead session to either Down or 362 AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The 363 session SHOULD send BFD Control packets in this state for a period 364 equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). 366 The semantic difference between Down and AdminDown state is for 367 further discussion. 369 4.10. Timer Manipulation 371 Because of the one-to-many mapping, a session of type MultipointHead 372 SHOULD NOT initiate a Poll Sequence in conjunction with timer value 373 changes. However to indicate change in packet MultipointHead session 374 MUST send packet with P bit set. MultipointTail session MUST NOT 375 reply if packet has M, P bit set and bfd.RequiredMinRxInterval set to 376 0. 378 The MultipointHead MUST send bfd.DetectMult packets with P bit set at 379 the old transmit interval before using the higher value in order to 380 avoid false detection timeouts at the tails. MultipointHead May also 381 wait some amount of time before making the changes to the transmit 382 interval (through configuration). 384 Change in the value of bfd.RequiredMinRxInterval is outside the scope 385 of this document. 387 4.11. Detection Times 389 Multipoint BFD is inherently asymmetric. As such, each session type 390 has a different approach to detection times. 392 Since the MultipointHead session never receives packets, it does not 393 calculate a detection time. 395 MultipointTail sessions cannot influence the transmission rate of the 396 MultipointHead session using the Required Min Rx Interval field 397 because of its one-to-many nature. As such, the Detection Time 398 calculation for a MultipointTail session does not use 399 bfd.RequiredMinRxInterval in the calculation. The detection time is 400 calculated as the product of the last received values of Desired Min 401 TX Interval and Detect Mult. 403 The value of bfd.DetectMult may be changed at any time on any session 404 type. 406 4.12. State Maintenance for Down/AdminDown Sessions 408 The length of time session state is kept after the session goes down 409 determines how long the session will continue to send BFD Control 410 packets (since no packets can be sent after the session is 411 destroyed.) 413 4.12.1. MultipointHead Sessions 415 When a MultipointHead session transitions to states Down or 416 AdminDown, the state SHOULD be maintained for a period equal to 417 (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails 418 more quickly detect the session going down (by continuing to transmit 419 BFD Control packets with the new state.) 421 4.12.2. MultipointTail Sessions 423 MultipointTail sessions MAY be destroyed immediately upon leaving Up 424 state, since tail will transmit no packets. 426 Otherwise, MultipointTail sessions SHOULD be maintained as long as 427 BFD Control packets are being received by it (which by definition 428 will indicate that the head is not Up.) 430 4.13. Base Specification Text Replacement 432 The following sections are meant to replace the corresponding 433 sections in the base specification. 435 4.13.1. Reception of BFD Control Packets 437 The following procedure replaces section 6.8.6 of [RFC5880]. 439 When a BFD Control packet is received, the following procedure MUST 440 be followed, in the order specified. If the packet is discarded 441 according to these rules, processing of the packet MUST cease at that 442 point. 444 If the version number is not correct (1), the packet MUST be 445 discarded. 447 If the Length field is less than the minimum correct value (24 if 448 the A bit is clear, or 26 if the A bit is set), the packet MUST be 449 discarded. 451 If the Length field is greater than the payload of the 452 encapsulating protocol, the packet MUST be discarded. 454 If the Detect Mult field is zero, the packet MUST be discarded. 456 If the My Discriminator field is zero, the packet MUST be 457 discarded. 459 Demultiplex the packet to a session according to Section 4.13.2 460 below. The result is either a session of the proper type, or the 461 packet is discarded (and packet processing MUST cease.) 463 If the A bit is set and no authentication is in use (bfd.AuthType 464 is zero), the packet MUST be discarded. 466 If the A bit is clear and authentication is in use (bfd.AuthType 467 is nonzero), the packet MUST be discarded. 469 If the A bit is set, the packet MUST be authenticated under the 470 rules of section 6.7, based on the authentication type in use 471 (bfd.AuthType.) This may cause the packet to be discarded. 473 Set bfd.RemoteDiscr to the value of My Discriminator. 475 Set bfd.RemoteState to the value of the State (Sta) field. 477 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 479 Set bfd.RemoteMinRxInterval to the value of Required Min RX 480 Interval. 482 If the Required Min Echo RX Interval field is zero, the 483 transmission of Echo packets, if any, MUST cease. 485 If a Poll Sequence is being transmitted by the local system and 486 the Final (F) bit in the received packet is set, the Poll Sequence 487 MUST be terminated. 489 If bfd.SessionType is PointToPoint, update the transmit interval 490 as described in [RFC5880] section 6.8.2. 492 If bfd.SessionType is PointToPoint, update the Detection Time as 493 described in [RFC5880] section 6.8.4. Otherwise, update the 494 Detection Time as described in Section 4.11 above. 496 If bfd.SessionState is AdminDown 498 Discard the packet 500 If received state is AdminDown 502 If bfd.SessionState is not Down 504 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 506 Set bfd.SessionState to Down 508 Else 510 If bfd.SessionState is Down 512 If bfd.SessionType is PointToPoint 514 If received State is Down 516 Set bfd.SessionState to Init 518 Else if received State is Init 520 Set bfd.SessionState to Up 522 Else (bfd.SessionType is not PointToPoint) 523 If received State is Up 525 Set bfd.SessionState to Up 527 Else if bfd.SessionState is Init 529 If received State is Init or Up 531 Set bfd.SessionState to Up 533 Else (bfd.SessionState is Up) 535 If received State is Down 537 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 539 Set bfd.SessionState to Down 541 Check to see if Demand mode should become active or not (see 542 [RFC5880] section 6.6). 544 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 545 bfd.RemoteSessionState is Up, Demand mode is active on the remote 546 system and the local system MUST cease the periodic transmission 547 of BFD Control packets (see Section 4.13.3.) 549 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 550 bfd.RemoteSessionState is not Up, Demand mode is not active on the 551 remote system and the local system MUST send periodic BFD Control 552 packets (see see Section 4.13.3.) 554 If the packet was not discarded, it has been received for purposes 555 of the Detection Time expiration rules in [RFC5880] section 6.8.4. 557 4.13.2. Demultiplexing BFD Control Packets 559 This section is part of the replacement for [RFC5880] section 6.8.6, 560 separated for clarity. 562 If the Multipoint (M) bit is set 564 If the Your Discriminator field is nonzero, the packet MUST be 565 discarded. 567 Select a session as based on source address, My Discriminator 568 and the identity of the multipoint tree which the Multipoint 569 BFD Control packet was received. If a session is found, and 570 bfd.SessionType is not MultipointTail, the packet MUST be 571 discarded. If a session is not found, a new session of type 572 MultipointTail MAY be created, or the packet MAY be discarded. 573 This choice is outside the scope of this specification. 575 Else (Multipoint bit is clear) 577 If the Your Discriminator field is nonzero 579 Select a session based on the value of Your Discriminator. 580 If no session is found, the packet MUST be discarded. 582 Else (Your Discriminator is zero) 584 If the State field is not Down or AdminDown, the packet MUST 585 be discarded. 587 Otherwise, the session MUST be selected based on some 588 combination of other fields, possibly including source 589 addressing information, the My Discriminator field, and the 590 interface over which the packet was received. The exact 591 method of selection is application-specific and is thus 592 outside the scope of this specification. 594 If a matching session is found, and bfd.SessionType is not 595 PointToPoint, the packet MUST be discarded. 597 If a matching session is not found, a new session of type 598 PointToPoint may be created, or the packet may be discarded. 599 This choice is outside the scope of this specification. 601 If the State field is Init and bfd.SessionType is not 602 PointToPoint, the packet MUST be discarded. 604 4.13.3. Transmitting BFD Control Packets 606 The following procedure replaces section 6.8.7 of [RFC5880]. 608 BFD Control packets MUST be transmitted periodically at the rate 609 determined according to [RFC5880] section 6.8.2, except as specified 610 in this section. 612 A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr 613 is zero and the system is taking the Passive role. 615 A system MUST NOT transmit any BFD Control packets if bfd.SilentTail 616 is 1. 618 A system MUST NOT periodically transmit BFD Control packets if Demand 619 mode is active on the remote system (bfd.RemoteDemandMode is 1, 620 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 621 Sequence is not being transmitted. 623 A system MUST NOT periodically transmit BFD Control packets if 624 bfd.RemoteMinRxInterval is zero. 626 If bfd.SessionType is MultipointHead, the transmit interval MUST be 627 set to bfd.DesiredMinTxInterval (this should happen automatically, as 628 bfd.RemoteMinRxInterval will be zero.) 630 If bfd.SessionType is not MultipointHead, the transmit interval MUST 631 be recalculated whenever bfd.DesiredMinTxInterval changes, or 632 whenever bfd.RemoteMinRxInterval changes, and is equal to the greater 633 of those two values. See [BFD] sections 6.8.2 and 6.8.3 for details 634 on transmit timers. 636 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 637 MultipointTail. 639 A system MUST NOT set the Demand (D) bit if bfd.SessionType 640 PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and 641 bfd.RemoteSessionState is Up. 643 If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control 644 packet SHOULD be transmitted during the interval between periodic 645 Control packet transmissions when the contents of that packet would 646 differ from that in the previously transmitted packet (other than the 647 Poll and Final bits) in order to more rapidly communicate a change in 648 state. 650 The contents of transmitted BFD Control packets MUST be set as 651 follows: 653 Version 655 Set to the current version number (1). 657 Diagnostic (Diag) 659 Set to bfd.LocalDiag. 661 State (Sta) 663 Set to the value indicated by bfd.SessionState. 665 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. Acknowledgements 775 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 776 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 777 greatly contributed to this document. 779 10. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, 783 DOI 10.17487/RFC2119, March 1997, 784 . 786 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 787 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 788 . 790 Authors' Addresses 792 Dave Katz 793 Juniper Networks 794 1194 N. Mathilda Ave. 795 Sunnyvale, California 94089-1206 796 USA 798 Email: dkatz@juniper.net 800 Dave Ward 801 Cisco Systems 802 170 West Tasman Dr. 803 San Jose, California 95134 804 USA 806 Email: wardd@cisco.com 807 Santosh Pallagatti (editor) 808 Individual contributor 810 Email: santosh.pallagatti@gmail.com