idnits 2.17.1 draft-katz-ward-bfd-02.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: 'KEYWORDS' is mentioned on line 50, but not defined == Unused Reference: 'KEYWORD' is defined on line 1157, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Katz 2 Internet Draft Juniper Networks 3 D. Ward 4 Cisco Systems 5 Category: Informational May, 2004 6 Expires: November, 2004 8 Bidirectional Forwarding Detection 9 draft-katz-ward-bfd-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes a protocol intended to detect faults in the 39 bidirectional path between two forwarding engines, including 40 interfaces, data link(s), and to the extent possible the forwarding 41 engines themselves, with potentially very low latency. It operates 42 independently of media, data protocols, and routing protocols. 43 Comments on this draft should be directed to rtg-bfd@ietf.org. 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 forwarding 94 plane next hop. It is intended to be implemented in some component 95 of the forwarding engine of a system, in cases where the forwarding 96 and control engines are separated. This not only binds the protocol 97 more to the forwarding plane, but decouples the protocol from the 98 fate of the routing protocol engine (making it useful in concert with 99 various "graceful restart" mechanisms for those protocols.) BFD may 100 also be implemented in the control engine, though doing so may 101 preclude the detection of some kinds of failures. 103 BFD operates on top of any data protocol being forwarded between two 104 systems. It is always run in a unicast, point-to-point mode. BFD 105 packets are carried as the payload of whatever encapsulating protocol 106 is appropriate for the medium and network. BFD may be running at 107 multiple layers in a system. The context of the operation of any 108 particular BFD session is bound to its encapsulation. 110 BFD can provide failure detection on any kind of path between 111 systems, including direct physical links, virtual circuits, tunnels, 112 MPLS LSPs, multihop routed paths, and unidirectional links (so long 113 as there is some return path, of course.) Multiple BFD sessions can 114 be established between the same pair of systems when multiple paths 115 between them are present in at least one direction, even if a lesser 116 number of paths are available in the other direction (multiple 117 parallel unidirectional links or MPLS LSPs, for example.) 119 The BFD state machine implements a three-way handshake, both when 120 establishing a BFD session and when tearing it down for any reason, 121 to ensure that both systems are aware of the state change. 123 BFD can be abstracted as a simple service. The service primitives 124 provided by BFD are to create, destroy, and modify a session, given 125 the destination address and other parameters. BFD in return provides 126 a signal to its clients indicating when the BFD session goes up or 127 down. 129 3. Protocol Overview 131 BFD is a simple, fixed-field, hello protocol that in many respects is 132 similar to the detection components of well-known routing protocols. 133 A pair of systems transmit BFD packets periodically over each path 134 between the two systems, and if a system stops receiving BFD packets 135 for long enough, some component in that particular bidirectional path 136 to the neighboring system is assumed to have failed. Under some 137 conditions, systems may negotiate to not send periodic BFD packets in 138 order to reduce overhead. 140 A path is only declared to be operational when two-way communication 141 has been established between systems (though this does not preclude 142 the use of unidirectional links.) 144 A separate BFD session is created for each communications path and 145 data protocol in use between two systems. 147 Each system estimates how quickly it can send and receive BFD packets 148 in order to come to an agreement with its neighbor about how rapidly 149 detection of failure will take place. These estimates can be 150 modified in real time in order to adapt to unusual situations. This 151 design also allows for fast systems on a shared medium with a slow 152 system to be able to more rapidly detect failures between the fast 153 systems while allowing the slow system to participate to the best of 154 its ability. 156 3.1. Addressing and Session Establishment 158 A BFD session is established based on the needs of the application 159 that will be making use of it. It is up to the application to 160 determine the need for BFD, and the addresses to use--there is no 161 discovery mechanism in BFD. For example, an OSPF implementation may 162 request a BFD session to be established to a neighbor discovered 163 using the OSPF Hello protocol. 165 3.2. Operating Modes 167 BFD has two operating modes which may be selected, as well as an 168 additional function that can be used in combination with the two 169 modes. 171 The primary mode is known as Asynchronous mode. In this mode, the 172 systems periodically send BFD Control packets to one another, and if 173 a number of those packets in a row are not received by the other 174 system, the session is declared to be down. 176 The second mode is known as Demand mode. In this mode, it is assumed 177 that each system has an independent way of verifying that it has 178 connectivity to the other system, so once a BFD session is 179 established, the systems stop sending BFD Control packets, except 180 when either system feels the need to verify connectivity explicitly, 181 in which case a short sequence of BFD Control packets is sent, and 182 then the protocol quiesces. 184 An adjunct to both modes is the Echo function. When the Echo 185 function is active, a stream of BFD Echo packets is transmitted in 186 such a way as to have the other system loop them back through its 187 forwarding path. If a number of packets in a row of the echoed data 188 stream are not received, the session is declared to be down. The 189 Echo function may be used with either Asynchronous or Demand modes. 190 Since the Echo function is handling the task of detection, the rate 191 of periodic transmission of Control packets may be reduced (in the 192 case of Asynchronous mode) or eliminated completely (in the case of 193 Demand mode.) 195 Pure asynchronous mode is advantageous in that it requires half as 196 many packets to achieve a particular detection time as does the Echo 197 function. It is also used when the Echo function cannot be supported 198 for some reason. 200 The Echo function has the advantage of truly testing only the 201 forwarding path on the remote system, which may reduce round-trip 202 jitter and thus allow more aggressive detection times, as well as 203 potentially detecting some classes of failure that might not 204 otherwise be detected. 206 The Echo function may be enabled individually in each direction. It 207 is enabled in a particular direction only when the system that loops 208 the Echo packets back signals that it will allow it, and when the 209 system that sends the Echo packets decides it wishes to. 211 Demand mode is useful in situations where the overhead of a periodic 212 protocol might prove onerous, such as a system with a very large 213 number of BFD sessions. It is also useful when the Echo function is 214 being used symmetrically. Demand mode has the disadvantage that 215 detection times are essentially driven by the heuristics of the 216 system implementation and are not known to the BFD protocol. Demand 217 mode also may not be used when the path round trip time is greater 218 than the desired detection time. See section 6.4 for more details. 220 4. BFD Control Packet Format 222 BFD Control packets are sent in an encapsulation appropriate to the 223 environment, which is outside of the scope of this document. See the 224 appropriate application document for encapsulation details. 226 The payload of a BFD Control packet has the following format: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |Vers | Diag |H|D|P|F|C|Rsvd | Detect Mult | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | My Discriminator | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Your Discriminator | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Desired Min TX Interval | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Required Min RX Interval | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Required Min Echo RX Interval | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Version (Vers) 246 The version number of the protocol. This document defines 247 protocol version 0. 249 Diagnostic (Diag) 251 A diagnostic code specifying the local system's reason for the 252 last transition of the session from Up to some other state. 253 Values are: 255 0 -- No Diagnostic 256 1 -- Control Detection Time Expired 257 2 -- Echo Function Failed 258 3 -- Neighbor Signaled Session Down 259 4 -- Forwarding Plane Reset 260 5 -- Path Down 261 6 -- Concatenated Path Down 262 7 -- Administratively Down 263 8-31 -- Reserved for future use 265 This field allows remote systems to determine the reason that the 266 previous session failed, for example. 268 I Hear You (H) 270 This bit is set to 0 if the transmitting system either is not 271 receiving BFD packets from the remote system, or is in the process 272 of tearing down the BFD session for some reason. This bit is set 273 to 1 if the transmitting system believes it is communicating with 274 the remote system. See the Elements of Procedure below for more 275 details. 277 Demand (D) 279 If set, the transmitting system wishes to operate in Demand Mode. 280 If clear, the transmitting system does not wish to or is not 281 capable of operating in Demand Mode. 283 Poll (P) 285 If set, the transmitting system is requesting verification of 286 connectivity, or of a parameter change. If clear, the 287 transmitting system is not requesting verification. 289 Final (F) 291 If set, the transmitting system is responding to a received BFD 292 Control packet that had the Poll (P) bit set. If clear, the 293 transmitting system is not responding to a Poll. 295 Control Plane Independent (C) 297 If set, the transmitting system's BFD implementation does not 298 share fate with its control plane (in other words, BFD is 299 implemented in the forwarding plane and can continue to function 300 through disruptions in the control plane.) If clear, the 301 transmitting system's BFD implementation shares fate with its 302 control plane. 304 The use of this bit is application dependent and is outside the 305 scope of this specification. See specific application 306 specifications for details. 308 Reserved (Rsvd) 310 These bits must be zero on transmit, and ignored on receipt. 312 Detect Mult 314 Detect time multiplier. The negotiated transmit interval, 315 multiplied by this value, provides the detection time for the 316 transmitting system in Asynchronous mode. 318 Length 320 Length of the BFD Control packet, in bytes. 322 My Discriminator 324 A unique, nonzero discriminator value generated by the 325 transmitting system, used to demultiplex multiple BFD sessions 326 between the same pair of systems. 328 Your Discriminator 330 The discriminator received from the corresponding remote system. 331 This field reflects back the received value of My Discriminator, 332 or is zero if that value is unknown. 334 Desired Min TX Interval 336 This is the minimum interval, in microseconds, that the local 337 system would like to use when transmitting BFD Control packets. 339 Required Min RX Interval 341 This is the minimum interval, in microseconds, between received 342 BFD Control packets that this system is capable of supporting. 344 Required Min Echo RX Interval 346 This is the minimum interval, in microseconds, between received 347 BFD Echo packets that this system is capable of supporting. If 348 this value is zero, the transmitting system does not support the 349 receipt of BFD Echo packets. 351 5. BFD Echo Packet Format 353 BFD Echo packets are sent in an encapsulation appropriate to the 354 environment. See the appropriate application document for the 355 specifics of particular environments. 357 The payload of a BFD Echo packet is a local matter, since only the 358 sending system ever processes the content. The only requirement is 359 that sufficient information is included to demultiplex the received 360 packet to the correct BFD session after it is looped back to the 361 sender. The contents are otherwise outside the scope of this 362 specification. 364 6. Elements of Procedure 366 This section discusses the normative requirements of the protocol in 367 order to achieve interoperability. It is important for implementors 368 to enforce only the requirements specified in this section, as 369 misguided pedantry has been proven by experience to adversely affect 370 interoperability. 372 Remember that all references of the form "bfd.Xx" refer to internal 373 state variables (defined in section 6.5.1), whereas all references to 374 "the Xxx field" refer to fields in the protocol packets themselves 375 (defined in section 6.4). 377 6.1. Overview 379 A system may take either an Active role or a Passive role in session 380 initialization. A system taking the Active role MUST send BFD 381 Control packets for a particular session, regardless of whether it 382 has received any BFD packets for that session. A system taking the 383 Passive role MUST NOT begin sending BFD packets for a particular 384 session until it has received a BFD packet for that session, and thus 385 has learned the remote system's discriminator value. At least one 386 system MUST take the Active role (possibly both.) The role that a 387 system takes is specific to the application of BFD, and is outside 388 the scope of this specification. 390 A session begins with the periodic, slow transmission of BFD Control 391 packets. When bidirectional communication is achieved (by virtue of 392 the I Hear You field being nonzero in both directions, a three way 393 handshake), the BFD session comes up. 395 Once the BFD session is Up, a system can choose to start the Echo 396 function if it desires to and the other system signals that it will 397 allow it. The rate of transmission of Control packets is typically 398 kept low when the Echo function is active. 400 If the Echo function is not active, the transmission rate of Control 401 packets may be increased to a level necessary to achieve the 402 detection time requirements for the session. 404 If both systems signal that they want to use Demand mode, the 405 transmission of BFD Control packets ceases once the session is Up. 406 Other means of implying connectivity are used to keep the session 407 alive. If one of the systems wishes to verify connectivity, it can 408 initiate a short exchange (a "Poll Sequence") of BFD Control packets 409 to verify this. 411 If Demand mode is not active, and no Control packets are received in 412 the calculated detection time, the session is declared down, and 413 signalled to the remote end by sending a zero value in the I Hear You 414 field in outgoing packets. 416 If sufficient Echo packets are lost, the session is declared down in 417 the same manner. 419 If Demand mode is active and no appropriate Control packets are 420 received in response to a Poll Sequence, the session is declared down 421 in the same manner. 423 If the session goes down, the transmission of Echo packets (if any) 424 ceases, and the transmission of Control packets goes back to the slow 425 rate. 427 Once a session has been declared down, it cannot come back up until 428 the remote end first signals that it is down (by setting its outgoing 429 I Hear You field to zero), thus implementing a three-way handshake. 431 A session may be kept administratively down by always setting its 432 outgoing I Hear You field to zero, and sending an explanatory 433 diagnostic code in the Diagnostic field. 435 6.2. Demultiplexing and the Discriminator Fields 437 Since multiple BFD sessions may be running between two systems, there 438 needs to be a mechanism for demultiplexing received BFD packets to 439 the proper session. 441 Each system MUST choose an opaque discriminator value that identifies 442 each session, and which MUST be unique among all BFD sessions on the 443 system. The local discriminator is sent in the My Discriminator 444 field in the BFD Control packet, and is echoed back in the Your 445 Discriminator field of packets sent from the remote end. 447 Once the remote end echoes back the local discriminator, all further 448 received packets are demultiplexed based on the Your Discriminator 449 field only (which means that, among other things, the source address 450 field can change or the interface over which the packets are received 451 can change, but the packets will still be associated with the proper 452 session.) 454 The method of demultiplexing the initial packets (in which Your 455 Discriminator is zero) is application-dependent, and is thus outside 456 the scope of this specification. 458 Note that it is permissible for a system to change its discriminator 459 during a session (without affecting the session state), since only 460 that system uses its discriminator for demultiplexing purposes (by 461 having the other system reflect it back.) The implications on an 462 implementation for changing the discriminator value is outside the 463 scope of this specification. 465 6.3. The Echo Function and Asymmetry 467 The Echo function can be run independently in each direction between 468 a pair of systems. For whatever reason, a system may advertise that 469 it is willing to receive (and loop back) Echo packets, but may not 470 wish to ever send any. The fact that a system is sending Echo 471 packets is not directly signalled to the system looping them back. 473 When a system is using the Echo function, it is advantageous to 474 choose a sedate transmission rate for Control packets, since liveness 475 detection is being handled by the Echo packets. This can be 476 controlled by manipulating the Desired Min TX Interval field (see 477 section 6.5.3.) 479 If the Echo function is only being run in one direction, the system 480 not running the Echo function will more likely wish to send fairly 481 rapid Control packets in order to achieve its desired detection time. 483 Since BFD allows independent transmission rates in each direction, 484 this is easily accomplished. 486 A system SHOULD always advertise the lowest value of Required Min RX 487 Interval and Required Min Echo RX Interval that it can under the 488 circumstances, to give the other system more freedom in choosing its 489 transmission rate. Note that a system is committing to be able to 490 receive both streams of packets at the rate it advertises, so this 491 should be taken into account when choosing the values to advertise. 493 6.4. Demand Mode 495 Demand mode is negotiated by virtue of both systems setting the 496 Demand (D) bit in its BFD Control packets. Both systems must request 497 Demand mode for it to become active. 499 Demand mode requires that some other mechanism is used to imply 500 continuing connectivity between the two systems. The mechanism used 501 does not have to be the same in both directions, and is outside of 502 the scope of this specification. One possible mechanism is the 503 receipt of traffic from the remote system; another is the use of the 504 Echo function. 506 Once a BFD session comes up, if Demand mode is active, both systems 507 stop sending periodic BFD Control packets, and depend on the 508 alternative mechanism for maintaining ongoing connectivity. 510 When a system wishes to verify connectivity, it initiates a Poll 511 Sequence. It starts periodically sending BFD Control packets with 512 the Poll (P) bit set, at the negotiated transmission rate. When a 513 system receives such a packet, it immediately replies with a BFD 514 Control packet of its own, with the Poll (P) bit clear, and the Final 515 (F) bit set. The receipt of a reply to a Poll terminates the Poll 516 Sequence. If no response is received to a Poll, the Poll is repeated 517 until the detection time expires, at which point the session is 518 declared to be down. 520 The detection time in Demand mode is calculated differently than in 521 Asynchronous mode; it is based on the transmit rate of the local 522 system, rather than the transmit rate of the remote system. This 523 ensures that the Poll Sequence mechanism works properly. See section 524 6.5.8 for more details. 526 Note that this mechanism requires that the detection time negotiated 527 is greater than the round trip time between the two systems, or the 528 Poll mechanism will always fail. Enforcement of this requirement is 529 outside the scope of this specification. 531 Demand mode MAY be enabled or disabled at any time by setting or 532 clearing the Demand (D) bit in the BFD Control packet, without 533 affecting the BFD session state. 535 Because the underlying detection mechanism is unspecified, and may 536 differ between the two systems, the overall detection time 537 characteristics of the path will not be fully known to either system. 538 The total detection time for a particular system is the sum of the 539 time prior to the initiation of the Poll Sequence, plus the 540 calculated detection time. 542 6.5. Functional Specifics 544 The following section of this specification is normative. The means 545 by which this specification is achieved is outside the scope of this 546 specification. 548 When a system is said to have "the Echo function active," it means 549 that the system is sending BFD Echo packets, implying that the 550 session is Up and the other system has signalled its willingness to 551 loop back Echo packets. 553 When a system is said to have "Demand mode active," it means that 554 bfd.DemandModeDesired is 1 in the local system (see State Variables 555 below), the remote system is signalling with the Demand (D) bit set, 556 and that the session is Up. 558 6.5.1. State Variables 560 A minimum amount of information about a session needs to be tracked 561 in order to achieve the elements of procedure described here. The 562 following is a set of state variables that are helpful in describing 563 the mechanisms of BFD. Any means of tracking this state may be used 564 so long as the protocol behaves as described. 566 All state variables in this specification are of the form "bfd.Xx" 567 and should not be confused with fields carried in the protocol 568 packets, which are always spelled out to match the names in section 569 4. 571 bfd.SessionState 573 The perceived state of the session (Init, Up, Failing, Down, or 574 AdminDown.) The exact action taken when the session state 575 changes is outside the scope of this specification, though it 576 is expected that this state change (particularly to and from Up 577 state) is reported to other components of the system. This 578 variable MUST be initialized to Failing. 580 bfd.LocalDiscr 582 The local discriminator for this BFD session, used to uniquely 583 identify it. It MUST be unique on this system, and nonzero. 584 The value is otherwise outside the scope of this specification. 586 bfd.RemoteDiscr 588 The remote discriminator for this BFD session. This is the 589 discriminator chosen by the remote system, and is totally 590 opaque to the local system. This MUST be initialized to zero. 592 bfd.RemoteHeard 594 This variable is set to 1 if the local system is actively 595 receiving BFD packets from the remote system, and is set to 0 596 if the local system has not received BFD packets recently 597 (within the detection time) or if the local system is 598 attempting to tear down the BFD session. This MUST be 599 initialized to zero. 601 bfd.LocalDiag 603 The diagnostic code specifying the reason the local session 604 state most recently transitioned from Up to some other state. 605 This MUST be initialized to zero (No Diagnostic.) 607 bfd.DesiredMinTxInterval 609 The minimum interval, in microseconds, between transmitted BFD 610 Control packets that this system would like to use at the 611 current time. The actual interval is negotiated between the 612 two systems. This MUST be initialized to a value of at least 613 one second (1,000,000 microseconds) according to the rules 614 described in section 6.5.3. The setting of this variable is 615 otherwise outside the scope of this specification. 617 bfd.RequiredMinRxInterval 619 The minimum interval, in microseconds, between received BFD 620 Control packets that this system requires. The setting of this 621 variable is outside the scope of this specification. 623 bfd.DemandModeDesired 625 Set to 1 if the local system wishes to use Demand mode, or 0 if 626 not. 628 bfd.DetectMult 630 The desired detect time multiplier for BFD Control packets. 631 The negotiated Control packet transmission interval, multiplied 632 by this variable, will be the detection time for this session 633 (as seen by the remote system.) This variable MUST be a 634 nonzero integer, and is otherwise outside the scope of this 635 specification. See section 6.5.4 for further information. 637 6.5.2. Timer Negotiation 639 The time values used to determine BFD packet transmission intervals 640 and the session detection time are continuously negotiated, and thus 641 may be changed at any time. The negotiation and time values are 642 independent in each direction for each session. Packets are always 643 periodically transmitted in Asynchronous mode, and are periodically 644 transmitted during Poll Sequences when in Demand mode. 646 Each system reports in the BFD Control packet how rapidly it would 647 like to transmit BFD packets, as well as how rapidly it is prepared 648 to receive them. With the exceptions listed in the remainder of this 649 section, a system MUST NOT transmit BFD Control packets with an 650 interval less than the larger of bfd.DesiredMinTxInterval and the 651 received Required Min RX Interval field. In other words, the system 652 reporting the slower rate determines the transmission rate. 654 The periodic transmission of BFD Control packets SHOULD be jittered 655 by up to 25%, that is, the interval SHOULD be reduced by a random 656 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 657 average interval between packets may be up to 12.5% less than that 658 negotiated. 660 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 661 Control packets MUST be no more than 90% of the negotiated 662 transmission interval, and MUST be no less than 75% of the negotiated 663 transmission interval. This is to ensure that, on the remote system, 664 the calculated DetectTime does not pass prior to the receipt of the 665 next BFD Control packet. 667 An extra, single BFD Control packet SHOULD be transmitted during the 668 interval between periodic Control packet transmissions if there is a 669 state change that needs to be communicated, in order to more rapidly 670 converge. (For example, if the local system determines that the BFD 671 session has gone down, it SHOULD communicate this without waiting for 672 the next periodic transmission.) With the exception listed in the 673 next paragraph, once such an extra packet has been transmitted, a 674 system MUST NOT send another BFD Control packet until the next 675 scheduled transmission. 677 If a BFD Control packet is received with the Poll (P) bit set to 1, 678 the receiving system MUST transmit a BFD Control packet with the Poll 679 (P) bit clear and the Final (F) bit set as soon as practicable, 680 without respect to the transmission timer or any other transmission 681 limitations, and without respect to whether Demand mode is active. 683 6.5.3. Timer Manipulation 685 The time values used to determine BFD packet transmission intervals 686 and the session detection time may be modified at any time without 687 affecting the state of the session. When the timer parameters are 688 changed for any reason, the requirements of this section apply. 690 If Demand mode is active, and either bfd.DesiredMinTxInterval is 691 changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST 692 be initiated (see section 6.5.8). 694 If Demand mode is not active, and either bfd.DesiredMinTxInterval is 695 changed or bfd.RequiredMinRxInterval is changed, all subsequent 696 transmitted Control packets MUST be sent with the Poll (P) bit set 697 until a packet is received with the Final (F) bit set. 699 If bfd.DesiredMinTxInterval is increased, the actual transmission 700 interval used MUST NOT change until a Control packet is received with 701 the Final (F) bit set. This is to ensure that the remote system 702 updates its Detect Time before the transmission interval increases. 704 If bfd.RequiredMinRxInterval is reduced, the calculated detection 705 time for the remote system MUST NOT change until a Control packet is 706 received with the Final (F) bit set. This is to ensure that the 707 remote system is transmitting packets at the higher rate (and those 708 packets are being received) prior to the detection time being 709 reduced. 711 When bfd.SessionState is not Up, the system MUST set 712 bfd.DesiredMinTxInterval to a value of not less than one second 713 (1,000,000 microseconds.) This is intended to ensure that the 714 bandwidth consumed by BFD sessions that are not Up is negligible, 715 particularly in the case where a neighbor may not be running BFD. 717 When the Echo function is active, a system SHOULD set 718 bfd.DesiredMinTxInterval to a value of not less than one second 719 (1,000,000 microseconds.) This is intended to keep BFD Control 720 traffic at a negligible level, since the actual detection function is 721 being performed using BFD Echo packets. 723 6.5.4. Calculating the Detection Time 725 The Detection Time (the period of time without receiving BFD packets 726 after which the session is determined to have failed) is not carried 727 explicitly in the protocol. Rather, it is calculated independently 728 in each direction by the receiving system based on the negotiated 729 transmit interval and the detection multiplier. Note that, in 730 Asynchronous mode, there may be different detection times in each 731 direction. 733 The calculation of the Detection Time is slightly different when in 734 Demand mode versus Asynchronous mode. 736 In Asynchronous mode, the Detection Time calculated in the local 737 system is equal to the value of Detect Mult received from the remote 738 system, multiplied by the agreed transmit interval (the greater of 739 bfd.RequiredMinRxInterval and the last received Desired Min TX 740 Interval.) The Detect Mult value is (roughly speaking, due to 741 jitter) the number of packets that have to be missed in a row to 742 declare the session to be down. 744 If Demand mode is not active, and a period of time equal to the 745 Detection Time passes without receiving a BFD Control packet from the 746 remote system, and bfd.SessionState is Init or Up, the session has 747 gone down--the local system MUST set bfd.SessionState to Failing, 748 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 749 Time Expired.) The timeout in Init state is to avoid a potential 750 deadlock in which one system is in Failing state and the other is in 751 Init state (which could happen if a packet were lost at the right 752 time.) 754 In Demand mode, the Detection Time calculated in the local system is 755 equal to bfd.DetectMult, multiplied by the agreed transmit interval 756 (the greater of bfd.RequiredMinRxInterval and the last received 757 Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due 758 to jitter) the number of packets that have to be missed in a row to 759 declare the session to be down. 761 If Demand mode is active, and a period of time equal to the Detection 762 Time passes after the initiation of a Poll Sequence (the transmission 763 of the first BFD Control packet with the Poll bit set), the session 764 has gone down--the local system MUST set bfd.SessionState to Failing, 765 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 766 Time Expired.) 768 (Note that a packet is considered to have been received, for the 769 purposes of Detection Time expiration, only if it has not been 770 "discarded" according to the rules of section 6.5.6.) 772 6.5.5. Detecting Failures with the Echo Function 774 When the Echo function is active and a sufficient number of Echo 775 packets have not arrived as they should, the session has gone 776 down--the local system MUST set bfd.SessionState to Failing, 777 bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function 778 Failed.) 780 The means by which the Echo function failures are detected is outside 781 of the scope of this specification. Any means which will detect a 782 communication failure is acceptable. 784 6.5.6. Reception of BFD Control Packets 786 When a BFD Control packet is received, the following procedure MUST 787 be followed, in the order specified: 789 If the version number is not correct (0), the packet MUST be 790 discarded. 792 If the Length field is less than the correct value (24), the 793 packet MUST be discarded. 795 If the Length field is greater than the payload of the 796 encapsulating protocol, the packet MUST be discarded. 798 If the Detect Mult field is zero, the packet MUST be discarded. 800 If the My Discriminator field is zero, the packet MUST be 801 discarded. 803 If the Your Discriminator field is nonzero, it MUST be used to 804 select the session with which this BFD packet is associated. If 805 no session is found, the packet MUST be discarded. 807 If the Your Discriminator field is zero and the I Hear You field 808 is nonzero, the packet MUST be discarded. 810 If the Your Discriminator field is zero, the session MUST be 811 selected based on some combination of other fields, possibly 812 including source addressing information, the My Discriminator 813 field, and the interface over which the packet was received. The 814 exact method of selection is application-specific and is thus 815 outside the scope of this specification. If a matching session is 816 not found, a new session may be created, or the packet may be 817 discarded. This choice is outside the scope of this 818 specification. 820 Set bfd.RemoteDiscr to the value of My Discriminator. 822 If the Required Min Echo RX Interval field is zero, the 823 transmission of Echo packets, if any, MUST cease. 825 If Demand mode is active, a Poll Sequence is being transmitted by 826 the local system, and the Final (F) bit in the received packet is 827 set, the Poll Sequence MUST be terminated. 829 If Demand mode is not active, the Final (F) bit in the received 830 packet is set, and the local system has been transmitting packets 831 with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in 832 subsequent transmitted packets. 834 Update the Detection Time as described in section 6.5.4. 836 If bfd.SessionState is Down 837 Set bfd.RemoteHeard to 1 838 If I Hear You is zero 839 Set bfd.SessionState to Init 840 Else 841 Set bfd.SessionState to Up 843 Else if bfd.SessionState is AdminDown 844 Discard the packet 846 Else if bfd.SessionState is Init 847 If I Hear You is nonzero 848 Set bfd.SessionState to Up 849 Else 850 Discard the packet 852 Else if bfd.SessionState is Up 853 If I Hear You is zero 854 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 855 Set bfd.SessionState to Failing 856 Set bfd.RemoteHeard to 0 858 Else if bfd.SessionState is Failing 859 If I Hear You is zero, set bfd.SessionState to Down 861 Update the transmit interval as described in section 6.5.2. 863 If the Demand (D) bit is set and bfd.DemandModeDesired is 1, 864 and bfd.SessionState is Up, Demand mode is active. 866 If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, 867 or bfd.SessionState is not Up, Demand mode is not 868 active. 870 If the Poll (P) bit is set, send a BFD Control packet to the 871 remote system with the Poll (P) bit clear, and the Final (F) bit 872 set. 874 If the packet was not discarded, it has been received for purposes of 875 the Detection Time expiration rules in section 6.5.4. 877 6.5.7. Transmitting BFD Control Packets 879 BFD Control packets MUST be transmitted periodically at the rate 880 determined according to section 6.5.2, except as specified in this 881 section. 883 The transmit interval MUST be recalculated whenever 884 bfd.DesiredMinTxInterval changes, or whenever the received Required 885 Min RX Interval changes, and is equal to the greater of those two 886 values. See sections 6.5.2 and 6.5.3 for details on transmit timers. 888 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 889 zero and the system is taking the Passive role. 891 A system MUST NOT periodically transmit BFD Control packets if Demand 892 mode is active and a Poll Sequence is not being transmitted. 894 A system MUST send a BFD Control packet in response to a received BFD 895 Control Packet with the Poll (P) bit set. The packet sent in 896 response MUST NOT have the Poll (P) bit set, and MUST have the Final 897 (F) bit set. 899 A single BFD Control packet SHOULD be transmitted between normally 900 scheduled transmissions when the contents of that packet would differ 901 from those in the previously transmitted packet (other than the Poll 902 and Final bits) in order to more rapidly communicate a change in 903 state. 905 The contents of transmitted BFD Control packets MUST be set as 906 follows: 908 Version 910 Set to the current version number (0). 912 Diagnostic (Diag) 914 Set to bfd.LocalDiag. 916 I Hear You (H) 918 Set to bfd.RemoteHeard. 920 Demand (D) 922 Set to bfd.DemandModeDesired. 924 Poll (P) 926 Set to 1 if the local system is sending a Poll Sequence or is 927 required to do so according to the requirements of section 6.5.3, 928 or 0 if not. 930 Final (F) 932 Set to 1 if the local system is responding to a Control packet 933 received with the Poll (P) bit set, or 0 if not. 935 Control Plane Independent (C) 937 Set to 1 if the local system's BFD implementation is independent 938 of the control plane (it can continue to function through a 939 disruption of the control plane.) 941 Reserved (Rsvd) 943 Set to 0. 945 Detect Mult 947 Set to bfd.DetectMult. 949 Length 951 Set to 24. 953 My Discriminator 955 Set to bfd.LocalDiscr. 957 Your Discriminator 959 Set to bfd.RemoteDiscr. 961 Desired Min TX Interval 963 Set to bfd.DesiredMinTxInterval. 965 Required Min RX Interval 967 Set to bfd.RequiredMinRxInterval. 969 Required Min Echo RX Interval 971 Set to the minimum required Echo packet receive interval for this 972 session. If this field is set to zero, the local system is 973 unwilling or unable to loop back BFD Echo packets to the remote 974 system, and the remote system will not send Echo packets. 976 6.5.8. Initiation of a Poll Sequence 978 If Demand mode is active, a Poll Sequence MUST be initiated whenever 979 the contents of the next BFD Control packet to be sent would be 980 different than the contents of the previous packet, with the 981 exception of the Poll (P) and Final (F) bits. This ensures that 982 parameter changes are transmitted to the remote system. Note that if 983 the I Hear You (H) bit is changing to zero, the session is going down 984 and Demand mode will no longer be active. 986 If Demand mode is active, a Poll Sequence SHOULD be initiated 987 whenever the system feels the need to verify connectivity with the 988 remote system. The conditions under which this is desirable are 989 outside the scope of this specification. 991 If a Poll Sequence is being sent, and a new Poll Sequence is 992 initiated due to one of the above conditions, the detection interval 993 MUST be restarted in order to ensure that a full Poll Sequence is 994 transmitted under the new conditions. 996 6.5.9. Reception of BFD Echo Packets 998 A received BFD Echo packet MUST be demultiplexed to the appropriate 999 session for processing. A means of detecting missing Echo packets 1000 MUST be implemented, which most likely involves processing of the 1001 Echo packets that are received. The processing of received Echo 1002 packets is otherwise outside the scope of this specification. 1004 6.5.10. Transmission of BFD Echo Packets 1006 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1007 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1008 Control packet received from the remote system contains a nonzero 1009 value in Required Min Echo RX Interval. 1011 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1012 interval between transmitted BFD Echo packets MUST NOT be less than 1013 the value advertised by the remote system in Required Min Echo RX 1014 Interval, except as follows: 1016 A 25% jitter MAY be applied to the rate of transmission, such that 1017 the actual interval MAY be between 75% and 100% of the advertised 1018 value. A single BFD Echo packet MAY be transmitted between 1019 normally scheduled Echo transmission intervals. 1021 The transmission of BFD Echo packets is otherwise outside the scope 1022 of this specification. 1024 6.5.11. Min Rx Interval Change 1026 When it is desired to change the rate at which BFD Control packets 1027 arrive from the remote system, bfd.RequiredMinRxInterval can be 1028 changed at any time to any value. The new value will be transmitted 1029 in the next outgoing Control packet, and the remote system will 1030 adjust accordingly. See sections 6.5.3 and 6.5.8 for further 1031 requirements. 1033 6.5.12. Min Tx Interval Change 1035 When it is desired to change the rate at which BFD Control packets 1036 are transmitted to the remote system (subject to the requirements of 1037 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1038 any time to any value. The rules in sections 6.5.3 and 6.5.8 apply. 1040 6.5.13. Detect Multiplier Change 1042 When it is desired to change the detect multiplier, the value of 1043 bfd.DetectMult can be changed to any nonzero value. The new value 1044 will be transmitted with the next BFD Control packet. See section 1045 6.5.8 for additional requirements. 1047 6.5.14. Enabling or Disabling The Echo Function 1049 If it is desired to start or stop the transmission of BFD Echo 1050 packets, this MAY be done at any time (subject to the transmission 1051 requirements detailed in section 6.5.10.) 1053 If it is desired to enable or disable the looping back of received 1054 BFD Echo packets, this MAY be done at any time by changing the value 1055 of Required Min RX Interval to zero or nonzero in outgoing BFD 1056 Control packets. 1058 6.5.15. Enabling or Disabling Demand Mode 1060 If it is desired to start or stop Demand mode, this MAY be done at 1061 any time by setting bfd.DemandModeDesired to the proper value. If 1062 Demand mode is no longer active, the system MUST begin transmitting 1063 periodic BFD Control packets as described in section 6.5.7. 1065 6.5.16. Forwarding Plane Reset 1067 When the forwarding plane in the local system is reset for some 1068 reason, such that the remote system can no longer rely on the local 1069 forwarding state, the local system MUST set bfd.LocalDiag to 4 1070 (Forwarding Plane Reset), set bfd.SessionState to Failing, and set 1071 bfd.RemoteHeard to zero. 1073 6.5.17. Administrative Control 1075 There may be circumstances where it is desirable to administratively 1076 enable or disable a BFD session. When this is desired, the following 1077 procedure MUST be followed: 1079 If enabling session 1080 Set bfd.SessionState to Failing 1081 Set bfd.RemoteHeard to zero 1083 Else 1084 Set bfd.SessionState to AdminDown 1085 Set bfd.RemoteHeard to zero 1086 Set bfd.LocalDiag to an appropriate value 1087 Cease the transmission of BFD Echo packets 1089 Specific diagnostic codes are provided for two scenarios. 1091 If signalling is received from outside BFD that the underlying path 1092 has failed, an implementation MAY adminstratively disable the session 1093 with the diagnostic Path Down. 1095 If the path being monitored by BFD is concatenated with other paths, 1096 it may be desirable to administratively bring down the BFD session 1097 when a concatenated path fails (as a way of propagating the 1098 failure indication.) In this case, an implementation MAY 1099 administratively disable the BFD session with the diagnostic 1100 Concatenated Path Down. 1102 Other scenarios MAY use the diagnostic Administratively Down. 1104 Contributors 1106 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 1107 significant contributors to this document. 1109 Acknowledgments 1111 This document was inspired by (and is intended to replace) the 1112 Protocol Liveness Protocol draft, written by Kireeti Kompella. 1114 Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 1115 et al. 1117 The authors would also like to thank Mike Shand, John Scudder, 1118 Stewart Bryant, and Pekka Savola for their substantive input. 1120 Authors' Addresses 1122 Dave Katz 1123 Juniper Networks 1124 1194 N. Mathilda Ave. 1125 Sunnyvale, California 94089-1206 USA 1126 Phone: +1-408-745-2000 1127 Email: dkatz@juniper.net 1129 Dave Ward 1130 Cisco Systems 1131 170 W. Tasman Dr. 1132 San Jose, CA 95134 USA 1133 Phone: +1-408-526-4000 1134 Email: dward@cisco.com 1136 Changes from the previous draft 1138 The primary technical change in this draft from the previous version 1139 is to allow a system to change its discriminator, by eliminating the 1140 sanity check in the packet reception rules. This has the side effect 1141 of also allowing the removal of the requirement to clear the remote 1142 discriminator after a session goes down. Although this change is not 1143 backward compatible, it is small enough to not warrant a change in 1144 the version number (since systems will interoperate properly so long 1145 as they do not change their discriminator, and if they do this will 1146 result in only a session flap. 1148 The Control Plane Independent (C) bit was added in this draft to 1149 facilitate interactions with OSPF and IS-IS Graceful Restart 1150 functions in the accompanying application draft. 1152 Otherwise, the changes in this draft from the previous version are 1153 cosmetic and/or editorial. 1155 Normative References 1157 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1158 Requirement Levels", RFC 2119, March 1997. 1160 Security Considerations 1162 When BFD is run over network layer protocols, a significant denial- 1163 of-service risk is created, as BFD packets may be trivial to spoof. 1164 When the session is directly connected across a single link 1165 (physical, or a tunnel such as GRE or IPsec), the TTL or Hop Count 1166 MUST be set to the maximum on transmit, and checked to be equal to 1167 the maximum value on reception (and the packet dropped if this is not 1168 the case.) If BFD is run across multiple hops, some alternative 1169 mechanism MUST be used. One option would be to ensure that the 1170 network addresses used for BFD are not routable outside of the 1171 infrastructure in which BFD is running (and assuming there are no 1172 users connected within that network.) Another option would be to 1173 filter all packets carrying BFD's UDP ports at the edges of the 1174 network. Still another option would be to use cryptographic methods, 1175 though this is not likely to allow for very short detection times. 1176 Securing BFD in a routed, multiple hop environment is for further 1177 study. 1179 IPR Notice 1181 The IETF has been notified of intellectual property rights claimed in 1182 regard to some or all of the specification contained in this 1183 document. For more information consult the online list of claimed 1184 rights. 1186 The IETF takes no position regarding the validity or scope of any 1187 intellectual property or other rights that might be claimed to 1188 pertain to the implementation or use of the technology described in 1189 this document or the extent to which any license under such rights 1190 might or might not be available; neither does it represent that it 1191 has made any effort to identify any such rights. Information on the 1192 IETF's procedures with respect to rights in standards-track and 1193 standards-related documentation can be found in BCP-11. Copies of 1194 claims of rights made available for publication and any assurances of 1195 licenses to be made available, or the result of an attempt made to 1196 obtain a general license or permission for the use of such 1197 proprietary rights by implementors or users of this specification can 1198 be obtained from the IETF Secretariat. 1200 The IETF invites any interested party to bring to its attention any 1201 copyrights, patents or patent applications, or other proprietary 1202 rights which may cover technology that may be required to practice 1203 this standard. Please address the information to the IETF Executive 1204 Director. 1206 Full Copyright Notice 1208 Copyright (C) The Internet Society (2004). All Rights Reserved. 1210 This document and translations of it may be copied and furnished to 1211 others, and derivative works that comment on or otherwise explain it 1212 or assist in its implementation may be prepared, copied, published 1213 and distributed, in whole or in part, without restriction of any 1214 kind, provided that the above copyright notice and this paragraph are 1215 included on all such copies and derivative works. However, this 1216 document itself may not be modified in any way, such as by removing 1217 the copyright notice or references to the Internet Society or other 1218 Internet organizations, except as needed for the purpose of 1219 developing Internet standards in which case the procedures for 1220 copyrights defined in the Internet Standards process must be 1221 followed, or as required to translate it into languages other than 1222 English. 1224 The limited permissions granted above are perpetual and will not be 1225 revoked by the Internet Society or its successors or assigns. 1227 This document and the information contained herein is provided on an 1228 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1229 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1230 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1231 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1232 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1234 Acknowledgement 1236 Funding for the RFC Editor function is currently provided by the 1237 Internet Society.