idnits 2.17.1 draft-katz-ward-bfd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'KEYWORDS' on line 50 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Katz 3 Internet Draft Juniper Networks 4 D. Ward 5 Cisco Systems 6 Category: Informational August, 2003 7 Expires: February, 2004 9 Bidirectional Forwarding Detection 10 draft-katz-ward-bfd-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes a protocol intended to detect faults in the 40 bidirectional path between two forwarding engines, including 41 interfaces, data link(s), and to the extent possible the forwarding 42 engines themselves, with potentially very low latency. It operates 43 independently of media, data protocols, and routing protocols. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 51 1. Introduction 53 An increasingly important feature of networking equipment is the 54 rapid detection of communication failures between adjacent systems, 55 in order to more quickly establish alternative paths. Currently, 56 detection can come fairly quickly in certain circumstances when data 57 link hardware comes into play (such as SONET alarms.) However, there 58 are media that do not provide this kind of signaling (such as 59 Ethernet), and some media may not detect certain kinds of failures in 60 the path, for example, failing interfaces or forwarding engine 61 components. 63 Networks use relatively slow "Hello" mechanisms, usually in routing 64 protocols, to detect failures when there is no hardware signaling to 65 help out. The detection times available in the existing protocols 66 are no better than a second, which is far too long for some 67 applications and represents a great deal of lost data at gigabit 68 rates. Furthermore, routing protocol Hellos are of no help when 69 those routing protocols are not in use, and the semantics of 70 detection are subtly different--they detect a failure in the path 71 between the two routing protocol engines. 73 The goal of BFD is to provide low-overhead, short-duration detection 74 of failures in the path between adjacent forwarding engines, 75 including the interfaces, data link(s), and to the extent possible 76 the forwarding engines themselves. 78 An additional goal is to provide a single mechanism that can be used 79 for liveness detection over any media, at any protocol layer, with a 80 wide range of detection times and overhead, to avoid a proliferation 81 of different methods. 83 This document specifies the details of the base protocol. The use of 84 some mechanisms are application dependent, and will be specified in a 85 separate series of application documents. These issues are so noted. 87 Note that many of the exact mechanisms are implementation dependent 88 and will not affect interoperability, and are thus outside the scope 89 of this specification. Those issues are so noted. 91 2. Design 93 BFD is designed to detect failures in communication with a data plane 94 next hop. It is intended to be implemented in some component of the 95 forwarding engine of a system, in cases where the forwarding and 96 control engines are separated. This not only binds the protocol more 97 to the data plane, but decouples the protocol from the fate of the 98 routing protocol engine (making it useful in concert with various 99 "graceful restart" mechanisms for those protocols.) 101 BFD operates on top of any data protocol being forwarded between two 102 systems. It is always run in a unicast, point-to-point mode. BFD 103 packets are carried as the payload of whatever encapsulating protocol 104 is appropriate for the medium and network. BFD may be running at 105 multiple layers in a system. The context of the operation of any 106 particular BFD session is bound to its encapsulation. 108 BFD can provide failure detection on any kind of path between 109 systems, including direct physical links, virtual circuits, tunnels, 110 MPLS LSPs, multihop routed paths, and unidirectional links (so long 111 as there is some return path, of course.) Multiple BFD sessions can 112 be established between the same pair of systems when multiple paths 113 between them are present in at least one direction, even if the same 114 path is shared by multiple sessions in one direction. 116 The BFD state machine implements a three-way handshake, both when 117 establishing a BFD session and when tearing it down for any reason, 118 to ensure that both systems are aware of the state change. 120 BFD can be abstracted as a simple service. The service primitives 121 provided by BFD are to create, destroy, and modify a session, given 122 the destination address and other parameters. BFD in return provides 123 a signal to its clients indicating when the BFD session goes up or 124 down. 126 3. Protocol Overview 128 BFD is a simple, fixed-field, hello protocol that in many respects is 129 similar to the detection components of well-known routing protocols. 130 A pair of systems transmit BFD packets periodically over each path 131 between the two systems, and if a system stops receiving BFD packets 132 for long enough, some component in that particular bidirectional path 133 to the neighboring system is assumed to have failed. Under some 134 conditions, systems may negotiate to not send periodic BFD packets in 135 order to reduce overhead. 137 A path is only declared to be operational when two-way communication 138 has been established between systems (though this does not preclude 139 the use of unidirectional links.) 141 A separate BFD session is created for each communications path and 142 data protocol in use between two systems. 144 Each system estimates how quickly it can send and receive BFD packets 145 in order to come to an agreement with its neighbor about how rapidly 146 detection of failure will take place. These estimates can be 147 modified in real time in order to adapt to unusual situations. This 148 design also allows for fast systems on a shared medium with a slow 149 system to be able to more rapidly detect failures between the fast 150 systems while allowing the slow system to participate to the best of 151 its ability. 153 3.1. Addressing and Session Establishment 155 A BFD session is established based on the needs of the application 156 that will be making use of it. It is up to the application to 157 determine the need for BFD, and the addresses to use--there is no 158 discovery mechanism in BFD. For example, an OSPF implementation may 159 request a BFD session to be established to a neighbor discovered 160 using the OSPF Hello protocol. 162 3.2. Operating Modes 164 BFD has two operating modes which may be selected, as well as an 165 additional function that can be used in combination with the two 166 modes. 168 The primary mode is known as Asynchronous mode. In this mode, the 169 systems periodically send BFD Control packets to one another, and if 170 a number of those packets in a row are not received by the other 171 system, the session is declared to be down. 173 The second mode is known as Demand mode. In this mode, it is assumed 174 that each system has an independent way of verifying that it has 175 connectivity to the other system, so once a BFD session is 176 established, the systems stop sending BFD Control packets, except 177 when either system feels the need to verify connectivity explicitly, 178 in which case a short sequence of BFD Control packets is sent, and 179 then the protocol quiesces. 181 An adjunct to both modes is the Echo function. When the Echo 182 function is active, a stream of BFD Echo packets is transmitted in 183 such a way as to have the other system loop them back through its 184 forwarding path. If a number of packets in a row of the echoed data 185 stream are not received, the session is declared to be down. The 186 Echo function may be used with either Asynchronous or Demand modes. 187 Since the Echo function is handling the task of detection, the rate 188 of periodic transmission of Control packets may be reduced (in the 189 case of Asynchronous mode) or eliminated completely (in the case of 190 Demand mode.) 192 Pure asynchronous mode is advantageous in that it requires half as 193 many packets to achieve a particular detection time as does the Echo 194 function. It is also used when the Echo function cannot be supported 195 for some reason. 197 The Echo function has the advantage of truly testing only the 198 forwarding path on the remote system, which may reduce round-trip 199 jitter and thus allow more aggressive detection times, as well as 200 potentially detecting some classes of failure that might not 201 otherwise be detected. 203 The Echo function may be enabled individually in each direction. It 204 is enabled in a particular direction only when the system that loops 205 the Echo packets back signals that it will allow it, and when the 206 system that sends the Echo packets decides it wishes to. 208 Demand mode is useful in situations where the overhead of a periodic 209 protocol might prove onerous, such as a system with a very large 210 number of BFD sessions. It is also useful when the Echo function is 211 being used symmetrically. Demand mode has the disadvantage that 212 detection times are essentially driven by the heuristics of the 213 system implementation and are not known to the BFD protocol. Demand 214 mode also may not be used when the path round trip time is greater 215 than the desired detection time. See section 6.4 for more details. 217 4. BFD Control Packet Format 219 BFD Control packets are sent in an encapsulation appropriate to the 220 environment, which is outside of the scope of this document. See the 221 appropriate application document for encapsulation details. 223 The payload of a BFD Control packet has the following format: 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |Vers | Diag |H|D|P|F| Rsvd | Detect Mult | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | My Discriminator | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Your Discriminator | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Desired Min TX Interval | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Required Min RX Interval | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Required Min Echo RX Interval | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Version (Vers) 243 The version number of the protocol. This document defines 244 protocol version 0. 246 Diagnostic (Diag) 248 A diagnostic code specifying the local system's reason for the 249 last transition of the session from Up to some other state. 250 Values are: 252 0 -- No Diagnostic 253 1 -- Control Detection Time Expired 254 2 -- Echo Function Failed 255 3 -- Neighbor Signaled Session Down 256 4 -- Forwarding Plane Reset 257 5 -- Path Down 258 6 -- Concatenated Path Down 259 7 -- Administratively Down 261 I Hear You (H) 263 This bit is set to 0 if the transmitting system either is not 264 receiving BFD packets from the remote system, or is in the process 265 of tearing down the BFD session for some reason (see the Elements 266 of Procedure below for more details.) 268 Demand (D) 270 If set, the transmitting system wishes to operate in Demand Mode. 272 Poll (P) 274 If set, the transmitting system requesting verification of 275 connectivity, or of a parameter change. 277 Final (F) 279 If set, the transmitting system is responding to a received BFD 280 Control packet that had the Poll (P) bit set. 282 Reserved (Rsvd) 284 These bits must be zero on transmit, and ignored on receipt. 286 Detect Mult 288 Detect time multiplier. The negotiated transmit interval, 289 multiplied by this value, provides the detection time for the 290 transmitting system in Asynchronous mode. 292 Length 294 Length of the BFD Control packet, in bytes. 296 My Discriminator 298 A unique, nonzero discriminator value generated by the 299 transmitting system, used to demultiplex multiple BFD sessions 300 between the same pair of systems. 302 Your Discriminator 304 The discriminator received from the corresponding remote system. 305 This field reflects back the received value of My Discriminator, 306 or is zero if that value is unknown. 308 Desired Min TX Interval 310 This is the minimum interval, in microseconds, that the local 311 system would like to use when transmitting BFD Control packets. 313 Required Min RX Interval 315 This is the minimum interval, in microseconds, between received 316 BFD Control packets that this system is capable of supporting. 318 Required Min Echo RX Interval 320 This is the minimum interval, in microseconds, between received 321 BFD Echo packets that this system is capable of supporting. If 322 this value is zero, the transmitting system does not support the 323 receipt of BFD Echo packets. 325 5. BFD Echo Packet Format 327 BFD Echo packets are sent in an encapsulation appropriate to the 328 environment. See the appropriate application document for the 329 specifics of particular environments. 331 The payload of a BFD Echo packet is a local matter, since only the 332 sending system ever processes the content. The only requirement is 333 that sufficient information is included to demultiplex the received 334 packet to the correct BFD session after it is looped back to the 335 sender. The contents are otherwise outside the scope of this 336 specification. 338 6. Elements of Procedure 340 This section discusses the normative requirements of the protocol in 341 order to achieve interoperability. It is important for implementors 342 to enforce only the requirements specified in this section, as 343 misguided pedantry has been proven by experience to adversely affect 344 interoperability. 346 6.1. Overview 348 A system may take either an Active role or a Passive role in session 349 initialization. A system taking the Active role MUST send BFD 350 Control packets regardless of whether it has received any BFD packets 351 for the session. A system taking the Passive role MUST NOT begin 352 sending BFD packets until it has received a BFD packet for the 353 session, and thus has learned the remote system's discriminator 354 value. At least one system MUST take the Active role (possibly 355 both.) The role that a system takes is specific to the application 356 of BFD, and is outside the scope of this specification. 358 A session begins with the periodic, slow transmission of BFD Control 359 packets. When bidirectional communication is achieved (by virtue of 360 the I Hear You field being nonzero in both directions, a three way 361 handshake), the BFD session comes up. 363 Once the BFD session is Up, a system can choose to start the Echo 364 function if it desires to and the other system signals that it will 365 allow it. The rate of transmission of Control packets is typically 366 kept low when the Echo function is active. 368 If the Echo function is not active, the transmission rate of Control 369 packets may be increased to a level necessary to achieve the 370 detection time requirements for the session. 372 If both systems signal that they want to use Demand mode, the 373 transmission of BFD Control packets ceases once the session is Up. 374 Other means of implying connectivity are used to keep the session 375 alive. If one of the systems wishes to verify connectivity, it can 376 initiate a short exchange (a "Poll Sequence") of BFD Control packets 377 to verify this. 379 If Demand mode is not active, and no Control packets are received in 380 the calculated detection time, the session is declared down, and 381 signalled to the remote end by sending a zero value in the I Hear You 382 field in outgoing packets. 384 If sufficient Echo packets are lost, the session is declared down in 385 the same manner. 387 If Demand mode is active and no Control packets are received in 388 response to a Poll Sequence, the session is declared down in the same 389 manner. 391 If the session goes down, the transmission of Echo packets (if any) 392 ceases, and the transmission of Control packets goes back to the slow 393 rate. 395 Once a session has been declared down, it cannot come back up until 396 the remote end first signals that it is down (by setting its outgoing 397 I Hear You field to zero), thus implementing a three-way handshake. 399 A session may be kept administratively down by always setting its 400 outgoing I Hear You field to zero, and sending an explanatory 401 diagnostic code in the Diagnostic field. 403 6.2. Demultiplexing and the Discriminator Fields 405 Since multiple BFD sessions may be running between two systems, there 406 needs to be a mechanism for demultiplexing received BFD packets to 407 the proper session. 409 Each system MUST choose an opaque discriminator value that identifies 410 each session, and which MUST be unique among all BFD sessions on the 411 system. The local discriminator is sent in the My Discriminator 412 field in the BFD Control packet, and is echoed back in the Your 413 Discriminator field of packets sent from the remote end. 415 Once the remote end echos back the local discriminator, all further 416 received packets are demultiplexed based on the Your Discriminator 417 field only (which means that, among other things, the source address 418 field can change or the interface over which the packets are received 419 can change, but the packets will still be associated with the proper 420 session.) 422 The method of demultiplexing the initial packets (in which Your 423 Discriminator is zero) is application-dependent, and is thus outside 424 the scope of this specification. 426 6.3. The Echo Function and Asymmetry 428 The Echo function can be run independently in each direction between 429 a pair of systems. For whatever reason, a system may advertise that 430 it is willing to receive (and loop back) Echo packets, but may not 431 wish to ever send any. The fact that a system is sending Echo 432 packets is not directly signalled to the system looping them back. 434 When a system is using the Echo function, it is advantageous to 435 choose a sedate transmission rate for Control packets, since the job 436 of detection is being handled by the Echo packets. This can be 437 controlled by manipulating the Desired Min TX Interval field (see 438 section 6.5.3.) 440 If the Echo function is only being run in one direction, the system 441 not running the Echo function will more likely wish to send fairly 442 rapid Control packets in order to achieve its desired detection time. 443 Since BFD allows independent transmission rates in each direction, 444 this is easily accomplished. 446 A system SHOULD always advertise the lowest value of Required Min RX 447 Interval and Required Min Echo RX Interval that it can under the 448 circumstances, to give the other system more freedom in choosing its 449 transmission rate. Note that a system is committing to be able to 450 receive both streams of packets at the rate it advertises, so this 451 should be taken into account when choosing the values to advertise. 453 6.4. Demand Mode 455 Demand mode is negotiated by virtue of both systems setting the 456 Demand (D) bit in its BFD Control packets. Both systems must request 457 Demand mode for it to become active. 459 Demand mode requires that some other mechanism is used to imply 460 continuing connectivity between the two systems. The mechanism used 461 does not have to be the same in both directions, and is outside of 462 the scope of this specification. One possible mechanism is the 463 receipt of traffic from the remote system; another is the use of the 464 Echo function. 466 Once a BFD session comes up, if Demand mode is active, both systems 467 stop sending periodic BFD Control packets, and depend on the 468 alternative mechanism for maintaining ongoing connectivity. 470 When a system wishes to verify connectivity, it initiates a Poll 471 Sequence. It starts periodically sending BFD Control packets with 472 the Poll (P) bit set, at the negotiated transmission rate. When a 473 system receives such a packet, it immediately replies with a BFD 474 Control packet of its own, with the Poll (P) bit clear, and the Final 475 (F) bit set. The receipt of a reply to a Poll terminates the Poll 476 Sequence. If no response is received to a Poll, the Poll is repeated 477 until the detection time expires, at which point the session is 478 declared to be down. 480 The detection time in Demand mode is calculated differently than in 481 Asynchronous mode; it is based on the transmit rate of the local 482 system, rather than the transmit rate of the remote system. This 483 ensures that the Poll Sequence mechanism works properly. See section 484 6.5.8 for more details. 486 Note that this mechanism requires that the detection time negotiated 487 is greater than the round trip time between the two systems, or the 488 Poll mechanism will always fail. Enforcement of this requirement is 489 outside the scope of this specification. 491 Demand mode MAY be enabled or disabled at any time by setting or 492 clearing the Demand (D) bit in the BFD Control packet, without 493 affecting the BFD session state. 495 Because the underlying detection mechanism is unspecified, and may 496 differ between the two systems, the overall detection time 497 characteristics of the path will not be fully known to either system. 498 The total detection time for a particular system is the sum of the 499 time prior to the initiation of the Poll Sequence, plus the 500 calculated detection time. 502 6.5. Functional Specifics 504 The following section of this specification is normative. The means 505 by which this specification is achieved is outside the scope of this 506 specification. 508 When a system is said to have "the Echo function active," it refers 509 to that system sending BFD Echo packets (and thus implies that the 510 session is Up and the other system has signalled its willingness to 511 loop back Echo packets.) 513 When a system is said to have "Demand mode active," it means that the 514 bfd.DemandModeDesired is 1 in the local system, the remote system is 515 signalling with the Demand (D) bit set, and that the session is Up. 517 6.5.1. State Variables 519 A minimum amount of information about a session needs to be tracked 520 in order to achieve the elements of procedure described here. The 521 following is a set of state variables that are helpful in describing 522 the mechanisms of BFD. Any means of tracking this state may be used 523 so long as the protocol behaves as described. 525 bfd.SessionState 527 The perceived state of the session (Init, Up, Failing, Down, or 528 AdminDown.) The exact action taken when the session state 529 changes is outside the scope of this specification, though it 530 is expected that this state change (particularly to and from Up 531 state) is reported to other components of the system. This 532 variable MUST be initialized to Failing. 534 bfd.LocalDiscr 536 The local discriminator for this BFD session, used to uniquely 537 identify it. It MUST be unique on this system, and nonzero. 538 The value is otherwise outside the scope of this specification. 540 bfd.RemoteDiscr 542 The remote discriminator for this BFD session. This is the 543 discriminator chosen by the remote system, and is totally 544 opaque to the local system. This MUST be initialized to zero. 546 Note that if the remote system changes its discriminator value 547 (because of a software restart, for example) the session can 548 never come up again until the outgoing Your Discriminator value 549 is set to zero, due to the packet acceptance rules. Therefore, 550 this field MUST be set to zero after no packets have been 551 received on this session for at least twice the Detection Time. 553 The net result of these rules is that, when a session fails due 554 to a Detect Time timeout, packets will be sent with the old 555 value of Your Discriminator and with I Hear You set to zero, 556 thus signalling the failure of the session; then subsequently 557 the Your Discriminator field is set to zero so that a new 558 discriminator can be accepted. 560 bfd.RemoteHeard 562 This variable is set to 1 if the local system is actively 563 receiving BFD packets from the remote system, and is set to 0 564 if the local system has not received BFD packets recently 565 (within the detection time) or if the local system is 566 attempting to tear down the BFD session. This MUST be 567 initialized to zero. 569 bfd.LocalDiag 571 The diagnostic code specifying the reason the local session 572 state most recently transitioned from Up to some other state. 573 This MUST be initialized to zero (No Diagnostic.) 575 bfd.DesiredMinTxInterval 577 The minimum interval, in microseconds, between transmitted BFD 578 Control packets that this system would like to use at the 579 current time. The actual interval is negotiated between the 580 two systems. This MUST be initialized to a value of at least 581 one second (1,000,000 microseconds) according to the rules 582 described in section 6.5.3. The setting of this variable is 583 otherwise outside the scope of this specification. 585 bfd.RequiredMinRxInterval 587 The minimum interval, in microseconds, between received BFD 588 Control packets that this system requires. The setting of this 589 variable is outside the scope of this specification. 591 bfd.DemandModeDesired 593 Set to 1 if the local system wishes to use Demand mode, or 0 if 594 not. 596 bfd.DetectMult 598 The desired detect time multiplier for BFD Control packets. 599 The negotiated Control packet transmission interval, multiplied 600 by this variable, will be the detection time for this session 601 (as seen by the remote system.) This variable MUST be a 602 nonzero integer, and is otherwise outside the scope of this 603 specification. See section 6.5.4 for further information. 605 6.5.2. Timer Negotiation 607 The time values used to determine BFD packet transmission intervals 608 and the session detection time are continuously negotiated, and thus 609 may be changed at any time. The negotiation and time values are 610 independent in each direction for each session. Packets are always 611 periodically transmitted in Asynchronous mode, and are periodically 612 transmitted during Poll Sequences when in Demand mode. 614 Each system reports in the BFD Control packet how rapidly it would 615 like to transmit BFD packets, as well as how rapidly it is prepared 616 to receive them. With the exceptions listed in the remainder of this 617 section, a system MUST NOT transmit BFD Control packets with an 618 interval less than the larger of bfd.DesiredMinTxInterval and the 619 received Required Min RX Interval field. In other words, the system 620 reporting the slower rate determines the transmission rate. 622 The periodic transmission of BFD Control packets SHOULD be jittered 623 by up to 25%, that is, the interval SHOULD be reduced by a random 624 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 625 average interval between packets may be up to 12.5% less than that 626 negotiated. 628 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 629 Control packets MUST be no more than 90% of the negotiated 630 transmission interval, and MUST be no less than 75% of the negotiated 631 transmission interval. This is to ensure that, on the remote system, 632 the calculated DetectTime does not pass prior to the receipt of the 633 next BFD Control packet. 635 An extra, single BFD Control packet SHOULD be transmitted during the 636 interval between periodic Control packet transmissions if there is a 637 state change that needs to be communicated, in order to more rapidly 638 converge. (For example, if the local system determines that the BFD 639 session has gone down, it SHOULD communicate this without waiting for 640 the next periodic transmission.) With the exception listed in the 641 next paragraph, once such an extra packet has been transmitted, a 642 system MUST NOT send another BFD Control packet until the next 643 scheduled transmission. 645 If a BFD Control packet is received with the Poll (P) bit set to 1, 646 the receiving system MUST transmit a BFD Control packet with the Poll 647 (P) bit clear and the Final (F) bit set as soon as practicable, 648 without respect to the transmission timer or any other transmission 649 limitations, and without respect to whether Demand mode is active. 651 6.5.3. Timer Manipulation 653 The time values used to determine BFD packet transmission intervals 654 and the session detection time may be modified at any time without 655 affecting the state of the session. When the timer parameters are 656 changed for any reason, the requirements of this section apply. 658 If bfd.DesiredMinTxInterval is changed, or bfd.RequiredMinRxInterval 659 is changed, and Demand mode is active, a Poll Sequence MUST be 660 initiated. 662 If bfd.DesiredMinTxInterval is changed, or bfd.RequiredMinRxInterval 663 is changed, and Demand mode is not active, all subsequent transmitted 664 Control packets MUST be sent with the Poll (P) bit set until a packet 665 is received with the Final (F) bit set. 667 If bfd.DesiredMinTxInterval is increased, the actual transmission 668 interval used MUST NOT change until a Control packet is received with 669 the Final (F) bit set. This is to ensure that the remote system 670 updates its Detect Time before the transmission interval increases. 672 If bfd.RequiredMinRxInterval is reduced, the calculated detection 673 time for the remote system MUST NOT change until a Control packet is 674 received with the Final (F) bit set. This is to ensure that the 675 remote system is transmitting packets at the higher rate (and those 676 packets are being received) prior to the detection time being 677 reduced. 679 When bfd.SessionState is not Up, the system MUST set 680 bfd.DesiredMinTxInterval to a value of not less than one second 681 (1,000,000 microseconds.) This is intended to ensure that the 682 bandwidth consumed by down BFD sessions is negligible, particularly 683 in the case where a neighbor may not be running BFD. 685 When the Echo function is active, a system SHOULD set 686 bfd.DesiredMinTxInterval to a value of not less than one second 687 (1,000,000 microseconds.) This is intended to keep BFD Control 688 traffic at a negligible level, since the actual detection function is 689 being performed using BFD Echo packets. 691 6.5.4. Calculating the Detection Time 693 The Detection Time (the period of time without receiving BFD packets 694 after which the session is determined to have failed) is not carried 695 explicitly in the protocol. Rather, it is calculated independently 696 in each direction by the receiving system based on the negotiated 697 transmit interval and the detection multiplier. Note that, in 698 Asynchronous mode, there may be different detection times in each 699 direction. 701 The calculation of the Detection Time is slightly different when in 702 Demand mode versus Asynchronous mode. 704 In Asynchronous mode, the Detection Time calculated in the local 705 system is equal to the value of Detect Mult received from the remote 706 system, multiplied by the agreed transmit interval (the greater of 707 bfd.RequiredMinRxInterval and the last received Desired Min TX 708 Interval.) The Detect Mult value is (roughly speaking, due to 709 jitter) the number of packets that have to be missed in a row to 710 declare the session to be down. 712 If Demand mode is not active, and a period of time equal to the 713 Detection Time passes without receiving a BFD Control packet from the 714 remote system, and bfd.SessionState is Init or Up, the session has 715 gone down--the local system MUST set bfd.SessionState to Failing, 716 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 717 Time Expired.) The timeout in Init state is to avoid a potential 718 deadlock in which one system is in Failing state and the other is in 719 Init state (which could happen if a packet were lost at the right 720 time.) 722 In Demand mode, the Detection Time calculated in the local system is 723 equal to bfd.DetectMult, multiplied by the agreed transmit interval 724 (the greater of bfd.RequiredMinRxInterval and the last received 725 Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due 726 to jitter) the number of packets that have to be missed in a row to 727 declare the session to be down. 729 If Demand mode is active, and a period of time equal to the Detection 730 Time passes after the initiation of a Poll Sequence (the transmission 731 of the first BFD Control packet with the Poll bit set), the session 732 has gone down--the local system MUST set bfd.SessionState to Failing, 733 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 734 Time Expired.) 736 (Note that a packet is considered to have been received, for the 737 purposes of the Detection Time, only if it has not been "discarded" 738 according to the rules of section 6.5.6.) 740 6.5.5. Detecting Failures with the Echo Function 742 When the Echo function is active and a sufficient number of Echo 743 packets have not arrived as they should, the session has gone 744 down--the local system MUST set bfd.SessionState to Failing, 745 bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function 746 Failed.) 748 The means by which the Echo function failures are detected is outside 749 of the scope of this specification. Any means which will detect a 750 communication failure is acceptable. 752 6.5.6. Reception of BFD Control Packets 754 When a BFD Control packet is received, the following procedure MUST 755 be followed, in the order specified: 757 If the version number is not correct (0), the packet MUST be 758 discarded. 760 If the Length field is less than the correct value (24), the 761 packet MUST be discarded. 763 If the Length field is greater than the payload of the 764 encapsulating protocol, the packet MUST be discarded. 766 If the Detect Mult field is zero, the packet MUST be discarded. 768 If the My Discriminator field is zero, the packet MUST be 769 discarded. 771 If the Your Discriminator field is nonzero, it MUST be used to 772 select the session with which this BFD packet is associated. If 773 no session is found, the packet MUST be discarded. 775 If the Your Discriminator field is zero and the I Hear You field 776 is nonzero, the packet MUST be discarded. 778 If the Your Discriminator field is zero, the session MUST selected 779 based on some combination of other fields, possibly including 780 source addressing information, the My Discriminator field, and the 781 interface over which the packet was received. The exact method of 782 selection is application-specific and is thus outside the scope of 783 this specification. If a matching session is not found, a new 784 session may be created, or the packet may be discarded. This 785 choice is outside the scope of this specification. 787 If the value of My Discriminator differs from bfd.RemoteDiscr, and 788 bfd.RemoteDiscr is nonzero, the packet MUST be discarded. 790 If the value of bfd.RemoteDiscr is zero, set it to the value of My 791 Discriminator. 793 If the Required Min Echo RX Interval field is zero, the 794 transmission of Echo packets, if any, MUST cease. 796 If a Poll Sequence is being transmitted by the local system, the 797 Poll Sequence MUST be terminated. Note that the setting of the 798 Final (F) bit is not considered. 800 If Demand mode is not active, the Final (F) bit in the received 801 packet is set, and the local system has been transmitting packets 802 with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in 803 subsequent transmitted packets. 805 If Demand mode is not active, calculate the Detection Time as 806 described in section 6.5.4. 808 If bfd.SessionState is Down 809 Set bfd.RemoteHeard to 1 810 If I Hear You is zero 811 Set bfd.SessionState to Init 812 Else 813 Set bfd.SessionState to Up 815 Else if bfd.SessionState is AdminDown 816 Discard the packet 818 Else if bfd.SessionState is Init 819 If I Hear You is nonzero 820 Set bfd.SessionState to Up 821 Else 822 Discard the packet 824 Else if bfd.SessionState is Up 825 If I Hear You is zero 826 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 827 Set bfd.SessionState to Failing 828 Set bfd.RemoteHeard to 0 830 Else if bfd.SessionState is Failing 831 If I Hear You is zero, set bfd.SessionState to Down 833 Update the transmit interval as described in section 6.5.2. 835 If the Demand (D) bit is set and bfd.DemandModeDesired is 1, 836 and bfd.SessionState is Up, Demand mode is active. 838 If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, 839 or bfd.SessionState is not Up, Demand mode is not 840 active. 842 If the Poll (P) bit is set, send a BFD Control packet to the 843 remote system with the Poll (P) bit clear, and the Final (F) bit 844 active. 846 If the packet was not discarded, it has been received for purposes of 847 the Detection Time rules in section 6.5.4. 849 6.5.7. Transmitting BFD Control Packets 851 BFD Control packets MUST be transmitted periodically at the rate 852 determined according to section 6.5.2, except as specified in this 853 section. 855 The transmit interval MUST be recalculated whenever 856 bfd.DesiredMinTxInterval changes, or whenever the received Required 857 Min RX Interval changes, and is equal to the greater of those two 858 values. See sections 6.5.2 and 6.5.3 for details on transmit timers. 860 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 861 zero and the system is taking the Passive role. 863 A system MUST NOT periodically transmit BFD Control packets if Demand 864 mode is active and a Poll Sequence is not being transmitted. 866 A system MUST send a BFD Control packet in response to a received BFD 867 Control Packet with the Poll (P) bit set. The packet sent in 868 response MUST NOT have the Poll (P) bit set, and MUST have the Final 869 (F) bit set. 871 A single BFD Control packet SHOULD be transmitted between normally 872 scheduled transmissions in order to more rapidly communicate a change 873 in state. 875 The contents of transmitted BFD Control packets MUST be set as 876 follows: 878 Version 880 Set to the current version number (0). 882 Diagnostic (Diag) 884 Set to bfd.LocalDiag. 886 I Hear You (H) 888 Set to bfd.RemoteHeard. 890 Demand (D) 892 Set to bfd.DemandModeDesired. 894 Poll (P) 896 Set to 1 if the local system is sending a Poll Sequence or is 897 required to do so according to the requirements of section 6.5.3, 898 or 0 if not. 900 Final (F) 902 Set to 1 if the local system is responding to a Control packet 903 received with the Poll (P) bit set, or 0 if not. 905 Reserved (Rsvd) 907 Set to 0. 909 Detect Mult 911 Set to bfd.DetectMult. 913 Length 915 Set to 24. 917 My Discriminator 919 Set to bfd.LocalDiscr. 921 Your Discriminator 923 Set to bfd.RemoteDiscr. 925 Desired Min TX Interval 927 Set to bfd.DesiredMinTxInterval. 929 Required Min RX Interval 931 Set to bfd.RequiredMinRxInterval. 933 Required Min Echo RX Interval 935 Set to the minimum required Echo packet receive interval for this 936 session. If this field is set to zero, the local system is 937 unwilling or unable to loop back BFD Echo packets to the remote 938 system, and the remote system will not send Echo packets. 940 6.5.8. Initiation of a Poll Sequence 942 If Demand mode is active, a Poll Sequence MUST be initiated whenever 943 the contents of the next BFD Control packet to be sent would be 944 different than the contents of the previous packet, with the 945 exception of the Poll (P) and Final (F) bits. This ensures that 946 parameter changes are transmitted to the remote system. Note that if 947 the I Hear You (H) bit is changing, the session is going down and 948 Demand mode will no longer be active. 950 If Demand mode is active, a Poll Sequence SHOULD be initiated 951 whenever the system feels the need to verify connectivity with the 952 remote system. The conditions under which this is desirable are 953 outside the scope of this specification. 955 If a Poll Sequence is being sent, and a new Poll Sequence is 956 initiated due to one of the above conditions, the detection interval 957 MUST be restarted in order to ensure that a full Poll Sequence is 958 transmitted under the new conditions. 960 6.5.9. Reception of BFD Echo Packets 962 A received BFD Echo packet MUST be demultiplexed to the appropriate 963 session for processing. A means of detecting missing Echo packets 964 MUST be implemented, which most likely involves processing of the 965 Echo packets that are received. The processing of received Echo 966 packets is otherwise outside the scope of this specification. 968 6.5.10. Transmission of BFD Echo Packets 970 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 971 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 972 Control packet received from the remote system contains a nonzero 973 value in Required Min Echo RX Interval. 975 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 976 interval between transmitted BFD Echo packets MUST NOT be less than 977 the value advertised by the remote system in Required Min Echo RX 978 Interval, except as follows: 980 A 25% jitter MAY be applied to the rate of transmission, such that 981 the actual interval MAY be between 75% and 100% of the advertised 982 value. A single BFD Echo packet MAY be transmitted between 983 normally scheduled Echo transmission intervals. 985 The transmission of BFD Echo packets is otherwise outside the scope 986 of this specification. 988 6.5.11. Min Rx Interval Change 990 When it is desired to change the rate at which BFD Control packets 991 arrive from the remote system, bfd.RequiredMinRxInterval can be 992 changed at any time to any value. The new value will be transmitted 993 in the next outgoing Control packet, and the remote system will 994 adjust accordingly. See sections 6.5.3 and 6.5.8 for further 995 requirements. 997 6.5.12. Min Tx Interval Change 999 When it is desired to change the rate at which BFD Control packets 1000 are transmitted to the remote system (subject to the requirements of 1001 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1002 any time to any value. The rules in sections 6.5.3 and 6.5.8 apply. 1004 6.5.13. Detect Multiplier Change 1006 When it is desired to change the detect multiplier, the value of 1007 bfd.DetectMult can be changed to any nonzero value. The new value 1008 will be transmitted with the next BFD Control packet. See section 1009 6.5.8 for additional requirements. 1011 6.5.14. Enabling or Disabling The Echo Function 1013 If it is desired to start or stop the transmission of BFD Echo 1014 packets, this MAY be done at any time (subject to the transmission 1015 requirements detailed in section 6.5.10.) 1017 If it is desired to enable or disable the looping back of received 1018 BFD Echo packets, this MAY be done at any time by changing the value 1019 of Required Min RX Interval to zero or nonzero in outgoing BFD 1020 Control packets. 1022 6.5.15. Enabling or Disabling Demand Mode 1024 If it is desired to start or stop Demand mode, this MAY be done at 1025 any time by setting bfd.DemandModeDesired to the proper value. If 1026 Demand mode is no longer active, the system MUST begin transmitting 1027 periodic BFD Control packets as described in section 6.5.7. 1029 6.5.16. Forwarding Plane Reset 1031 When the forwarding plane in the local system is reset for some 1032 reason, such that the remote system can no longer rely on the local 1033 forwarding state, the local system MUST set bfd.LocalDiag to 4 1034 (Forwarding Plane Reset), set bfd.SessionState to Failing, and set 1035 bfd.RemoteHeard to zero. 1037 6.5.17. Administrative Control 1039 There may be circumstances where it is desirable to administratively 1040 enable or disable a BFD session. When this is desired, the following 1041 procedure MUST be followed: 1043 If enabling session 1044 Set bfd.SessionState to Failing 1045 Set bfd.RemoteHeard to zero 1047 Else 1048 Set bfd.SessionState to AdminDown 1049 Set bfd.RemoteHeard to zero 1050 Set bfd.LocalDiag to an appropriate value 1051 Cease the transmission of BFD Echo packets 1053 Specific diagnostic codes are provided for two scenarios. 1055 If signalling is received from outside BFD that the underlying path 1056 has failed, an implementation MAY adminstratively disable the session 1057 with the diagnostic Path Down. 1059 If the path being monitored by BFD is concatenated with other paths, 1060 it may be desirable to administratively bring down the BFD session 1061 when a concatenated path fails (as a way of propagating the 1062 failure indication.) In this case, an implementation MAY 1063 administratively disable the BFD session with the diagnostic 1064 Concatenated Path Down. 1066 Other scenarios MAY use the diagnostic Administratively Down. 1068 Contributors 1070 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 1071 significant contributors to this document. 1073 Acknowledgments 1075 This document was inspired by (and is intended to replace) the 1076 Protocol Liveness Protocol draft, written by Kireeti Kompella. 1078 Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 1079 et al. 1081 The authors would also like to thank Mike Shand, John Scudder, and 1082 Stewart Bryant for their substantive input. 1084 Authors' Addresses 1086 Dave Katz 1087 Juniper Networks 1088 1194 N. Mathilda Ave. 1089 Sunnyvale, California 94089-1206 USA 1090 Phone: +1-408-745-2000 1091 Email: dkatz@juniper.net 1093 Dave Ward 1094 Cisco Systems 1095 170 W. Tasman Dr. 1096 San Jose, CA 95134 USA 1097 Phone: +1-408-526-4000 1098 Email: dward@cisco.com 1100 Changes from the previous draft 1102 The largest change since the previous draft is the addition of Demand 1103 mode and the Poll/Final mechanism. This draft otherwise contains 1104 little in the way of functional change compared to the previous 1105 draft. This draft is not interoperable with the previous draft due 1106 to reshuffling of the headers. The version number was not 1107 incremented due to a lack of deployed software. 1109 In this draft, the normative requirements are spelled out more 1110 explicitly, and a fix for a potential deadlock case was added (by 1111 making the detection timer continue to run once the neighbor's 1112 discriminator value is known.) 1114 Security Considerations 1116 When BFD is run over network layer protocols, a significant denial- 1117 of-service risk is created, as BFD packets may be trivial to spoof. 1118 When the session is directly connected across a single link, the TTL 1119 MUST be set to the maximum on transmit, and checked to be equal to 1120 the maximum value on reception (and the packet dropped if this is not 1121 the case.) If BFD is run across multiple hops, some alternative 1122 mechanism MUST be used. One option would be to ensure that the 1123 network addresses used for BFD are not routable outside of the 1124 infrastructure in which BFD is running (and assuming there are no 1125 users connected within that network.) Another option would be to 1126 filter all packets carrying BFD's UDP ports at the edges of the 1127 network. Still another option would be to use cryptographic methods, 1128 though this is not likely to allow for very short detection times. 1130 IPR Notice 1132 The IETF has been notified of intellectual property rights claimed in 1133 regard to some or all of the specification contained in this 1134 document. For more information consult the online list of claimed 1135 rights. 1137 The IETF takes no position regarding the validity or scope of any 1138 intellectual property or other rights that might be claimed to 1139 pertain to the implementation or use of the technology described in 1140 this document or the extent to which any license under such rights 1141 might or might not be available; neither does it represent that it 1142 has made any effort to identify any such rights. Information on the 1143 IETF's procedures with respect to rights in standards-track and 1144 standards-related documentation can be found in BCP-11. Copies of 1145 claims of rights made available for publication and any assurances of 1146 licenses to be made available, or the result of an attempt made to 1147 obtain a general license or permission for the use of such 1148 proprietary rights by implementors or users of this specification can 1149 be obtained from the IETF Secretariat. 1151 The IETF invites any interested party to bring to its attention any 1152 copyrights, patents or patent applications, or other proprietary 1153 rights which may cover technology that may be required to practice 1154 this standard. Please address the information to the IETF Executive 1155 Director. 1157 Full Copyright Notice 1159 Copyright (C) The Internet Society (2003). All Rights Reserved. 1161 This document and translations of it may be copied and furnished to 1162 others, and derivative works that comment on or otherwise explain it 1163 or assist in its implementation may be prepared, copied, published 1164 and distributed, in whole or in part, without restriction of any 1165 kind, provided that the above copyright notice and this paragraph are 1166 included on all such copies and derivative works. However, this 1167 document itself may not be modified in any way, such as by removing 1168 the copyright notice or references to the Internet Society or other 1169 Internet organizations, except as needed for the purpose of 1170 developing Internet standards in which case the procedures for 1171 copyrights defined in the Internet Standards process must be 1172 followed, or as required to translate it into languages other than 1173 English. 1175 The limited permissions granted above are perpetual and will not be 1176 revoked by the Internet Society or its successors or assigns. 1178 This document and the information contained herein is provided on an 1179 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1180 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1181 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1182 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1183 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1185 Acknowledgement 1187 Funding for the RFC Editor function is currently provided by the 1188 Internet Society.