< draft-ietf-bfd-multipoint-16.txt | draft-ietf-bfd-multipoint-17.txt > | |||
---|---|---|---|---|
Internet Engineering Task Force D. Katz | Internet Engineering Task Force D. Katz | |||
Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
Updates: 5880 (if approved) D. Ward | Updates: 5880 (if approved) D. Ward | |||
Intended status: Standards Track Cisco Systems | Intended status: Standards Track Cisco Systems | |||
Expires: October 20, 2018 S. Pallagatti, Ed. | Expires: November 24, 2018 S. Pallagatti, Ed. | |||
Individual contributor | Individual contributor | |||
G. Mirsky, Ed. | G. Mirsky, Ed. | |||
ZTE Corp. | ZTE Corp. | |||
April 18, 2018 | May 23, 2018 | |||
BFD for Multipoint Networks | BFD for Multipoint Networks | |||
draft-ietf-bfd-multipoint-16 | draft-ietf-bfd-multipoint-17 | |||
Abstract | Abstract | |||
This document describes extensions to the Bidirectional Forwarding | This document describes extensions to the Bidirectional Forwarding | |||
Detection (BFD) protocol for its use in multipoint and multicast | Detection (BFD) protocol for its use in multipoint and multicast | |||
networks. | networks. | |||
Requirements Language | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | ||||
"OPTIONAL" in this document are to be interpreted as described in BCP | ||||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | 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). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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." | |||
This Internet-Draft will expire on October 20, 2018. | This Internet-Draft will expire on November 24, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://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. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 | 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 4 | 5.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 | |||
4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 | 5.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 | 5.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 | |||
4.4.1. New State Variable Values . . . . . . . . . . . . . . 5 | 5.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.4.2. State Variable Initialization and Maintenance . . . . 6 | 5.4.1. New State Variable Values . . . . . . . . . . . . . . 5 | |||
4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 | 5.4.2. State Variable Initialization and Maintenance . . . . 6 | |||
4.6. Session Establishment . . . . . . . . . . . . . . . . . . 6 | 5.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 | 5.6. Session Establishment . . . . . . . . . . . . . . . . . . 6 | |||
4.8. Packet consumption on tails . . . . . . . . . . . . . . . 7 | 5.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 | |||
4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 | 5.8. Packet consumption on tails . . . . . . . . . . . . . . . 7 | |||
4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 8 | 5.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 | |||
4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 | 5.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 8 | |||
4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 | 5.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 9 | 5.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 | |||
4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 | 5.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 9 | |||
4.13. Base Specification Text Replacement . . . . . . . . . . . 10 | 5.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 | |||
4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 | 5.13. Base Specification Text Replacement . . . . . . . . . . . 10 | |||
4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 | 5.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 | |||
4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 14 | 5.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 | |||
5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 5.13.3. Transmitting BFD Control Packets . . . . . . . . . . 14 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
11. Normative References . . . . . . . . . . . . . . . . . . . . 17 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
1. Introduction | 1. Introduction | |||
The Bidirectional Forwarding Detection protocol [RFC5880] 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, the | Although this seems in conflict with the "Bidirectional" in BFD, the | |||
protocol is capable supporting this use case. | protocol is capable of supporting this use case. | |||
This application of BFD allows for the tails to detect a lack of | This application of BFD allows for the tails to detect a lack of | |||
connectivity from the head. Due to unidirectional nature, virtually | connectivity from the head. Due to unidirectional nature, virtually | |||
all options and timing parameters are controlled by the head. | all options and timing parameters are controlled by the head. | |||
As an option, the tail may notify the head of the lack of multipoint | As an option, the tail may notify the head of the lack of multipoint | |||
connectivity. Details of tail notification to the head are outside | connectivity. Details of tail notification to the head are outside | |||
the scope of this document. | the scope of this document. | |||
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. | |||
Term "connectivity" in this document is not being used in the context | Term "connectivity" in this document is not being used in the context | |||
of connectivity verification in transport network but as an | of connectivity verification in transport network but as an | |||
alternative to "continuity", i.e. existence of a forwarding path | alternative to "continuity", i.e., the existence of a forwarding path | |||
between the sender and the receiver. | between the sender and the receiver. | |||
This document effectively modifies and adds to the base BFD | This document effectively updates and extends the base BFD | |||
specification [RFC5880]. | specification [RFC5880]. | |||
2. Goals | 2. Keywords | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | ||||
"OPTIONAL" in this document are to be interpreted as described in BCP | ||||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
3. 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. | failed. | |||
Another goal is for the mechanism to work on any multicast | Another goal is for the mechanism to work on any multicast | |||
technology. | technology. | |||
A further goal is to support multiple, overlapping point-to- | A further goal is to support multiple, overlapping point-to- | |||
multipoint paths, as well as multipoint-to-multipoint paths, and to | multipoint paths, as well as multipoint-to-multipoint paths, and to | |||
allow point-to-point BFD sessions to operate simultaneously among the | allow point-to-point BFD sessions to operate simultaneously among the | |||
systems participating in Multipoint BFD. | systems participating in Multipoint BFD. | |||
It is not a goal for this protocol to verify point-to-point bi- | It is not a goal for this protocol to verify point-to-point bi- | |||
directional connectivity between the head and any tail. This can be | directional connectivity between the head and any tail. This can be | |||
done independently (and with no penalty in protocol overhead) by | done independently (and with no penalty in protocol overhead) by | |||
using point-to-point BFD. | using point-to-point BFD. | |||
3. Overview | 4. 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 having failed. For some applications this | tail declares the path to have failed. For some applications this is | |||
is the only mechanism necessary; the head can remain ignorant of the | the only mechanism necessary; the head can remain ignorant of the | |||
tails. | tails. | |||
The head of a multipoint BFD session may wish to be alerted to the | The head of a multipoint BFD session may wish to be alerted to the | |||
tails' connectivity (or lack thereof). Details of how the head keeps | tails' connectivity (or lack thereof). Details of how the head keeps | |||
track of tails and how tails alert their connectivity to the head are | track of tails and how tails alert their connectivity to the head are | |||
outside scope of this document. | outside scope of this document. | |||
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, as described in Section 4.7 and | at both heads and tails, as described in Section 5.7 and | |||
Section 4.13.2. Furthermore, the same head and tail may share | Section 5.13.2. Furthermore, the same head and tail may share | |||
multiple multipoint paths, and a multipoint path may have multiple | multiple multipoint paths, and a multipoint path may have multiple | |||
heads. | heads. | |||
4. Protocol Details | 5. 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 | 5.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 [RFC5880]. This means that Multipoint BFD does not depend | the M bit [RFC5880]. This means that Multipoint BFD does not depend | |||
on the recipient of a packet to know whether the packet was received | on the recipient of a packet to know whether the packet was received | |||
over a multipoint path. This can be useful in scenarios where this | over a 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 | 5.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. | |||
The head has a session of type MultipointHead, as defined in | The head has a session of type MultipointHead, as defined in | |||
Section 4.4.1, that is bound to a multipoint path. Multipoint BFD | Section 5.4.1, that is bound to a multipoint path. Multipoint BFD | |||
Control packets are sent by this session over the multipoint path, | Control packets are sent by this session over the multipoint path, | |||
and no BFD Control packets are received by it. | and no BFD Control packets are received by it. | |||
Each tail has a session of type MultipointTail, as defined in | Each tail has a session of type MultipointTail, as defined in | |||
Section 4.4.1, associated with a multipoint path. These sessions | Section 5.4.1, associated with a multipoint path. These sessions | |||
receive BFD Control packets from the head over the multipoint path. | receive BFD Control packets from the head over the multipoint path. | |||
4.3. Session Failure Semantics | 5.3. Session Failure Semantics | |||
The semantics of session failure is subtle enough to warrant further | The semantics of session failure is 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. | |||
4.4. State Variables | 5.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 Variable Values | 5.4.1. New State Variable Values | |||
A number of new values of the state variable bfd.SessionType are | A number of new values of the state variable bfd.SessionType are | |||
added to the base BFD [RFC5880] and base S-BFD [RFC7880] | added to the base BFD [RFC5880] and base S-BFD [RFC7880] | |||
specifications in support of Multipoint BFD. | specifications in support of Multipoint BFD. | |||
bfd.SessionType | bfd.SessionType | |||
The type of this session as defined in [RFC7880]. Newly added | The type of this session as defined in [RFC7880]. Newly added | |||
values are: | values are: | |||
skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 5 ¶ | |||
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. | |||
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. | the session is created. | |||
4.4.2. State Variable Initialization and Maintenance | 5.4.2. State Variable Initialization and Maintenance | |||
Some state variables defined in section 6.8.1 of [RFC5880] need to be | Some state variables defined in section 6.8.1 of [RFC5880] need to be | |||
initialized or manipulated differently depending on the session type. | initialized or manipulated differently depending on the session type. | |||
bfd.RequiredMinRxInterval | bfd.RequiredMinRxInterval | |||
This variable MUST be initialized to 0 for session type | This variable MUST be initialized to 0 for session type | |||
MultipointHead. | MultipointHead. | |||
bfd.DemandMode | bfd.DemandMode | |||
This variable MUST be initialized to 1 for session type | This variable MUST be initialized to 1 for session type | |||
MultipointHead and MUST be initialized to 0 for session type | MultipointHead and MUST be initialized to 0 for session type | |||
MultipointTail. | MultipointTail. | |||
4.5. State Machine | 5.5. 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. | |||
Sessions of type MultipointHead MUST NOT send BFD control packets | Sessions of type MultipointHead MUST NOT send BFD control packets | |||
with the State field being set to INIT, and those packets MUST be | with the State field being set to INIT, and those packets MUST be | |||
ignored on receipt. | ignored on receipt. | |||
The following diagram provides an overview of the state machine for | The following diagram provides an overview of the state machine for | |||
skipping to change at page 6, line 47 ¶ | skipping to change at page 6, line 47 ¶ | |||
+------+ 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.6. Session Establishment | 5.6. Session Establishment | |||
Unlike point-to-point BFD, Multipoint BFD provides a form of the | Unlike point-to-point BFD, Multipoint BFD provides a form of the | |||
discovery mechanism for tails to discover the head. The minimum | discovery mechanism for tails to discover the head. The minimum | |||
amount of a priori information required both on the head and tails is | amount of a priori information required both on the head and tails is | |||
binding to the multipoint path over which BFD is running. The head | the binding to the multipoint path over which BFD is running. The | |||
transmits Multipoint BFD packets on that tree, and the tails listen | head transmits Multipoint BFD packets on that tree, and the tails | |||
for BFD packets on that tree. All other information MAY be | listen for BFD packets on that tree. All other information MAY be | |||
determined dynamically. | determined dynamically. | |||
A session of type MultipointHead is created for each multipoint path | A session of type MultipointHead is created for each multipoint path | |||
over which the head wishes to run BFD. This session runs in the | over which the head wishes to run BFD. This session runs in the | |||
Active role , per section 6.1 [RFC5880]. Except when | Active role , per section 6.1 [RFC5880]. Except when | |||
administratively terminating BFD service, this session is always in | administratively terminating BFD service, this session is always in | |||
state Up and always operates in Demand mode. No received packets are | state Up and always operates in Demand mode. No received packets are | |||
ever demultiplexed to the MultipointHead session. In this sense, it | ever demultiplexed to the MultipointHead session. In this sense, it | |||
is a degenerate form of a session. | is a degenerate form of a session. | |||
Sessions on the tail MAY be established dynamically, based on the | Sessions on the tail MAY be established dynamically, based on the | |||
receipt of a Multipoint BFD Control packet from the head, and are of | receipt of a Multipoint BFD Control packet from the head, and are of | |||
type MultipointTail. Tail sessions always take the Passive role, per | type MultipointTail. Tail sessions always take the Passive role, per | |||
section 6.1 [RFC5880]. | section 6.1 [RFC5880]. | |||
4.7. Discriminators and Packet Demultiplexing | 5.7. 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 multipoint | The head sends Multipoint BFD Control packets over the multipoint | |||
path via the MultipointHead session with My Discr set to a value | path via the MultipointHead session with My Discr set to a value | |||
bound to the multipoint path, and with Your Discr set to zero. | bound to the multipoint path, and with Your Discr set to zero. | |||
IP and MPLS multipoint tails MUST demultiplex BFD packets based on a | IP and MPLS multipoint tails MUST demultiplex BFD packets based on a | |||
combination of the source address, My Discriminator and the identity | combination of the source address, My Discriminator and the identity | |||
skipping to change at page 7, line 44 ¶ | skipping to change at page 7, line 44 ¶ | |||
received from. Together they uniquely identify the head of the | received from. Together they uniquely identify the head of the | |||
multipoint path. Bootstrapping BFD session to multipoint MPLS LSP in | multipoint path. Bootstrapping BFD session to multipoint MPLS LSP in | |||
case of penultimate hop popping is outside the scope of this | case of penultimate hop popping is outside the scope of this | |||
document. | document. | |||
Note that, unlike point-to-point sessions, the My Discriminator value | Note that, unlike point-to-point sessions, the My Discriminator value | |||
on MultipointHead session MUST NOT be changed during the life of a | on MultipointHead session 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.8. Packet consumption on tails | 5.8. Packet consumption on tails | |||
BFD packets received on tails for an IP multicast group MUST be | BFD packets received on tails for an IP multicast group MUST be | |||
consumed by tails and MUST NOT be forwarded to receivers. Node with | consumed by tails and MUST NOT be forwarded to receivers. Node with | |||
the BFD session of type MultipointTail MUST identify packet received | the BFD session of type MultipointTail MUST identify packet received | |||
on an IP multipoint path as BFD control packet if the destination UDP | on an IP multipoint path as BFD control packet if the destination UDP | |||
port value equals 3784. | port value equals 3784. | |||
For multipoint LSPs, when IP/UDP encapsulation of BFD control packets | For multipoint LSPs, when IP/UDP encapsulation of BFD control packets | |||
is used, MultipointTail MUST expect destination UDP port 3784. | is used, MultipointTail MUST expect destination UDP port 3784. | |||
Destination IP address of BFD control packet MUST be in 127.0.0.0/8 | Destination IP address of BFD control packet MUST be in 127.0.0.0/8 | |||
range for IPv4 or in 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. The | range for IPv4 or in 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. The | |||
use of these destination addresses is consistent with the | use of these destination addresses is consistent with the | |||
explanations and usage in [RFC8029]. Packets identified as BFD | explanations and usage in [RFC8029]. Packets identified as BFD | |||
packets MUST be consumed by MultipointTail and demultiplex as | packets MUST be consumed by MultipointTail and demultiplex as | |||
described in Section 4.13.2. Use of other types of encapsulation of | described in Section 5.13.2. Use of other types of encapsulation of | |||
the BFD control message over multipoint LSP is outside the scope of | the BFD control message over multipoint LSP is outside the scope of | |||
this document. | this document. | |||
4.9. Bringing Up and Shutting Down Multipoint BFD Service | 5.9. 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 | available) SHOULD start with bfd.SessionState set to Down and | |||
bfd.RequiredMinRxInterval MUST be set to zero in the MultipointHead | bfd.RequiredMinRxInterval MUST be set to zero in the MultipointHead | |||
session. The session SHOULD remain in this state for a time equal to | session. 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 a larger value of bfd.DesiredMinTxInterval than | is using the same or a larger value of bfd.DesiredMinTxInterval than | |||
it did previously). | it did previously). | |||
skipping to change at page 8, line 46 ¶ | skipping to change at page 8, line 46 ¶ | |||
To shut down a multipoint session the head MUST administratively set | To shut down a multipoint session the head MUST administratively set | |||
bfd.SessionState in the MultipointHead session to either Down or | bfd.SessionState in the MultipointHead session to either Down or | |||
AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The | AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The | |||
session SHOULD send BFD Control packets in this state for a period | session SHOULD send BFD Control packets in this state for a period | |||
equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). | equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). | |||
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.10. Timer Manipulation | 5.10. 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. However, to indicate a change in the packets, | changes. However, to indicate a change in the packets, | |||
MultipointHead session MUST send packets with the P bit set. | MultipointHead session MUST send packets with the P bit set. | |||
MultipointTail session MUST NOT reply if the packet has M and P bits | MultipointTail session MUST NOT reply if the packet has M and P bits | |||
set and bfd.RequiredMinRxInterval set to 0. | set and bfd.RequiredMinRxInterval set to 0. | |||
The MultipointHead, when changing the transmit interval to a higher | The MultipointHead, when changing the transmit interval to a higher | |||
value, MUST send BFD control packets with P bit set at the old | value, MUST send BFD control packets with P bit set at the old | |||
transmit interval before using the higher value in order to avoid | transmit interval before using the higher value in order to avoid | |||
false detection timeouts at the tails. MultipointHead session MAY | false detection timeouts at the tails. MultipointHead session MAY | |||
also wait some amount of time before making the changes to the | also wait some amount of time before making the changes to the | |||
transmit interval (through configuration). | transmit interval (through configuration). | |||
Change in the value of bfd.RequiredMinRxInterval is outside the scope | Change in the value of bfd.RequiredMinRxInterval is outside the scope | |||
of this document. | of this document. | |||
4.11. Detection Times | 5.11. 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 MultipointHead sessions never receive packets, they do not | Since MultipointHead sessions never receive packets, they do not | |||
calculate a detection time. | calculate a detection time. | |||
MultipointTail sessions cannot influence the transmission rate of the | MultipointTail sessions cannot influence the transmission rate of the | |||
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.12. State Maintenance for Down/AdminDown Sessions | 5.12. 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.12.1. MultipointHead Sessions | 5.12.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.12.2. MultipointTail Sessions | 5.12.2. MultipointTail Sessions | |||
MultipointTail sessions MAY be destroyed immediately upon leaving Up | MultipointTail sessions MAY be destroyed immediately upon leaving Up | |||
state, since tail will transmit no packets. | state, since tail will transmit no packets. | |||
Otherwise, MultipointTail sessions SHOULD be maintained as long as | Otherwise, MultipointTail sessions SHOULD be maintained as long as | |||
BFD Control packets are being received by it (which by definition | BFD Control packets are being received by it (which by definition | |||
will indicate that the head is not Up). | will indicate that the head is not Up). | |||
4.13. Base Specification Text Replacement | 5.13. 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 [RFC5880] in support of BFD for | sections in the base specification [RFC5880] in support of BFD for | |||
multipoint networks while not changing processing for point-to-point | multipoint networks while not changing processing for point-to-point | |||
BFD. | BFD. | |||
4.13.1. Reception of BFD Control Packets | 5.13.1. Reception of BFD Control Packets | |||
The following procedure replaces section 6.8.6 of [RFC5880]. | The following procedure replaces entire 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 10, line 45 ¶ | skipping to change at page 10, line 45 ¶ | |||
discarded. | discarded. | |||
If the Length field is greater than the payload of the | If the Length field is greater than the payload of the | |||
encapsulating protocol, the packet MUST be discarded. | encapsulating protocol, the packet MUST be discarded. | |||
If the Detect Mult field is zero, the packet MUST be discarded. | If the Detect Mult field is zero, the packet MUST be discarded. | |||
If the My Discriminator field is zero, the packet MUST be | If the My Discriminator field is zero, the packet MUST be | |||
discarded. | discarded. | |||
Demultiplex the packet to a session according to Section 4.13.2 | Demultiplex the packet to a session according to Section 5.13.2 | |||
below. The result is either a session of the proper type, or the | below. The result is either a session of the proper type, or the | |||
packet is discarded (and packet processing MUST cease). | packet is discarded (and packet processing MUST cease). | |||
If the A bit is set and no authentication is in use (bfd.AuthType | If the A bit is set and no authentication is in use (bfd.AuthType | |||
is zero), the packet MUST be discarded. | is zero), the packet MUST be discarded. | |||
If the A bit is clear and authentication is in use (bfd.AuthType | If the A bit is clear and authentication is in use (bfd.AuthType | |||
is nonzero), the packet MUST be discarded. | is nonzero), the packet MUST be discarded. | |||
If the A bit is set, the packet MUST be authenticated under the | If the A bit is set, the packet MUST be authenticated under the | |||
skipping to change at page 11, line 35 ¶ | skipping to change at page 11, line 35 ¶ | |||
the Final (F) bit in the received packet is set, the Poll Sequence | the Final (F) bit in the received packet is set, the Poll Sequence | |||
MUST be terminated. | MUST be terminated. | |||
If bfd.SessionType is PointToPoint, update the transmit interval | If bfd.SessionType is PointToPoint, update the transmit interval | |||
as described in [RFC5880] section 6.8.2. | as described in [RFC5880] 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 section 6.8.4 of [RFC5880]. If bfd.SessionType is | described in section 6.8.4 of [RFC5880]. If bfd.SessionType is | |||
MultipointTail, then update the Detection Time as the product of | MultipointTail, then update the Detection Time as the product of | |||
the last received values of Desired Min TX Interval and Detect | the last received values of Desired Min TX Interval and Detect | |||
Mult, as described in Section 4.11 of this specification. | Mult, as described in Section 5.11 of this specification. | |||
If bfd.SessionState is AdminDown | If bfd.SessionState is AdminDown | |||
Discard the packet | Discard the packet | |||
If the received state is AdminDown | If the 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) | |||
skipping to change at page 12, line 40 ¶ | skipping to change at page 12, line 40 ¶ | |||
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 | Check to see if Demand mode should become active or not (see | |||
[RFC5880] 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.13.3). | of BFD Control packets (see Section 5.13.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.13.3). | packets (see Section 5.13.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 [RFC5880] section 6.8.4. | of the Detection Time expiration rules in [RFC5880] section 6.8.4. | |||
4.13.2. Demultiplexing BFD Control Packets | 5.13.2. Demultiplexing BFD Control Packets | |||
This section is part of the replacement for [RFC5880] 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 as based on source address, My Discriminator | Select a session as based on source address, My Discriminator | |||
skipping to change at page 14, line 5 ¶ | skipping to change at page 14, line 5 ¶ | |||
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.13.3. Transmitting BFD Control Packets | 5.13.3. Transmitting BFD Control Packets | |||
The following procedure replaces section 6.8.7 of [RFC5880]. | The following procedure replaces entire 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 [RFC5880] section 6.8.2, except as specified | determined according to [RFC5880] section 6.8.2, except as specified | |||
in this section. | in 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.SessionType | A system MUST NOT transmit any BFD Control packets if bfd.SessionType | |||
is MultipointTail. | is MultipointTail. | |||
skipping to change at page 16, line 37 ¶ | skipping to change at page 16, line 37 ¶ | |||
Set to 0 if bfd.SessionType is MultipointHead or | Set to 0 if bfd.SessionType is MultipointHead or | |||
MultipointTail. | MultipointTail. | |||
Authentication Section | Authentication Section | |||
Included and set according to the rules in [RFC5880] section | Included and set according to the rules in [RFC5880] section | |||
6.7 if authentication is in use (bfd.AuthType is nonzero). | 6.7 if authentication is in use (bfd.AuthType is nonzero). | |||
Otherwise, this section is not present. | Otherwise, this section is not present. | |||
5. Assumptions | 6. Assumptions | |||
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. IANA Considerations | 7. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
7. Security Considerations | 8. Security Considerations | |||
The same security considerations as those described in [RFC5880] | The same security considerations as those described in [RFC5880] | |||
apply to this document. Additionally, implementations that create | apply to this document. Additionally, implementations that create | |||
MultpointTail sessions dynamically upon receipt of Multipoint BFD | MultpointTail sessions dynamically upon receipt of Multipoint BFD | |||
Control packets MUST implement protective measures to prevent an | Control packets MUST implement protective measures to prevent an | |||
infinite number of MultipointTail sessions being created. Below are | infinite number of MultipointTail sessions being created. Below are | |||
listed some points to be considered in such implementations. | listed some points to be considered in such implementations. | |||
If a Multipoint BFD Control packet did not arrive on a multicast | If a Multipoint BFD Control packet did not arrive on a multicast | |||
tree (e.g. on the expected interface, with expected MPLS label, | tree (e.g., on the expected interface, with expected MPLS label, | |||
etc), then a MultipointTail session should not be created. | etc), then a MultipointTail session should not be created. | |||
If redundant streams are expected for a given multicast stream, | If redundant streams are expected for a given multicast stream, | |||
then the implementations should not create more MultipointTail | then the implementations should not create more MultipointTail | |||
sessions than the number of streams. Additionally, when the | sessions than the number of streams. Additionally, when the | |||
number of MultipointTail sessions exceeds the number of expected | number of MultipointTail sessions exceeds the number of expected | |||
streams, then the implementation should generate an alarm to users | streams, then the implementation should generate an alarm to users | |||
to indicate the anomaly. | to indicate the anomaly. | |||
The implementation should have a reasonable upper bound on the | The implementation should have a reasonable upper bound on the | |||
number of MultipointTail sessions that can be created, with the | number of MultipointTail sessions that can be created, with the | |||
upper bound potentially being computed based on the number of | upper bound potentially being computed based on the number of | |||
multicast streams that the system is expecting. | multicast streams that the system is expecting. | |||
8. Contributors | 9. 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. | |||
9. Acknowledgments | 10. Acknowledgments | |||
Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, | Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, | |||
Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have | Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have | |||
greatly contributed to this document. | greatly contributed to this document. | |||
10. Normative References | 11. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | |||
<https://www.rfc-editor.org/info/rfc5880>. | <https://www.rfc-editor.org/info/rfc5880>. | |||
End of changes. 51 change blocks. | ||||
91 lines changed or deleted | 92 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |