idnits 2.17.1 draft-ietf-bfd-multipoint-14.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. -- The draft header indicates that this document updates RFC7880, 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 (February 21, 2018) is 2254 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 (==), 4 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, 7880 (if approved) D. Ward 5 Intended status: Standards Track Cisco Systems 6 Expires: August 25, 2018 S. Pallagatti, Ed. 7 Individual contributor 8 G. Mirsky, Ed. 9 ZTE Corp. 10 February 21, 2018 12 BFD for Multipoint Networks 13 draft-ietf-bfd-multipoint-14 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 August 25, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 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 head are outside the 115 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 path between the 125 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 have failed. For some applications this is 157 the only mechanism necessary; the head can remain ignorant of the 158 tails. 160 A head may wish to be alerted to the tails' connectivity (or lack 161 thereof). Details of how the head keeps track of tails and how tails 162 alert their connectivity to the head are outside scope of this 163 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. Furthermore, the same head and tail may 169 share multiple multipoint paths, and a multipoint path may have 170 multiple heads. 172 4. Protocol Details 174 This section describes the operation of Multipoint BFD in detail. 176 4.1. Multipoint BFD Control Packets 178 Multipoint BFD Control packets (packets sent by the head over a 179 multipoint path) are explicitly marked as such, via the setting of 180 the M bit [RFC5880]. This means that Multipoint BFD does not depend 181 on the recipient of a packet to know whether the packet was received 182 over a multipoint path. This can be useful in scenarios where this 183 information may not be available to the recipient. 185 4.2. Session Model 187 Multipoint BFD is modeled as a set of sessions of different types. 188 The elements of procedure differ slightly for each type. 190 Point-to-point sessions, as described in [RFC5880], are of type 191 PointToPoint. 193 The head has a session of type MultipointHead, as defined in 194 Section 4.4.1, that is bound to a multipoint path. Multipoint BFD 195 Control packets are sent by this session over the multipoint path, 196 and no BFD Control packets are received by it. 198 Each tail has a session of type MultipointTail, as defined in 199 Section 4.4.1, associated with a multipoint path. These sessions 200 receive BFD Control packets from the head over the multipoint path. 202 4.3. Session Failure Semantics 204 The semantics of session failure are subtle enough to warrant further 205 explanation. 207 MultipointHead sessions cannot fail (since they are controlled 208 administratively). 210 If a MultipointTail session fails, it means that the tail definitely 211 has lost contact with the head (or the head has been administratively 212 disabled) and the tail should take appropriate action. 214 4.4. State Variables 216 Multipoint BFD introduces some new state variables, and modifies the 217 usage of a few existing ones. 219 4.4.1. New State Variable Values 221 A number of new values of the state variable bfd.SessionType are 222 added to the base BFD [RFC5880] and base S-BFD [RFC7880] 223 specifications in support of Multipoint BFD. 225 bfd.SessionType 227 The type of this session as defined in [RFC7880]. Newly added 228 values are: 230 PointToPoint: Classic point-to-point BFD. 232 MultipointHead: A session on the head responsible for the 233 periodic transmission of multipoint BFD Control packets 234 along the multipoint path. 236 MultipointTail: A multipoint session on a tail. 238 This variable MUST be initialized to the appropriate type when 239 the session is created, according to the rules in Section 4.13 241 4.4.2. State Variable Initialization and Maintenance 243 Some state variables defined in section 6.8.1 of [RFC5880] need to be 244 initialized or manipulated differently depending on the session type. 246 bfd.RequiredMinRxInterval 248 This variable MUST be set to 0 for session type 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 MUST be ignored on 264 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 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 the binding to the multipoint path over which BFD is running. The 288 head transmits Multipoint BFD packets on that tree, and the tails 289 listen 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 with 351 bfd.RequiredMinRxInterval set to zero in the MultipointHead session. 352 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 larger value of bfd.DesiredMinTxInterval than it 356 did previously). 358 Multipoint BFD service is brought up by administratively setting 359 bfd.SessionState to Up in the MultipointHead session. 361 A head may wish to shut down its BFD service in a controlled fashion. 362 This is desirable because the tails need not wait a detection time 363 prior to declaring the multipoint session to be down (and taking 364 whatever action is necessary in that case). 366 To shut down a multipoint session a head MUST administratively set 367 bfd.SessionState in the MultipointHead session to either Down or 368 AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The 369 session SHOULD send BFD Control packets in this state for a period 370 equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). 372 The semantic difference between Down and AdminDown state is for 373 further discussion. 375 4.10. Timer Manipulation 377 Because of the one-to-many mapping, a session of type MultipointHead 378 SHOULD NOT initiate a Poll Sequence in conjunction with timer value 379 changes. However, to indicate a change in the packets, 380 MultipointHead session MUST send packets with the P bit set. 381 MultipointTail session MUST NOT reply if packet has M, P bit set and 382 bfd.RequiredMinRxInterval set to 0. 384 The MultipointHead, when changing the transmit interval to higher 385 value, MUST send BFD control packets with P bit set at the old 386 transmit interval before using the higher value in order to avoid 387 false detection timeouts at the tails. MultipointHead session MAY 388 also wait some amount of time before making the changes to the 389 transmit interval (through configuration). 391 Change in the value of bfd.RequiredMinRxInterval is outside the scope 392 of this document. 394 4.11. Detection Times 396 Multipoint BFD is inherently asymmetric. As such, each session type 397 has a different approach to detection times. 399 Since MultipointHead sessions never receive packets, they do not 400 calculate a detection time. 402 MultipointTail sessions cannot influence the transmission rate of the 403 MultipointHead session using the Required Min Rx Interval field 404 because of its one-to-many nature. As such, the detection time 405 calculation for a MultipointTail session does not use 406 bfd.RequiredMinRxInterval in the calculation. The detection time is 407 calculated as the product of the last received values of Desired Min 408 TX Interval and Detect Mult. 410 The value of bfd.DetectMult may be changed at any time on any session 411 type. 413 4.12. State Maintenance for Down/AdminDown Sessions 415 The length of time session state is kept after the session goes down 416 determines how long the session will continue to send BFD Control 417 packets (since no packets can be sent after the session is 418 destroyed). 420 4.12.1. MultipointHead Sessions 422 When a MultipointHead session transitions to states Down or 423 AdminDown, the state SHOULD be maintained for a period equal to 424 (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails 425 more quickly detect the session going down (by continuing to transmit 426 BFD Control packets with the new state). 428 4.12.2. MultipointTail Sessions 430 MultipointTail sessions MAY be destroyed immediately upon leaving Up 431 state, since tail will transmit no packets. 433 Otherwise, MultipointTail sessions SHOULD be maintained as long as 434 BFD Control packets are being received by it (which by definition 435 will indicate that the head is not Up). 437 4.13. Base Specification Text Replacement 439 The following sections are meant to replace the corresponding 440 sections in the base specification [RFC5880] in support of BFD for 441 multipoint networks while not changing processing for point-to-point 442 BFD. 444 4.13.1. Reception of BFD Control Packets 446 The following procedure replaces section 6.8.6 of [RFC5880]. 448 When a BFD Control packet is received, the following procedure MUST 449 be followed, in the order specified. If the packet is discarded 450 according to these rules, processing of the packet MUST cease at that 451 point. 453 If the version number is not correct (1), the packet MUST be 454 discarded. 456 If the Length field is less than the minimum correct value (24 if 457 the A bit is clear, or 26 if the A bit is set), the packet MUST be 458 discarded. 460 If the Length field is greater than the payload of the 461 encapsulating protocol, the packet MUST be discarded. 463 If the Detect Mult field is zero, the packet MUST be discarded. 465 If the My Discriminator field is zero, the packet MUST be 466 discarded. 468 Demultiplex the packet to a session according to Section 4.13.2 469 below. The result is either a session of the proper type, or the 470 packet is discarded (and packet processing MUST cease). 472 If the A bit is set and no authentication is in use (bfd.AuthType 473 is zero), the packet MUST be discarded. 475 If the A bit is clear and authentication is in use (bfd.AuthType 476 is nonzero), the packet MUST be discarded. 478 If the A bit is set, the packet MUST be authenticated under the 479 rules of [RFC5880] section 6.7, based on the authentication type 480 in use (bfd.AuthType). This may cause the packet to be discarded. 482 Set bfd.RemoteDiscr to the value of My Discriminator. 484 Set bfd.RemoteState to the value of the State (Sta) field. 486 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 488 Set bfd.RemoteMinRxInterval to the value of Required Min RX 489 Interval. 491 If the Required Min Echo RX Interval field is zero, the 492 transmission of Echo packets, if any, MUST cease. 494 If a Poll Sequence is being transmitted by the local system and 495 the Final (F) bit in the received packet is set, the Poll Sequence 496 MUST be terminated. 498 If bfd.SessionType is PointToPoint, update the transmit interval 499 as described in [RFC5880] section 6.8.2. 501 If bfd.SessionType is PointToPoint, update the Detection Time as 502 described in section 6.8.4 of [RFC5880]. If bfd.SessionType is 503 MultipointTail, then update the Detection Time as the product of 504 the last received values of Desired Min TX Interval and Detect 505 Mult, as described in Section 4.11 of this specification. 507 If bfd.SessionState is AdminDown 509 Discard the packet 511 If received state is AdminDown 513 If bfd.SessionState is not Down 515 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 517 Set bfd.SessionState to Down 519 Else 521 If bfd.SessionState is Down 522 If bfd.SessionType is PointToPoint 524 If received State is Down 526 Set bfd.SessionState to Init 528 Else if received State is Init 530 Set bfd.SessionState to Up 532 Else (bfd.SessionType is not PointToPoint) 534 If received State is Up 536 Set bfd.SessionState to Up 538 Else if bfd.SessionState is Init 540 If received State is Init or Up 542 Set bfd.SessionState to Up 544 Else (bfd.SessionState is Up) 546 If received State is Down 548 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 550 Set bfd.SessionState to Down 552 Check to see if Demand mode should become active or not (see 553 [RFC5880] section 6.6). 555 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 556 bfd.RemoteSessionState is Up, Demand mode is active on the remote 557 system and the local system MUST cease the periodic transmission 558 of BFD Control packets (see Section 4.13.3). 560 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 561 bfd.RemoteSessionState is not Up, Demand mode is not active on the 562 remote system and the local system MUST send periodic BFD Control 563 packets (see see Section 4.13.3). 565 If the packet was not discarded, it has been received for purposes 566 of the Detection Time expiration rules in [RFC5880] section 6.8.4. 568 4.13.2. Demultiplexing BFD Control Packets 570 This section is part of the replacement for [RFC5880] section 6.8.6, 571 separated for clarity. 573 If the Multipoint (M) bit is set 575 If the Your Discriminator field is nonzero, the packet MUST be 576 discarded. 578 Select a session as based on source address, My Discriminator 579 and the identity of the multipoint tree which the Multipoint 580 BFD Control packet was received. If a session is found, and 581 bfd.SessionType is not MultipointTail, the packet MUST be 582 discarded. If a session is not found, a new session of type 583 MultipointTail MAY be created, or the packet MAY be discarded. 584 This choice is outside the scope of this specification. 586 Else (Multipoint bit is clear) 588 If the Your Discriminator field is nonzero 590 Select a session based on the value of Your Discriminator. 591 If no session is found, the packet MUST be discarded. 593 Else (Your Discriminator is zero) 595 If the State field is not Down or AdminDown, the packet MUST 596 be discarded. 598 Otherwise, the session MUST be selected based on some 599 combination of other fields, possibly including source 600 addressing information, the My Discriminator field, and the 601 interface over which the packet was received. The exact 602 method of selection is application-specific and is thus 603 outside the scope of this specification. 605 If a matching session is found, and bfd.SessionType is not 606 PointToPoint, the packet MUST be discarded. 608 If a matching session is not found, a new session of type 609 PointToPoint MAY be created, or the packet MAY be discarded. 610 This choice is outside the scope of this specification. 612 If the State field is Init and bfd.SessionType is not 613 PointToPoint, the packet MUST be discarded. 615 4.13.3. Transmitting BFD Control Packets 617 The following procedure replaces section 6.8.7 of [RFC5880]. 619 BFD Control packets MUST be transmitted periodically at the rate 620 determined according to [RFC5880] section 6.8.2, except as specified 621 in this section. 623 A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr 624 is zero and the system is taking the Passive role. 626 A system MUST NOT transmit any BFD Control packets if bfd.SessionType 627 is MultipointTail. 629 A system MUST NOT periodically transmit BFD Control packets if Demand 630 mode is active on the remote system (bfd.RemoteDemandMode is 1, 631 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 632 Sequence is not being transmitted. 634 A system MUST NOT periodically transmit BFD Control packets if 635 bfd.RemoteMinRxInterval is zero. 637 If bfd.SessionType is MultipointHead, the transmit interval MUST be 638 set to bfd.DesiredMinTxInterval (this should happen automatically, as 639 bfd.RemoteMinRxInterval will be zero). 641 If bfd.SessionType is not MultipointHead, the transmit interval MUST 642 be recalculated whenever bfd.DesiredMinTxInterval changes, or 643 whenever bfd.RemoteMinRxInterval changes, and is equal to the greater 644 of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for 645 details on transmit timers. 647 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 648 MultipointTail. 650 A system MUST NOT set the Demand (D) bit if bfd.SessionType 651 PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and 652 bfd.RemoteSessionState is Up. 654 If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control 655 packet SHOULD be transmitted during the interval between periodic 656 Control packet transmissions when the contents of that packet would 657 differ from that in the previously transmitted packet (other than the 658 Poll and Final bits) in order to more rapidly communicate a change in 659 state. 661 The contents of transmitted BFD Control packets MUST be set as 662 follows: 664 Version 666 Set to the current version number (1). 668 Diagnostic (Diag) 670 Set to bfd.LocalDiag. 672 State (Sta) 674 Set to the value indicated by bfd.SessionState. 676 Poll (P) 678 Set to 1 if the local system is sending a Poll Sequence or is a 679 session of type MultipointHead soliciting the identities of the 680 tails, or 0 if not. 682 Final (F) 684 Set to 1 if the local system is responding to a Control packet 685 received with the Poll (P) bit set, or 0 if not. 687 Control Plane Independent (C) 689 Set to 1 if the local system's BFD implementation is 690 independent of the control plane (it can continue to function 691 through a disruption of the control plane). 693 Authentication Present (A) 695 Set to 1 if authentication is in use on this session 696 (bfd.AuthType is nonzero), or 0 if not. 698 Demand (D) 700 Set to bfd.DemandMode if bfd.SessionState is Up and 701 bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is 702 MultipointHead. Otherwise it is set to 0. 704 Multipoint (M) 706 Set to 1 if bfd.SessionType is MultipointHead. Otherwise it is 707 set to 0. 709 Detect Mult 711 Set to bfd.DetectMult. 713 Length 715 Set to the appropriate length, based on the fixed header length 716 (24) plus any Authentication Section. 718 My Discriminator 720 Set to bfd.LocalDiscr. 722 Your Discriminator 724 Set to bfd.RemoteDiscr. 726 Desired Min TX Interval 728 Set to bfd.DesiredMinTxInterval. 730 Required Min RX Interval 732 Set to bfd.RequiredMinRxInterval. 734 Required Min Echo RX Interval 736 Set to 0 if bfd.SessionType is MultipointHead or 737 MultipointTail. 739 Authentication Section 741 Included and set according to the rules in [RFC5880] section 742 6.7 if authentication is in use (bfd.AuthType is nonzero). 743 Otherwise this section is not present. 745 5. Assumptions 747 If authentication is in use, all tails must be configured to have a 748 common authentication key in order to receive the multipoint BFD 749 Control packets. 751 6. IANA Considerations 753 This document has no actions for IANA. 755 7. Security Considerations 757 The same security considerations as those described in [RFC5880] 758 apply to this document. Additionally, implementations that create 759 MultpointTail sessions dynamically upon receipt of Multipoint BFD 760 Control packets MUST implement protective measures to prevent 761 infinite number of MultipointTail sessions being created. Below are 762 listed some points to be considered in such implementations. 764 If a Multipoint BFD Control packet did not arrive on a multicast 765 tree (e.g. on expected interface, with expected MPLS label, etc), 766 then a MultipointTail session should not be created. 768 If redundant streams are expected for a given multicast stream, 769 then the implementations should not create more MultipointTail 770 sessions than the number of streams. Additionally, when the 771 number of MultipointTail sessions exceeds the number of expected 772 streams, then the implementation should generate an alarm to users 773 to indicate the anomaly. 775 The implementation should have a reasonable upper bound on the 776 number of MultipointTail sessions that can be created, with the 777 upper bound potentially being computed based on the number of 778 multicast streams that the system is expecting. 780 8. Contributors 782 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 783 Systems provided the initial idea for this specification and 784 contributed to its development. 786 9. Acknowledgements 788 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 789 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 790 greatly contributed to this document. 792 10. Normative References 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, 796 DOI 10.17487/RFC2119, March 1997, 797 . 799 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 800 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 801 . 803 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 804 Pallagatti, "Seamless Bidirectional Forwarding Detection 805 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 806 . 808 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 809 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 810 Switched (MPLS) Data-Plane Failures", RFC 8029, 811 DOI 10.17487/RFC8029, March 2017, 812 . 814 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 815 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 816 May 2017, . 818 Authors' Addresses 820 Dave Katz 821 Juniper Networks 822 1194 N. Mathilda Ave. 823 Sunnyvale, California 94089-1206 824 USA 826 Email: dkatz@juniper.net 828 Dave Ward 829 Cisco Systems 830 170 West Tasman Dr. 831 San Jose, California 95134 832 USA 834 Email: wardd@cisco.com 836 Santosh Pallagatti (editor) 837 Individual contributor 839 Email: santosh.pallagatti@gmail.com 841 Greg Mirsky (editor) 842 ZTE Corp. 844 Email: gregimirsky@gmail.com