idnits 2.17.1 draft-ietf-bfd-multipoint-15.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC5880, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- 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 (April 17, 2018) is 2173 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). 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 Updates: 5880 (if approved) D. Ward 5 Intended status: Standards Track Cisco Systems 6 Expires: October 19, 2018 S. Pallagatti, Ed. 7 Individual contributor 8 G. Mirsky, Ed. 9 ZTE Corp. 10 April 17, 2018 12 BFD for Multipoint Networks 13 draft-ietf-bfd-multipoint-15 15 Abstract 17 This document describes extensions to the Bidirectional Forwarding 18 Detection (BFD) protocol for its use in multipoint and multicast 19 networks. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in BCP 26 14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 19, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 68 4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 4 69 4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 70 4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 71 4.4.1. New State Variable Values . . . . . . . . . . . . . . 5 72 4.4.2. State Variable Initialization and Maintenance . . . . 6 73 4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 74 4.6. Session Establishment . . . . . . . . . . . . . . . . . . 6 75 4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 76 4.8. Packet consumption on tails . . . . . . . . . . . . . . . 7 77 4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 78 4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 8 79 4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 80 4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 81 4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 9 82 4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 83 4.13. Base Specification Text Replacement . . . . . . . . . . . 10 84 4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 85 4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 86 4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 14 87 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 92 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 The Bidirectional Forwarding Detection protocol [RFC5880] specifies a 98 method for verifying unicast connectivity between a pair of systems. 99 This document defines a method for using BFD to provide verification 100 of multipoint or multicast connectivity between a multipoint sender 101 (the "head") and a set of one or more multipoint receivers (the 102 "tails"). 104 As multipoint transmissions are inherently unidirectional, this 105 mechanism purports only to verify this unidirectional connectivity. 106 Although this seems in conflict with the "Bidirectional" in BFD, the 107 protocol is capable supporting this use case. 109 This application of BFD allows for the tails to detect a lack of 110 connectivity from the head. Due to unidirectional nature, virtually 111 all options and timing parameters are controlled by the head. 113 As an option, the tail may notify the head of the lack of multipoint 114 connectivity. Details of tail notification to the head are outside 115 the scope of this document. 117 Throughout this document, the term "multipoint" is defined as a 118 mechanism by which one or more systems receive packets sent by a 119 single sender. This specifically includes such things as IP 120 multicast and point-to-multipoint MPLS. 122 Term "connectivity" in this document is not being used in the context 123 of connectivity verification in transport network but as an 124 alternative to "continuity", i.e. existence of a forwarding path 125 between the sender and the receiver. 127 This document effectively modifies and adds to the base BFD 128 specification [RFC5880]. 130 2. Goals 132 The primary goal of this mechanism is to allow tails to rapidly 133 detect the fact that multipoint connectivity from the head has 134 failed. 136 Another goal is for the mechanism to work on any multicast 137 technology. 139 A further goal is to support multiple, overlapping point-to- 140 multipoint paths, as well as multipoint-to-multipoint paths, and to 141 allow point-to-point BFD sessions to operate simultaneously among the 142 systems participating in Multipoint BFD. 144 It is not a goal for this protocol to verify point-to-point bi- 145 directional connectivity between the head and any tail. This can be 146 done independently (and with no penalty in protocol overhead) by 147 using point-to-point BFD. 149 3. Overview 151 The heart of this protocol is the periodic transmission of BFD 152 Control packets along a multipoint path, from the head to all tails 153 on the tree. The contents of the BFD packets provide the means for 154 the tails to calculate the detection time for path failure. If no 155 BFD Control packets are received by a tail for a detection time, the 156 tail declares the path to having failed. For some applications this 157 is the only mechanism necessary; the head can remain ignorant of the 158 tails. 160 The head of a multipoint BFD session may wish to be alerted to the 161 tails' connectivity (or lack thereof). Details of how the head keeps 162 track of tails and how tails alert their connectivity to the head are 163 outside scope of this document. 165 Although this document describes a single head and a set of tails 166 spanned by a single multipoint path, the protocol is capable of 167 supporting (and discriminating between) more than one multipoint path 168 at both heads and tails, as described in Section 4.7 and 169 Section 4.13.2. Furthermore, the same head and tail may share 170 multiple multipoint paths, and a multipoint path may have multiple 171 heads. 173 4. Protocol Details 175 This section describes the operation of Multipoint BFD in detail. 177 4.1. Multipoint BFD Control Packets 179 Multipoint BFD Control packets (packets sent by the head over a 180 multipoint path) are explicitly marked as such, via the setting of 181 the M bit [RFC5880]. This means that Multipoint BFD does not depend 182 on the recipient of a packet to know whether the packet was received 183 over a multipoint path. This can be useful in scenarios where this 184 information may not be available to the recipient. 186 4.2. Session Model 188 Multipoint BFD is modeled as a set of sessions of different types. 189 The elements of procedure differ slightly for each type. 191 The head has a session of type MultipointHead, as defined in 192 Section 4.4.1, that is bound to a multipoint path. Multipoint BFD 193 Control packets are sent by this session over the multipoint path, 194 and no BFD Control packets are received by it. 196 Each tail has a session of type MultipointTail, as defined in 197 Section 4.4.1, associated with a multipoint path. These sessions 198 receive BFD Control packets from the head over the multipoint path. 200 4.3. Session Failure Semantics 202 The semantics of session failure is subtle enough to warrant further 203 explanation. 205 MultipointHead sessions cannot fail (since they are controlled 206 administratively). 208 If a MultipointTail session fails, it means that the tail definitely 209 has lost contact with the head (or the head has been administratively 210 disabled) and the tail should take appropriate action. 212 4.4. State Variables 214 Multipoint BFD introduces some new state variables and modifies the 215 usage of a few existing ones. 217 4.4.1. New State Variable Values 219 A number of new values of the state variable bfd.SessionType are 220 added to the base BFD [RFC5880] and base S-BFD [RFC7880] 221 specifications in support of Multipoint BFD. 223 bfd.SessionType 225 The type of this session as defined in [RFC7880]. Newly added 226 values are: 228 PointToPoint: Classic point-to-point BFD, as described in 229 [RFC5880]. 231 MultipointHead: A session on the head responsible for the 232 periodic transmission of multipoint BFD Control packets 233 along the multipoint path. 235 MultipointTail: A multipoint session on a tail. 237 This variable MUST be initialized to the appropriate type when 238 the session is created, according to the rules in Section 4.13 240 4.4.2. State Variable Initialization and Maintenance 242 Some state variables defined in section 6.8.1 of [RFC5880] need to be 243 initialized or manipulated differently depending on the session type. 245 bfd.RequiredMinRxInterval 247 This variable MUST be initialized to 0 for session type 248 MultipointHead. 250 bfd.DemandMode 252 This variable MUST be initialized to 1 for session type 253 MultipointHead and MUST be initialized to 0 for session type 254 MultipointTail. 256 4.5. State Machine 258 The BFD state machine works slightly differently in the multipoint 259 application. In particular, since there is a many-to-one mapping, 260 three-way handshakes for session establishment and teardown are 261 neither possible nor appropriate. As such, there is no Init state. 262 Sessions of type MultipointHead MUST NOT send BFD control packets 263 with the State field being set to INIT, and those packets MUST be 264 ignored on receipt. 266 The following diagram provides an overview of the state machine for 267 session type MultipointTail. The notation on each arc represents the 268 state of the remote system (as received in the State field in the BFD 269 Control packet) or indicates the expiration of the Detection Timer. 271 DOWN, ADMIN DOWN, 272 +------+ TIMER +------+ 273 +----| |<---------------------| |----+ 274 DOWN,| | DOWN | | UP | |UP 275 ADMIN DOWN,+--->| |--------------------->| |<---+ 276 TIMER +------+ UP +------+ 278 Sessions of type MultipointHead never receive packets and have no 279 Detection Timer, and as such all state transitions are 280 administratively driven. 282 4.6. Session Establishment 284 Unlike point-to-point BFD, Multipoint BFD provides a form of the 285 discovery mechanism for tails to discover the head. The minimum 286 amount of a priori information required both on the head and tails is 287 binding to the multipoint path over which BFD is running. The head 288 transmits Multipoint BFD packets on that tree, and the tails listen 289 for BFD packets on that tree. All other information MAY be 290 determined dynamically. 292 A session of type MultipointHead is created for each multipoint path 293 over which the head wishes to run BFD. This session runs in the 294 Active role , per section 6.1 [RFC5880]. Except when 295 administratively terminating BFD service, this session is always in 296 state Up and always operates in Demand mode. No received packets are 297 ever demultiplexed to the MultipointHead session. In this sense, it 298 is a degenerate form of a session. 300 Sessions on the tail MAY be established dynamically, based on the 301 receipt of a Multipoint BFD Control packet from the head, and are of 302 type MultipointTail. Tail sessions always take the Passive role, per 303 section 6.1 [RFC5880]. 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 multipoint 311 path via the MultipointHead session with My Discr set to a value 312 bound to the multipoint path, 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 multipoint MPLS LSP in 319 case of penultimate hop popping is outside the scope of this 320 document. 322 Note that, unlike point-to-point sessions, the My Discriminator value 323 on MultipointHead session 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 an IP multicast group MUST be 330 consumed by tails and MUST NOT be forwarded to receivers. Node with 331 the BFD session of type MultipointTail MUST identify packet received 332 on an IP multipoint path as BFD control packet if the destination UDP 333 port value equals 3784. 335 For multipoint LSPs, when IP/UDP encapsulation of BFD control packets 336 is used, MultipointTail MUST expect destination UDP port 3784. 337 Destination IP address of BFD control packet MUST be in 127.0.0.0/8 338 range for IPv4 or in 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. The 339 use of these destination addresses is consistent with the 340 explanations and usage in [RFC8029]. Packets identified as BFD 341 packets MUST be consumed by MultipointTail and demultiplex as 342 described in Section 4.13.2. Use of other types of encapsulation of 343 the BFD control message over multipoint LSP is outside the scope of 344 this document. 346 4.9. Bringing Up and Shutting Down Multipoint BFD Service 348 Because there is no three-way handshake in Multipoint BFD, a newly 349 started head (that does not have any previous state information 350 available) SHOULD start with bfd.SessionState set to Down and 351 bfd.RequiredMinRxInterval MUST be set to zero in the MultipointHead 352 session. The session SHOULD remain in this state for a time equal to 353 (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that 354 all MultipointTail sessions are reset (so long as the restarted head 355 is using the same or a larger value of bfd.DesiredMinTxInterval than 356 it did previously). 358 Multipoint BFD service is brought up by administratively setting 359 bfd.SessionState to Up in the MultipointHead session. 361 The head of a multipoint BFD session may wish to shut down its BFD 362 service in a controlled fashion. This is desirable because the tails 363 need not wait a detection time prior to declaring the multipoint 364 session to be down (and taking whatever action is necessary in that 365 case). 367 To shut down a multipoint session the head MUST administratively set 368 bfd.SessionState in the MultipointHead session to either Down or 369 AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The 370 session SHOULD send BFD Control packets in this state for a period 371 equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). 373 The semantic difference between Down and AdminDown state is for 374 further discussion. 376 4.10. Timer Manipulation 378 Because of the one-to-many mapping, a session of type MultipointHead 379 SHOULD NOT initiate a Poll Sequence in conjunction with timer value 380 changes. However, to indicate a change in the packets, 381 MultipointHead session MUST send packets with the P bit set. 383 MultipointTail session MUST NOT reply if the packet has M and P bits 384 set and bfd.RequiredMinRxInterval set to 0. 386 The MultipointHead, when changing the transmit interval to a higher 387 value, MUST send BFD control packets with P bit set at the old 388 transmit interval before using the higher value in order to avoid 389 false detection timeouts at the tails. MultipointHead session MAY 390 also wait some amount of time before making the changes to the 391 transmit interval (through configuration). 393 Change in the value of bfd.RequiredMinRxInterval is outside the scope 394 of this document. 396 4.11. Detection Times 398 Multipoint BFD is inherently asymmetric. As such, each session type 399 has a different approach to detection times. 401 Since MultipointHead sessions never receive packets, they do not 402 calculate a detection time. 404 MultipointTail sessions cannot influence the transmission rate of the 405 MultipointHead session using the Required Min Rx Interval field 406 because of its one-to-many nature. As such, the detection time 407 calculation for a MultipointTail session does not use 408 bfd.RequiredMinRxInterval in the calculation. The detection time is 409 calculated as the product of the last received values of Desired Min 410 TX Interval and Detect Mult. 412 The value of bfd.DetectMult may be changed at any time on any session 413 type. 415 4.12. State Maintenance for Down/AdminDown Sessions 417 The length of time session state is kept after the session goes down 418 determines how long the session will continue to send BFD Control 419 packets (since no packets can be sent after the session is 420 destroyed). 422 4.12.1. MultipointHead Sessions 424 When a MultipointHead session transitions to states Down or 425 AdminDown, the state SHOULD be maintained for a period equal to 426 (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails 427 more quickly detect the session going down (by continuing to transmit 428 BFD Control packets with the new state). 430 4.12.2. MultipointTail Sessions 432 MultipointTail sessions MAY be destroyed immediately upon leaving Up 433 state, since tail will transmit no packets. 435 Otherwise, MultipointTail sessions SHOULD be maintained as long as 436 BFD Control packets are being received by it (which by definition 437 will indicate that the head is not Up). 439 4.13. Base Specification Text Replacement 441 The following sections are meant to replace the corresponding 442 sections in the base specification [RFC5880] in support of BFD for 443 multipoint networks while not changing processing for point-to-point 444 BFD. 446 4.13.1. Reception of BFD Control Packets 448 The following procedure replaces section 6.8.6 of [RFC5880]. 450 When a BFD Control packet is received, the following procedure MUST 451 be followed, in the order specified. If the packet is discarded 452 according to these rules, processing of the packet MUST cease at that 453 point. 455 If the version number is not correct (1), the packet MUST be 456 discarded. 458 If the Length field is less than the minimum correct value (24 if 459 the A bit is clear, or 26 if the A bit is set), the packet MUST be 460 discarded. 462 If the Length field is greater than the payload of the 463 encapsulating protocol, the packet MUST be discarded. 465 If the Detect Mult field is zero, the packet MUST be discarded. 467 If the My Discriminator field is zero, the packet MUST be 468 discarded. 470 Demultiplex the packet to a session according to Section 4.13.2 471 below. The result is either a session of the proper type, or the 472 packet is discarded (and packet processing MUST cease). 474 If the A bit is set and no authentication is in use (bfd.AuthType 475 is zero), the packet MUST be discarded. 477 If the A bit is clear and authentication is in use (bfd.AuthType 478 is nonzero), the packet MUST be discarded. 480 If the A bit is set, the packet MUST be authenticated under the 481 rules of [RFC5880] section 6.7, based on the authentication type 482 in use (bfd.AuthType). This may cause the packet to be discarded. 484 Set bfd.RemoteDiscr to the value of My Discriminator. 486 Set bfd.RemoteState to the value of the State (Sta) field. 488 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 490 Set bfd.RemoteMinRxInterval to the value of Required Min RX 491 Interval. 493 If the Required Min Echo RX Interval field is zero, the 494 transmission of Echo packets, if any, MUST cease. 496 If a Poll Sequence is being transmitted by the local system and 497 the Final (F) bit in the received packet is set, the Poll Sequence 498 MUST be terminated. 500 If bfd.SessionType is PointToPoint, update the transmit interval 501 as described in [RFC5880] section 6.8.2. 503 If bfd.SessionType is PointToPoint, update the Detection Time as 504 described in section 6.8.4 of [RFC5880]. If bfd.SessionType is 505 MultipointTail, then update the Detection Time as the product of 506 the last received values of Desired Min TX Interval and Detect 507 Mult, as described in Section 4.11 of this specification. 509 If bfd.SessionState is AdminDown 511 Discard the packet 513 If the received state is AdminDown 515 If bfd.SessionState is not Down 517 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 519 Set bfd.SessionState to Down 521 Else 523 If bfd.SessionState is Down 524 If bfd.SessionType is PointToPoint 526 If received State is Down 528 Set bfd.SessionState to Init 530 Else if received State is Init 532 Set bfd.SessionState to Up 534 Else (bfd.SessionType is not PointToPoint) 536 If received State is Up 538 Set bfd.SessionState to Up 540 Else if bfd.SessionState is Init 542 If received State is Init or Up 544 Set bfd.SessionState to Up 546 Else (bfd.SessionState is Up) 548 If received State is Down 550 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 552 Set bfd.SessionState to Down 554 Check to see if Demand mode should become active or not (see 555 [RFC5880] section 6.6). 557 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up and 558 bfd.RemoteSessionState is Up, Demand mode is active on the remote 559 system and the local system MUST cease the periodic transmission 560 of BFD Control packets (see Section 4.13.3). 562 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 563 bfd.RemoteSessionState is not Up, Demand mode is not active on the 564 remote system and the local system MUST send periodic BFD Control 565 packets (see Section 4.13.3). 567 If the packet was not discarded, it has been received for purposes 568 of the Detection Time expiration rules in [RFC5880] section 6.8.4. 570 4.13.2. Demultiplexing BFD Control Packets 572 This section is part of the replacement for [RFC5880] section 6.8.6, 573 separated for clarity. 575 If the Multipoint (M) bit is set 577 If the Your Discriminator field is nonzero, the packet MUST be 578 discarded. 580 Select a session as based on source address, My Discriminator 581 and the identity of the multipoint tree which the Multipoint 582 BFD Control packet was received. If a session is found, and 583 bfd.SessionType is not MultipointTail, the packet MUST be 584 discarded. If a session is not found, a new session of type 585 MultipointTail MAY be created, or the packet MAY be discarded. 586 This choice is outside the scope of this specification. 588 Else (Multipoint bit is clear) 590 If the Your Discriminator field is nonzero 592 Select a session based on the value of Your Discriminator. 593 If no session is found, the packet MUST be discarded. 595 Else (Your Discriminator is zero) 597 If the State field is not Down or AdminDown, the packet MUST 598 be discarded. 600 Otherwise, the session MUST be selected based on some 601 combination of other fields, possibly including source 602 addressing information, the My Discriminator field, and the 603 interface over which the packet was received. The exact 604 method of selection is application-specific and is thus 605 outside the scope of this specification. 607 If a matching session is found, and bfd.SessionType is not 608 PointToPoint, the packet MUST be discarded. 610 If a matching session is not found, a new session of type 611 PointToPoint MAY be created, or the packet MAY be discarded. 612 This choice is outside the scope of this specification. 614 If the State field is Init and bfd.SessionType is not 615 PointToPoint, the packet MUST be discarded. 617 4.13.3. Transmitting BFD Control Packets 619 The following procedure replaces section 6.8.7 of [RFC5880]. 621 BFD Control packets MUST be transmitted periodically at the rate 622 determined according to [RFC5880] section 6.8.2, except as specified 623 in this section. 625 A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr 626 is zero and the system is taking the Passive role. 628 A system MUST NOT transmit any BFD Control packets if bfd.SessionType 629 is MultipointTail. 631 A system MUST NOT periodically transmit BFD Control packets if Demand 632 mode is active on the remote system (bfd.RemoteDemandMode is 1, 633 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 634 Sequence is not being transmitted. 636 A system MUST NOT periodically transmit BFD Control packets if 637 bfd.RemoteMinRxInterval is zero. 639 If bfd.SessionType is MultipointHead, the transmit interval MUST be 640 set to bfd.DesiredMinTxInterval (this should happen automatically, as 641 bfd.RemoteMinRxInterval will be zero). 643 If bfd.SessionType is not MultipointHead, the transmit interval MUST 644 be recalculated whenever bfd.DesiredMinTxInterval changes, or 645 whenever bfd.RemoteMinRxInterval changes, and is equal to the greater 646 of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for 647 details on transmit timers. 649 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 650 MultipointTail. 652 A system MUST NOT set the Demand (D) bit if bfd.SessionType 653 PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and 654 bfd.RemoteSessionState is Up. 656 If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control 657 packet SHOULD be transmitted during the interval between periodic 658 Control packet transmissions when the contents of that packet would 659 differ from that in the previously transmitted packet (other than the 660 Poll and Final bits) in order to more rapidly communicate a change in 661 state. 663 The contents of transmitted BFD Control packets MUST be set as 664 follows: 666 Version 668 Set to the current version number (1). 670 Diagnostic (Diag) 672 Set to bfd.LocalDiag. 674 State (Sta) 676 Set to the value indicated by bfd.SessionState. 678 Poll (P) 680 Set to 1 if the local system is sending a Poll Sequence or is a 681 session of type MultipointHead soliciting the identities of the 682 tails, or 0 if not. 684 Final (F) 686 Set to 1 if the local system is responding to a Control packet 687 received with the Poll (P) bit set, or 0 if not. 689 Control Plane Independent (C) 691 Set to 1 if the local system's BFD implementation is 692 independent of the control plane (it can continue to function 693 through a disruption of the control plane). 695 Authentication Present (A) 697 Set to 1 if authentication is in use in this session 698 (bfd.AuthType is nonzero), or 0 if not. 700 Demand (D) 702 Set to bfd.DemandMode if bfd.SessionState is Up and 703 bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is 704 MultipointHead. Otherwise it is set to 0. 706 Multipoint (M) 708 Set to 1 if bfd.SessionType is MultipointHead. Otherwise, it 709 is set to 0. 711 Detect Mult 713 Set to bfd.DetectMult. 715 Length 717 Set to the appropriate length, based on the fixed header length 718 (24) plus any Authentication Section. 720 My Discriminator 722 Set to bfd.LocalDiscr. 724 Your Discriminator 726 Set to bfd.RemoteDiscr. 728 Desired Min TX Interval 730 Set to bfd.DesiredMinTxInterval. 732 Required Min RX Interval 734 Set to bfd.RequiredMinRxInterval. 736 Required Min Echo RX Interval 738 Set to 0 if bfd.SessionType is MultipointHead or 739 MultipointTail. 741 Authentication Section 743 Included and set according to the rules in [RFC5880] section 744 6.7 if authentication is in use (bfd.AuthType is nonzero). 745 Otherwise, this section is not present. 747 5. Assumptions 749 If authentication is in use, all tails must be configured to have a 750 common authentication key in order to receive the multipoint BFD 751 Control packets. 753 6. IANA Considerations 755 This document has no actions for IANA. 757 7. Security Considerations 759 The same security considerations as those described in [RFC5880] 760 apply to this document. Additionally, implementations that create 761 MultpointTail sessions dynamically upon receipt of Multipoint BFD 762 Control packets MUST implement protective measures to prevent an 763 infinite number of MultipointTail sessions being created. Below are 764 listed some points to be considered in such implementations. 766 If a Multipoint BFD Control packet did not arrive on a multicast 767 tree (e.g. on the expected interface, with expected MPLS label, 768 etc), then a MultipointTail session should not be created. 770 If redundant streams are expected for a given multicast stream, 771 then the implementations should not create more MultipointTail 772 sessions than the number of streams. Additionally, when the 773 number of MultipointTail sessions exceeds the number of expected 774 streams, then the implementation should generate an alarm to users 775 to indicate the anomaly. 777 The implementation should have a reasonable upper bound on the 778 number of MultipointTail sessions that can be created, with the 779 upper bound potentially being computed based on the number of 780 multicast streams that the system is expecting. 782 8. Contributors 784 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 785 Systems provided the initial idea for this specification and 786 contributed to its development. 788 9. Acknowledgments 790 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 791 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 792 greatly contributed to this document. 794 10. Normative References 796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", BCP 14, RFC 2119, 798 DOI 10.17487/RFC2119, March 1997, 799 . 801 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 802 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 803 . 805 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 806 Pallagatti, "Seamless Bidirectional Forwarding Detection 807 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 808 . 810 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 811 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 812 Switched (MPLS) Data-Plane Failures", RFC 8029, 813 DOI 10.17487/RFC8029, March 2017, 814 . 816 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 817 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 818 May 2017, . 820 Authors' Addresses 822 Dave Katz 823 Juniper Networks 824 1194 N. Mathilda Ave. 825 Sunnyvale, California 94089-1206 826 USA 828 Email: dkatz@juniper.net 830 Dave Ward 831 Cisco Systems 832 170 West Tasman Dr. 833 San Jose, California 95134 834 USA 836 Email: wardd@cisco.com 838 Santosh Pallagatti (editor) 839 Individual contributor 841 Email: santosh.pallagatti@gmail.com 843 Greg Mirsky (editor) 844 ZTE Corp. 846 Email: gregimirsky@gmail.com