< draft-ietf-bfd-base-05.txt   draft-ietf-bfd-base-06.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: December, 2006 June, 2006 Expires: September, 2007 March, 2007
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-05.txt draft-ietf-bfd-base-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract Abstract
This document describes a protocol intended to detect faults in the This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. independently of media, data protocols, and routing protocols.
Comments on this draft should be directed to rtg-bfd@ietf.org. Comments on this draft should be directed to rtg-bfd@ietf.org.
Conventions used in this document Conventions used in this document
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . 18 6.3 Demultiplexing and the Discriminator Fields . . . . . . 18
6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 18 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 19
6.5 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 19 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 19
6.6 Authentication . . . . . . . . . . . . . . . . . . . . . 20 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 20
6.6.1 Enabling and Disabling Authentication . . . . . . 20 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 21
6.6.2 Simple Password Authentication . . . . . . . . . . 21 6.7.1 Enabling and Disabling Authentication . . . . . . 22
6.6.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 22 6.7.2 Simple Password Authentication . . . . . . . . . . 22
6.6.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 23 6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 23
6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 25 6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 25
6.7.1 State Variables . . . . . . . . . . . . . . . . . 25 6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 27
6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 28 6.8.1 State Variables . . . . . . . . . . . . . . . . . 27
6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 29 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 30
6.7.4 Calculating the Detection Time . . . . . . . . . . 30 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 31
6.7.5 Detecting Failures with the Echo Function . . . . 31 6.8.4 Calculating the Detection Time . . . . . . . . . . 32
6.7.6 Reception of BFD Control Packets . . . . . . . . . 31 6.8.5 Detecting Failures with the Echo Function . . . . 33
6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33 6.8.6 Reception of BFD Control Packets . . . . . . . . . 34
6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 36 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36
6.7.9 Reception of BFD Echo Packets . . . . . . . . . . 36 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39
6.7.10 Transmission of BFD Echo Packets . . . . . . . . 37 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39
6.7.11 Min Rx Interval Change . . . . . . . . . . . . . 37 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40
6.7.12 Min Tx Interval Change . . . . . . . . . . . . . 37 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40
6.7.13 Detect Multiplier Change . . . . . . . . . . . . 37 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40
6.7.14 Enabling or Disabling the Echo Function . . . . . 38 6.8.13 Enabling or Disabling the Echo Function . . . . . 40
6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 38 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41
6.7.16 Forwarding Plane Reset . . . . . . . . . . . . . 38 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41
6.7.17 Administrative Control . . . . . . . . . . . . . 38 6.8.16 Administrative Control . . . . . . . . . . . . . 41
6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 39 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 41
Backward Compatibility (Non-Normative) . . . . . . . . . . . . 39 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
Security Considerations . . . . . . . . . . . . . . . . . . . . 41 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42 Security Considerations . . . . . . . . . . . . . . . . . . . . 44
Normative References . . . . . . . . . . . . . . . . . . . . . 42 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 Normative References . . . . . . . . . . . . . . . . . . . . . 45
Changes from the previous draft . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Changes from the previous draft . . . . . . . . . . . . . . . . 46
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
An increasingly important feature of networking equipment is the An increasingly important feature of networking equipment is the
rapid detection of communication failures between adjacent systems, rapid detection of communication failures between adjacent systems,
in order to more quickly establish alternative paths. Detection can in order to more quickly establish alternative paths. Detection can
come fairly quickly in certain circumstances when data link hardware come fairly quickly in certain circumstances when data link hardware
comes into play (such as SONET alarms.) However, there are media comes into play (such as SONET alarms.) However, there are media
that do not provide this kind of signaling (such as Ethernet), and that do not provide this kind of signaling (such as Ethernet), and
some media may not detect certain kinds of failures in the path, for some media may not detect certain kinds of failures in the path, for
skipping to change at page 6, line 6 skipping to change at page 6, line 6
BFD has two operating modes which may be selected, as well as an BFD has two operating modes which may be selected, as well as an
additional function that can be used in combination with the two additional function that can be used in combination with the two
modes. modes.
The primary mode is known as Asynchronous mode. In this mode, the The primary mode is known as Asynchronous mode. In this mode, the
systems periodically send BFD Control packets to one another, and if systems periodically send BFD Control packets to one another, and if
a number of those packets in a row are not received by the other a number of those packets in a row are not received by the other
system, the session is declared to be down. system, the session is declared to be down.
The second mode is known as Demand mode. In this mode, it is assumed The second mode is known as Demand mode. In this mode, it is assumed
that each system has an independent way of verifying that it has that a system has an independent way of verifying that it has
connectivity to the other system. Once a BFD session is established, connectivity to the other system. Once a BFD session is established,
the systems stop sending BFD Control packets, except when either such a system may ask the other system to stop sending BFD Control
system feels the need to verify connectivity explicitly, in which packets, except when the system feels the need to verify connectivity
case a short sequence of BFD Control packets is sent, and then the explicitly, in which case a short sequence of BFD Control packets is
protocol quiesces. exchanged, and then the far system quiesces. Demand mode may operate
independently in each direction, or simultaneously.
An adjunct to both modes is the Echo function. When the Echo An adjunct to both modes is the Echo function. When the Echo
function is active, a stream of BFD Echo packets is transmitted in function is active, a stream of BFD Echo packets is transmitted in
such a way as to have the other system loop them back through its such a way as to have the other system loop them back through its
forwarding path. If a number of packets of the echoed data stream forwarding path. If a number of packets of the echoed data stream
are not received, the session is declared to be down. The Echo are not received, the session is declared to be down. The Echo
function may be used with either Asynchronous or Demand modes. Since function may be used with either Asynchronous or Demand modes. Since
the Echo function is handling the task of detection, the rate of the Echo function is handling the task of detection, the rate of
periodic transmission of Control packets may be reduced (in the case periodic transmission of Control packets may be reduced (in the case
of Asynchronous mode) or eliminated completely (in the case of Demand of Asynchronous mode) or eliminated completely (in the case of Demand
skipping to change at page 6, line 46 skipping to change at page 6, line 47
is enabled in a particular direction only when the system that loops is enabled in a particular direction only when the system that loops
the Echo packets back signals that it will allow it, and when the the Echo packets back signals that it will allow it, and when the
system that sends the Echo packets decides it wishes to. system that sends the Echo packets decides it wishes to.
Demand mode is useful in situations where the overhead of a periodic Demand mode is useful in situations where the overhead of a periodic
protocol might prove onerous, such as a system with a very large protocol might prove onerous, such as a system with a very large
number of BFD sessions. It is also useful when the Echo function is number of BFD sessions. It is also useful when the Echo function is
being used symmetrically. Demand mode has the disadvantage that being used symmetrically. Demand mode has the disadvantage that
detection times are essentially driven by the heuristics of the detection times are essentially driven by the heuristics of the
system implementation and are not known to the BFD protocol. Demand system implementation and are not known to the BFD protocol. Demand
mode also may not be used when the path round trip time is greater mode may not be used when the path round trip time is greater than
than the desired detection time. See section 6.5 for more details. the desired detection time. See section 6.6 for more details.
4. BFD Control Packet Format 4. BFD Control Packet Format
4.1. Generic BFD Control Packet Format 4.1. Generic BFD Control Packet Format
BFD Control packets are sent in an encapsulation appropriate to the BFD Control packets are sent in an encapsulation appropriate to the
environment. The specific encapsulation is outside of the scope of environment. The specific encapsulation is outside of the scope of
this document. See the appropriate application document for this specification. See the appropriate application document for
encapsulation details. encapsulation details.
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 |Sta|P|F|C|A|D|R| Detect Mult | Length | |Vers | Diag |Sta|P|F|C|A|D|M| 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 8, line 8 skipping to change at page 8, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Vers) Version (Vers)
The version number of the protocol. This document defines The version number of the protocol. This document defines
protocol version 1. 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 to states Down or AdminDown. 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
skipping to change at page 8, line 37 skipping to change at page 8, line 38
Values are: Values are:
0 -- AdminDown 0 -- AdminDown
1 -- Down 1 -- Down
2 -- Init 2 -- Init
3 -- Up 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, and is expecting a packet
transmitting system is not requesting verification. with the Final (F) bit in reply. If clear, the 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
Control packet that had the Poll (P) bit set. If clear, the Control packet that had the Poll (P) bit set. If clear, the
transmitting system is not responding to a Poll. transmitting system is not responding to a Poll.
Control Plane Independent (C) Control Plane Independent (C)
If set, the transmitting system's BFD implementation does not If set, the transmitting system's BFD implementation does not
skipping to change at page 9, line 25 skipping to change at page 9, line 25
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.
Demand (D) Demand (D)
If set, the transmitting system wishes to operate in Demand Mode. If set, Demand mode is active in the transmitting system (the
If clear, the transmitting system does not wish to or is not system wishes to operate in Demand mode, knows that the session is
capable of operating in Demand Mode. up in both directions, and is directing the remote system to cease
the periodic transmission of BFD Control packets.) If clear,
Demand mode is not active in the transmitting system.
Reserved (R) Multipoint (M)
This bit must be zero on transmit, and ignored on receipt. This bit is reserved for future point-to-multipoint extensions to
BFD. It must be zero on both transmit and receipt.
Detect Mult Detect Mult
Detect time multiplier. The negotiated transmit interval, Detection 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.
My Discriminator My Discriminator
A unique, nonzero discriminator value generated by the A unique, nonzero discriminator value generated by the
skipping to change at page 10, line 16 skipping to change at page 10, line 21
Your Discriminator Your Discriminator
The discriminator received from the corresponding remote system. The discriminator received from the corresponding remote system.
This field reflects back the received value of My Discriminator, This field reflects back the received value of My Discriminator,
or is zero if that value is unknown. or is zero if that value is unknown.
Desired Min TX Interval Desired Min TX Interval
This is the minimum interval, in microseconds, that the local This is the minimum interval, in microseconds, that the local
system would like to use when transmitting BFD Control packets. system would like to use when transmitting BFD Control packets.
The value zero is reserved.
Required Min RX Interval Required Min RX Interval
This is the minimum interval, in microseconds, between received This is the minimum interval, in microseconds, between received
BFD Control packets that this system is capable of supporting. BFD Control packets that this system is capable of supporting. If
this value is zero, the transmitting system does not want the
remote system to send any periodic BFD Control packets.
Required Min Echo RX Interval Required Min Echo RX Interval
This is the minimum interval, in microseconds, between received This is the minimum interval, in microseconds, between received
BFD Echo packets that this system is capable of supporting. If BFD Echo packets that this system is capable of supporting. If
this value is zero, the transmitting system does not support the this value is zero, the transmitting system does not support the
receipt of BFD Echo packets. receipt of BFD Echo packets.
Auth Type Auth Type
skipping to change at page 11, line 7 skipping to change at page 11, line 13
5 - Meticulous Keyed SHA1 5 - Meticulous Keyed SHA1
6-255 - Reserved for future use 6-255 - Reserved for future use
Auth Len Auth Len
The length, in bytes, of the authentication section, including the The length, in bytes, of the authentication section, including the
Auth Type and Auth Len fields. Auth Type and Auth Len fields.
4.2. Simple Password Authentication Section Format 4.2. Simple Password Authentication Section Format
If the Autentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 1 (Simple Password), the Authentication Type field contains 1 (Simple Password), the
Authentication Section has the following format: Authentication Section has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Password... | | Auth Type | Auth Len | Auth Key ID | Password... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 10 skipping to change at page 13, line 10
The Sequence Number for this packet. For Keyed MD5 The Sequence Number for this packet. For Keyed MD5
Authentication, this value is incremented occasionally. 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.7.3 for details.)
4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1), the Authentication Section has the following format: Keyed SHA1), the Authentication Section has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 21 skipping to change at page 14, line 21
The Sequence Number for this packet. For Keyed SHA1 The Sequence Number for this packet. For Keyed SHA1
Authentication, this value is incremented occasionally. 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.7.4 for details.)
5. BFD Echo Packet Format 5. BFD Echo Packet Format
BFD Echo packets are sent in an encapsulation appropriate to the BFD Echo packets are sent in an encapsulation appropriate to the
environment. See the appropriate application documents for the environment. See the appropriate application documents for the
specifics of particular environments. specifics of particular environments.
The payload of a BFD Echo packet is a local matter, since only the The payload of a BFD Echo packet is a local matter, since only the
sending system ever processes the content. The only requirement is sending system ever processes the content. The only requirement is
that sufficient information is included to demultiplex the received that sufficient information is included to demultiplex the received
skipping to change at page 15, line 14 skipping to change at page 15, line 14
6. Elements of Procedure 6. Elements of Procedure
This section discusses the normative requirements of the protocol in This section discusses the normative requirements of the protocol in
order to achieve interoperability. It is important for implementors order to achieve interoperability. It is important for implementors
to enforce only the requirements specified in this section, as to enforce only the requirements specified in this section, as
misguided pedantry has been proven by experience to adversely affect misguided pedantry has been proven by experience to adversely affect
interoperability. interoperability.
Remember that all references of the form "bfd.Xx" refer to internal Remember that all references of the form "bfd.Xx" refer to internal
state variables (defined in section 6.7.1), whereas all references to state variables (defined in section 6.8.1), whereas all references to
"the Xxx field" refer to fields in the protocol packets themselves "the Xxx field" refer to fields in the protocol packets themselves
(defined in section 4). (defined in section 4).
6.1. Overview 6.1. Overview
A system may take either an Active role or a Passive role in session A system may take either an Active role or a Passive role in session
initialization. A system taking the Active role MUST send BFD initialization. A system taking the Active role MUST send BFD
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
skipping to change at page 15, line 44 skipping to change at page 15, line 44
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 Once the session is up, a system may signal that it has entered
transmission of BFD Control packets ceases once the session is Up. Demand mode, and the transmission of BFD Control packets by the
Other means of implying connectivity are used to keep the session remote system ceases. Other means of implying connectivity are used
alive. If one of the systems wishes to verify connectivity, it can to keep the session alive. If either system wishes to verify
initiate a short exchange (a "Poll Sequence") of BFD Control packets bidirectional connectivity, it can initiate a short exchange of BFD
to verify this. Control packets (a "Poll Sequence"; see section 6.5) to do so.
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.8.4), the session is
declared Down. This is signaled to the remote end via the State declared Down. This is signaled to the remote end via the State
(Sta) field in outgoing packets. (Sta) 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. See section 6.7.5. the same manner. See section 6.8.5.
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. See section 6.5. in the same manner. See section 6.6.
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 leaving the Up the remote end first signals that it is down (by leaving the Up
state), thus implementing a three-way handshake. state), thus implementing a three-way handshake.
A session may be kept administratively down by entering the AdminDown A session may be kept administratively down by entering the AdminDown
skipping to change at page 16, line 48 skipping to change at page 16, line 48
Each system communicates its session state in the State (Sta) field Each system communicates its session state in the State (Sta) field
in the BFD Control packet, and that received state in combination in the BFD Control packet, and that received state in combination
with the local session state drives the state machine. with the local session state drives the state machine.
Down state means that the session is down (or has just been created.) Down state means that the session is down (or has just been created.)
A session remains in Down state until the remote system indicates A session remains in Down state until the remote system indicates
that it agrees that the session is down by sending a BFD Control 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 with the State field set to anything other than Up. If that
packet signals Down state, the session advances to Init state; if packet signals Down state, the session advances to Init state; if
that packet signals Init state, the session advances to Up state. that packet signals Init state, the session advances to Up state.
Semantically, Down state indicates that the forwarding path is
unavailable, and that appropriate actions should be taken by the
applications monitoring the state of the BFD session. A system MAY
hold a session in Down state indefinitely (by simply refusing to
advance the session state.) This may be done for operational or
adminstrative reasons, among others.
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 Init or Up either a BFD Control Packet is received that is signaling Init or Up
state (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 Down 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 Down state, or the detection time If either the remote system signals Down state, or the detection time
expires, the session advances to Down state. expires, the session advances to Down state.
AdminDown state means that the session is being held administratively AdminDown state means that the session is being held administratively
down. This causes the remote system to enter Down state, and remain down. This causes the remote system to enter Down state, and remain
there until the local system exits AdminDown state. there until the local system exits AdminDown state. AdminDown state
has no semantic implications for the availability of the forwarding
path.
The following diagram provides an overview of the state machine. The following diagram provides an overview of the state machine.
Transitions involving AdminDown state are deleted for clarity (but Transitions involving AdminDown state are deleted for clarity (but
are fully specified in section 6.7.6.) The notation on each arc are fully specified in section 6.8.6.) The notation on each arc
represents the state of the remote system (as received in the State represents the state of the remote system (as received in the State
field in the BFD Control packet) or indicates the expiration of the field in the BFD Control packet) or indicates the expiration of the
Detection Time. Detection Timer.
+--+ +--+
| | UP | | UP, ADMIN DOWN, TIMER
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| | | | | | ADMIN DOWN,| |
| | DOWN,| | | |ADMIN DOWN, DOWN,| |
| |TIMER TIMER| | | |TIMER TIMER| |
V | | V V | | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
6.3. Demultiplexing and the Discriminator Fields 6.3. Demultiplexing and the Discriminator Fields
skipping to change at page 18, line 47 skipping to change at page 19, line 17
The Echo function can be run independently in each direction between The Echo function can be run independently in each direction between
a pair of systems. For whatever reason, a system may advertise that a pair of systems. For whatever reason, a system may advertise that
it is willing to receive (and loop back) Echo packets, but may not it is willing to receive (and loop back) Echo packets, but may not
wish to ever send any. The fact that a system is sending Echo wish to ever send any. The fact that a system is sending Echo
packets is not directly signaled to the system looping them back. packets is not directly signaled to the system looping them back.
When a system is using the Echo function, it is advantageous to When a system is using the Echo function, it is advantageous to
choose a sedate reception rate for Control packets, since liveness choose a sedate reception rate for Control packets, since liveness
detection is being handled by the Echo packets. This can be detection is being handled by the Echo packets. This can be
controlled by manipulating the Required Min RX Interval field (see controlled by manipulating the Required Min RX Interval field (see
section 6.7.3.) section 6.8.3.)
If the Echo function is only being run in one direction, the system If the Echo function is only being run in one direction, the system
not running the Echo function will more likely wish to receive fairly not running the Echo function will more likely wish to receive fairly
rapid Control packets in order to achieve its desired detection time. rapid Control packets in order to achieve its desired detection time.
Since BFD allows independent transmission rates in each direction, Since BFD allows independent transmission rates in each direction,
this is easily accomplished. this is easily accomplished.
A system SHOULD otherwise advertise the lowest value of Required Min A system SHOULD otherwise advertise the lowest value of Required Min
RX Interval and Required Min Echo RX Interval that it can under the RX Interval and Required Min Echo RX Interval that it can under the
circumstances, to give the other system more freedom in choosing its circumstances, to give the other system more freedom in choosing its
transmission rate. Note that a system is committing to be able to transmission rate. Note that a system is committing to be able to
receive both streams of packets at the rate it advertises, so this receive both streams of packets at the rate it advertises, so this
should be taken into account when choosing the values to advertise. should be taken into account when choosing the values to advertise.
6.5. Demand Mode 6.5. The Poll Sequence
Demand mode is negotiated by virtue of both systems setting the A Poll Sequence is an exchange of BFD Control packets that is used in
Demand (D) bit in its BFD Control packets. Both systems must request some circumstances to ensure that the remote system is aware of
Demand mode for it to become active. parameter changes. It is also used in Demand mode (see section 6.6)
to validate bidirectional connectivity.
A Poll Sequence consists of a system sending periodic BFD Control
packets with the Poll (P) bit set. When the other system receives a
Poll, it immediately transmits a BFD Control packet with the Final
(F) bit set, independent of any periodic BFD Control packets it may
be sending (see section 6.8.7). When the system sending the Poll
sequence receives a packet with Final, the Poll Sequence is
terminated, and any subsequent BFD Control packets are sent with the
Poll bit cleared. A BFD Control packet MUST NOT have both the Poll
(P) and Final (F) bits set.
If periodic BFD Control packets are already being sent (the remote
system is not in Demand mode), the Poll Sequence MUST be performed by
setting the Poll (P) bit on those scheduled periodic transmissions;
additional packets MUST NOT be sent.
After a Poll Sequence is terminated, the system requesting the Poll
Sequence will cease the periodic transmission of BFD Control packets
if the remote end is in Demand mode; otherwise it will return to the
periodic transmission of BFD Control packets with the Poll (P) bit
clear.
Typically, the entire sequence consists of a single packet in each
direction, though packet losses or relatively long packet latencies
may result in multiple Poll packets to be sent before the sequence
terminates.
6.6. Demand Mode
Demand mode is requested independently in each direction by virtue of
a system setting the Demand (D) bit in its BFD Control packets. The
Demand bit can only be set if both systems think the session is up.
The system receiving the Demand bit ceases the periodic transmission
of BFD Control packets. If both systems are operating in Demand
mode, no periodic BFD Control packets will flow in either direction.
Demand mode requires that some other mechanism is used to imply Demand mode requires that some other mechanism is used to imply
continuing connectivity between the two systems. The mechanism used continuing connectivity between the two systems. The mechanism used
does not have to be the same in both directions, and is outside of does not have to be the same in both directions, and is outside of
the scope of this specification. One possible mechanism is the the scope of this specification. One possible mechanism is the
receipt of traffic from the remote system; another is the use of the receipt of traffic from the remote system; another is the use of the
Echo function. Echo function.
Once a BFD session comes up, if Demand mode is active, both systems When a system in Demand mode wishes to verify bidirectional
stop sending periodic BFD Control packets, and depend on the connectivity, it initiates a Poll Sequence (see section 6.5). If no
alternative mechanism for maintaining ongoing connectivity. response is received to a Poll, the Poll is repeated until the
detection time expires, at which point the session is declared to be
When a system wishes to verify connectivity, it initiates a Poll down. Note that if Demand mode is operating only on the remote
Sequence. It starts periodically sending BFD Control packets with system, the Poll Sequence is performed on the local system by simply
the Poll (P) bit set, at the negotiated transmission rate. When a setting the Poll (P) bit in regular periodic BFD Control packets.
system receives such a packet, it immediately replies with a BFD
Control packet of its own, with the Poll (P) bit clear, and the Final
(F) bit set. The receipt of a reply to a Poll terminates the Poll
Sequence. If no response is received to a Poll, the Poll is repeated
until the detection time expires, at which point the session is
declared to be down.
The detection time in Demand mode is calculated differently than in The detection time in Demand mode is calculated differently than in
Asynchronous mode; it is based on the transmit rate of the local Asynchronous mode; it is based on the transmit rate of the local
system, rather than the transmit rate of the remote system. This system, rather than the transmit rate of the remote system. This
ensures that the Poll Sequence mechanism works properly. See section ensures that the Poll Sequence mechanism works properly. See section
6.7.8 for more details. 6.8.4 for more details.
Note that this mechanism requires that the detection time negotiated Note that this mechanism requires that the detection time negotiated
is greater than the round trip time between the two systems, or the is greater than the round trip time between the two systems, or the
Poll mechanism will always fail. Enforcement of this requirement is Poll mechanism will always fail. Enforcement of this requirement is
outside the scope of this specification. outside the scope of this specification.
Demand mode MAY be enabled or disabled at any time by setting or Demand mode MAY be enabled or disabled at any time, independently in
clearing the Demand (D) bit in the BFD Control packet, without each direction, by setting or clearing the Demand (D) bit in the BFD
affecting the BFD session state. Control packet, without affecting the BFD session state. Note that
the Demand bit MUST NOT be set unless both systems perceive the
session to be Up (the local system thinks the session is Up, and the
remote system last reported Up state in the State (Sta) field of the
BFD Control packet.)
When the transmitted value of the Demand (D) bit is to be changed,
the transmitting system MUST initiate a Poll Sequence in conjunction
with changing the bit in order to ensure that both systems are aware
of the change.
If Demand mode is active on either or both systems, a Poll Sequence
MUST be initiated whenever the contents of the next BFD Control
packet to be sent would be different than the contents of the
previous packet, with the exception of the Poll (P) and Final (F)
bits. This ensures that parameter changes are transmitted to the
remote system and that the remote system acknowledges these changes.
Because the underlying detection mechanism is unspecified, and may Because the underlying detection mechanism is unspecified, and may
differ between the two systems, the overall detection time differ between the two systems, the overall detection time
characteristics of the path will not be fully known to either system. characteristics of the path will not be fully known to either system.
The total detection time for a particular system is the sum of the The total detection time for a particular system is the sum of the
time prior to the initiation of the Poll Sequence, plus the time prior to the initiation of the Poll Sequence, plus the
calculated detection time. calculated detection time.
6.6. Authentication Note that if Demand mode is enabled in only one direction, continuous
bidirectional connectivity verification is lost (only connectivity in
the direction from the system in Demand mode to the other system will
be verified.) Resolving the issue of one system requesting Demand
mode while the other requires continuous bidirectional connectivity
verification is outside the scope of this specification.
6.7. Authentication
An optional Authentication Section may be present in the BFD Control An optional Authentication Section may be present in the BFD Control
packet. In its generic form, the purpose of the Authentication packet. In its generic form, the purpose of the Authentication
Section is to carry all necessary information, based on the Section is to carry all necessary information, based on the
authentication type in use, to allow the receiving system to authentication type in use, to allow the receiving system to
determine the validity of the received packet. The exact mechanism determine the validity of the received packet. The exact mechanism
depends on the authentication type in use, but in general the depends on the authentication type in use, but in general the
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.8.6.
Implementations supporting authentication MUST support SHA1 Implementations supporting authentication MUST support SHA1
authentication. Other forms of authentication are optional. authentication. Other forms of authentication are optional.
6.6.1. Enabling and Disabling Authentication 6.7.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
acceptance rules essentially require the local and remote machines to acceptance rules essentially require the local and remote machines to
do so in a more or less synchronized fashion (within the detect do so in a more or less synchronized fashion (within the detection
time)--a packet with authentication will only be accepted if time)--a packet with authentication will only be accepted if
authentication is "in use" (and likewise packets without authentication is "in use" (and likewise packets without
authentication. authentication.
One possible approach is to build an implementation such that One possible approach is to build an implementation such that
authentication is configured, but not considered "in use" until the authentication is configured, but not considered "in use" until the
first packet containing a matching authentication section is received first packet containing a matching authentication section is received
(providing the necessary synchronization.) Likewise, authentication (providing the necessary synchronization.) Likewise, authentication
could be configured off, but still considered "in use" until the could be configured off, but still considered "in use" until the
receipt of the first packet without the authentication section. receipt of the first packet without the authentication section.
In order to avoid security risks, implementations using this method In order to avoid security risks, implementations using this method
should only allow the authentication state to be changed once without should only allow the authentication state to be changed once without
some form of intervention (so that authentication cannot be turned on some form of intervention (so that authentication cannot be turned on
and off repeatedly simply based on the receipt of BFD Control packets and off repeatedly simply based on the receipt of BFD Control packets
from remote systems.) from remote systems.)
6.6.2. Simple Password Authentication 6.7.2. Simple Password Authentication
The most straightforward (and weakest) form of authentication is The most straightforward (and weakest) form of authentication is
Simple Password Authentication. In this method of authentication, Simple Password Authentication. In this method of authentication,
one or more Passwords (with corresponding Key IDs) are configured in one or more Passwords (with corresponding Key IDs) are configured in
each system and one of these Password/ID pairs is carried in each BFD each system and one of these Password/ID pairs is carried in each BFD
Control packet. The receiving system accepts the packet if the Control packet. The receiving system accepts the packet if the
Password and Key ID matches one of the Password/ID pairs configured Password and Key ID matches one of the Password/ID pairs configured
in that system. in that system.
Transmission Using Simple Password Authentication Transmission Using Simple Password Authentication
skipping to change at page 22, line 7 skipping to change at page 23, line 30
password, the received packet MUST be discarded. password, the received packet MUST be discarded.
If the Auth Len field is not equal to the length of the password If the Auth Len field is not equal to the length of the password
selected by the Key ID, plus three, the packet MUST be discarded. selected by the Key ID, plus three, the packet MUST be discarded.
If the Password field does not match the password selected by the If the Password field does not match the password selected by the
Key ID, the packet MUST be discarded. Key ID, the packet MUST be discarded.
Otherwise, the packet MUST be accepted. Otherwise, the packet MUST be accepted.
6.6.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are
very similar to those used in other protocols. In these methods of very similar to those used in other protocols. In these methods of
authentication, one or more secret keys (with corresponding Key IDs) authentication, one or more secret keys (with corresponding Key IDs)
are configured in each system. One of the Keys is included in an MD5 are configured in each system. One of the Keys is included in an MD5
[MD5] checksum calculated over the outgoing BFD Control packet, but [MD5] checksum calculated over the outgoing BFD Control packet, but
the Key itself is not carried in the packet. To help avoid replay the Key itself is not carried in the packet. To help avoid replay
attacks, a sequence number is also carried in each packet. For Keyed attacks, a sequence number is also carried in each packet. For Keyed
MD5, the sequence number is occasionally incremented. For Meticulous MD5, the sequence number is occasionally incremented. For Meticulous
Keyed MD5, the sequence number is incremented on every packet. Keyed MD5, the sequence number is incremented on every packet.
skipping to change at page 23, line 38 skipping to change at page 25, line 15
packet MUST be discarded. For Meticulous Keyed MD5, if the packet MUST be discarded. For Meticulous Keyed MD5, if the
Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32 bit circular number space, the received packet MUST be unsigned 32 bit circular number space, the received packet MUST be
discarded. discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received 1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted. Sequence Number field, and the received packet MUST be accepted.
6.6.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication
The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms
are very similar to those used in other protocols. In these methods are very similar to those used in other protocols. In these methods
of authentication, one or more secret keys (with corresponding Key of authentication, one or more secret keys (with corresponding Key
IDs) are configured in each system. One of the Keys is included in a IDs) are configured in each system. One of the Keys is included in a
SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet, SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet,
but the Key itself is not carried in the packet. To help avoid but the Key itself is not carried in the packet. To help avoid
replay attacks, a sequence number is also carried in each packet. replay attacks, a sequence number is also carried in each packet.
For Keyed SHA1, the sequence number is occasionally incremented. For For Keyed SHA1, the sequence number is occasionally incremented. For
Meticulous Keyed SHA1, the sequence number is incremented on every Meticulous Keyed SHA1, the sequence number is incremented on every
skipping to change at page 25, line 23 skipping to change at page 27, line 5
packet MUST be discarded. For Meticulous Keyed SHA1, if the packet MUST be discarded. For Meticulous Keyed SHA1, if the
Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32 bit circular number space, the received packet MUST be unsigned 32 bit circular number space, the received packet MUST be
discarded. discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received 1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted. Sequence Number field, and the received packet MUST be accepted.
6.7. Functional Specifics 6.8. Functional Specifics
The following section of this specification is normative. The means The following section of this specification is normative. The means
by which this specification is achieved is outside the scope of this by which this specification is achieved is outside the scope of this
specification. specification.
When a system is said to have "the Echo function active," it means When a system is said to have "the Echo function active," it means
that the system is sending BFD Echo packets, implying that the that the system is sending BFD Echo packets, implying that the
session is Up and the other system has signaled its willingness to session is Up and the other system has signaled its willingness to
loop back Echo packets. loop back Echo packets.
When a system is said to have "Demand mode active," it means that When the local system is said to have "Demand mode active," it means
bfd.DemandModeDesired is 1 in the local system (see State Variables that bfd.DemandMode is 1 in the local system (see section 6.8.1), the
below), the remote system is signalling with the Demand (D) bit set, session is Up, and the remote system is signaling that the session is
and that the session is Up. in state Up.
6.7.1. State Variables When the remote system is said to have "Demand mode active," it means
that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D)
bit in the last received BFD Control packet), the session is Up, and
the remote system is signaling that the session is in state Up.
6.8.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 When the text refers to initializing a state variable, this takes
place only at the time that the session (and the corresponding state place only at the time that the session (and the corresponding state
variables) is created. The state variables are subsequently variables) is created. The state variables are subsequently
manipulated by the state machine and are never reinitialized, even if manipulated by the state machine and are never reinitialized, even if
the session fails and is reestablished. the session fails and is reestablished.
Once session state is created, and at least one BFD Control packet is
received from the remote end, it MUST be preserved for at least one
Detection Time (see section 6.8.4) subsequent to the receipt of the
last BFD Control packet, regardless of the session state. This
preserves timing parameters in case the session flaps. A system MAY
preserve session state longer than this. The preservation or
destruction of session state when no BFD Control packets for this
session have been received from the remote system is outside the
scope of this specification.
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, 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 Down. variable MUST be initialized to Down.
bfd.RemoteSessionState
The session state last reported by the remote system in the
State (Sta) field of the BFD Control packet. This 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.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 change to states Down or AdminDown. This
(No Diagnostic.) MUST be initialized to zero (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
current time. The actual interval is negotiated between the current time. The actual interval is negotiated between the
two systems. This MUST be initialized to a value of at least two systems. This MUST be initialized to a value of at least
one second (1,000,000 microseconds) according to the rules one second (1,000,000 microseconds) according to the rules
described in section 6.7.3. The setting of this variable is described in section 6.8.3. The setting of this variable is
otherwise outside the scope of this specification. otherwise outside the scope of this specification.
bfd.RequiredMinRxInterval bfd.RequiredMinRxInterval
The minimum interval, in microseconds, between received BFD The minimum interval, in microseconds, between received BFD
Control packets that this system requires. The setting of this Control packets that this system requires. The setting of this
variable is outside the scope of this specification. variable is outside the scope of this specification. A value
of zero means that this system does not want to receive any
periodic BFD Control packets. See section 6.8.18 for details.
bfd.DemandModeDesired bfd.RemoteMinRxInterval
The last value of Required Min RX Interval received from the
remote system in a BFD Control packet. This variable MUST be
initialized to 1.
bfd.DemandMode
Set to 1 if the local system wishes to use Demand mode, or 0 if Set to 1 if the local system wishes to use Demand mode, or 0 if
not. not.
bfd.RemoteDemandMode
Set to 1 if the remote system wishes to use Demand mode, or 0
if not. This is the value of the Demand (D) bit in the last
received BFD Control packet. This variable MUST be initialized
to zero.
bfd.DetectMult bfd.DetectMult
The desired detect time multiplier for BFD Control packets. The desired detection time multiplier for BFD Control packets.
The negotiated Control packet transmission interval, multiplied The negotiated Control packet transmission interval, multiplied
by this variable, will be the detection time for this session by this variable, will be the detection time for this session
(as seen by the remote system.) This variable MUST be a (as seen by the remote system.) This variable MUST be a
nonzero integer, and is otherwise outside the scope of this nonzero integer, and is otherwise outside the scope of this
specification. See section 6.7.4 for further information. specification. See section 6.8.4 for further information.
bfd.AuthType bfd.AuthType
The authentication type in use for this session, as defined in The authentication type in use for this session, as defined in
section 4.1, or zero if no authentication is in use. section 4.1, or zero if no authentication is in use.
bfd.RcvAuthSeq bfd.RcvAuthSeq
A 32 bit unsigned integer containing the next sequence number A 32 bit unsigned integer containing the next sequence number
for keyed MD5 or SHA1 authentication expected to be received. for keyed MD5 or SHA1 authentication expected to be received.
skipping to change at page 28, line 16 skipping to change at page 30, line 33
Set to 1 if the next sequence number for keyed MD5 or SHA1 Set to 1 if the next sequence number for keyed MD5 or SHA1
authentication expected to be received is known, or 0 if it is authentication expected to be received is known, or 0 if it is
not known. This variable MUST be initialized to zero. not known. This variable MUST be initialized to zero.
This variable MUST be set to zero after no packets have been This variable MUST be set to zero after no packets have been
received on this session for at least twice the Detection Time. received on this session for at least twice the Detection Time.
This ensures that the sequence number can be resynchronized if This ensures that the sequence number can be resynchronized if
the remote system restarts. the remote system restarts.
6.7.2. Timer Negotiation 6.8.2. Timer Negotiation
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 are continuously negotiated, and thus and the session detection time are continuously negotiated, and thus
may be changed at any time. The negotiation and time values are may be changed at any time. The negotiation and time values are
independent in each direction for each session. Packets are always independent in each direction for each session.
periodically transmitted in Asynchronous mode, and are periodically
transmitted during Poll Sequences when in Demand mode.
Each system reports in the BFD Control packet how rapidly it would Each system reports in the BFD Control packet how rapidly it would
like to transmit BFD packets, as well as how rapidly it is prepared like to transmit BFD packets, as well as how rapidly it is prepared
to receive them. With the exceptions listed in the remainder of this to receive them. With the exceptions listed in the remainder of this
section, a system MUST NOT transmit BFD Control packets with an section, a system MUST NOT transmit BFD Control packets at an
interval less than the larger of bfd.DesiredMinTxInterval and the interval less than the larger of bfd.DesiredMinTxInterval and
received Required Min RX Interval field. In other words, the system bfd.RemoteMinRxInterval. In other words, the system reporting the
reporting the slower rate determines the transmission rate. slower rate determines the transmission rate.
The periodic transmission of BFD Control packets SHOULD be jittered The periodic transmission of BFD Control packets SHOULD be jittered
by up to 25%, that is, the interval SHOULD be reduced by a random by up to 25%, that is, the interval SHOULD be reduced by a random
value of 0 to 25%, in order to avoid self-synchronization. Thus, the value of 0 to 25%, in order to avoid self-synchronization. Thus, the
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.
A BFD Control packet SHOULD be transmitted during the interval 6.8.3. Timer Manipulation
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, 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 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 either bfd.DesiredMinTxInterval is changed or
changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
be initiated (see section 6.7.8). initiated (see section 6.5). If the timing is such that a system
receiving a Poll Sequence wishes to change the parameters described
If Demand mode is not active, bfd.SessionState is Up, and either in this paragraph, the new parameter values may be carried in packets
bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is with the Final (F) bit set, even if the Poll Sequence has not yet
changed, all subsequent transmitted Control packets MUST be sent with been sent.
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 and bfd.SessionState is Up, If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,
the actual transmission interval used MUST NOT change until a Control the actual transmission interval used MUST NOT change until the Poll
packet is received with the Final (F) bit set. This is to ensure Sequence described above has terminated. This is to ensure that the
that the remote system updates its Detect Time before the remote system updates its Detection Time before the transmission
transmission interval increases. interval increases.
If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
the calculated detection time for the remote system MUST NOT change the previous value of bfd.RequiredMinRxInterval MUST be used when
until a Control packet is received with the Final (F) bit set. This calculating the detection time for the remote system until the Poll
is to ensure that the remote system is transmitting packets at the Sequence described above has terminated. This is to ensure that the
higher rate (and those packets are being received) prior to the remote system is transmitting packets at the higher rate (and those
detection time being reduced. packets are being received) prior to the 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.
If the local system reduces its transmit interval due to
bfd.RemoteMinRxInterval being reduced (the remote system has
advertised a reduced value in Required Min RX Interval), and the
remote system is not in Demand mode, the local system MUST honor the
new interval immediately. In other words, the local system cannot
wait longer than the new interval between the previous packet
transmission and the next one. If this interval has already passed
since the last transmission (because the new interval is
significantly shorter), the local system MUST send the next periodic
BFD Control packet as soon as practicable.
When the Echo function is active, a system SHOULD set When the Echo function is active, a system SHOULD set
bfd.RequiredMinRxInterval to a value of not less than one second bfd.RequiredMinRxInterval to a value of not less than one second
(1,000,000 microseconds.) This is intended to keep received BFD (1,000,000 microseconds.) This is intended to keep received BFD
Control traffic at a negligible level, since the actual detection Control traffic at a negligible level, since the actual detection
function is being performed using BFD Echo packets. function is being performed using BFD Echo packets.
6.7.4. Calculating the Detection Time In any case other than those explicitly called out above, timing
parameter changes MUST be effected immediately (changing the
transmission rate and/or the Detection Time), and a Poll Sequence
SHOULD NOT be sent.
Note that the Poll Sequence mechanism is ambiguous if more than one
parameter change is made that would require its use, and those
multiple changes are spread across multiple packets (since the
semantics of the returning Final are unclear.) Therefore, if
multiple changes are made that require the use of a Poll Sequence,
there are three choices: 1) they MUST be communicated in a single
BFD Control packet (so the semantics of the Final reply are clear),
or 2) sufficient time must have transpired since the Poll Sequence
was completed to disambiguate the situation (at least a round trip
time since the last Poll was transmitted) prior to the initiation of
another Poll Sequence, or 3) an additional BFD Control packet with
the Final (F) bit *clear* MUST be received after the Poll Sequence
has completed prior to the initiation of another Poll Sequence (this
option is not available when Demand mode is active.)
6.8.4. Calculating the Detection Time
The Detection Time (the period of time without receiving BFD packets The Detection Time (the period of time without receiving BFD packets
after which the session is determined to have failed) is not carried after which the session is determined to have failed) is not carried
explicitly in the protocol. Rather, it is calculated independently explicitly in the protocol. Rather, it is calculated independently
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 there may
Asynchronous mode, there may be different detection times in each 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 of the remote system, multiplied by the agreed transmit interval of the remote
system (the greater of bfd.RequiredMinRxInterval and the last system (the greater of bfd.RequiredMinRxInterval and the last
received Desired Min TX Interval.) The Detect Mult value is (roughly received Desired Min TX Interval.) The Detect Mult value is (roughly
speaking, due to jitter) the number of packets that have to be missed speaking, due to jitter) the number of packets that have to be missed
in a row to 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 Down and gone down--the local system MUST set bfd.SessionState to Down and
bfd.LocalDiag to 1 (Control Detection Time Expired.) bfd.LocalDiag to 1 (Control Detection Time Expired.)
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
of the local system (the greater of bfd.DesiredMinTxInterval and the of the local system (the greater of bfd.DesiredMinTxInterval and
last received Required Min RX Interval.) bfd.DetectMult is (roughly bfd.RemoteMinRxInterval.) bfd.DetectMult is (roughly speaking, due
speaking, due to jitter) the number of packets that have to be missed to jitter) the number of packets that have to be missed in a row to
in a row to declare the session to be down. 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 Down, has gone down--the local system MUST set bfd.SessionState to Down,
and bfd.LocalDiag to 1 (Control Detection Time Expired.) and bfd.LocalDiag to 1 (Control Detection 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.8.6.)
6.7.5. Detecting Failures with the Echo Function 6.8.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 Down, and down--the local system MUST set bfd.SessionState to Down, and
bfd.LocalDiag to 2 (Echo Function Failed.) bfd.LocalDiag to 2 (Echo Function 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.8.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 (1), 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 Multipoint (M) bit is nonzero, 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 State field is not If the Your Discriminator field is zero and the State field is not
Down or AdminDown, the packet MUST be discarded. Down or AdminDown, the packet MUST be discarded.
skipping to change at page 32, line 14 skipping to change at page 35, line 6
discarded. This choice is outside the scope of this discarded. This choice is outside the scope of this
specification. specification.
If the A bit is set and no authentication is in use (bfd.AuthType If the A bit is set and no authentication is in use (bfd.AuthType
is zero), the packet MUST be discarded. is zero), the packet MUST be discarded.
If the A bit is clear and authentication is in use (bfd.AuthType If the A bit is clear and authentication is in use (bfd.AuthType
is nonzero), the packet MUST be discarded. is nonzero), the packet MUST be discarded.
If the A bit is set, the packet MUST be authenticated under the If the A bit is set, the packet MUST be authenticated under the
rules of section 6.6, based on the authentication type in use rules of section 6.7, based on the authentication type in use
(bfd.AuthType.) This may cause the packet to be discarded. (bfd.AuthType.) This may cause the packet to be discarded.
Set bfd.RemoteDiscr to the value of My Discriminator. Set bfd.RemoteDiscr to the value of My Discriminator.
Set bfd.RemoteState to the value of the State (Sta) field.
Set bfd.RemoteDemandMode to the value of the Demand (D) bit.
Set bfd.RemoteMinRxInterval to the value of Required Min RX
Interval.
If the Required Min Echo RX Interval field is zero, the If the Required Min Echo RX Interval field is zero, the
transmission of Echo packets, if any, MUST cease. transmission of Echo packets, if any, MUST cease.
If Demand mode is active, a Poll Sequence is being transmitted by If a Poll Sequence is being transmitted by the local system and
the local system, and the Final (F) bit in the received packet is the Final (F) bit in the received packet is set, the Poll Sequence
set, the Poll Sequence MUST be terminated. 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. Update the transmit interval as described in section 6.8.2.
Update the transmit interval as described in section 6.7.2. Update the Detection Time as described in section 6.8.4.
If bfd.SessionState is AdminDown If bfd.SessionState is AdminDown
Discard the packet Discard the packet
If received state is AdminDown If received state is AdminDown
If bfd.SessionState is not Down If bfd.SessionState is not Down
Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.LocalDiag to 3 (Neighbor signaled session down)
Set bfd.SessionState to Down Set bfd.SessionState to Down
Else Else
skipping to change at page 33, line 9 skipping to change at page 35, line 51
Set bfd.SessionState to Init Set bfd.SessionState to Init
Else if received State is Init Else if received State is Init
Set bfd.SessionState to Up Set bfd.SessionState to Up
Else if bfd.SessionState is Init Else if bfd.SessionState is Init
If received State is Init or Up If received State is Init or Up
Set bfd.SessionState to Up Set bfd.SessionState to Up
Else (bfd.SessionState is Up) Else (bfd.SessionState is Up)
If received State is Down If received State is Down
Set bfd.LocalDiag to 3 (Neighbor signaled session Set bfd.LocalDiag to 3 (Neighbor signaled session down)
down)
Set bfd.SessionState to Down Set bfd.SessionState to Down
If the Demand (D) bit is set and bfd.DemandModeDesired is 1, Check to see if Demand mode should become active or not
and bfd.SessionState is Up, Demand mode is active. (see section 6.6).
If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and
or bfd.SessionState is not Up, Demand mode is not bfd.RemoteSessionState is Up, Demand mode is active on the
active. remote system and the local system MUST cease the periodic
transmission of BFD Control packets (see section 6.8.7.)
If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or
bfd.RemoteSessionState is not Up, Demand mode is not active on the
remote system and the local system MUST send periodic BFD Control
packets (see section 6.8.7.)
If the Poll (P) bit is set, send a BFD Control packet to the If the Poll (P) bit is set, send a BFD Control packet to the
remote system with the Poll (P) bit clear, and the Final (F) bit remote system with the Poll (P) bit clear, and the Final (F) bit
set. set (see section 6.8.7.)
If the packet was not discarded, it has been received for purposes If the packet was not discarded, it has been received for purposes
of the Detection Time expiration rules in section 6.7.4. of the Detection Time expiration rules in section 6.8.4.
6.7.7. Transmitting BFD Control Packets 6.8.7. Transmitting BFD Control Packets
BFD Control packets MUST be transmitted periodically at the rate BFD Control packets MUST be transmitted periodically at the rate
determined according to section 6.7.2, except as specified in this determined according to section 6.8.2, except as specified in this
section. section.
The transmit interval MUST be recalculated whenever The transmit interval MUST be recalculated whenever
bfd.DesiredMinTxInterval changes, or whenever the received Required bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval
Min RX Interval changes, and is equal to the greater of those two changes, and is equal to the greater of those two values. See
values. See sections 6.7.2 and 6.7.3 for details on transmit timers. sections 6.8.2 and 6.8.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
bfd.RemoteMinRxInterval is zero.
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 on the remote system (bfd.RemoteDemandMode is 1,
bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll
Sequence is not being transmitted.
A system MUST send a BFD Control packet in response to a received BFD If a BFD Control packet is received with the Poll (P) bit set to 1,
Control Packet with the Poll (P) bit set, regardless of the BFD the receiving system MUST transmit a BFD Control packet with the Poll
session state. The packet sent in response MUST NOT have the Poll (P) bit clear and the Final (F) bit set as soon as practicable,
(P) bit set, and MUST have the Final (F) bit set. A system MAY limit without respect to the transmission timer or any other transmission
the rate at which such packets are transmitted. If rate limiting is limitations, without respect to the session state, and without
in effect, the advertised value of Desired Min TX Interval must be respect to whether Demand mode is active on either system. A system
greater than or equal to the interval between transmitted packets MAY limit the rate at which such packets are transmitted. If rate
imposed by the rate limiting function. 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 BFD Control packet SHOULD be transmitted between normally scheduled A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1,
transmissions when the contents of that packet would differ from bfd.SessionState is Up, and bfd.RemoteSessionState is Up.
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 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.
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 (1). Set to the current version number (1).
Diagnostic (Diag) Diagnostic (Diag)
Set to bfd.LocalDiag. Set to bfd.LocalDiag.
State (Sta) State (Sta)
Set to the value indicated by bfd.SessionState. 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 0 if
required to do so according to the requirements of section 6.7.3, 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
received with the Poll (P) bit set, or 0 if not. received with the Poll (P) bit set, or 0 if not.
Control Plane Independent (C) Control Plane Independent (C)
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.
Demand (D) Demand (D)
Set to bfd.DemandModeDesired. Set to bfd.DemandMode if bfd.SessionState is Up and
bfd.RemoteSessionState is Up. Otherwise it is set to 0.
Reserved (R) Multipoint (M)
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 36, line 14 skipping to change at page 39, line 22
Required Min Echo RX Interval Required Min Echo RX Interval
Set to the minimum required Echo packet receive interval for this Set to the minimum required Echo packet receive interval for this
session. If this field is set to zero, the local system is session. If this field is set to zero, the local system is
unwilling or unable to loop back BFD Echo packets to the remote unwilling or unable to loop back BFD Echo packets to the remote
system, and the remote system will not send Echo packets. system, and the remote system will not send Echo packets.
Authentication Section Authentication Section
Included and set according to the rules in section 6.6 if Included and set according to the rules in section 6.7 if
authentication is in use (bfd.AuthType is nonzero.) Otherwise authentication is in use (bfd.AuthType is nonzero.) Otherwise
this section is not present. this section is not present.
6.7.8. Initiation of a Poll Sequence 6.8.8. Reception of BFD Echo Packets
If Demand mode is active, a Poll Sequence MUST be initiated whenever
the contents of the next BFD Control packet to be sent would be
different than the contents of the previous packet, with the
exception of the Poll (P) and Final (F) bits. This ensures that
parameter changes are transmitted to the remote system.
If Demand mode is active, a Poll Sequence SHOULD be initiated
whenever the system feels the need to verify connectivity with the
remote system. The conditions under which this is desirable are
outside the scope of this specification.
If a Poll Sequence is being sent, and a new Poll Sequence is
initiated due to one of the above conditions, the detection interval
MUST be restarted in order to ensure that a full Poll Sequence is
transmitted under the new conditions.
6.7.9. Reception of BFD Echo Packets
A received BFD Echo packet MUST be demultiplexed to the appropriate A received BFD Echo packet MUST be demultiplexed to the appropriate
session for processing. A means of detecting missing Echo packets session for processing. A means of detecting missing Echo packets
MUST be implemented, which most likely involves processing of the MUST be implemented, which most likely involves processing of the
Echo packets that are received. The processing of received Echo Echo packets that are received. The processing of received Echo
packets is otherwise outside the scope of this specification. packets is otherwise outside the scope of this specification.
6.7.10. Transmission of BFD Echo Packets 6.8.9. Transmission of BFD Echo Packets
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Up. BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval. value in Required Min Echo RX Interval.
BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The
interval between transmitted BFD Echo packets MUST NOT be less than interval between transmitted BFD Echo packets MUST NOT be less than
the value advertised by the remote system in Required Min Echo RX the value advertised by the remote system in Required Min Echo RX
Interval, except as follows: Interval, except as follows:
A 25% jitter MAY be applied to the rate of transmission, such that A 25% jitter MAY be applied to the rate of transmission, such that
the actual interval MAY be between 75% and 100% of the advertised the actual interval MAY be between 75% and 100% of the advertised
value. A single BFD Echo packet MAY be transmitted between value. A single BFD Echo packet MAY be transmitted between
normally scheduled Echo transmission intervals. normally scheduled Echo transmission intervals.
The transmission of BFD Echo packets is otherwise outside the scope The transmission of BFD Echo packets is otherwise outside the scope
of this specification. of this specification.
6.7.11. Min Rx Interval Change 6.8.10. Min Rx Interval Change
When it is desired to change the rate at which BFD Control packets When it is desired to change the rate at which BFD Control packets
arrive from the remote system, bfd.RequiredMinRxInterval can be arrive from the remote system, bfd.RequiredMinRxInterval can be
changed at any time to any value. The new value will be transmitted changed at any time to any value. The new value will be transmitted
in the next outgoing Control packet, and the remote system will in the next outgoing Control packet, and the remote system will
adjust accordingly. See sections 6.7.3 and 6.7.8 for further adjust accordingly. See section 6.8.3 for further requirements.
requirements.
6.7.12. Min Tx Interval Change 6.8.11. Min Tx Interval Change
When it is desired to change the rate at which BFD Control packets When it is desired to change the rate at which BFD Control packets
are transmitted to the remote system (subject to the requirements of are transmitted to the remote system (subject to the requirements of
the neighboring system), bfd.DesiredMinTxInterval can be changed at the neighboring system), bfd.DesiredMinTxInterval can be changed at
any time to any value. The rules in sections 6.7.3 and 6.7.8 apply. any time to any value. The rules in section 6.8.3 apply.
6.7.13. Detect Multiplier Change 6.8.12. Detect Multiplier Change
When it is desired to change the detect multiplier, the value of When it is desired to change the detect multiplier, the value of
bfd.DetectMult can be changed to any nonzero value. The new value bfd.DetectMult can be changed to any nonzero value. The new value
will be transmitted with the next BFD Control packet. See section will be transmitted with the next BFD Control packet, and the use of
6.7.8 for additional requirements. a Poll Sequence is not necessary. See section 6.6 for additional
requirements.
6.7.14. Enabling or Disabling The Echo Function 6.8.13. Enabling or Disabling The Echo Function
If it is desired to start or stop the transmission of BFD Echo If it is desired to start or stop the transmission of BFD Echo
packets, this MAY be done at any time (subject to the transmission packets, this MAY be done at any time (subject to the transmission
requirements detailed in section 6.7.10.) requirements detailed in section 6.8.9.)
If it is desired to enable or disable the looping back of received If it is desired to enable or disable the looping back of received
BFD Echo packets, this MAY be done at any time by changing the value BFD Echo packets, this MAY be done at any time by changing the value
of Required Min RX Interval to zero or nonzero in outgoing BFD of Required Min Echo RX Interval to zero or nonzero in outgoing BFD
Control packets. Control packets.
6.7.15. Enabling or Disabling Demand Mode 6.8.14. Enabling or Disabling Demand Mode
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.DemandMode to the proper value. Demand mode
Demand mode is no longer active, the system MUST begin transmitting will subsequently become active under the rules described in section
periodic BFD Control packets as described in section 6.7.7. 6.6.
6.7.16. Forwarding Plane Reset If Demand mode is no longer active on the remote system, the local
system MUST begin transmitting periodic BFD Control packets as
described in section 6.8.7.
6.8.15. 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), and set bfd.SessionState to Down. (Forwarding Plane Reset), and set bfd.SessionState to Down.
6.7.17. Administrative Control 6.8.16. 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 Down Set bfd.SessionState to Down
Else Else
Set bfd.SessionState to AdminDown Set bfd.SessionState to AdminDown
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 If signaling is received from outside BFD that the underlying
path has failed, an implementation MAY adminstratively disable path has failed, an implementation MAY administratively disable
the session with the diagnostic Path Down. the session 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.8.17. Concatenated Paths
If the path being monitored by BFD is concatenated with other paths, If the path being monitored by BFD is concatenated with other paths,
it may be desirable to propagate the indication of a failure of one it may be desirable to propagate the indication of a failure of one
of those paths across the BFD session (providing an interworking of those paths across the BFD session (providing an interworking
function for liveness monitoring between BFD and other technologies.) function for liveness monitoring between BFD and other technologies.)
Two diagnostic codes are defined for this purpose: Concatenated Path Two diagnostic codes are defined for this purpose: Concatenated Path
Down and Reverse Concatenated Path Down. The first propagates Down and Reverse Concatenated Path Down. The first propagates
forward path failures (in which the concatenated path fails in the forward path failures (in which the concatenated path fails in the
direction toward the interworking system), and the second propagates direction toward the interworking system), and the second propagates
reverse path failures (in which the concatenated path fails in the reverse path failures (in which the concatenated path fails in the
direction away from the interworking system, assuming a bidirectional direction away from the interworking system, assuming a bidirectional
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 on the
action is necessary, as the diagnostic code will be carried via the remote system, no other action is necessary, as the diagnostic code
periodic transmission of BFD Control packets. If Demand Mode is will be carried via the periodic transmission of BFD Control packets.
active, a Poll Sequence MUST be initiated to ensure that the If Demand mode is active on the remote system (the local system is
diagnostic code is transmitted. Note that if the BFD session not transmitting periodic BFD Control packets), a Poll Sequence MUST
subsequently fails, the diagnostic code will be overwritten with a be initiated to ensure that the diagnostic code is transmitted. Note
code detailing the cause of the failure. It is up to the that if the BFD session subsequently fails, the diagnostic code will
interworking agent to perform the above procedure again, once the BFD be overwritten with a code detailing the cause of the failure. It is
session reaches Up state, if the propagation of the concatenated path up to the interworking agent to perform the above procedure again,
failure is to resume. once the BFD session reaches Up state, if the propagation of the
concatenated path failure is to resume.
6.8.18. Holding Down Sessions
A system may choose to prevent a BFD session from being established.
One possible reason might be to manage the rate at which sessions are
established. This can be done by holding the session in Down or
AdminDown state, as appropriate.
There are two related mechanisms that are available to help with this
task. First, a system is required to maintain session state
(including timing parameters), even when a session is down, until a
Detection Time has passed without the receipt of any BFD Control
packets. This means that a system may take down a session and
transmit an arbitrarily large value in the Required Min RX Interval
field to control the rate at which it receives packets.
Additionally, a system may transmit a value of zero for Required Min
RX Interval to indicate that the remote system should send no packets
whatsoever.
So long as the local system continues to transmit BFD Control
packets, the remote system is obligated to obey the value carried in
Required Min RX Interval. If the remote system does not receive any
BFD Control packets for a Detection Time, it resets
bfd.RemoteMinRxIvl to a small value and then can transmit at its own
rate.
Backward Compatibility (Non-Normative) Backward Compatibility (Non-Normative)
Although Version 0 of this document is unlikely to have been deployed Although Version 0 of this document is unlikely to have been deployed
widely, some implementors may wish to have a backward compatibility widely, some implementors may wish to have a backward compatibility
mechanism. Note that any mechanism may be potentially used that does mechanism. Note that any mechanism may be potentially used that does
not alter the protocol definition, so interoperability should not be not alter the protocol definition, so interoperability should not be
an issue. an issue.
The suggested mechanism described here has the property that it will The suggested mechanism described here has the property that it will
skipping to change at page 40, line 33 skipping to change at page 44, line 10
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, Pekka Savola, and Richard Spencer for their Stewart Bryant, Pekka Savola, and Richard Spencer for their
substantive input. 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
skipping to change at page 43, line 5 skipping to change at page 46, line 21
Phone: +1-408-745-2000 Phone: +1-408-745-2000
Email: dkatz@juniper.net Email: dkatz@juniper.net
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 only substantive change from the previous draft is to fix a bug The most significant technical change in this draft is a rework of
in section 6.4 regarding the manipulation of timers when the Echo Demand Mode, based on bugs turned up by implementation experience.
Function is active. The previous text discussed manipulation of the Additionally, Demand Mode can now be enabled independently in each
transmit timing, when it is actually the receive timing that matters. direction.
This change does not affect interoperability or correctness of
function, but instead properly describes an optimization.
All other changes are purely editorial in nature. Text was added requiring that an implementation maintain session
state for a detection time after the session goes down, to ensure
that the remote end can still control the transmit rate of the local
system even when the session isn't up. In conjunction with this, the
semantics of Required Min RX Interval so that a value of zero informs
the remote system that it cannot send any periodic BFD Control
packets.
Additional state variables were added to support Demand mode, and to
simplify the text elsewhere.
Text describing how to disambiguate multiple Poll Sequences in the
face of multiple parameter changes was added.
The pseudocode describing packet reception was reordered slightly.
Text regarding the semantics of Down and AdminDown state was added.
Many editorial changes were made. The most significant is to unify
the concept of a Poll Sequence (so that it is independent of Demand
Mode.) Explanatory text was added in a number of places based on
feedback from implementors.
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.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
skipping to change at page 44, line 7 skipping to change at page 47, line 36
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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 December, 2006. This document expires in September, 2007.
 End of changes. 120 change blocks. 
284 lines changed or deleted 451 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/