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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/