idnits 2.17.1 draft-ietf-bfd-multipoint-05.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 -- The document date (January 12, 2015) is 3390 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 624, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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: July 16, 2015 Cisco Systems 6 S. Pallagatti, Ed. 7 Juniper Networks 8 January 12, 2015 10 BFD for Multipoint Networks 11 draft-ietf-bfd-multipoint-05 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 July 16, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 65 4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 4 66 4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 67 4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 68 4.4.1. New State Variables . . . . . . . . . . . . . . . . . 5 69 4.4.2. State Variable Initialization and Maintenance . . . . 6 70 4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 71 4.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 72 4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 73 4.8. Packet consumption on tails . . . . . . . . . . . . . . . 7 74 4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 75 4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 8 76 4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 77 4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 78 4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 9 79 4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 9 80 4.13. Base Specification Text Replacement . . . . . . . . . . . 9 81 4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 82 4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 12 83 4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 13 84 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 88 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The Bidirectional Forwarding Detection protocol [RFC5880] specifies a 94 method for verifying unicast connectivity between a pair of systems. 95 This document defines a method for using BFD to provide verification 96 of multipoint or multicast connectivity between a multipoint sender 97 (the "head") and a set of one or more multipoint receivers (the 98 "tails"). 100 As multipoint transmissions are inherently unidirectional, this 101 mechanism purports only to verify this unidirectional connectivity. 102 Although this seems in conflict with the "Bidirectional" in BFD, it 103 is a natural fit for that protocol. 105 This application of BFD allows for the tails to detect a lack of 106 connectivity from the head. Due to unidirectional nature, virtually 107 all options and timing parameters are controlled by the head. 109 As an option, the tail may notify the head of the lack of multipoint 110 connectivity. Details of tail notification to head are outside the 111 scope of this document. 113 Throughout this document, the term "multipoint" is defined as a 114 mechanism by which one or more systems receive packets sent by a 115 single sender. This specifically includes such things as IP 116 multicast and point-to-multipoint MPLS. 118 This document effectively modifies and adds to the base BFD 119 specification. It is the intention of the authors to fold these 120 extensions into the base specification at the appropriate time. 122 2. Goals 124 The primary goal of this mechanism is to allow tails to rapidly 125 detect the fact that multipoint connectivity from the head has 126 failed. 128 Another goal is for the mechanism to work on any multicast or 129 multipoint medium. 131 A further goal is to support multiple, overlapping multipoint paths, 132 as well as multipoint paths with multiple heads, and to allow point- 133 to-point BFD sessions to operate simultaneously among the systems 134 participating in Multipoint BFD. 136 A final goal is to integrate multipoint operation into the base 137 specification in such a way as to make it relatively easy to support 138 both multipoint and point-to-point operation in a single 139 implementation. 141 It is a non-goal for this protocol to verify point-to-point 142 connectivity between the head and any tails. This can be done 143 independently (and with no penalty in protocol overhead) by using 144 point-to-point BFD. 146 3. Overview 148 The heart of this protocol is the periodic transmission of BFD 149 Control packets along a multipoint path, from the head to all tails 150 on the tree. The contents of the BFD packets provide the means for 151 the tails to calculate the detection time for path failure. If no 152 BFD Control packets are received by a tail for a detection time, the 153 tail declares the path to have failed. For some applications this is 154 the only mechanism necessary; the head can remain ignorant of the 155 tails. 157 Head may wish to be alerted to the tails' connectivity (or lack 158 thereof). There may be a number of options, details of which are 159 outside scope of this document. 161 Although this document describes a single head and a set of tails 162 spanned by a single multipoint path, the protocol is capable of 163 supporting (and discriminating between) more than one multipoint path 164 at both heads and tails. Furthermore, the same head and tail may 165 share multiple multipoint paths, and a multipoint path may have 166 multiple heads. 168 4. Protocol Details 170 This section describes the operation of Multipoint BFD in detail. 172 4.1. Multipoint BFD Control Packets 174 Multipoint BFD Control packets (packets sent by the head over a 175 multipoint path) are explicitly marked as such, via the setting of 176 the M bit (added to the latest revision of the BFD base 177 specification. 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.16. 236 bfd.SilentTail 237 Always set to 1, a tail will never transmit any BFD Control 238 packets to the head under any circumstances. Setting to 0 is 239 outside the scope of this document. 241 This variable is only pertinent when bfd.SessionType is 242 MultipointTail. 244 4.4.2. State Variable Initialization and Maintenance 246 Some state variables defined in section 6.8.1 of the BFD base 247 specification need to be initialized or manipulated differently 248 depending on the session type. 250 bfd.RequiredMinRxInterval 252 This variable MUST be set to 0 for session type MultipointHead. 254 bfd.DemandMode 256 This variable MUST be initialized to 1 for session type 257 MultipointHead and MUST be initialized to 0 for session type 258 MultipointTail. 260 4.5. State Machine 262 The BFD state machine works slightly differently in the multipoint 263 application. In particular, since there is a many-to-one mapping, 264 three-way handshakes for session establishment and teardown are 265 neither possible nor appropriate. As such there is no Init state. 267 The following diagram provides an overview of the state machine for 268 session type MultipointTail. The notation on each arc represents the 269 state of the remote system (as received in the State field in the BFD 270 Control packet) or indicates the expiration of the Detection Timer. 272 DOWN, ADMIN DOWN, 273 +------+ TIMER +------+ 274 +----| |<---------------------| |----+ 275 DOWN,| | DOWN | | UP | |UP 276 ADMIN DOWN,+--->| |--------------------->| |<---+ 277 TIMER +------+ UP +------+ 279 Sessions of type MultipointHead never receive packets and have no 280 Detection Timer, and as such all state transitions are 281 administratively driven. 283 4.6. Session Establishment 285 Unlike Point-to-point BFD, Multipoint BFD provides a form of 286 discovery mechanism for tails to discover the head. The minimum 287 amount of a priori information required both on the head and tails is 288 the binding to the multipoint path over which BFD is running. The 289 head transmits Multipoint BFD packets on that tree, and the tails 290 listen for BFD packets on that tree. All other information MAY be 291 determined dynamically. 293 A session of type MultipointHead is created for each multipoint path 294 over which the head wishes to run BFD. This session runs in the 295 Active role. Except when terminating BFD service, this session is 296 always in state Up and always operates in Demand mode. No received 297 packets are ever demultiplexed to the MultipointHead session. In 298 this sense it 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. 304 4.7. Discriminators and Packet Demultiplexing 306 The use of Discriminators is somewhat different in Multipoint BFD 307 than in Point-to-point BFD. 309 The head sends Multipoint BFD Control packets over the MultipointHead 310 session with My Discr set to a value bound to the multipoint path, 311 and with Your Discr set to zero. 313 IP and MPLS multipoint tails MUST demultiplex BFD packets based on a 314 combination of the source address, My Discriminator and the identity 315 of the multipoint tree which the Multipoint BFD Control packet was 316 received from. Together they uniquely identify the head of the 317 multipoint path. Bootstrapping BFD session to a multipoint LSP in 318 case of penultimate hop popping is outside the scope of this 319 document. 321 Note that, unlike PointToPoint sessions, the discriminator values on 322 all multipoint session types MUST NOT be changed during the life of a 323 session. This is a side effect of the more complex demultiplexing 324 scheme. 326 4.8. Packet consumption on tails 328 Tail MUST consume packet with destination UDP port number "3784" on 329 IP multipoint path. For multipoint LSP, tail MUST use destination 330 UDP port "3784" and IP "127.0.0.0/8" range. 332 4.9. Bringing Up and Shutting Down Multipoint BFD Service 334 Because there is no three-way handshake in Multipoint BFD, a newly 335 started head (that does not have any previous state information 336 available) SHOULD start with bfd.SessionState set to Down and with 337 bfd.RequiredMinRxInterval set to zero in the MultipointHead session. 338 The session SHOULD remain in this state for a time equal to 339 (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that 340 all MultipointTail sessions are reset (so long as the restarted head 341 is using the same or larger value of bfd.DesiredMinTxInterval than it 342 did previously.) 344 Multipoint BFD service is brought up by administratively setting 345 bfd.SessionState to Up in the MultipointHead session. 347 A head may wish to shut down its BFD service in a controlled fashion. 348 This is desirable because the tails need not wait a detection time 349 prior to declaring the multipoint session to be down (and taking 350 whatever action is necessary in that case.) 352 To shut down a multipoint session a head MUST administratively set 353 bfd.SessionState in the MultipointHead session to either Down or 354 AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero (to keep 355 the tails from sending any BFD Control packets back.) The session 356 SHOULD send BFD Control packets in this state for a period equal to 357 (bfd.DesiredMinTxInterval * bfd.DetectMult). 359 The semantic difference between Down and AdminDown state is for 360 further discussion. 362 4.10. Timer Manipulation 364 Because of the one-to-many mapping, a session of type MultipointHead 365 SHOULD NOT initiate a Poll Sequence in conjunction with timer value 366 changes. However to indicate change in packet MultipointHead session 367 MUST send packet with P bit set. MultipointTail session MUST NOT 368 reply if packet has M, P bit set and bfd.RequiredMinRxInterval set to 369 0. 371 The MultipointHead MUST send bfd.DetectMult packets with P bit set at 372 the old transmit interval before using the higher value in order to 373 avoid false detection timeouts at the tails. MultipointHead May also 374 wait some amount of time before making the changes to the transmit 375 interval (through configuration). 377 Change in the value of bfd.RequiredMinRxInterval is outside the scope 378 of this document. 380 4.11. Detection Times 382 Multipoint BFD is inherently asymmetric. As such, each session type 383 has a different approach to detection times. 385 Since the MultipointHead session never receives packets, it does not 386 calculate a detection time. 388 MultipointTail sessions cannot influence the transmission rate of the 389 MultipointHead session using the Required Min Rx Interval field 390 because of its one-to-many nature. As such, the Detection Time 391 calculation for a MultipointTail session does not use 392 bfd.RequiredMinRxInterval in the calculation. The detection time is 393 calculated as the product of the last received values of Desired Min 394 TX Interval and Detect Mult. 396 The value of bfd.DetectMult may be changed at any time on any session 397 type. 399 4.12. State Maintenance for Down/AdminDown Sessions 401 The length of time session state is kept after the session goes down 402 determines how long the session will continue to send BFD Control 403 packets (since no packets can be sent after the session is 404 destroyed.) 406 4.12.1. MultipointHead Sessions 408 When a MultipointHead session transitions to states Down or 409 AdminDown, the state SHOULD be maintained for a period equal to 410 (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails 411 more quickly detect the session going down (by continuing to transmit 412 BFD Control packets with the new state.) 414 4.12.2. MultipointTail Sessions 416 MultipointTail sessions MAY be destroyed immediately upon leaving Up 417 state, since tail will transmit no packets. 419 Otherwise, MultipointTail sessions MUST be maintained as long as BFD 420 Control packets are being received by it (which by definition will 421 indicate that the head is not Up.) 423 4.13. Base Specification Text Replacement 425 The following sections are meant to replace the corresponding 426 sections in the base specification. 428 4.13.1. Reception of BFD Control Packets 430 The following procedure replaces section 6.8.6 of [RFC5880]. 432 When a BFD Control packet is received, the following procedure MUST 433 be followed, in the order specified. If the packet is discarded 434 according to these rules, processing of the packet MUST cease at that 435 point. 437 If the version number is not correct (1), the packet MUST be 438 discarded. 440 If the Length field is less than the minimum correct value (24 if 441 the A bit is clear, or 26 if the A bit is set), the packet MUST be 442 discarded. 444 If the Length field is greater than the payload of the 445 encapsulating protocol, the packet MUST be discarded. 447 If the Detect Mult field is zero, the packet MUST be discarded. 449 If the My Discriminator field is zero, the packet MUST be 450 discarded. 452 Demultiplex the packet to a session according to section 4.16.2 453 below. The result is either a session of the proper type, or the 454 packet is discarded (and packet processing MUST cease.) 456 If the A bit is set and no authentication is in use (bfd.AuthType 457 is zero), the packet MUST be discarded. 459 If the A bit is clear and authentication is in use (bfd.AuthType 460 is nonzero), the packet MUST be discarded. 462 If the A bit is set, the packet MUST be authenticated under the 463 rules of section 6.7, based on the authentication type in use 464 (bfd.AuthType.) This may cause the packet to be discarded. 466 Set bfd.RemoteDiscr to the value of My Discriminator. 468 Set bfd.RemoteState to the value of the State (Sta) field. 470 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 472 Set bfd.RemoteMinRxInterval to the value of Required Min RX 473 Interval. 475 If the Required Min Echo RX Interval field is zero, the 476 transmission of Echo packets, if any, MUST cease. 478 If a Poll Sequence is being transmitted by the local system and 479 the Final (F) bit in the received packet is set, the Poll Sequence 480 MUST be terminated. 482 If bfd.SessionType is PointToPoint, update the transmit interval 483 as described in [BFD] section 6.8.2. 485 If bfd.SessionType is PointToPoint, update the Detection Time as 486 described in [BFD] section 6.8.4. Otherwise, update the Detection 487 Time as described in section 4.14 above. 489 If bfd.SessionState is AdminDown 491 Discard the packet 493 If received state is AdminDown 495 If bfd.SessionState is not Down 497 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 499 Set bfd.SessionState to Down 501 Else 503 If bfd.SessionState is Down 505 If bfd.SessionType is PointToPoint 507 If received State is Down 509 Set bfd.SessionState to Init 511 Else if received State is Init 513 Set bfd.SessionState to Up 515 Else (bfd.SessionType is not PointToPoint) 517 If received State is Up 519 Set bfd.SessionState to Up 521 Else if bfd.SessionState is Init 522 If received State is Init or Up 524 Set bfd.SessionState to Up 526 Else (bfd.SessionState is Up) 528 If received State is Down 530 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 532 Set bfd.SessionState to Down 534 Check to see if Demand mode should become active or not (see 535 [RFC5880] section 6.6). 537 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 538 bfd.RemoteSessionState is Up, Demand mode is active on the remote 539 system and the local system MUST cease the periodic transmission 540 of BFD Control packets (see section 4.16.3.) 542 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 543 bfd.RemoteSessionState is not Up, Demand mode is not active on the 544 remote system and the local system MUST send periodic BFD Control 545 packets (see section 4.16.3.) 547 If the packet was not discarded, it has been received for purposes 548 of the Detection Time expiration rules in [BFD] section 6.8.4. 550 4.13.2. Demultiplexing BFD Control Packets 552 This section is part of the replacement for [RFC5880] section 6.8.6, 553 separated for clarity. 555 If the Multipoint (M) bit is set 557 If the Your Discriminator field is nonzero, the packet MUST be 558 discarded. 560 Select a session based on the source address and the My 561 Discriminator field. If a session is found, and 562 bfd.SessionType is not MultipointTail, the packet MUST be 563 discarded. If a session is not found, a new session of type 564 MultipointTail MAY be created, or the packet MAY be discarded. 565 This choice is outside the scope of this specification. 567 Else (Multipoint bit is clear) 569 If the Your Discriminator field is nonzero 570 Select a session based on the value of Your Discriminator. 571 If no session is found, the packet MUST be discarded. 573 Else (Your Discriminator is zero) 575 If the State field is not Down or AdminDown, the packet MUST 576 be discarded. 578 Otherwise, the session MUST be selected based on some 579 combination of other fields, possibly including source 580 addressing information, the My Discriminator field, and the 581 interface over which the packet was received. The exact 582 method of selection is application-specific and is thus 583 outside the scope of this specification. 585 If a matching session is found, and bfd.SessionType is not 586 PointToPoint, the packet MUST be discarded. 588 If a matching session is not found, a new session of type 589 PointToPoint may be created, or the packet may be discarded. 590 This choice is outside the scope of this specification. 592 If the State field is Init and bfd.SessionType is not 593 PointToPoint, the packet MUST be discarded. 595 4.13.3. Transmitting BFD Control Packets 597 The following procedure replaces section 6.8.7 of [RFC5880]. 599 BFD Control packets MUST be transmitted periodically at the rate 600 determined according to [BFD] section 6.8.2, except as specified in 601 this section. 603 A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr 604 is zero and the system is taking the Passive role. 606 A system MUST NOT transmit any BFD Control packets if bfd.SilentTail 607 is 1. 609 A system MUST NOT periodically transmit BFD Control packets if Demand 610 mode is active on the remote system (bfd.RemoteDemandMode is 1, 611 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 612 Sequence is not being transmitted. 614 A system MUST NOT periodically transmit BFD Control packets if 615 bfd.RemoteMinRxInterval is zero. 617 If bfd.SessionType is MultipointHead, the transmit interval MUST be 618 set to bfd.DesiredMinTxInterval (this should happen automatically, as 619 bfd.RemoteMinRxInterval will be zero.) 621 If bfd.SessionType is not MultipointHead, the transmit interval MUST 622 be recalculated whenever bfd.DesiredMinTxInterval changes, or 623 whenever bfd.RemoteMinRxInterval changes, and is equal to the greater 624 of those two values. See [BFD] sections 6.8.2 and 6.8.3 for details 625 on transmit timers. 627 If a BFD Control packet is received with the Poll (P) bit set to 1, 628 the receiving system MUST transmit a BFD Control packet with the Poll 629 (P) bit clear and the Final (F) bit, without respect to the 630 transmission timer or any other transmission limitations, without 631 respect to the session state, and without respect to whether Demand 632 mode is active on either system. A system MAY limit the rate at 633 which such packets are transmitted. If rate limiting is in effect, 634 the advertised value of Desired Min TX Interval MUST be greater than 635 or equal to the interval between transmitted packets imposed by the 636 rate limiting function. If the Multipoint (M) bit is set in the 637 received packet, the packet transmission MUST be delayed by a random 638 amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). 639 Otherwise, the packet MUST be transmitted as soon as practicable. 641 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 642 MultipointTail. 644 A system MUST NOT set the Demand (D) bit if bfd.SessionType 645 PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and 646 bfd.RemoteSessionState is Up. 648 If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control 649 packet SHOULD be transmitted during the interval between periodic 650 Control packet transmissions when the contents of that packet would 651 differ from that in the previously transmitted packet (other than the 652 Poll and Final bits) in order to more rapidly communicate a change in 653 state. 655 The contents of transmitted BFD Control packets MUST be set as 656 follows: 658 Version 660 Set to the current version number (1). 662 Diagnostic (Diag) 664 Set to bfd.LocalDiag. 666 State (Sta) 668 Set to the value indicated by bfd.SessionState. 670 Poll (P) 672 Set to 1 if the local system is sending a Poll Sequence or is a 673 session of type MultipointHead soliciting the identities of the 674 tails, or 0 if not. 676 Final (F) 678 Set to 1 if the local system is responding to a Control packet 679 received with the Poll (P) bit set, or 0 if not. 681 Control Plane Independent (C) 683 Set to 1 if the local system's BFD implementation is 684 independent of the control plane (it can continue to function 685 through a disruption of the control plane.) 687 Authentication Present (A) 689 Set to 1 if authentication is in use on this session 690 (bfd.AuthType is nonzero), or 0 if not. 692 Demand (D) 694 Set to bfd.DemandMode if bfd.SessionState is Up and 695 bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is 696 MultipointHead. Otherwise it is set to 0. 698 Multipoint (M) 700 Set to 1 if bfd.SessionType is MultipointHead. Otherwise it is 701 set to 0. 703 Detect Mult 705 Set to bfd.DetectMult. 707 Length 709 Set to the appropriate length, based on the fixed header length 710 (24) plus any Authentication Section. 712 My Discriminator 713 Set to bfd.LocalDiscr. 715 Your Discriminator 717 Set to bfd.RemoteDiscr. 719 Desired Min TX Interval 721 Set to bfd.DesiredMinTxInterval. 723 Required Min RX Interval 725 Set to bfd.RequiredMinRxInterval. 727 Required Min Echo RX Interval 729 Set to 0 if bfd.SessionType is MultipointHead or 730 MultipointTail. 732 Authentication Section 734 Included and set according to the rules in section 6.7 if 735 authentication is in use (bfd.AuthType is nonzero.) Otherwise 736 this section is not present. 738 5. Assumptions 740 If authentication is in use, all tails must be configured to have a 741 common authentication key in order to receive the multipoint BFD 742 Control packets. 744 6. IANA Considerations 746 This document has no actions for IANA. 748 7. Security Considerations 750 Implementations that creates MultpointTail sessions dynamically upon 751 receipt of Multipoint BFD Control packets MUST implement protective 752 measures to prevent infinite number of MultipointTail session being 753 created. Below lists some points to be considered in such 754 implementations. 756 If a Multipoint BFD Control packet did not arrive on a multicast 757 tree (ex: on expected interface, with expected MPLS label, etc), 758 then a MultipointTail session should not be created. 760 If redundant streams are expected for a given multicast stream, 761 then the implementations should not create more MultipointTail 762 sessions than the number of streams. Additionally, when the 763 number of MultipointTail sessions exceeds the number of expected 764 streams, then the implementation should generate an alarm to users 765 to indicate the anomaly. 767 The implementation should have a reasonable upper bound on the 768 number of MultipointTail sessions that can be created, with the 769 upper bound potentially being computed based on the number of 770 multicast streams that the system is expecting. 772 8. Contributors 774 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 775 Systems provided the initial idea for this specification and 776 contributed to its development. 778 9. Normative References 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, March 1997. 783 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 784 (BFD)", RFC 5880, June 2010. 786 Authors' Addresses 788 Dave Katz 789 Juniper Networks 790 1194 N. Mathilda Ave. 791 Sunnyvale, California 94089-1206 792 USA 794 Email: dkatz@juniper.net 796 Dave Ward 797 Cisco Systems 798 170 West Tasman Dr. 799 San Jose, California 95134 800 USA 802 Email: wardd@cisco.com 803 Santosh Pallagatti (editor) 804 Juniper Networks 805 Embassy Business Park 806 Bangalore, KA 560093 807 India 809 Email: santoshpk@juniper.net