draft-ietf-bfd-multipoint-03.txt   draft-ietf-bfd-multipoint-04.txt 
Network Working Group D. Katz Internet Engineering Task Force D. Katz
Internet Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Proposed Standard D. Ward Intended status: Standards Track D. Ward
Cisco Expires: February 13, 2015 Cisco Systems
S. Pallagatti, Ed.
Expires: August, 2014 February 4, 2014 Juniper Networks
August 12, 2014
BFD for Multipoint Networks BFD for Multipoint Networks
draft-ietf-bfd-multipoint-03.txt draft-ietf-bfd-multipoint-04
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks. Comments on this draft should be directed to rtg-
bfd@ietf.org.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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 other Task Force (IETF). Note that other groups may also distribute
groups may also distribute working documents as Internet-Drafts. working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on February 13, 2015.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks. Comments on this draft should be directed to
rtg-bfd@ietf.org.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Multipoint BFD Control Packets . . . . . . . . . . . . . . 6 4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 5
4.2 Session Model . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Session Failure Semantics . . . . . . . . . . . . . . . . 7 4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 6
4.4 State Variables . . . . . . . . . . . . . . . . . . . . . 7 4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 7
4.4.1 New State Variables . . . . . . . . . . . . . . . . . 7 4.4.1. New State Variables . . . . . . . . . . . . . . . . . 7
4.4.2 State Variable Initialization and Maintenance . . . . 9 4.4.2. State Variable Initialization and Maintenance . . . . 8
4.5 Controlling Multipoint BFD Options . . . . . . . . . . . 10 4.5. Controlling Multipoint BFD Options . . . . . . . . . . . 9
4.6 State Machine . . . . . . . . . . . . . . . . .. . . . . 10 4.6. State Machine . . . . . . . . . . . . . . . . . . . . . . 10
4.7 Session Establishment . . . . . . . . . . . . . . . . . 11 4.7. Session Establishment . . . . . . . . . . . . . . . . . . 10
4.8 Discriminators and Packet Demultiplexing . . . . . . . . 12 4.8. Discriminators and Packet Demultiplexing . . . . . . . . 11
4.9 Controlling Tail Packet Transmission . . . . . . . . . . 12 4.9. Controlling Tail Packet Transmission . . . . . . . . . . 11
4.10 Bringing Up and Shutting Down Multipoint BFD Service . 13 4.10. Bringing Up and Shutting Down Multipoint BFD Service . . 12
4.11 Soliciting the Tails . . . . . . . . . . . . . . . . . 14 4.11. Soliciting the Tails . . . . . . . . . . . . . . . . . . 13
4.12 Verifying Connectivity to Specific Tails . . . . . . . 14 4.12. Verifying Connectivity to Specific Tails . . . . . . . . 13
4.13 Timer Manipulation . . . . . . . . . . . . . . . . . . 15 4.13. Timer Manipulation . . . . . . . . . . . . . . . . . . . 14
4.14 Detection Times . . . . . . . . . . . . . . . . . . . . 15 4.14. Detection Times . . . . . . . . . . . . . . . . . . . . . 14
4.15 State Maintenance for Down/AdminDown Sessions . . . . . 16 4.15. State Maintenance for Down/AdminDown Sessions . . . . . . 15
4.15.1 MultipointHead Sessions . . . . . . . . . . . . . 16 4.15.1. MultipointHead Sessions . . . . . . . . . . . . . . 15
4.15.2 MultipointTail Sessions . . . . . . . . . . . . . 16 4.15.2. MultipointTail Sessions . . . . . . . . . . . . . . 15
4.15.3 MultipointClient Sessions . . . . . . . . . . . . 17 4.15.3. MultipointClient Sessions . . . . . . . . . . . . . 16
4.16 Base Specification Text Replacement . . . . . . . . . . 17 4.16. Base Specification Text Replacement . . . . . . . . . . . 16
4.16.1 Reception of BFD Control Packets . . . . . . . . 17 4.16.1. Reception of BFD Control Packets . . . . . . . . . . 16
4.16.2 Demultiplexing of BFD Control Packets . . . . . . 20 4.16.2. Demultiplexing BFD Control Packets . . . . . . . . . 19
4.16.3 Transmitting BFD Control Packets . . . . . . . . 21 4.16.3. Transmitting BFD Control Packets . . . . . . . . . . 20
5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Operational Scenarios . . . . . . . . . . . . . . . . . . . 25 6. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 24
6.1 No Head Notification . . . . . . . . . . . . . . . . . . 26 6.1. No Head Notification . . . . . . . . . . . . . . . . . . 24
6.2 Unreliable Head Notification . . . . . . . . . . . . . . 26 6.2. Unreliable Head Notification . . . . . . . . . . . . . . 24
6.3 Semi-reliable Head Notification and Tail Solicitation . 26 6.3. Semi-reliable Head Notification and Tail Solicitation . . 25
6.4 Reliable Head Notification . . . . . . . . . . . . . . . 27 6.4. Reliable Head Notification . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. Normative References . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Normative References . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Changes from the previous draft . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection protocol [BFD] specifies a The Bidirectional Forwarding Detection protocol [RFC5880] specifies a
method for verifying unicast connectivity between a pair of systems. method for verifying unicast connectivity between a pair of systems.
This document defines a method for using BFD to provide verification This document defines a method for using BFD to provide verification
of multipoint or multicast connectivity between a multipoint sender of multipoint or multicast connectivity between a multipoint sender
(the "head") and a set of one or more multipoint receivers (the (the "head") and a set of one or more multipoint receivers (the
"tails"). "tails").
As multipoint transmissions are inherently unidirectional, this As multipoint transmissions are inherently unidirectional, this
mechanism purports only to verify this unidirectional connectivity. mechanism purports only to verify this unidirectional connectivity.
Although this seems in conflict with the "Bidirectional" in BFD, it Although this seems in conflict with the "Bidirectional" in BFD, it
is a natural fit for that protocol. is a natural fit for that protocol.
skipping to change at page 4, line 12 skipping to change at page 3, line 47
Throughout this document, the term "multipoint" is defined as a Throughout this document, the term "multipoint" is defined as a
mechanism by which one or more systems receive packets sent by a mechanism by which one or more systems receive packets sent by a
single sender. This specifically includes such things as IP single sender. This specifically includes such things as IP
multicast and point-to-multipoint MPLS. multicast and point-to-multipoint MPLS.
This document effectively modifies and adds to the base BFD This document effectively modifies and adds to the base BFD
specification. It is the intention of the authors to fold these specification. It is the intention of the authors to fold these
extensions into the base specification at the appropriate time. extensions into the base specification at the appropriate time.
2. Goals 2. Goals
The primary goal of this mechanism is to allow tails to rapidly The primary goal of this mechanism is to allow tails to rapidly
detect the fact that multipoint connectivity from the head has detect the fact that multipoint connectivity from the head has
failed. An optional goal is for the head to reasonably rapidly have failed. An optional goal is for the head to reasonably rapidly have
knowledge of tails that have lost connectivity from the head. knowledge of tails that have lost connectivity from the head.
Since scaling is a primary concern (particularly state implosion Since scaling is a primary concern (particularly state implosion
toward the head), it is a goal that the head be in control of all toward the head), it is a goal that the head be in control of all
timing aspects of the mechanism, and that BFD packets from the tails timing aspects of the mechanism, and that BFD packets from the tails
to the head not be synchronized. to the head not be synchronized.
skipping to change at page 5, line 5 skipping to change at page 4, line 30
A final goal is to integrate multipoint operation into the base A final goal is to integrate multipoint operation into the base
specification in such a way as to make it relatively easy to support specification in such a way as to make it relatively easy to support
both multipoint and point-to-point operation in a single both multipoint and point-to-point operation in a single
implementation. implementation.
It is a non-goal for this protocol to verify point-to-point It is a non-goal for this protocol to verify point-to-point
connectivity between the head and any tails. This can be done connectivity between the head and any tails. This can be done
independently (and with no penalty in protocol overhead) by using independently (and with no penalty in protocol overhead) by using
point-to-point BFD. point-to-point BFD.
3. Overview 3. Overview
The heart of this protocol is the periodic transmission of BFD The heart of this protocol is the periodic transmission of BFD
Control packets along a multipoint path, from the head to all tails Control packets along a multipoint path, from the head to all tails
on the tree. The contents of the BFD packets provide the means for on the tree. The contents of the BFD packets provide the means for
the tails to calculate the detection time for path failure. If no the tails to calculate the detection time for path failure. If no
BFD Control packets are received by a tail for a detection time, the BFD Control packets are received by a tail for a detection time, the
tail declares the path to have failed. For some applications this is tail declares the path to have failed. For some applications this is
the only mechanism necessary; the head can remain ignorant of the the only mechanism necessary; the head can remain ignorant of the
tails. In this mode, the tails never send any BFD traffic to the tails. In this mode, the tails never send any BFD traffic to the
head. head.
If the head wishes to be alerted to the tails' connectivity (or lack If the head wishes to be alerted to the tails' connectivity (or lack
thereof), there are a number of options. First, if all that is thereof), there are a number of options. First, if all that is
needed is an unreliable failure notification, the head can direct the needed is an unreliable failure notification, the head can direct the
tails to transmit unicast BFD Control packets back to the head when tails to transmit unicast BFD Control packets back to the head when
the path fails. the path fails.
If the head wishes to know the identity of the tails on the If the head wishes to know the identity of the tails on the
skipping to change at page 6, line 12 skipping to change at page 5, line 37
head, but will still be able to detect multipoint path failures from head, but will still be able to detect multipoint path failures from
the head. the head.
Although this document describes a single head and a set of tails Although this document describes a single head and a set of tails
spanned by a single multipoint path, the protocol is capable of spanned by a single multipoint path, the protocol is capable of
supporting (and discriminating between) more than one multipoint path supporting (and discriminating between) more than one multipoint path
at both heads and tails. Furthermore, the same head and tail may at both heads and tails. Furthermore, the same head and tail may
share multiple multipoint paths, and a multipoint path may have share multiple multipoint paths, and a multipoint path may have
multiple heads. multiple heads.
4. Protocol Details 4. Protocol Details
This section describes the operation of Multipoint BFD in detail. This section describes the operation of Multipoint BFD in detail.
4.1. Multipoint BFD Control Packets 4.1. Multipoint BFD Control Packets
Multipoint BFD Control packets (packets sent by the head over a Multipoint BFD Control packets (packets sent by the head over a
multipoint path) are explicitly marked as such, via the setting of multipoint path) are explicitly marked as such, via the setting of
the M bit (added to the latest revision of the BFD base the M bit (added to the latest revision of the BFD base
specification. This means that Multipoint BFD does not depend on the specification. This means that Multipoint BFD does not depend on the
recipient of a packet to know whether the packet was received over a recipient of a packet to know whether the packet was received over a
multipoint path. This can be useful in scenarios where this multipoint path. This can be useful in scenarios where this
information may not be available to the recipient. information may not be available to the recipient.
4.2. Session Model 4.2. Session Model
Multipoint BFD is modeled as a set of sessions of different types. Multipoint BFD is modeled as a set of sessions of different types.
The elements of procedure differ slightly for each type. The elements of procedure differ slightly for each type.
Point-to-point sessions, as described in [BFD], are of type Point-to-point sessions, as described in [BFD], are of type
PointToPoint. PointToPoint.
The head has a session of type MultipointHead that is bound to a The head has a session of type MultipointHead that is bound to a
multipoint path. Multipoint BFD Control packets are sent by this multipoint path. Multipoint BFD Control packets are sent by this
session over the multipoint path, and no BFD Control packets are session over the multipoint path, and no BFD Control packets are
skipping to change at page 7, line 4 skipping to change at page 6, line 28
If the head is keeping track of some or all of the tails, it has a If the head is keeping track of some or all of the tails, it has a
session of type MultipointClient per tail that it cares about. All session of type MultipointClient per tail that it cares about. All
of the MultipointClient sessions for tails on a particular particular of the MultipointClient sessions for tails on a particular particular
multipoint path are grouped with the MultipointHead session to which multipoint path are grouped with the MultipointHead session to which
the clients are listening. A BFD Poll Sequence may be sent over such the clients are listening. A BFD Poll Sequence may be sent over such
a session to a tail if the head wishes to verify connectivity. These a session to a tail if the head wishes to verify connectivity. These
sessions receive any BFD Control packets sent by the tails, and never sessions receive any BFD Control packets sent by the tails, and never
transmit periodic BFD Control packets other than Poll Sequences transmit periodic BFD Control packets other than Poll Sequences
(since periodic transmission is always done by the MultipointHead (since periodic transmission is always done by the MultipointHead
session.) session.)
Each tail has a session of type MultipointTail associated with a Each tail has a session of type MultipointTail associated with a
multipoint path. These sessions receive BFD Control packets from the multipoint path. These sessions receive BFD Control packets from the
head, both as multipoint packets (the MultipointHead session) and as head, both as multipoint packets (the MultipointHead session) and as
unicast packets (the MultipointClient session, if it exists.) Any unicast packets (the MultipointClient session, if it exists.) Any
BFD Control packets sent to the head are sent over this session. BFD Control packets sent to the head are sent over this session.
4.3. Session Failure Semantics 4.3. Session Failure Semantics
The semantics of session failure are subtle enough to warrant further The semantics of session failure are subtle enough to warrant further
explanation. explanation.
MultipointHead sessions cannot fail (since they are controlled MultipointHead sessions cannot fail (since they are controlled
administratively.) administratively.)
If a MultipointTail session fails, it means that the tail definitely If a MultipointTail session fails, it means that the tail definitely
has lost contact with the head (or the head has been administratively has lost contact with the head (or the head has been administratively
disabled) and the tail should take appropriate action. disabled) and the tail should take appropriate action.
If a MultipointClient session receives a BFD Control packet from the If a MultipointClient session receives a BFD Control packet from the
tail with state Down or AdminDown, the head reliably knows that the tail with state Down or AdminDown, the head reliably knows that the
tail has lost multipoint connectivity. If the Detection Time expires tail has lost multipoint connectivity. If the Detection Time expires
on a MultipointClient session, it is ambiguous as to whether the on a MultipointClient session, it is ambiguous as to whether the
multipoint connectivity failed or whether there was a unicast path multipoint connectivity failed or whether there was a unicast path
problem in one direction or the other, so the head does not reliably problem in one direction or the other, so the head does not reliably
know the tail state. know the tail state.
4.4. State Variables 4.4. State Variables
Multipoint BFD introduces some new state variables, and modifies the Multipoint BFD introduces some new state variables, and modifies the
usage of a few existing ones. usage of a few existing ones.
4.4.1. New State Variables 4.4.1. New State Variables
A number of state variables are added to the base specification in A number of state variables are added to the base specification in
support of Multipoint BFD. support of Multipoint BFD.
bfd.SessionType bfd.SessionType
The type of this session. Allowable values are: The type of this session. Allowable values are:
PointToPoint: Classic point-to-point BFD. PointToPoint: Classic point-to-point BFD.
MultipointHead: A session on the head responsible for the MultipointHead: A session on the head responsible for the
periodic transmission of multipoint BFD Control packets periodic transmission of multipoint BFD Control packets
along the multipoint path. along the multipoint path.
MultipointClient: A session on the head that tracks the MultipointClient: A session on the head that tracks the
state of an individual tail, when desirable. state of an individual tail, when desirable.
MultipointTail: A multipoint session on a tail. MultipointTail: A multipoint session on a tail.
This variable MUST be initialized to the appropriate type when This variable MUST be initialized to the appropriate type when
the session is created, according to the rules in section 4.16. the session is created, according to the rules in section 4.16.
bfd.SilentTail bfd.SilentTail
If 1, a tail will never transmit any BFD Control packets to the If 1, a tail will never transmit any BFD Control packets to the
head under any circumstances. If 0, a tail may send packets to head under any circumstances. If 0, a tail may send packets to
the head according to other parts of this specification. This the head according to other parts of this specification. This
allows tails to be provisioned to always be silent, even when allows tails to be provisioned to always be silent, even when
skipping to change at page 9, line 6 skipping to change at page 8, line 25
Set to 1 if a tail receives a unicast BFD Control packet from Set to 1 if a tail receives a unicast BFD Control packet from
the head. This variable MUST be set to zero if the session the head. This variable MUST be set to zero if the session
transitions from Up state to some other state. transitions from Up state to some other state.
This variable MUST be initialized to zero. This variable MUST be initialized to zero.
This variable is only pertinent when Bfd.SessionType is This variable is only pertinent when Bfd.SessionType is
MultipointTail. MultipointTail.
4.4.2. State Variable Initialization and Maintenance 4.4.2. State Variable Initialization and Maintenance
Some state variables defined in section 6.8.1 of the BFD base Some state variables defined in section 6.8.1 of the BFD base
specification need to be initialized or manipulated differently specification need to be initialized or manipulated differently
depending on the session type. depending on the session type.
bfd.LocalDiscr bfd.LocalDiscr
For session type MultipointClient, this variable MUST always For session type MultipointClient, this variable MUST always
match the value of bfd.LocalDiscr in the associated match the value of bfd.LocalDiscr in the associated
MultipointHead session. MultipointHead session.
skipping to change at page 9, line 31 skipping to change at page 8, line 50
match the value of bfd.DesiredMinTxInterval in the associated match the value of bfd.DesiredMinTxInterval in the associated
MultipointHead session. MultipointHead session.
bfd.RequiredMinRxInterval bfd.RequiredMinRxInterval
This variable MUST always be 0 for session type MultipointHead This variable MUST always be 0 for session type MultipointHead
if bfd.ReportTailDown is 0. if bfd.ReportTailDown is 0.
It should be noted that for sessions of type MultipointTail, It should be noted that for sessions of type MultipointTail,
this variable only affects the rate of unicast Polls sent by this variable only affects the rate of unicast Polls sent by
the head; the rate of multipoint packets is necessarily the head; the rate of multipoint packets is necessarily
unaffected by it. unaffected by it.
bfd.DemandMode bfd.DemandMode
This variable MUST be initialized to 1 for session types This variable MUST be initialized to 1 for session types
MultipointHead and MultipointClient, and MUST be initialized to MultipointHead and MultipointClient, and MUST be initialized to
0 for session type MultipointTail. 0 for session type MultipointTail.
bfd.DetectMult bfd.DetectMult
For session type MultipointClient, this variable MUST always For session type MultipointClient, this variable MUST always
match the value of bfd.DetectMult in the associated match the value of bfd.DetectMult in the associated
MultipointHead session. MultipointHead session.
4.5. Controlling Multipoint BFD Options 4.5. Controlling Multipoint BFD Options
The state variables defined above are used to choose which The state variables defined above are used to choose which
operational options are active. operational options are active.
The most basic form of operation, in which BFD Control packets flow The most basic form of operation, in which BFD Control packets flow
only from the head and no tracking is desired of tail state at the only from the head and no tracking is desired of tail state at the
head, is accomplished by setting bfd.ReportTailDown to 0 in the head, is accomplished by setting bfd.ReportTailDown to 0 in the
MultipointHead session. MultipointHead session.
If the head wishes to know the identity of the tails, it sends If the head wishes to know the identity of the tails, it sends
skipping to change at page 10, line 42 skipping to change at page 10, line 5
from a particular tail, it sends a BFD Control packet from the from a particular tail, it sends a BFD Control packet from the
MultipointClient session associated with that tail. This has the MultipointClient session associated with that tail. This has the
effect of eliminating the initial delay that the tail would otherwise effect of eliminating the initial delay that the tail would otherwise
insert prior to transmission of the packet. insert prior to transmission of the packet.
If a tail wishes to operate silently (sending no BFD Control packets If a tail wishes to operate silently (sending no BFD Control packets
to the head) it sets bfd.SilentTail to 1 in the MultipointTail to the head) it sets bfd.SilentTail to 1 in the MultipointTail
session. This allows a tail to be silent independent of the settings session. This allows a tail to be silent independent of the settings
on the head. on the head.
4.6. State Machine 4.6. State Machine
The BFD state machine works slightly differently in the multipoint The BFD state machine works slightly differently in the multipoint
application. In particular, since there is a many-to-one mapping, application. In particular, since there is a many-to-one mapping,
three-way handshakes for session establishment and teardown are three-way handshakes for session establishment and teardown are
neither possible nor appropriate. As such there is no Init state. neither possible nor appropriate. As such there is no Init state.
The following diagram provides an overview of the state machine for The following diagram provides an overview of the state machine for
session types MultipointClient and MultipointTail. The notation on session types MultipointClient and MultipointTail. The notation on
each arc represents the state of the remote system (as received in each arc represents the state of the remote system (as received in
the State field in the BFD Control packet) or indicates the the State field in the BFD Control packet) or indicates the
expiration of the Detection Timer. expiration of the Detection Timer.
DOWN, ADMIN DOWN, DOWN, ADMIN DOWN,
+------+ TIMER +------+ +------+ TIMER +------+
+----| |<---------------------| |----+ +----| |<---------------------| |----+
DOWN,| | DOWN | | UP | |UP DOWN,| | DOWN | | UP | |UP
ADMIN DOWN,+--->| |--------------------->| |<---+ ADMIN DOWN,+--->| |--------------------->| |<---+
TIMER +------+ UP +------+ TIMER +------+ UP +------+
Sessions of type MultipointHead never receive packets and have no Sessions of type MultipointHead never receive packets and have no
Detection Timer, and as such all state transitions are Detection Timer, and as such all state transitions are
administratively driven. administratively driven.
4.7. Session Establishment 4.7. Session Establishment
Unlike Point-to-point BFD, Multipoint BFD provides a form of Unlike Point-to-point BFD, Multipoint BFD provides a form of
discovery mechanism for tails to discover the head, and vice versa. discovery mechanism for tails to discover the head, and vice versa.
The minimum amount of a priori information required both on the head The minimum amount of a priori information required both on the head
and tails is the binding to the multipoint path over which BFD is and tails is the binding to the multipoint path over which BFD is
running. The head transmits Multipoint BFD packets on that tree, and running. The head transmits Multipoint BFD packets on that tree, and
the tails listen for BFD packets on that tree. All other information the tails listen for BFD packets on that tree. All other information
MAY be determined dynamically. MAY be determined dynamically.
A session of type MultipointHead is created for each multipoint path A session of type MultipointHead is created for each multipoint path
skipping to change at page 12, line 5 skipping to change at page 11, line 14
If BFD Control packets are received at the head, they are If BFD Control packets are received at the head, they are
demultiplexed to sessions of type MultipointClient, which represent demultiplexed to sessions of type MultipointClient, which represent
the set of tails that the head is interested in tracking. These the set of tails that the head is interested in tracking. These
sessions will typically also be established dynamically based on the sessions will typically also be established dynamically based on the
receipt of BFD Control packets. The head has broad latitude in receipt of BFD Control packets. The head has broad latitude in
choosing which tails to track, if any, without affecting the basic choosing which tails to track, if any, without affecting the basic
operation of the protocol. The head directly controls whether or not operation of the protocol. The head directly controls whether or not
tails are allowed to send BFD Control packets back to the head. tails are allowed to send BFD Control packets back to the head.
4.8. Discriminators and Packet Demultiplexing 4.8. Discriminators and Packet Demultiplexing
The use of Discriminators is somewhat different in Multipoint BFD The use of Discriminators is somewhat different in Multipoint BFD
than in Point-to-point BFD. than in Point-to-point BFD.
The head sends Multipoint BFD Control packets over the MultipointHead The head sends Multipoint BFD Control packets over the MultipointHead
session with My Discr set to a value bound to the multipoint path, session with My Discr set to a value bound to the multipoint path,
and with Your Discr set to zero. The tails MUST demultiplex these and with Your Discr set to zero. The tails MUST demultiplex these
packets based on a combination of the source address and My Discr, packets based on a combination of the source address and My Discr,
which together uniquely identify the head and the multipoint path. which together uniquely identify the head and the multipoint path.
skipping to change at page 12, line 34 skipping to change at page 11, line 43
When the head sends unicast BFD Control packets to a tail from a When the head sends unicast BFD Control packets to a tail from a
MultipointClient session, the value of Your Discr will be valid, and MultipointClient session, the value of Your Discr will be valid, and
the tail MUST demultiplex the packet based solely on Your Discr. the tail MUST demultiplex the packet based solely on Your Discr.
Note that, unlike PointToPoint sessions, the discriminator values on Note that, unlike PointToPoint sessions, the discriminator values on
all multipoint session types MUST NOT be changed during the life of a all multipoint session types MUST NOT be changed during the life of a
session. This is a side effect of the more complex demultiplexing session. This is a side effect of the more complex demultiplexing
scheme. scheme.
4.9. Controlling Tail Packet Transmission 4.9. Controlling Tail Packet Transmission
As the fan-in from the tails to the head may be very large, it is As the fan-in from the tails to the head may be very large, it is
critical that the flow of BFD Control packets from the tails is critical that the flow of BFD Control packets from the tails is
controlled. controlled.
The head always operates in Demand mode. This means that no tail The head always operates in Demand mode. This means that no tail
will send an asynchronous BFD Control packet as long as the session will send an asynchronous BFD Control packet as long as the session
is Up. is Up.
The value of Required Min Rx Interval received by a tail in a unicast The value of Required Min Rx Interval received by a tail in a unicast
skipping to change at page 13, line 18 skipping to change at page 12, line 27
to receive no periodic traffic. This can be set in the to receive no periodic traffic. This can be set in the
MultipointHead session (suppressing traffic from all tails) or it can MultipointHead session (suppressing traffic from all tails) or it can
be set in a MultipointClient session (suppressing traffic from only a be set in a MultipointClient session (suppressing traffic from only a
single tail.) single tail.)
Any tail may be provisioned to never send *any* BFD Control packets Any tail may be provisioned to never send *any* BFD Control packets
to the head by setting bfd.SilentTail to 1. This provides a to the head by setting bfd.SilentTail to 1. This provides a
mechanism by which only a subset of tails report their session status mechanism by which only a subset of tails report their session status
to the head. to the head.
4.10. Bringing Up and Shutting Down Multipoint BFD Service 4.10. Bringing Up and Shutting Down Multipoint BFD Service
Because there is no three-way handshake in Multipoint BFD, a newly Because there is no three-way handshake in Multipoint BFD, a newly
started head (that does not have any previous state information started head (that does not have any previous state information
available) SHOULD start with bfd.SessionState set to Down and with available) SHOULD start with bfd.SessionState set to Down and with
bfd.RequiredMinRxInterval set to zero in the MultipointHead session. bfd.RequiredMinRxInterval set to zero in the MultipointHead session.
The session SHOULD remain in this state for a time equal to The session SHOULD remain in this state for a time equal to
(bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that
all MultipointTail sessions are reset (so long as the restarted head all MultipointTail sessions are reset (so long as the restarted head
is using the same or larger value of bfd.DesiredMinTxInterval than it is using the same or larger value of bfd.DesiredMinTxInterval than it
did previously.) did previously.)
skipping to change at page 14, line 5 skipping to change at page 13, line 10
AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero (to keep AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero (to keep
the tails from sending any BFD Control packets back.) The session the tails from sending any BFD Control packets back.) The session
SHOULD send BFD Control packets in this state for a period equal to SHOULD send BFD Control packets in this state for a period equal to
(bfd.DesiredMinTxInterval * bfd.DetectMult). The tail SHOULD destroy (bfd.DesiredMinTxInterval * bfd.DetectMult). The tail SHOULD destroy
all MultipointClient sessions associated with the MultipointHead all MultipointClient sessions associated with the MultipointHead
session. session.
The semantic difference between Down and AdminDown state is for The semantic difference between Down and AdminDown state is for
further discussion. further discussion.
4.11. Soliciting the Tails 4.11. Soliciting the Tails
If the head wishes to know the identities of the tails, the If the head wishes to know the identities of the tails, the
MultipointHead session MAY send a BFD Control packet as specified in MultipointHead session MAY send a BFD Control packet as specified in
section 4.16.3, with the Poll (P) bit set to 1. This will cause all section 4.16.3, with the Poll (P) bit set to 1. This will cause all
of the tails to reply with a unicast BFD Control Packet, randomized of the tails to reply with a unicast BFD Control Packet, randomized
across one packet interval. across one packet interval.
The decision as to when to send a multipoint Poll is outside the The decision as to when to send a multipoint Poll is outside the
scope of this specification. However, it must never be sent more scope of this specification. However, it must never be sent more
often than the regular multipoint BFD Control packet. Since the tail often than the regular multipoint BFD Control packet. Since the tail
skipping to change at page 14, line 29 skipping to change at page 13, line 34
Soliciting the tails also starts the Detection Timer for each Soliciting the tails also starts the Detection Timer for each
associated MultipointClient session, which will cause those sessions associated MultipointClient session, which will cause those sessions
to time out if the associated tails do not respond. to time out if the associated tails do not respond.
Note that for this mechanism to work properly, the Detection Time Note that for this mechanism to work properly, the Detection Time
(which is equal to bfd.DesiredMinTxInterval) MUST be greater than the (which is equal to bfd.DesiredMinTxInterval) MUST be greater than the
round trip time of BFD Control packets from the head to the tail (via round trip time of BFD Control packets from the head to the tail (via
the multipoint path) and back (via a unicast path.) See section 4.14 the multipoint path) and back (via a unicast path.) See section 4.14
for more details. for more details.
4.12. Verifying Connectivity to Specific Tails 4.12. Verifying Connectivity to Specific Tails
If the head wishes to verify connectivity to a specific tail, the If the head wishes to verify connectivity to a specific tail, the
corresponding MultipointClient session MAY send a BFD Poll Sequence corresponding MultipointClient session MAY send a BFD Poll Sequence
to said tail. This might be done in reaction to the expiration of to said tail. This might be done in reaction to the expiration of
the Detection Timer (the tail didn't respond to a multipoint Poll), the Detection Timer (the tail didn't respond to a multipoint Poll),
or it might be done on a proactive basis. or it might be done on a proactive basis.
The interval between transmitted packets in the Poll Sequence MUST be The interval between transmitted packets in the Poll Sequence MUST be
calculated as specified in the base specification (the greater of calculated as specified in the base specification (the greater of
bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval.) bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval.)
skipping to change at page 15, line 15 skipping to change at page 14, line 20
reset the tail session by sending a Poll Sequence with state reset the tail session by sending a Poll Sequence with state
AdminDown (after the completion of which the session will come back AdminDown (after the completion of which the session will come back
up.) up.)
Note that a failure of the head to receive a response to a Poll Note that a failure of the head to receive a response to a Poll
Sequence does not necessarily mean that the tail has lost multipoint Sequence does not necessarily mean that the tail has lost multipoint
connectivity, though a reply to a Poll Sequence does reliably connectivity, though a reply to a Poll Sequence does reliably
indicate connectivity or lack thereof (by virtue of the tail's state indicate connectivity or lack thereof (by virtue of the tail's state
not being Up in the BFD Control packet.) not being Up in the BFD Control packet.)
4.13. Timer Manipulation 4.13. Timer Manipulation
Because of the one-to-many mapping, a session of type MultipointHead Because of the one-to-many mapping, a session of type MultipointHead
SHOULD NOT initiate a Poll Sequence in conjunction with timer value SHOULD NOT initiate a Poll Sequence in conjunction with timer value
changes. As such, such a session cannot wait for a Final before changes. As such, such a session cannot wait for a Final before
increasing the transmit interval; such a session SHOULD send increasing the transmit interval; such a session SHOULD send
bfd.DetectMult packets at the old transmit interval before using the bfd.DetectMult packets at the old transmit interval before using the
higher value in order to avoid false detection timeouts at the tails. higher value in order to avoid false detection timeouts at the tails.
Since MultipointHead sessions do not calculate detection times, the Since MultipointHead sessions do not calculate detection times, the
value of bfd.RequiredMinRxInterval may be changed at any time. value of bfd.RequiredMinRxInterval may be changed at any time.
4.14. Detection Times 4.14. Detection Times
Multipoint BFD is inherently asymmetric. As such, each session type Multipoint BFD is inherently asymmetric. As such, each session type
has a different approach to detection times. has a different approach to detection times.
Since the MultipointHead session never receives packets, it does not Since the MultipointHead session never receives packets, it does not
calculate a detection time. calculate a detection time.
MultipointClient sessions at the head are always in Demand mode, and MultipointClient sessions at the head are always in Demand mode, and
as such only care about detection time in two cases. First, if a as such only care about detection time in two cases. First, if a
Poll Sequence is being sent on a MultipointClient session, the Poll Sequence is being sent on a MultipointClient session, the
skipping to change at page 16, line 17 skipping to change at page 15, line 20
MultipointHead session using the Required Min Rx Interval field MultipointHead session using the Required Min Rx Interval field
because of its one-to-many nature. As such, the Detection Time because of its one-to-many nature. As such, the Detection Time
calculation for a MultipointTail session does not use calculation for a MultipointTail session does not use
bfd.RequiredMinRxInterval in the calculation. The detection time is bfd.RequiredMinRxInterval in the calculation. The detection time is
calculated as the product of the last received values of Desired Min calculated as the product of the last received values of Desired Min
TX Interval and Detect Mult. TX Interval and Detect Mult.
The value of bfd.DetectMult may be changed at any time on any session The value of bfd.DetectMult may be changed at any time on any session
type. type.
4.15. State Maintenance for Down/AdminDown Sessions 4.15. State Maintenance for Down/AdminDown Sessions
The length of time session state is kept after the session goes down The length of time session state is kept after the session goes down
determines how long the session will continue to send BFD Control determines how long the session will continue to send BFD Control
packets (since no packets can be sent after the session is packets (since no packets can be sent after the session is
destroyed.) destroyed.)
4.15.1. MultipointHead Sessions 4.15.1. MultipointHead Sessions
When a MultipointHead session transitions to states Down or When a MultipointHead session transitions to states Down or
AdminDown, the state SHOULD be maintained for a period equal to AdminDown, the state SHOULD be maintained for a period equal to
(bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails
more quickly detect the session going down (by continuing to transmit more quickly detect the session going down (by continuing to transmit
BFD Control packets with the new state.) BFD Control packets with the new state.)
4.15.2. MultipointTail Sessions 4.15.2. MultipointTail Sessions
If bfd.SilentTail is 1, or bfd.RemoteMinRxInterval is zero, If bfd.SilentTail is 1, or bfd.RemoteMinRxInterval is zero,
MultipointTail sessions MAY be destroyed immediately upon leaving Up MultipointTail sessions MAY be destroyed immediately upon leaving Up
state, since they will transmit no further packets. state, since they will transmit no further packets.
Otherwise, MultipointTail sessions MUST be maintained as long as BFD Otherwise, MultipointTail sessions MUST be maintained as long as BFD
Control packets are being received by it (which by definition will Control packets are being received by it (which by definition will
indicate that the head is not Up.) indicate that the head is not Up.)
MultipointTail sessions MUST be maintained after a Detection Time MultipointTail sessions MUST be maintained after a Detection Time
expiration for at least the longer of an additional Detection Time expiration for at least the longer of an additional Detection Time
and the transmission of the first (delayed) BFD Control packet to the and the transmission of the first (delayed) BFD Control packet to the
head. The state MAY be maintained longer than this, but the session head. The state MAY be maintained longer than this, but the session
MUST NOT transmit periodic BFD Control packets for a period longer MUST NOT transmit periodic BFD Control packets for a period longer
than the negotiated transmit interval multiplied by bfd.DetectMult; than the negotiated transmit interval multiplied by bfd.DetectMult;
after this time either the session MUST be destroyed or after this time either the session MUST be destroyed or
bfd.RemoteMinRxInterval MUST be set to zero to suppress packet bfd.RemoteMinRxInterval MUST be set to zero to suppress packet
transmission. transmission.
4.15.3. MultipointClient Sessions 4.15.3. MultipointClient Sessions
If the MultipointHead session is going down (which only happens If the MultipointHead session is going down (which only happens
administratively), all associated MultipointClient sessions SHOULD be administratively), all associated MultipointClient sessions SHOULD be
destroyed as they are superfluous. destroyed as they are superfluous.
If a MultipointClient session goes down due to the receipt of an If a MultipointClient session goes down due to the receipt of an
unsolicited BFD Control packet from the tail with state Down or unsolicited BFD Control packet from the tail with state Down or
AdminDown (not in response to a Poll), and tail connectivity AdminDown (not in response to a Poll), and tail connectivity
verification is not being done, the session MAY be destroyed. If verification is not being done, the session MAY be destroyed. If
verification is desired, the session SHOULD send a Poll Sequence and verification is desired, the session SHOULD send a Poll Sequence and
the session SHOULD be maintained. the session SHOULD be maintained.
If the tail replies to a Poll Sequence with state Down or AdminDown, If the tail replies to a Poll Sequence with state Down or AdminDown,
it means that the tail session is definitely down. In this case, the it means that the tail session is definitely down. In this case, the
session MAY be destroyed. session MAY be destroyed.
If the Detection Time expires on a MultipointClient session (meaning If the Detection Time expires on a MultipointClient session (meaning
that the tail did not reply to a Poll Sequence) the session MAY be that the tail did not reply to a Poll Sequence) the session MAY be
destroyed. destroyed.
4.16. Base Specification Text Replacement 4.16. Base Specification Text Replacement
The following sections are meant to replace the corresponding The following sections are meant to replace the corresponding
sections in the base specification. sections in the base specification.
4.16.1. Reception of BFD Control Packets 4.16.1. Reception of BFD Control Packets
The following procedure replaces section 6.8.6 of [BFD]. The following procedure replaces section 6.8.6 of [RFC5880].
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
skipping to change at page 19, line 13 skipping to change at page 18, line 10
MUST be terminated. MUST be terminated.
If bfd.SessionType is PointToPoint or MultipointClient, update the If bfd.SessionType is PointToPoint or MultipointClient, update the
transmit interval as described in [BFD] section 6.8.2. transmit interval as described in [BFD] section 6.8.2.
If bfd.SessionType is PointToPoint, update the Detection Time as If bfd.SessionType is PointToPoint, update the Detection Time as
described in [BFD] section 6.8.4. Otherwise, update the Detection described in [BFD] section 6.8.4. Otherwise, update the Detection
Time as described in section 4.14 above. Time as described in section 4.14 above.
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
If bfd.SessionState is Down If bfd.SessionState is Down
If bfd.SessionType is PointToPoint If bfd.SessionType is PointToPoint
If received State is Down If received State is Down
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 (bfd.SessionType is not PointToPoint) Else (bfd.SessionType is not PointToPoint)
If received State is Up If received State is Up
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 (see [BFD] Check to see if Demand mode should become active or not (see
section 6.6). [RFC5880] 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 remote bfd.RemoteSessionState is Up, Demand mode is active on the remote
system and the local system MUST cease the periodic transmission system and the local system MUST cease the periodic transmission
of BFD Control packets (see section 4.16.3.) of BFD Control packets (see section 4.16.3.)
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 4.16.3.) packets (see section 4.16.3.)
If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD
Control packet to the remote system with the Poll (P) bit clear, Control packet to the remote system with the Poll (P) bit clear,
and the Final (F) bit set (see section 4.16.3.) and the Final (F) bit set (see section 4.16.3.)
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 [BFD] section 6.8.4. of the Detection Time expiration rules in [BFD] section 6.8.4.
4.16.2. Demultiplexing BFD Control Packets 4.16.2. Demultiplexing BFD Control Packets
This section is part of the replacement for [BFD] section 6.8.6, This section is part of the replacement for [RFC5880] section 6.8.6,
separated for clarity. separated for clarity.
If the Multipoint (M) bit is set If the Multipoint (M) bit is set
If the Your Discriminator field is nonzero, the packet MUST be If the Your Discriminator field is nonzero, the packet MUST be
discarded. discarded.
Select a session based on the source address and the My Select a session based on the source address and the My
Discriminator field. If a session is found, and Discriminator field. If a session is found, and
bfd.SessionType is not MultipointTail, the packet MUST be bfd.SessionType is not MultipointTail, the packet MUST be
skipping to change at page 21, line 23 skipping to change at page 20, line 35
If a matching session is found, and bfd.SessionType is not If a matching session is found, and bfd.SessionType is not
PointToPoint, the packet MUST be discarded. PointToPoint, the packet MUST be discarded.
If a matching session is not found, a new session of type If a matching session is not found, a new session of type
PointToPoint may be created, or the packet may be discarded. PointToPoint may be created, or the packet may be discarded.
This choice is outside the scope of this specification. This choice is outside the scope of this specification.
If the State field is Init and bfd.SessionType is not If the State field is Init and bfd.SessionType is not
PointToPoint, the packet MUST be discarded. PointToPoint, the packet MUST be discarded.
4.16.3. Transmitting BFD Control Packets 4.16.3. Transmitting BFD Control Packets
The following procedure replaces section 6.8.7 of [BFD]. The following procedure replaces section 6.8.7 of [RFC5880].
BFD Control packets MUST be transmitted periodically at the rate BFD Control packets MUST be transmitted periodically at the rate
determined according to [BFD] section 6.8.2, except as specified in determined according to [BFD] section 6.8.2, except as specified in
this section. this section.
A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr
is zero and the system is taking the Passive role. is zero and the system is taking the Passive role.
A system MUST NOT transmit any BFD Control packets if bfd.SilentTail A system MUST NOT transmit any BFD Control packets if bfd.SilentTail
is 1. is 1.
skipping to change at page 23, line 5 skipping to change at page 22, line 15
If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control
packet SHOULD be transmitted during the interval between periodic packet SHOULD be transmitted during the interval between periodic
Control packet transmissions when the contents of that packet would Control packet transmissions when the contents of that packet would
differ from that in the previously transmitted packet (other than the differ from that in the previously transmitted packet (other than the
Poll and Final bits) in order to more rapidly communicate a change in Poll and Final bits) in order to more rapidly communicate a change in
state. state.
The contents of transmitted BFD Control packets MUST be set as The contents of transmitted BFD Control packets MUST be set as
follows: follows:
Version Version
Set to the current version number (1).
Diagnostic (Diag) Set to the current version number (1).
Set to bfd.LocalDiag. Diagnostic (Diag)
State (Sta) Set to bfd.LocalDiag.
Set to the value indicated by bfd.SessionState. State (Sta)
Poll (P) Set to the value indicated by bfd.SessionState.
Set to 1 if the local system is sending a Poll Sequence or is a Poll (P)
session of type MultipointHead soliciting the identities of the
tails, or 0 if not.
Final (F) Set to 1 if the local system is sending a Poll Sequence or is a
session of type MultipointHead soliciting the identities of the
tails, or 0 if not.
Set to 1 if the local system is responding to a Control packet Final (F)
received with the Poll (P) bit set, or 0 if not.
Control Plane Independent (C) Set to 1 if the local system is responding to a Control packet
received with the Poll (P) bit set, or 0 if not.
Set to 1 if the local system's BFD implementation is independent Control Plane Independent (C)
of the control plane (it can continue to function through a
disruption of the control plane.)
Authentication Present (A) Set to 1 if the local system's BFD implementation is
independent of the control plane (it can continue to function
through a disruption of the control plane.)
Set to 1 if authentication is in use on this session (bfd.AuthType Authentication Present (A)
is nonzero), or 0 if not.
Demand (D) Set to 1 if authentication is in use on this session
(bfd.AuthType is nonzero), or 0 if not.
Set to bfd.DemandMode if bfd.SessionState is Up and Demand (D)
bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is Set to bfd.DemandMode if bfd.SessionState is Up and
MultipointHead or MultipointClient. Otherwise it is set to 0. bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is
MultipointHead or MultipointClient. Otherwise it is set to 0.
Multipoint (M) Multipoint (M)
Set to 1 if bfd.SessionType is MultipointHead. Otherwise it is Set to 1 if bfd.SessionType is MultipointHead. Otherwise it is
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
(24) plus any Authentication Section. (24) plus any Authentication Section.
My Discriminator My Discriminator
Set to bfd.LocalDiscr. Set to bfd.LocalDiscr.
Your Discriminator Your Discriminator
Set to bfd.RemoteDiscr. Set to bfd.RemoteDiscr.
Desired Min TX Interval Desired Min TX Interval
Set to bfd.DesiredMinTxInterval. Set to bfd.DesiredMinTxInterval.
Required Min RX Interval Required Min RX Interval
Set to bfd.RequiredMinRxInterval. Set to bfd.RequiredMinRxInterval.
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
session. If this field is set to zero, the local system is this session. If this field is set to zero, the local system
unwilling or unable to loop back BFD Echo packets to the remote is unwilling or unable to loop back BFD Echo packets to the
system, and the remote system will not send Echo packets. remote system, and the remote system will not send Echo
packets.
Authentication Section Authentication Section
Included and set according to the rules in section 6.7 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.
5. Assumptions 5. Assumptions
If head notification is to be used, it is assumed that a multipoint If head notification is to be used, it is assumed that a multipoint
BFD packet encapsulation contains enough information so that a tail BFD packet encapsulation contains enough information so that a tail
can address a unicast BFD packet to the head. can address a unicast BFD packet to the head.
If head notification is to be used, it is assumed that is that there If head notification is to be used, it is assumed that is that there
is bidirectional unicast communication available (at the same is bidirectional unicast communication available (at the same
protocol layer within which BFD is being run) between the tail and protocol layer within which BFD is being run) between the tail and
head. head.
skipping to change at page 25, line 37 skipping to change at page 24, line 31
knowledge of tail state. knowledge of tail state.
Since the normal BFD three-way handshake is not used in this Since the normal BFD three-way handshake is not used in this
application, a tail transitioning from state Up to Down and back to application, a tail transitioning from state Up to Down and back to
Up again may not be reliably detected at the head. Up again may not be reliably detected at the head.
If authentication is in use, all tails must be configured to have a If authentication is in use, all tails must be configured to have a
common authentication key in order to receive the multipoint BFD common authentication key in order to receive the multipoint BFD
Control packets. Control packets.
6. Operational Scenarios 6. Operational Scenarios
It is worth analyzing how this protocol reacts to various scenarios. It is worth analyzing how this protocol reacts to various scenarios.
There are three path components present, namely, the multipoint path, There are three path components present, namely, the multipoint path,
the forward unicast path (from head to a particular tail), and the the forward unicast path (from head to a particular tail), and the
reverse unicast path (from a tail to the head.) There are also four reverse unicast path (from a tail to the head.) There are also four
options as to how the head is notified about failures from the tail. options as to how the head is notified about failures from the tail.
6.1. No Head Notification 6.1. No Head Notification
Since the only path used in this scenario is the multipoint path, Since the only path used in this scenario is the multipoint path,
none of the others matter. A failure in the multipoint path will none of the others matter. A failure in the multipoint path will
result in the tail noticing the failure within a detection time, and result in the tail noticing the failure within a detection time, and
the head will remain ignorant of the tail state. the head will remain ignorant of the tail state.
6.2. Unreliable Head Notification 6.2. Unreliable Head Notification
In this scenario, the tail sends back unsolicicted BFD packets in In this scenario, the tail sends back unsolicicted BFD packets in
response to the detection of a multipoint path failure. It uses the response to the detection of a multipoint path failure. It uses the
reverse unicast path, but not the forward unicast path. reverse unicast path, but not the forward unicast path.
If the multipoint path fails but the reverse unicast path stays up, If the multipoint path fails but the reverse unicast path stays up,
the tail will detect the failure within a detection time, and the the tail will detect the failure within a detection time, and the
head will know about it within one reverse packet time (since the head will know about it within one reverse packet time (since the
notification is delayed.) notification is delayed.)
If both the multipoint path and the reverse unicast paths fail, the If both the multipoint path and the reverse unicast paths fail, the
tail will detect the failure but the head will remain unaware of it. tail will detect the failure but the head will remain unaware of it.
6.3. Semi-reliable Head Notification and Tail Solicitation 6.3. Semi-reliable Head Notification and Tail Solicitation
In this scenario, the head sends occasional multipoint Polls in In this scenario, the head sends occasional multipoint Polls in
addition to (or in lieu of) non-Poll multipoint BFD Control packets, addition to (or in lieu of) non-Poll multipoint BFD Control packets,
expecting the tails to reply with Final. This also uses the reverse expecting the tails to reply with Final. This also uses the reverse
unicast path, but not the forward unicast path. unicast path, but not the forward unicast path.
If the multipoint path fails but the reverse unicast path stays up, If the multipoint path fails but the reverse unicast path stays up,
the tail will detect the failure within a detection time, and the the tail will detect the failure within a detection time, and the
head will know about it within one reverse packet time (the head will know about it within one reverse packet time (the
notification is delayed to avoid synchronization of the tails.) notification is delayed to avoid synchronization of the tails.)
skipping to change at page 27, line 5 skipping to change at page 25, line 39
If the reverse unicast path fails but the multipoint path stays up, If the reverse unicast path fails but the multipoint path stays up,
the head will see the BFD session fail, but the state of the the head will see the BFD session fail, but the state of the
multipoint path will be unknown to the head. The tail will continue multipoint path will be unknown to the head. The tail will continue
to receive multipoint data traffic. to receive multipoint data traffic.
If either the multipoint Poll or the unicast reply is lost in If either the multipoint Poll or the unicast reply is lost in
transit, the head will see the BFD session fail, but the state of the transit, the head will see the BFD session fail, but the state of the
multipoint path will be unknown to the head. The tail will continue multipoint path will be unknown to the head. The tail will continue
to receive multipoint data traffic. to receive multipoint data traffic.
6.4. Reliable Head Notification 6.4. Reliable Head Notification
In this scenario, the head sends occasional multipoint Polls in In this scenario, the head sends occasional multipoint Polls in
addition to (or in lieu of) non-Poll multipoint BFD control packets, addition to (or in lieu of) non-Poll multipoint BFD control packets,
expecting the tails to reply with Final. If a tail that had expecting the tails to reply with Final. If a tail that had
previously replied to a multipoint Poll fails to reply (or if the previously replied to a multipoint Poll fails to reply (or if the
head simply wishes to verify tail connectivity,) the head issues a head simply wishes to verify tail connectivity,) the head issues a
unicast Poll Sequence to the tail. This scenario makes use of all unicast Poll Sequence to the tail. This scenario makes use of all
three paths. three paths.
If the multipoint path fails but the two unicast paths stay up, the If the multipoint path fails but the two unicast paths stay up, the
tail will detect the failure within a detection time, and the head tail will detect the failure within a detection time, and the head
will know about it within one reverse packet time (since the will know about it within one reverse packet time (since the
notification is delayed.) Note that the reverse packet time may be notification is delayed.) Note that the reverse packet time may be
smaller in this case if the head has previously issued a unicast Poll smaller in this case if the head has previously issued a unicast Poll
(since the tail will not delay transmission of the notification in (since the tail will not delay transmission of the notification in
this case.) this case.)
If both the multipoint path and the reverse unicast paths fail If both the multipoint path and the reverse unicast paths fail
(regardless of the state of the forward unicast path), the tail will (regardless of the state of the forward unicast path), the tail will
detect the failure but the head will remain unaware of this fact. detect the failure but the head will remain unaware of this fact.
skipping to change at page 28, line 5 skipping to change at page 26, line 36
Sequence, but the state of the multipoint path will be unknown to the Sequence, but the state of the multipoint path will be unknown to the
head. The tail will continue to receive multipoint data traffic. head. The tail will continue to receive multipoint data traffic.
If the multipoint path and the reverse unicast path both stay up but If the multipoint path and the reverse unicast path both stay up but
the forward unicast path fails, neither side will notice so long as a the forward unicast path fails, neither side will notice so long as a
unicast Poll Sequence is never sent by the head. If the head sends a unicast Poll Sequence is never sent by the head. If the head sends a
unicast Poll Sequence, the head will see the BFD session fail, but unicast Poll Sequence, the head will see the BFD session fail, but
the state of the multipoint path will be unknown to the head. The the state of the multipoint path will be unknown to the head. The
tail will continue to receive multipoint data traffic. tail will continue to receive multipoint data traffic.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security Considerations 8. Security Considerations
This specification does not raise any additional security issues This specification does not raise any additional security issues
beyond those of the specifications referred to in the list of beyond those of the specifications referred to in the list of
normative references. normative references.
9. Normative References 9. Contributors
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding
Detection", RFC 5880, June 2010
Contributors
Rahul Aggarwal of Juniper Networks and George Swallow of Cisco Rahul Aggarwal of Juniper Networks and George Swallow of Cisco
Systems provided the initial idea for this specification and Systems provided the initial idea for this specification and
contributed to its development. contributed to its development.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
Authors' Addresses Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA Sunnyvale, California 94089-1206
Phone: +1-408-745-2000 USA
Email: dkatz@juniper.net
Dave Ward Email: dkatz@juniper.net
Cisco
170 West Tasman Dr.
San Jose, CA 95134
Phone: +1-408-526-4000
Email: dward@cisco.com
Changes from the previous draft Dave Ward
Cisco Systems
170 West Tasman Dr.
San Jose, California 95134
USA
This is a reissue of the previous version. There are only minor Email: wardd@cisco.com
editorial changes.
This document expires in August, 2014. Santosh Pallagatti (editor)
Juniper Networks
Embassy Business Park
Bangalore, KA 560093
India
Email: santoshpk@juniper.net
 End of changes. 115 change blocks. 
200 lines changed or deleted 210 lines changed or added

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