--- 1/draft-ietf-bfd-base-01.txt 2006-02-04 22:51:07.000000000 +0100 +++ 2/draft-ietf-bfd-base-02.txt 2006-02-04 22:51:07.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems -Expires: August 2005 February, 2005 +Expires: September, 2005 March, 2005 Bidirectional Forwarding Detection - draft-ietf-bfd-base-01.txt + draft-ietf-bfd-base-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -61,44 +61,44 @@ 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 4.2 Simple Password Authentication Section Format . . . . . 11 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format . . . . . . . . . . . . . . . . . . . . . 12 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format . . . . . . . . . . . . . . . . . . . . . 13 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 14 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 15 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 16 - 6.3 Demultiplexing and the Discriminator Fields . . . . . . 17 + 6.3 Demultiplexing and the Discriminator Fields . . . . . . 18 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 18 - 6.5 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 18 - 6.6 Authentication . . . . . . . . . . . . . . . . . . . . . 19 + 6.5 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 19 + 6.6 Authentication . . . . . . . . . . . . . . . . . . . . . 20 6.6.1 Enabling and Disabling Authentication . . . . . . 20 - 6.6.2 Simple Password Authentication . . . . . . . . . . 20 - 6.6.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 21 + 6.6.2 Simple Password Authentication . . . . . . . . . . 21 + 6.6.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 22 6.6.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 23 - 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 24 + 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 25 6.7.1 State Variables . . . . . . . . . . . . . . . . . 25 - 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 27 - 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 28 - 6.7.4 Calculating the Detection Time . . . . . . . . . . 29 - 6.7.5 Detecting Failures with the Echo Function . . . . 30 - 6.7.6 Reception of BFD Control Packets . . . . . . . . . 30 + 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 28 + 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 29 + 6.7.4 Calculating the Detection Time . . . . . . . . . . 30 + 6.7.5 Detecting Failures with the Echo Function . . . . 31 + 6.7.6 Reception of BFD Control Packets . . . . . . . . . 31 6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33 - 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 35 + 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 36 6.7.9 Reception of BFD Echo Packets . . . . . . . . . . 36 6.7.10 Transmission of BFD Echo Packets . . . . . . . . 36 6.7.11 Min Rx Interval Change . . . . . . . . . . . . . 37 6.7.12 Min Tx Interval Change . . . . . . . . . . . . . 37 6.7.13 Detect Multiplier Change . . . . . . . . . . . . 37 6.7.14 Enabling or Disabling the Echo Function . . . . . 37 - 6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 37 + 6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 38 6.7.16 Forwarding Plane Reset . . . . . . . . . . . . . 38 6.7.17 Administrative Control . . . . . . . . . . . . . 38 6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 38 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 Security Considerations . . . . . . . . . . . . . . . . . . . . 39 Normative References . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 Changes from the previous draft . . . . . . . . . . . . . . . . 41 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 42 @@ -283,21 +283,21 @@ The BFD Control packet has a Mandatory Section and an optional Authentication Section. The format of the Authentication Section, if present, is dependent on the type of authentication in use. The Mandatory Section of a BFD Control packet has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Vers | Diag |H|D|P|F|C|A|Rsv| Detect Mult | Length | + |Vers | Diag |Sta|P|F|C|A|D|R| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | @@ -307,55 +307,50 @@ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Authentication Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (Vers) The version number of the protocol. This document defines - protocol version 0. + protocol version 1. Diagnostic (Diag) A diagnostic code specifying the local system's reason for the last session state change. Values are: 0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset 5 -- Path Down 6 -- Concatenated Path Down 7 -- Administratively Down 8 -- Reverse Concatenated Path Down 9-31 -- Reserved for future use This field allows remote systems to determine the reason that the previous session failed, for example. - I Hear You (H) - - This bit is set to 0 if the transmitting system either is not - receiving BFD packets from the remote system, or is in the process - of tearing down the BFD session for some reason. This bit is set - to 1 if the transmitting system believes it is communicating with - the remote system. See the Elements of Procedure below for more - details. + State (Sta) - Demand (D) + The current BFD session state as seen by the transmitting system. + Values are: - If set, the transmitting system wishes to operate in Demand Mode. - If clear, the transmitting system does not wish to or is not - capable of operating in Demand Mode. + 0 -- AdminDown + 1 -- Down + 2 -- Init + 3 -- Up Poll (P) If set, the transmitting system is requesting verification of connectivity, or of a parameter change. If clear, the transmitting system is not requesting verification. Final (F) If set, the transmitting system is responding to a received BFD @@ -373,23 +368,29 @@ The use of this bit is application dependent and is outside the scope of this specification. See specific application specifications for details. Authentication Present (A) If set, the Authentication Section is present and the session is to be authenticated. - Reserved (Rsv) + Demand (D) - These bits must be zero on transmit, and ignored on receipt. + If set, the transmitting system wishes to operate in Demand Mode. + If clear, the transmitting system does not wish to or is not + capable of operating in Demand Mode. + + Reserved (R) + + This bit must be zero on transmit, and ignored on receipt. Detect Mult Detect time multiplier. The negotiated transmit interval, multiplied by this value, provides the detection time for the transmitting system in Asynchronous mode. Length Length of the BFD Control packet, in bytes. @@ -509,21 +510,21 @@ The authentication key ID in use for this packet. This allows multiple keys to be active simultaneously. Reserved This byte must be set to zero on transmit, and ignored on receipt. Sequence Number The Sequence Number for this packet. For Keyed MD5 - Authentication, this value is incremented periodically. For + Authentication, this value is incremented occasionally. For Meticulous Keyed MD5 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks. Auth Key/Checksum This field carries the 16 byte MD5 checksum for the packet. When the checksum is calculated, the shared MD5 key is stored in this field. (See section 6.6.3 for details.) @@ -560,21 +561,21 @@ The authentication key ID in use for this packet. This allows multiple keys to be active simultaneously. Reserved This byte must be set to zero on transmit, and ignored on receipt. Sequence Number The Sequence Number for this packet. For Keyed SHA1 - Authentication, this value is incremented periodically. For + Authentication, this value is incremented occasionally. For Meticulous Keyed SHA1 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks. Auth Key/Checksum This field carries the 20 byte SHA1 checksum for the packet. When the checksum is calculated, the shared SHA1 key is stored in this field. (See section 6.6.4 for details.) @@ -611,102 +612,130 @@ Control packets for a particular session, regardless of whether it has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets for a particular session until it has received a BFD packet for that session, and thus has learned the remote system's discriminator value. At least one system MUST take the Active role (possibly both.) The role that a system takes is specific to the application of BFD, and is outside the scope of this specification. A session begins with the periodic, slow transmission of BFD Control - packets. When bidirectional communication is achieved (by virtue of - the I Hear You field being nonzero in both directions, a three way - handshake), the BFD session comes up. + packets. When bidirectional communication is achieved, the BFD + session comes up. Once the BFD session is Up, a system can choose to start the Echo function if it desires to and the other system signals that it will allow it. The rate of transmission of Control packets is typically kept low when the Echo function is active. If the Echo function is not active, the transmission rate of Control packets may be increased to a level necessary to achieve the detection time requirements for the session. If both systems signal that they want to use Demand mode, the transmission of BFD Control packets ceases once the session is Up. Other means of implying connectivity are used to keep the session alive. If one of the systems wishes to verify connectivity, it can initiate a short exchange (a "Poll Sequence") of BFD Control packets to verify this. If Demand mode is not active, and no Control packets are received in the calculated detection time (see section 6.7.4), the session is - declared down, and signalled to the remote end by sending a zero - value in the I Hear You field in outgoing packets. + declared down, and signalled to the remote end via the State (Sta) + field in outgoing packets. If sufficient Echo packets are lost, the session is declared down in the same manner. If Demand mode is active and no appropriate Control packets are received in response to a Poll Sequence, the session is declared down in the same manner. If the session goes down, the transmission of Echo packets (if any) ceases, and the transmission of Control packets goes back to the slow rate. Once a session has been declared down, it cannot come back up until - the remote end first signals that it is down (by setting its outgoing - I Hear You field to zero), thus implementing a three-way handshake. + the remote end first signals that it is down (by leaving the Up + state), thus implementing a three-way handshake. - A session may be kept administratively down by always setting its - outgoing I Hear You field to zero, and sending an explanatory - diagnostic code in the Diagnostic field. + A session may be kept administratively down by entering the AdminDown + state and sending an explanatory diagnostic code in the Diagnostic + field. 6.2. BFD State Machine - The BFD state machine is quite straightforward. There are four + The BFD state machine is quite straightforward. There are three states through which a session normally proceeds, two for - establishing a session (Init and Up) and two for tearing down a - session (Failing and Down.) This allows a three-way handshake for - both session establishment and session teardown (assuring that both - systems are aware of all session state changes.) A fifth state - (AdminDown) exists so that a session can be administratively put down + establishing a session (Init and Up) and one for tearing down a + session (Down.) This allows a three-way handshake for both session + establishment and session teardown (assuring that both systems are + aware of all session state changes.) A fourth state (AdminDown) + exists so that a session can be administratively put down indefinitely. - Failing state indicates that the session has just failed (or has just - been created.) A session remains in Failing state until the remote - system indicates that it agrees that the session is down by sending a - BFD Control packet with I Hear You = 0. When this occurs, the - session advances to the Down state. + Each system communicates its session state in the State (Sta) field + in the BFD Control packet, and that received state in combination + with the local session state drives the state machine. - Down state means that the session is down and both systems know as - much. A session will remain in Down state only until the next BFD - Control packet is received from the remote system. If that packet - signals I Hear You = 0, the session advances to Init state; if that - packet signals I Hear You = 1, the session advances to Up state. + Down state means that the session is down (or has just been created.) + A session remains in Down state until the remote system indicates + that it agrees that the session is down by sending a BFD Control + packet with the State field set to anything other than Up. If that + packet signals Down state, the session advances to Init state; if + that packet signals Init state, the session advances to Up state. Init state means that the remote system is communicating, and the local system desires to bring the session up, but the remote system does not yet realize it. A session will remain in Init state until - either a BFD Control Packet is received that is signalling I Hear You - = 1 (in which case the session advances to Up state) or until the + either a BFD Control Packet is received that is signalling Init or Up + state (in which case the session advances to Up state) or until the detection time expires, meaning that communication with the remote - system has been lost (in which case the session advances to Failing + system has been lost (in which case the session advances to Down state.) Up state means that the BFD session has successfully been established, and implies that connectivity between the systems is working. The session will remain in the Up state until either connectivity fails, or the session is taken down administratively. - If either the remote system signals I Hear You = 0, or the detection - time expires, the session advances to Failing state. + If either the remote system signals Down state, or the detection time + expires, the session advances to Down state. + + AdminDown state means that the session is being held administratively + down. This causes the remote system to enter Down state, and remain + there until the local system exits AdminDown state. + + The following diagram provides an overview of the state machine. + Transitions involving AdminDown state are deleted for clarity (but + are fully specified in section 6.7.6.) The notation on each arc + represents the state of the remote system (as received in the State + field in the BFD Control packet) or indicates the expiration of the + Detection Time. + + +--+ + | | UP + | V + DOWN +------+ INIT + +------------| |------------+ + | | DOWN | | + | +-------->| |<--------+ | + | | +------+ | | + | | | | + | | | | + | | DOWN,| | + | |TIMER TIMER| | + V | | V + +------+ +------+ + +----| | | |----+ + DOWN| | INIT |--------------------->| UP | |INIT, UP + +--->| | INIT, UP | |<---+ + +------+ +------+ 6.3. Demultiplexing and the Discriminator Fields Since multiple BFD sessions may be running between two systems, there needs to be a mechanism for demultiplexing received BFD packets to the proper session. Each system MUST choose an opaque discriminator value that identifies each session, and which MUST be unique among all BFD sessions on the system. The local discriminator is sent in the My Discriminator @@ -818,22 +848,22 @@ transmitting system will put information in the Authentication Section that vouches for the packet's validity, and the receiving system will examine the Authentication Section and either accept the packet for further processing, or discard it. Note that in the subsections below, to "accept" a packet means only that the packet has passed authentication; it may in fact be discarded for other reasons as described in the general packet reception rules described in section 6.7.6. - Implementations MUST support SHA1 authentication. Other froms of - authentication are optional. + Implementations supporting authentication MUST support SHA1 + authentication. Other forms of authentication are optional. 6.6.1. Enabling and Disabling Authentication It may be desirable to enable or disable authentication on a session without disturbing the session state. The exact mechanism for doing so is outside the scope of this specification. However, it is useful to point out some issues in supporting this mechanism. In a simple implementation, a BFD session will fail when authentication is either turned on or turned off, because the packet @@ -1065,57 +1093,54 @@ and that the session is Up. 6.7.1. State Variables A minimum amount of information about a session needs to be tracked in order to achieve the elements of procedure described here. The following is a set of state variables that are helpful in describing the mechanisms of BFD. Any means of tracking this state may be used so long as the protocol behaves as described. + When the text refers to initializing a state variable, this takes + place only at the time that the session (and the corresponding state + variables) is created. The state variables are subsequently + manipulated by the state machine and are never reinitialized, even if + the session fails and is reestablished. + All state variables in this specification are of the form "bfd.Xx" and should not be confused with fields carried in the protocol packets, which are always spelled out to match the names in section 4. bfd.SessionState - The perceived state of the session (Init, Up, Failing, Down, or + The perceived state of the session (Init, Up, Down, or AdminDown.) The exact action taken when the session state changes is outside the scope of this specification, though it is expected that this state change (particularly to and from Up state) is reported to other components of the system. This - variable MUST be initialized to Failing. + variable MUST be initialized to Down. bfd.LocalDiscr The local discriminator for this BFD session, used to uniquely identify it. It MUST be unique across all BFD sessions on this system, and nonzero. It SHOULD be set to a random (but still unique) value to improve security. The value is otherwise outside the scope of this specification. bfd.RemoteDiscr The remote discriminator for this BFD session. This is the discriminator chosen by the remote system, and is totally opaque to the local system. This MUST be initialized to zero. - bfd.RemoteHeard - - This variable is set to 1 if the local system is actively - receiving BFD packets from the remote system, and is set to 0 - if the local system has not received BFD packets recently - (within the detection time) or if the local system is - attempting to tear down the BFD session. This MUST be - initialized to zero. - bfd.LocalDiag The diagnostic code specifying the reason for the most recent local session state chage. This MUST be initialized to zero (No Diagnostic.) bfd.DesiredMinTxInterval The minimum interval, in microseconds, between transmitted BFD Control packets that this system would like to use at the @@ -1196,64 +1221,63 @@ average interval between packets may be up to 12.5% less than that negotiated. If bfd.DetectMult is equal to 1, the interval between transmitted BFD Control packets MUST be no more than 90% of the negotiated transmission interval, and MUST be no less than 75% of the negotiated transmission interval. This is to ensure that, on the remote system, the calculated DetectTime does not pass prior to the receipt of the next BFD Control packet. - An extra, single BFD Control packet SHOULD be transmitted during the - interval between periodic Control packet transmissions if there is a - state change that needs to be communicated, in order to more rapidly - converge. (For example, if the local system determines that the BFD - session has gone down, it SHOULD communicate this without waiting for - the next periodic transmission.) With the exception listed in the - next paragraph, once such an extra packet has been transmitted, a - system MUST NOT send another BFD Control packet until the next - scheduled transmission. + A BFD Control packet SHOULD be transmitted during the interval + between periodic Control packet transmissions when the contents of + that packet would differ from that in the previously transmitted + packet (other than the Poll and Final bits) in order to more rapidly + communicate a change in state. If a BFD Control packet is received with the Poll (P) bit set to 1, the receiving system MUST transmit a BFD Control packet with the Poll (P) bit clear and the Final (F) bit set as soon as practicable, without respect to the transmission timer or any other transmission - limitations, and without respect to whether Demand mode is active. + limitations, without respect to the session state, and without + respect to whether Demand mode is active. 6.7.3. Timer Manipulation The time values used to determine BFD packet transmission intervals and the session detection time may be modified at any time without affecting the state of the session. When the timer parameters are changed for any reason, the requirements of this section apply. If Demand mode is active, and either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated (see section 6.7.8). - If Demand mode is not active, and either bfd.DesiredMinTxInterval is - changed or bfd.RequiredMinRxInterval is changed, all subsequent - transmitted Control packets MUST be sent with the Poll (P) bit set - until a packet is received with the Final (F) bit set (except for - those packets sent in response to received Polls.) + If Demand mode is not active, bfd.SessionState is Up, and either + bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is + changed, all subsequent transmitted Control packets MUST be sent with + the Poll (P) bit set until a packet is received with the Final (F) + bit set (except for those packets sent in response to received + Polls.) - If bfd.DesiredMinTxInterval is increased, the actual transmission - interval used MUST NOT change until a Control packet is received with - the Final (F) bit set. This is to ensure that the remote system - updates its Detect Time before the transmission interval increases. + If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, + the actual transmission interval used MUST NOT change until a Control + packet is received with the Final (F) bit set. This is to ensure + that the remote system updates its Detect Time before the + transmission interval increases. - If bfd.RequiredMinRxInterval is reduced, the calculated detection - time for the remote system MUST NOT change until a Control packet is - received with the Final (F) bit set. This is to ensure that the - remote system is transmitting packets at the higher rate (and those - packets are being received) prior to the detection time being - reduced. + If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, + the calculated detection time for the remote system MUST NOT change + until a Control packet is received with the Final (F) bit set. This + is to ensure that the remote system is transmitting packets at the + higher rate (and those packets are being received) prior to the + detection time being reduced. When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. When the Echo function is active, a system SHOULD set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to keep BFD Control @@ -1268,94 +1292,88 @@ in each direction by the receiving system based on the negotiated transmit interval and the detection multiplier. Note that, in Asynchronous mode, there may be different detection times in each direction. The calculation of the Detection Time is slightly different when in Demand mode versus Asynchronous mode. In Asynchronous mode, the Detection Time calculated in the local system is equal to the value of Detect Mult received from the remote - system, multiplied by the agreed transmit interval (the greater of - bfd.RequiredMinRxInterval and the last received Desired Min TX - Interval.) The Detect Mult value is (roughly speaking, due to - jitter) the number of packets that have to be missed in a row to - declare the session to be down. + system, multiplied by the agreed transmit interval of the remote + system (the greater of bfd.RequiredMinRxInterval and the last + received Desired Min TX Interval.) The Detect Mult value is (roughly + speaking, due to jitter) the number of packets that have to be missed + in a row to declare the session to be down. If Demand mode is not active, and a period of time equal to the Detection Time passes without receiving a BFD Control packet from the remote system, and bfd.SessionState is Init or Up, the session has - gone down--the local system MUST set bfd.SessionState to Failing, - bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection - Time Expired.) The timeout in Init state is to avoid a potential - deadlock in which one system is in Failing state and the other is in - Init state (which could happen if a packet were lost at the right - time.) + gone down--the local system MUST set bfd.SessionState to Down and + bfd.LocalDiag to 1 (Control Detection Time Expired.) In Demand mode, the Detection Time calculated in the local system is equal to bfd.DetectMult, multiplied by the agreed transmit interval - (the greater of bfd.RequiredMinRxInterval and the last received - Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due - to jitter) the number of packets that have to be missed in a row to - declare the session to be down. + of the local system (the greater of bfd.DesiredMinTxInterval and the + last received Required Min RX Interval.) bfd.DetectMult is (roughly + speaking, due to jitter) the number of packets that have to be missed + in a row to declare the session to be down. If Demand mode is active, and a period of time equal to the Detection Time passes after the initiation of a Poll Sequence (the transmission of the first BFD Control packet with the Poll bit set), the session - has gone down--the local system MUST set bfd.SessionState to Failing, - bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection - Time Expired.) + has gone down--the local system MUST set bfd.SessionState to Down, + and bfd.LocalDiag to 1 (Control Detection Time Expired.) (Note that a packet is considered to have been received, for the purposes of Detection Time expiration, only if it has not been "discarded" according to the rules of section 6.7.6.) 6.7.5. Detecting Failures with the Echo Function When the Echo function is active and a sufficient number of Echo packets have not arrived as they should, the session has gone - down--the local system MUST set bfd.SessionState to Failing, - bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function - Failed.) + down--the local system MUST set bfd.SessionState to Down, and + bfd.LocalDiag to 2 (Echo Function Failed.) The means by which the Echo function failures are detected is outside of the scope of this specification. Any means which will detect a communication failure is acceptable. 6.7.6. Reception of BFD Control Packets When a BFD Control packet is received, the following procedure MUST be followed, in the order specified. If the packet is discarded according to these rules, processing of the packet MUST cease at that point. - If the version number is not correct (0), the packet MUST be + If the version number is not correct (1), the packet MUST be discarded. If the Length field is less than the minimum correct value (24 if the A bit is clear, or 26 if the A bit is set), the packet MUST be discarded. If the Length field is greater than the payload of the encapsulating protocol, the packet MUST be discarded. If the Detect Mult field is zero, the packet MUST be discarded. If the My Discriminator field is zero, the packet MUST be discarded. If the Your Discriminator field is nonzero, it MUST be used to select the session with which this BFD packet is associated. If no session is found, the packet MUST be discarded. - If the Your Discriminator field is zero and the I Hear You field - is nonzero, the packet MUST be discarded. + If the Your Discriminator field is zero and the State field is not + Down or AdminDown, the packet MUST be discarded. If the Your Discriminator field is zero, the session MUST be selected based on some combination of other fields, possibly including source addressing information, the My Discriminator field, and the interface over which the packet was received. The exact method of selection is application-specific and is thus outside the scope of this specification. If a matching session is not found, a new session may be created, or the packet may be discarded. This choice is outside the scope of this specification. @@ -1379,44 +1397,42 @@ the local system, and the Final (F) bit in the received packet is set, the Poll Sequence MUST be terminated. If Demand mode is not active, the Final (F) bit in the received packet is set, and the local system has been transmitting packets with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in subsequent transmitted packets. Update the Detection Time as described in section 6.7.4. - If bfd.SessionState is Down - Set bfd.RemoteHeard to 1 - If I Hear You is zero - Set bfd.SessionState to Init - Else - Set bfd.SessionState to Up + If received state is AdminDown + If bfd.SessionState is not Down + Set bfd.LocalDiag to 3 (Neighbor signaled session down) + Set bfd.SessionState to Down - Else if bfd.SessionState is AdminDown + Else + If bfd.SessionState is AdminDown Discard the packet - Else if bfd.SessionState is Init - If I Hear You is nonzero + Else if bfd.SessionState is Down + If received State is Down + Set bfd.SessionState to Init + Else if received State is Init Set bfd.SessionState to Up - Else - Discard the packet - Else if bfd.SessionState is Up - If I Hear You is zero + Else if bfd.SessionState is Init + If received State is Init or Up + Set bfd.SessionState to Up + Else (bfd.SessionState is Up) + If received State is Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) - Set bfd.SessionState to Failing - Set bfd.RemoteHeard to 0 - - Else if bfd.SessionState is Failing - If I Hear You is zero, set bfd.SessionState to Down + Set bfd.SessionState to Down Update the transmit interval as described in section 6.7.2. If the Demand (D) bit is set and bfd.DemandModeDesired is 1, and bfd.SessionState is Up, Demand mode is active. If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, or bfd.SessionState is not Up, Demand mode is not active. @@ -1438,51 +1454,47 @@ Min RX Interval changes, and is equal to the greater of those two values. See sections 6.7.2 and 6.7.3 for details on transmit timers. A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is zero and the system is taking the Passive role. A system MUST NOT periodically transmit BFD Control packets if Demand mode is active and a Poll Sequence is not being transmitted. A system MUST send a BFD Control packet in response to a received BFD - Control Packet with the Poll (P) bit set. The packet sent in - response MUST NOT have the Poll (P) bit set, and MUST have the Final - (F) bit set. A system MAY limit the rate at which such packets are - transmitted. If rate limiting is in effect, the advertised value of - Desired Min TX Interval must be greater than or equal to the interval - between transmitted packets imposed by the rate limiting function. + Control Packet with the Poll (P) bit set, regardless of the BFD + session state. The packet sent in response MUST NOT have the Poll + (P) bit set, and MUST have the Final (F) bit set. A system MAY limit + the rate at which such packets are transmitted. If rate limiting is + in effect, the advertised value of Desired Min TX Interval must be + greater than or equal to the interval between transmitted packets + imposed by the rate limiting function. - A single BFD Control packet SHOULD be transmitted between normally - scheduled transmissions when the contents of that packet would differ - from those in the previously transmitted packet (other than the Poll - and Final bits) in order to more rapidly communicate a change in - state. + A BFD Control packet SHOULD be transmitted between normally scheduled + transmissions when the contents of that packet would differ from + those in the previously transmitted packet (other than the Poll and + Final bits) in order to more rapidly communicate a change in state. The contents of transmitted BFD Control packets MUST be set as follows: Version - Set to the current version number (0). + Set to the current version number (1). Diagnostic (Diag) Set to bfd.LocalDiag. - I Hear You (H) - - Set to bfd.RemoteHeard. - - Demand (D) + State (Sta) - Set to bfd.DemandModeDesired. + Set to the value indicated by bfd.SessionState. Poll (P) Set to 1 if the local system is sending a Poll Sequence or is required to do so according to the requirements of section 6.7.3, or 0 if not. Final (F) Set to 1 if the local system is responding to a Control packet @@ -1492,21 +1504,25 @@ Set to 1 if the local system's BFD implementation is independent of the control plane (it can continue to function through a disruption of the control plane.) Authentication Present (A) Set to 1 if authentication is in use on this session (bfd.AuthType is nonzero), or 0 if not. - Reserved (Rsvd) + Demand (D) + + Set to bfd.DemandModeDesired. + + Reserved (R) Set to 0. Detect Mult Set to bfd.DetectMult. Length Set to the appropriate length, based on the fixed header length @@ -1628,36 +1644,33 @@ If it is desired to start or stop Demand mode, this MAY be done at any time by setting bfd.DemandModeDesired to the proper value. If Demand mode is no longer active, the system MUST begin transmitting periodic BFD Control packets as described in section 6.7.7. 6.7.16. Forwarding Plane Reset When the forwarding plane in the local system is reset for some reason, such that the remote system can no longer rely on the local forwarding state, the local system MUST set bfd.LocalDiag to 4 - (Forwarding Plane Reset), set bfd.SessionState to Failing, and set - bfd.RemoteHeard to zero. + (Forwarding Plane Reset), and set bfd.SessionState to Down. 6.7.17. Administrative Control There may be circumstances where it is desirable to administratively enable or disable a BFD session. When this is desired, the following procedure MUST be followed: If enabling session - Set bfd.SessionState to Failing - Set bfd.RemoteHeard to zero + Set bfd.SessionState to Down Else Set bfd.SessionState to AdminDown - Set bfd.RemoteHeard to zero Set bfd.LocalDiag to an appropriate value Cease the transmission of BFD Echo packets If signalling is received from outside BFD that the underlying path has failed, an implementation MAY adminstratively disable the session with the diagnostic Path Down. Other scenarios MAY use the diagnostic Administratively Down. 6.7.18. Concatenated Paths @@ -1676,49 +1689,49 @@ link.) A system MAY signal one of these failure states by simply setting bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD session is not taken down. If Demand Mode is not active, no other action is necessary, as the diagnostic code will be carried via the periodic transmission of BFD Control packets. If Demand Mode is active, a Poll Sequence MUST be initiated to ensure that the diagnostic code is transmitted. Note that if the BFD session subsequently fails, the diagnostic code will be overwritten with a - code detailing the cause of the failure, so it is up to the - interworking agent to perform this procedure again, once the BFD + code detailing the cause of the failure. It is up to the + interworking agent to perform the above procedure again, once the BFD session reaches Up state, if the propagation of the concatenated path failure is to resume. Contributors Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document. Acknowledgments This document was inspired by (and is intended to replace) the Protocol Liveness Protocol draft, written by Kireeti Kompella. Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang et al. The authors would also like to thank Mike Shand, John Scudder, - Stewart Bryant, and Pekka Savola for their substantive input. + Stewart Bryant, Pekka Savola, and Richard Spencer for their + substantive input. Security Considerations As BFD may be tied into the stability of the network infrastructure (such as routing protocols), the effects of an attack on a BFD session may be very serious. This ultimately has denial-of-service effects, as links may be declared to be down (or falsely declared to be up.) - When BFD is run over network layer protocols, a significant denial- of-service risk is created, as BFD packets may be trivial to spoof. When the session is directly connected across a single link (physical, or a secure tunnel such as IPsec), the TTL or Hop Count MUST be set to the maximum on transmit, and checked to be equal to the maximum value on reception (and the packet dropped if this is not the case.) See [GTSM] for more information on this technique. If BFD is run across multiple hops or an insecure tunnel (such as GRE), the Authentication Section SHOULD be utilized. @@ -1786,24 +1799,40 @@ Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: dward@cisco.com Changes from the previous draft The primary technical change in this draft from the previous version - is the addition of SHA1 authentication, the addition of a method for - enabling and disabling authentication without disturbing BFD session - state, and the modification of the procedures for handling - concatenated paths. + is an updated state machine, and an updated packet format to effect + it (with an appropriate change to the version number.) This version + of the draft is incompatible with previous versions, and will not + interoperate with them (but the two versions will ignore one + another.) + + The packet transmission rules were relaxed to allow multiple "extra" + packets to be sent between regularly scheduled transmissions, in + order to take advantage of the new state machine to speed up session + establishment. + + Verbiage regarding the Poll/Final bits was updated to state that + Polls must be sent when in Up state and the timing parameters change + (but that Finals in response to Polls are sent in any state.) + + A mistake in the description of the calculation of the Detection Time + while in Demand Mode was corrected. + + The fact that SHA1 authentication is mandatory only when implementing + authentication was clarified. Otherwise, the changes in this draft from the previous version are cosmetic and/or editorial. IPR Notice The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. @@ -1840,11 +1869,11 @@ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. - This document expires in August, 2005. + This document expires in September, 2005.