draft-ietf-bfd-base-06.txt   draft-ietf-bfd-base-07.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: September, 2007 March, 2007 Expires: July, 2008 January, 2008
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-06.txt draft-ietf-bfd-base-07.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 3, line 7 skipping to change at page 3, line 7
6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36
6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39
6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39
6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40
6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40
6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40
6.8.13 Enabling or Disabling the Echo Function . . . . . 40 6.8.13 Enabling or Disabling the Echo Function . . . . . 40
6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41
6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41
6.8.16 Administrative Control . . . . . . . . . . . . . 41 6.8.16 Administrative Control . . . . . . . . . . . . . 41
6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 41 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 42
6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42
Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
Security Considerations . . . . . . . . . . . . . . . . . . . . 44 Security Considerations . . . . . . . . . . . . . . . . . . . . 44
IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45
Normative References . . . . . . . . . . . . . . . . . . . . . 45 Normative References . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
Changes from the previous draft . . . . . . . . . . . . . . . . 46 Changes from the previous draft . . . . . . . . . . . . . . . . 46
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 47 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 46
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
example, failing interfaces or forwarding engine components. example, failing interfaces or forwarding engine components.
Networks use relatively slow "Hello" mechanisms, usually in routing Networks use relatively slow "Hello" mechanisms, usually in routing
protocols, to detect failures when there is no hardware signaling to protocols, to detect failures when there is no hardware signaling to
help out. The time to detect failures ("detection times") available help out. The time to detect failures ("Detection Times") available
in the existing protocols are no better than a second, which is far in the existing protocols are no better than a second, which is far
too long for some applications and represents a great deal of lost too long for some applications and represents a great deal of lost
data at gigabit rates. Furthermore, routing protocol Hellos are of data at gigabit rates. Furthermore, routing protocol Hellos are of
no help when those routing protocols are not in use, and the no help when those routing protocols are not in use, and the
semantics of detection are subtly different--they detect a failure in semantics of detection are subtly different--they detect a failure in
the path between the two routing protocol engines. the path between the two routing protocol engines.
The goal of BFD is to provide low-overhead, short-duration detection The goal of BFD is to provide low-overhead, short-duration detection
of failures in the path between adjacent forwarding engines, of failures in the path between adjacent forwarding engines,
including the interfaces, data link(s), and to the extent possible including the interfaces, data link(s), and to the extent possible
the forwarding engines themselves. the forwarding engines themselves.
An additional goal is to provide a single mechanism that can be used An additional goal is to provide a single mechanism that can be used
for liveness detection over any media, at any protocol layer, with a for liveness detection over any media, at any protocol layer, with a
wide range of detection times and overhead, to avoid a proliferation wide range of Detection Times and overhead, to avoid a proliferation
of different methods. of different methods.
This document specifies the details of the base protocol. The use of This document specifies the details of the base protocol. The use of
some mechanisms are application dependent and are specified in a some mechanisms are application dependent and are specified in a
separate series of application documents. These issues are so noted. separate series of application documents. These issues are so noted.
Note that many of the exact mechanisms are implementation dependent Note that many of the exact mechanisms are implementation dependent
and will not affect interoperability, and are thus outside the scope and will not affect interoperability, and are thus outside the scope
of this specification. Those issues are so noted. of this specification. Those issues are so noted.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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
mode.) mode.)
Pure asynchronous mode is advantageous in that it requires half as Pure asynchronous mode is advantageous in that it requires half as
many packets to achieve a particular detection time as does the Echo many packets to achieve a particular Detection Time as does the Echo
function. It is also used when the Echo function cannot be supported function. It is also used when the Echo function cannot be supported
for some reason. for some reason.
The Echo function has the advantage of truly testing only the The Echo function has the advantage of truly testing only the
forwarding path on the remote system. This may reduce round-trip forwarding path on the remote system. This may reduce round-trip
jitter and thus allow more aggressive detection times, as well as jitter and thus allow more aggressive Detection Times, as well as
potentially detecting some classes of failure that might not potentially detecting some classes of failure that might not
otherwise be detected. otherwise be detected.
The Echo function may be enabled individually in each direction. It The Echo function may be enabled individually in each direction. It
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 may not be used when the path round trip time is greater than mode may not be used when the path round trip time is greater than
the desired detection time. See section 6.6 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 specification. See the appropriate application document for this specification. See the appropriate application document for
encapsulation details. encapsulation details.
skipping to change at page 9, line 39 skipping to change at page 9, line 39
Demand mode is not active in the transmitting system. Demand mode is not active in the transmitting system.
Multipoint (M) Multipoint (M)
This bit is reserved for future point-to-multipoint extensions to This bit is reserved for future point-to-multipoint extensions to
BFD. It must be zero on both transmit and receipt. BFD. It must be zero on both transmit and receipt.
Detect Mult Detect Mult
Detection 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
transmitting system, used to demultiplex multiple BFD sessions transmitting system, used to demultiplex multiple BFD sessions
skipping to change at page 15, line 42 skipping to change at page 15, line 42
packets. When bidirectional communication is achieved, the BFD packets. When bidirectional communication is achieved, the BFD
session comes Up. session comes Up.
Once the BFD session is Up, a system can choose to start the Echo Once the BFD session is Up, a system can choose to start the Echo
function if it desires to and the other system signals that it will function if it desires to and the other system signals that it will
allow it. The rate of transmission of Control packets is typically allow it. The rate of transmission of Control packets is typically
kept low when the Echo function is active. kept low when the Echo function is active.
If the Echo function is not active, the transmission rate of Control If the Echo function is not active, the transmission rate of Control
packets may be increased to a level necessary to achieve the packets may be increased to a level necessary to achieve the
detection time requirements for the session. Detection Time requirements for the session.
Once the session is up, a system may signal that it has entered Once the session is up, a system may signal that it has entered
Demand mode, and the transmission of BFD Control packets by the Demand mode, and the transmission of BFD Control packets by the
remote system ceases. Other means of implying connectivity are used remote system ceases. Other means of implying connectivity are used
to keep the session alive. If either system wishes to verify to keep the session alive. If either system wishes to verify
bidirectional connectivity, it can initiate a short exchange of BFD bidirectional connectivity, it can initiate a short exchange of BFD
Control packets (a "Poll Sequence"; see section 6.5) to do so. 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.8.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.8.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.6. in the same manner. See section 6.6.
skipping to change at page 17, line 6 skipping to change at page 17, line 6
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 Semantically, Down state indicates that the forwarding path is
unavailable, and that appropriate actions should be taken by the unavailable, and that appropriate actions should be taken by the
applications monitoring the state of the BFD session. A system MAY applications monitoring the state of the BFD session. A system MAY
hold a session in Down state indefinitely (by simply refusing to hold a session in Down state indefinitely (by simply refusing to
advance the session state.) This may be done for operational or advance the session state.) This may be done for operational or
adminstrative reasons, among others. administrative 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 signaling 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. AdminDown state there until the local system exits AdminDown state. AdminDown state
has no semantic implications for the availability of the forwarding has no semantic implications for the availability of the forwarding
path. 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.8.6.) The notation on each arc are fully specified in sections 6.8.6 and 6.8.16.) The notation on
represents the state of the remote system (as received in the State each arc represents the state of the remote system (as received in
field in the BFD Control packet) or indicates the expiration of the the State field in the BFD Control packet) or indicates the
Detection Timer. expiration of the Detection Timer.
+--+ +--+
| | UP, ADMIN DOWN, TIMER | | UP, ADMIN DOWN, TIMER
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
skipping to change at page 19, line 21 skipping to change at page 19, line 21
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.8.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.
skipping to change at page 20, line 36 skipping to change at page 20, line 36
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.
When a system in Demand mode wishes to verify bidirectional When a system in Demand mode wishes to verify bidirectional
connectivity, it initiates a Poll Sequence (see section 6.5). If no connectivity, it initiates a Poll Sequence (see section 6.5). If no
response is received to a Poll, the Poll is repeated until the response is received to a Poll, the Poll is repeated until the
detection time expires, at which point the session is declared to be Detection Time expires, at which point the session is declared to be
down. Note that if Demand mode is operating only on the remote down. Note that if Demand mode is operating only on the local
system, the Poll Sequence is performed on the local system by simply system, the Poll Sequence is performed by simply setting the Poll (P)
setting the Poll (P) bit in regular periodic BFD Control packets. bit in regular periodic BFD Control packets, as required by section
6.6.
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.8.4 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, independently in Demand mode MAY be enabled or disabled at any time, independently in
each direction, by setting or clearing the Demand (D) bit in the BFD each direction, by setting or clearing the Demand (D) bit in the BFD
Control packet, without affecting the BFD session state. Note that Control packet, without affecting the BFD session state. Note that
the Demand bit MUST NOT be set unless both systems perceive the 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 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 remote system last reported Up state in the State (Sta) field of the
skipping to change at page 21, line 26 skipping to change at page 21, line 27
of the change. of the change.
If Demand mode is active on either or both systems, a Poll Sequence If Demand mode is active on either or both systems, a Poll Sequence
MUST be initiated whenever the contents of the next BFD Control MUST be initiated whenever the contents of the next BFD Control
packet to be sent would be different than the contents of the packet to be sent would be different than the contents of the
previous packet, with the exception of the Poll (P) and Final (F) previous packet, with the exception of the Poll (P) and Final (F)
bits. This ensures that parameter changes are transmitted to the bits. This ensures that parameter changes are transmitted to the
remote system and that the remote system acknowledges these changes. 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.
Note that if Demand mode is enabled in only one direction, continuous Note that if Demand mode is enabled in only one direction, continuous
bidirectional connectivity verification is lost (only connectivity in bidirectional connectivity verification is lost (only connectivity in
the direction from the system in Demand mode to the other system will the direction from the system in Demand mode to the other system will
be verified.) Resolving the issue of one system requesting Demand be verified.) Resolving the issue of one system requesting Demand
mode while the other requires continuous bidirectional connectivity mode while the other requires continuous bidirectional connectivity
verification is outside the scope of this specification. verification is outside the scope of this specification.
6.7. Authentication 6.7. Authentication
skipping to change at page 22, line 23 skipping to change at page 22, line 24
6.7.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 detection 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.
skipping to change at page 28, line 35 skipping to change at page 28, line 35
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.
If a period of a Detection Time passes without the receipt of a
valid, authenticated BFD packet from the remote system, this
variable MUST be set 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 change to states Down or AdminDown. This local session state change to states Down or AdminDown. This
MUST be initialized to zero (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.8.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.
skipping to change at page 29, line 38 skipping to change at page 29, line 42
bfd.RemoteDemandMode bfd.RemoteDemandMode
Set to 1 if the remote system wishes to use Demand mode, or 0 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 if not. This is the value of the Demand (D) bit in the last
received BFD Control packet. This variable MUST be initialized received BFD Control packet. This variable MUST be initialized
to zero. to zero.
bfd.DetectMult bfd.DetectMult
The desired detection 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.8.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
skipping to change at page 30, line 36 skipping to change at page 30, line 38
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.8.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. independent in each direction for each session.
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 at an section, a system MUST NOT transmit BFD Control packets at an
interval less than the larger of bfd.DesiredMinTxInterval and interval less than the larger of bfd.DesiredMinTxInterval and
bfd.RemoteMinRxInterval. In other words, the system reporting the bfd.RemoteMinRxInterval. In other words, the system reporting the
slower rate determines the transmission rate. slower rate determines the transmission rate.
skipping to change at page 31, line 19 skipping to change at page 31, line 23
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.
6.8.3. Timer Manipulation 6.8.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 either bfd.DesiredMinTxInterval is changed or If either bfd.DesiredMinTxInterval is changed or
bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
initiated (see section 6.5). If the timing is such that a system initiated (see section 6.5). If the timing is such that a system
receiving a Poll Sequence wishes to change the parameters described receiving a Poll Sequence wishes to change the parameters described
in this paragraph, the new parameter values may be carried in packets in this paragraph, the new parameter values may be carried in packets
with the Final (F) bit set, even if the Poll Sequence has not yet with the Final (F) bit set, even if the Poll Sequence has not yet
been sent. been sent.
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 the Poll the actual transmission interval used MUST NOT change until the Poll
Sequence described above has terminated. This is to ensure that the Sequence described above has terminated. This is to ensure that the
remote system updates its Detection Time before the transmission remote system updates its Detection Time before the 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 previous value of bfd.RequiredMinRxInterval MUST be used when the previous value of bfd.RequiredMinRxInterval MUST be used when
calculating the detection time for the remote system until the Poll calculating the Detection Time for the remote system until the Poll
Sequence described above has terminated. This is to ensure that the Sequence described above has terminated. This is to ensure that the
remote system is transmitting packets at the higher rate (and those remote system is transmitting packets at the higher rate (and those
packets are being received) prior to the detection time being packets are being received) prior to the Detection Time being
reduced. 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 If the local system reduces its transmit interval due to
bfd.RemoteMinRxInterval being reduced (the remote system has bfd.RemoteMinRxInterval being reduced (the remote system has
skipping to change at page 32, line 24 skipping to change at page 32, line 27
BFD Control packet as soon as practicable. 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.
In any case other than those explicitly called out above, timing In any case other than those explicitly called out above, timing
parameter changes MUST be effected immediately (changing the parameter changes MUST be effected immediately (changing the
transmission rate and/or the Detection Time), and a Poll Sequence transmission rate and/or the Detection Time).
SHOULD NOT be sent.
Note that the Poll Sequence mechanism is ambiguous if more than one Note that the Poll Sequence mechanism is ambiguous if more than one
parameter change is made that would require its use, and those parameter change is made that would require its use, and those
multiple changes are spread across multiple packets (since the multiple changes are spread across multiple packets (since the
semantics of the returning Final are unclear.) Therefore, if semantics of the returning Final are unclear.) Therefore, if
multiple changes are made that require the use of a Poll Sequence, multiple changes are made that require the use of a Poll Sequence,
there are three choices: 1) they MUST be communicated in a single there are three choices: 1) they MUST be communicated in a single
BFD Control packet (so the semantics of the Final reply are clear), BFD Control packet (so the semantics of the Final reply are clear),
or 2) sufficient time must have transpired since the Poll Sequence or 2) sufficient time must have transpired since the Poll Sequence
was completed to disambiguate the situation (at least a round trip was completed to disambiguate the situation (at least a round trip
skipping to change at page 32, line 49 skipping to change at page 32, line 51
has completed prior to the initiation of another Poll Sequence (this has completed prior to the initiation of another Poll Sequence (this
option is not available when Demand mode is active.) option is not available when Demand mode is active.)
6.8.4. Calculating the Detection Time 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 there may transmit interval and the detection multiplier. Note that there may
be different detection times in each direction. be different Detection Times in each 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
skipping to change at page 36, line 4 skipping to change at page 36, line 4
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 down) Set bfd.LocalDiag to 3 (Neighbor signaled session down)
Set bfd.SessionState to Down Set bfd.SessionState to Down
Check to see if Demand mode should become active or not Check to see if Demand mode should become active or not (see
(see section 6.6). section 6.6).
If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and
bfd.RemoteSessionState is Up, Demand mode is active on the bfd.RemoteSessionState is Up, Demand mode is active on the remote
remote system and the local system MUST cease the periodic system and the local system MUST cease the periodic transmission
transmission of BFD Control packets (see section 6.8.7.) of BFD Control packets (see section 6.8.7.)
If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or
bfd.RemoteSessionState is not Up, Demand mode is not active on the bfd.RemoteSessionState is not Up, Demand mode is not active on the
remote system and the local system MUST send periodic BFD Control remote system and the local system MUST send periodic BFD Control
packets (see section 6.8.7.) 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 (see section 6.8.7.) set (see section 6.8.7.)
skipping to change at page 41, line 37 skipping to change at page 41, line 37
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 signaling is received from outside BFD that the underlying If signaling is received from outside BFD that the underlying path
path has failed, an implementation MAY administratively disable has failed, an implementation MAY administratively disable the
the session with the diagnostic Path Down. session with the diagnostic Path Down.
Other scenarios MAY use the diagnostic Administratively Down. Other scenarios MAY use the diagnostic Administratively Down.
BFD Control packets SHOULD be transmitted for at least a Detection
Time after transitioning to AdminDown state in order to ensure that
the remote system is aware of the state change. BFD Control packets
MAY be transmitted indefinitely after transitioning to AdminDown
state in order to maintain session state in each system (see section
6.8.18 below.)
6.8.17. 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
skipping to change at page 43, line 15 skipping to change at page 43, line 22
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
converge on version 1 if both systems implement it, even if one converge on version 1 if both systems implement it, even if one
system is upgraded from version 0 within a detection time. It will system is upgraded from version 0 within a Detection Time. It will
interoperate with a system that implements only one version (or is interoperate with a system that implements only one version (or is
configured to support only one version.) A system should obviously configured to support only one version.) A system should obviously
not perform this function if it is configured to or is only capable not perform this function if it is configured to or is only capable
of using a single version. of using a single version.
A BFD session will enter a "negotiation holddown" if it is configured A BFD session will enter a "negotiation holddown" if it is configured
for automatic versioning and either has just started up, or the for automatic versioning and either has just started up, or the
session has been manually cleared. The session is set to AdminDown session has been manually cleared. The session is set to AdminDown
state and Version 1. During the holddown period, which lasts for one state and Version 1. During the holddown period, which lasts for one
detection time, the system sends BFD Control packets as usual, but Detection Time, the system sends BFD Control packets as usual, but
ignores received packets. After the holddown time is complete, the ignores received packets. After the holddown time is complete, the
state transitions to Down and normal operation resumes. state transitions to Down and normal operation resumes.
When a system is not in holddown, if it doing automatic versioning When a system is not in holddown, if it doing automatic versioning
and is currently using Version 1, if any Version 0 packet is received and is currently using Version 1, if any Version 0 packet is received
for the session, it switches immediately to Version 0. If it is for the session, it switches immediately to Version 0. If it is
currently using Version 0 and a Version 1 packet is received that currently using Version 0 and a Version 1 packet is received that
indicates that the neighbor is in state AdminDown, it switches to indicates that the neighbor is in state AdminDown, it switches to
Version 1. If using Version 0 and a Version 1 packet is received Version 1. If using Version 0 and a Version 1 packet is received
indicating a state other than AdminDown, the packet is ignored (per indicating a state other than AdminDown, the packet is ignored (per
skipping to change at page 44, line 17 skipping to change at page 44, line 22
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.
The authors would also like to thank Owen Wheeler for hosting
teleconferences between the authors of this specification and
multiple vendors in order address implementation and clarity issues.
Security Considerations Security Considerations
As BFD may be tied into the stability of the network infrastructure As BFD may be tied into the stability of the network infrastructure
(such as routing protocols), the effects of an attack on a BFD (such as routing protocols), the effects of an attack on a BFD
session may be very serious. This ultimately has denial-of-service session may be very serious. This ultimately has denial-of-service
effects, as links may be declared to be down (or falsely declared to effects, as links may be declared to be down (or falsely declared to
be up.) be up.)
When BFD is run over network layer protocols, a significant denial- When BFD is run over network layer protocols, a significant denial-
of-service risk is created, as BFD packets may be trivial to spoof. of-service risk is created, as BFD packets may be trivial to spoof.
skipping to change at page 45, line 30 skipping to change at page 45, line 41
Discriminator may be changed at any time during a session, this Discriminator may be changed at any time during a session, this
mechanism may also help mitigate attacks. mechanism may also help mitigate attacks.
IANA Considerations IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
Normative References Normative References
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
(GTSM)", RFC 3682, February 2004. (GTSM)", RFC 5082, October 2007.
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[SHA1] "Secure Hash Standard", United States of America, National [SHA1] "Secure Hash Standard", United States of America, National
skipping to change at page 46, line 23 skipping to change at page 46, line 29
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 most significant technical change in this draft is a rework of A correction was made to the description of Demand mode in section
Demand Mode, based on bugs turned up by implementation experience. 6.6. Another correction was made to the interaction between timing
Additionally, Demand Mode can now be enabled independently in each changes and the transmission of a Poll Sequence in section 6.8.3.
direction. The requirement to clear bfd.RemoteDiscr when the remote system falls
silent was added to section 6.8.1. The continuing transmission of
Text was added requiring that an implementation maintain session Control packets in AdminDown state was added to section 6.8.16. All
state for a detection time after the session goes down, to ensure other changes are purely editorial in nature.
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 47, line 36 skipping to change at page 47, line 26
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 IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE 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 September, 2007. This document expires in July, 2008.
 End of changes. 48 change blocks. 
82 lines changed or deleted 76 lines changed or added

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