< draft-ietf-bfd-multipoint-12.txt | draft-ietf-bfd-multipoint-13.txt > | |||
---|---|---|---|---|
Internet Engineering Task Force D. Katz | Internet Engineering Task Force D. Katz | |||
Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
Intended status: Standards Track D. Ward | Updates: 5880, 7880 (if approved) D. Ward | |||
Expires: June 22, 2018 Cisco Systems | Intended status: Standards Track Cisco Systems | |||
S. Pallagatti, Ed. | Expires: July 31, 2018 S. Pallagatti, Ed. | |||
Individual contributor | Individual contributor | |||
G. Mirsky, Ed. | G. Mirsky, Ed. | |||
ZTE Corp. | ZTE Corp. | |||
December 19, 2017 | January 27, 2018 | |||
BFD for Multipoint Networks | BFD for Multipoint Networks | |||
draft-ietf-bfd-multipoint-12 | draft-ietf-bfd-multipoint-13 | |||
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. Comments on this draft should be directed to rtg- | networks. | |||
bfd@ietf.org. | ||||
Requirements Language | Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 45 ¶ | |||
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 June 22, 2018. | This Internet-Draft will expire on July 31, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 | 4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 | |||
4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 | 4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 | |||
4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 | 4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.4.1. New State Variables . . . . . . . . . . . . . . . . . 5 | 4.4.1. New State Variable Values . . . . . . . . . . . . . . 5 | |||
4.4.2. State Variable Initialization and Maintenance . . . . 6 | 4.4.2. State Variable Initialization and Maintenance . . . . 6 | |||
4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 | 4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 | 4.6. Session Establishment . . . . . . . . . . . . . . . . . . 6 | |||
4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 | 4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 | |||
4.8. Packet consumption on tails . . . . . . . . . . . . . . . 8 | 4.8. Packet consumption on tails . . . . . . . . . . . . . . . 7 | |||
4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 | 4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 | |||
4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 9 | 4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 8 | |||
4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 | 4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 | 4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 | |||
4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 10 | 4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 9 | |||
4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 | 4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 9 | |||
4.13. Base Specification Text Replacement . . . . . . . . . . . 10 | 4.13. Base Specification Text Replacement . . . . . . . . . . . 10 | |||
4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 | 4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 | |||
4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 | 4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 12 | |||
4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 14 | 4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 13 | |||
5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
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"). | |||
skipping to change at page 3, line 32 ¶ | skipping to change at page 3, line 32 ¶ | |||
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 head are outside the | connectivity. Details of tail notification to head are outside the | |||
scope of this document. | 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 context of | Term "connectivity" in this document is not being used in the context | |||
connectivity verification in transport network but as an alternative | of connectivity verification in transport network but as an | |||
to "continuity", i.e. existence of a path between the sender and the | alternative to "continuity", i.e. existence of a path between the | |||
receiver. | sender and the receiver. | |||
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 [RFC5880]. | |||
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. | failed. | |||
Another goal is for the mechanism to work on any multicast or | Another goal is for the mechanism to work on any multicast | |||
multipoint medium. | technology. | |||
A further goal is to support multiple, overlapping multipoint paths, | ||||
as well as multipoint paths with multiple heads, and to allow point- | ||||
to-point BFD sessions to operate simultaneously among the systems | ||||
participating in Multipoint BFD. | ||||
A final goal is to integrate multipoint operation into the base | A further goal is to support multiple, overlapping point-to- | |||
specification in such a way as to make it relatively easy to support | multipoint paths, as well as multipoint-to-multipoint paths, and to | |||
both multipoint and point-to-point operation in a single | allow point-to-point BFD sessions to operate simultaneously among the | |||
implementation. | systems participating in Multipoint BFD. | |||
It is a non-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 tails. 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 | 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. | tails. | |||
Head may wish to be alerted to the tails' connectivity (or lack | A head may wish to be alerted to the tails' connectivity (or lack | |||
thereof). Details of how head keeps track of tails and how tails | thereof). Details of how the head keeps track of tails and how tails | |||
alert it's connectivity to head are outside scope of this document. | alert their connectivity to the head are 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. 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. This means that Multipoint BFD does not depend on the | the M bit [RFC5880]. This means that Multipoint BFD does not depend | |||
recipient of a packet to know whether the packet was received over a | on the recipient of a packet to know whether the packet was received | |||
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 | 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 [RFC5880], are of type | Point-to-point sessions, as described in [RFC5880], 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 Section 4.4.1 that is | |||
multipoint path. Multipoint BFD Control packets are sent by this | bound to a multipoint path. Multipoint BFD Control packets are sent | |||
session over the multipoint path, and no BFD Control packets are | by this session over the multipoint path, and no BFD Control packets | |||
received by it. | are received by it. | |||
Each tail has a session of type MultipointTail associated with a | Each tail has a session of type MultipointTail, as defined in | |||
multipoint path. These sessions receive BFD Control packets from the | Section 4.4.1, associated with a multipoint path. These sessions | |||
head over multipoint path. | receive BFD Control packets from the head over the multipoint path. | |||
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. | |||
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 Variable Values | |||
A number of state variables and their values are added to the base | A number of values of the state variable are added to the base BFD | |||
BFD [RFC5880] and base S-BFD [RFC7880] specifications in support of | [RFC5880] and base S-BFD [RFC7880] specifications in support of | |||
Multipoint BFD. | 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: | |||
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. | |||
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.13 | the session is created, according to the rules in Section 4.13 | |||
bfd.SilentTail | ||||
Always set to 1, a tail will never transmit any BFD Control | ||||
packets to the head under any circumstances. Setting to 0 is | ||||
outside the scope of this document. | ||||
This variable is only pertinent when bfd.SessionType is | ||||
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 [RFC5880] needs | Some state variables defined in section 6.8.1 of [RFC5880] need to be | |||
to be initialized or manipulated differently depending on the session | initialized or manipulated differently depending on the session type. | |||
type. | ||||
bfd.RequiredMinRxInterval | bfd.RequiredMinRxInterval | |||
This variable MUST be set to 0 for session type MultipointHead. | This variable MUST be set to 0 for session type 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 | 4.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. | |||
Session of type MultipointHead MUST NOT send BFD control packets with | Sessions of type MultipointHead MUST NOT send BFD control packets | |||
the State field being set to INIT, and must be ignored on receipt. | with the State field being set to INIT, and MUST be 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 | |||
session type MultipointTail. The notation on each arc represents the | session type MultipointTail. The notation on each arc represents the | |||
state of the remote system (as received in the State field in the BFD | state of the remote system (as received in the State field in the BFD | |||
Control packet) or indicates the expiration of the Detection Timer. | Control packet) or indicates the 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.6. Session Establishment | 4.6. 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. 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 | |||
the binding to the multipoint path over which BFD is running. The | the binding to the multipoint path over which BFD is running. The | |||
head transmits Multipoint BFD packets on that tree, and the tails | head transmits Multipoint BFD packets on that tree, and the tails | |||
listen 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. Except when terminating BFD service, this session is | Active role , per section 6.1 [RFC5880]. Except when | |||
always in state Up and always operates in Demand mode. No received | administratively terminating BFD service, this session is always in | |||
packets are ever demultiplexed to the MultipointHead session. In | state Up and always operates in Demand mode. No received packets are | |||
this sense it is a degenerate form of a session. | ever demultiplexed to the MultipointHead session. In this sense it | |||
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. | type MultipointTail. Tail sessions always take the Passive role, per | |||
section 6.1 [RFC5880]. | ||||
4.7. Discriminators and Packet Demultiplexing | 4.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 MultipointHead | The head sends Multipoint BFD Control packets over the multipoint | |||
session with My Discr set to a value bound to the multipoint path, | path via the MultipointHead session with My Discr set to a value | |||
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 | |||
of the multipoint tree which the Multipoint BFD Control packet was | of the multipoint tree which the Multipoint BFD Control packet was | |||
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 a multipoint 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 PointToPoint 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 | 4.8. Packet consumption on tails | |||
BFD packets received on tails for a multicast group MUST be consumed | BFD packets received on tails for an IP multicast group MUST be | |||
by tails and MUST NOT be forwarded to receivers. Session of type | consumed by tails and MUST NOT be forwarded to receivers. Session of | |||
MultipointTail MUST identify the packet as BFD with the help of | type MultipointTail MUST identify the packet as BFD with the help of | |||
destination UDP port number "3784" on IP multipoint path. | destination UDP port number "3784" on IP multipoint path. | |||
For multipoint LSP, when IP/UDP encapsulation of BFD control packet | For multipoint LSPs, when IP/UDP encapsulation of BFD control packets | |||
used, MultipointTail MUST use destination UDP port "3784" and | is used, MultipointTail MUST use destination UDP port "3784" and | |||
"127.0.0.0/8" range for IPv4 or "0:0:0:0:0:FFFF:7F00:0/104" range for | "127.0.0.0/8" range for IPv4 or "0:0:0:0:0:FFFF:7F00:0/104" range for | |||
IPv6. Packet identified as BFD packet MUST be consumed by | IPv6 ([RFC8029]). Packets identified as BFD packets MUST be consumed | |||
MultipointTail and demultiplex as described in Section 4.13.2. Use | by MultipointTail and demultiplex as described in Section 4.13.2. | |||
of other types of encapsulation for multipoint LSP is outside the | Use of other types of encapsulation for multipoint LSP is outside the | |||
scope of this document. | scope of this document. | |||
4.9. Bringing Up and Shutting Down Multipoint BFD Service | 4.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 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). | |||
Multipoint BFD service is brought up by administratively setting | Multipoint BFD service is brought up by administratively setting | |||
bfd.SessionState to Up in the MultipointHead session. | bfd.SessionState to Up in the MultipointHead session. | |||
A head may wish to shut down its BFD service in a controlled fashion. | A head may wish to shut down its BFD service in a controlled fashion. | |||
This is desirable because the tails need not wait a detection time | This is desirable because the tails need not wait a detection time | |||
prior to declaring the multipoint session to be down (and taking | prior to declaring the multipoint session to be down (and taking | |||
whatever action is necessary in that case.) | whatever action is necessary in that case). | |||
To shut down a multipoint session a head MUST administratively set | To shut down a multipoint session a 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 | 4.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 change in packet MultipointHead session | changes. However, to indicate a change in the packets, | |||
MUST send packet with P bit set. MultipointTail session MUST NOT | MultipointHead session MUST send packets with P bit set. | |||
reply if packet has M, P bit set and bfd.RequiredMinRxInterval set to | MultipointTail session MUST NOT reply if packet has M, P bit set and | |||
0. | bfd.RequiredMinRxInterval set to 0. | |||
The MultipointHead, when changing the transmit interval to higher | The MultipointHead, when changing the transmit interval to 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 MAY also wait | false detection timeouts at the tails. MultipointHead session MAY | |||
some amount of time before making the changes to the transmit | also wait some amount of time before making the changes to the | |||
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 | 4.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 the MultipointHead session never receives packets, it does 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 | 4.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 | 4.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 | 4.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 | 4.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. | sections in the base specification [RFC5880] in support of BFD for | |||
multipoint networks while not changing processing for point-to-point | ||||
BFD. | ||||
4.13.1. Reception of BFD Control Packets | 4.13.1. Reception of BFD Control Packets | |||
The following procedure replaces section 6.8.6 of [RFC5880]. | 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. | |||
skipping to change at page 11, line 7 ¶ | skipping to change at page 10, line 38 ¶ | |||
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 4.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 | |||
rules of section 6.7, based on the authentication type in use | rules of [RFC5880] section 6.7, based on the authentication type | |||
(bfd.AuthType.) This may cause the packet to be discarded. | in use (bfd.AuthType). This may cause the packet to be discarded. | |||
Set bfd.RemoteDiscr to the value of My Discriminator. | Set bfd.RemoteDiscr to the value of My Discriminator. | |||
Set bfd.RemoteState to the value of the State (Sta) field. | Set bfd.RemoteState to the value of the State (Sta) field. | |||
Set bfd.RemoteDemandMode to the value of the Demand (D) bit. | Set bfd.RemoteDemandMode to the value of the Demand (D) bit. | |||
Set bfd.RemoteMinRxInterval to the value of Required Min RX | Set bfd.RemoteMinRxInterval to the value of Required Min RX | |||
Interval. | Interval. | |||
skipping to change at page 12, line 45 ¶ | skipping to change at page 12, line 26 ¶ | |||
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 4.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 see Section 4.13.3.) | packets (see see Section 4.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 | 4.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 | |||
skipping to change at page 14, line 19 ¶ | skipping to change at page 13, line 47 ¶ | |||
The following procedure replaces section 6.8.7 of [RFC5880]. | 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 [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.SilentTail | A system MUST NOT transmit any BFD Control packets if bfd.SessionType | |||
is 1. | is MultipointTail. | |||
A system MUST NOT periodically transmit BFD Control packets if Demand | A system MUST NOT periodically transmit BFD Control packets if Demand | |||
mode is active on the remote system (bfd.RemoteDemandMode is 1, | mode is active on the remote system (bfd.RemoteDemandMode is 1, | |||
bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll | bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll | |||
Sequence is not being transmitted. | Sequence is not being transmitted. | |||
A system MUST NOT periodically transmit BFD Control packets if | A system MUST NOT periodically transmit BFD Control packets if | |||
bfd.RemoteMinRxInterval is zero. | bfd.RemoteMinRxInterval is zero. | |||
If bfd.SessionType is MultipointHead, the transmit interval MUST be | If bfd.SessionType is MultipointHead, the transmit interval MUST be | |||
set to bfd.DesiredMinTxInterval (this should happen automatically, as | set to bfd.DesiredMinTxInterval (this should happen automatically, as | |||
bfd.RemoteMinRxInterval will be zero.) | bfd.RemoteMinRxInterval will be zero). | |||
If bfd.SessionType is not MultipointHead, the transmit interval MUST | If bfd.SessionType is not MultipointHead, the transmit interval MUST | |||
be recalculated whenever bfd.DesiredMinTxInterval changes, or | be recalculated whenever bfd.DesiredMinTxInterval changes, or | |||
whenever bfd.RemoteMinRxInterval changes, and is equal to the greater | whenever bfd.RemoteMinRxInterval changes, and is equal to the greater | |||
of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for | of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for | |||
details on transmit timers. | details on transmit timers. | |||
A system MUST NOT set the Demand (D) bit if bfd.SessionType is | A system MUST NOT set the Demand (D) bit if bfd.SessionType is | |||
MultipointTail. | MultipointTail. | |||
skipping to change at page 15, line 35 ¶ | skipping to change at page 15, line 17 ¶ | |||
Final (F) | Final (F) | |||
Set to 1 if the local system is responding to a Control packet | Set to 1 if the local system is responding to a Control packet | |||
received with the Poll (P) bit set, or 0 if not. | received with the Poll (P) bit set, or 0 if not. | |||
Control Plane Independent (C) | Control Plane Independent (C) | |||
Set to 1 if the local system's BFD implementation is | Set to 1 if the local system's BFD implementation is | |||
independent of the control plane (it can continue to function | independent of the control plane (it can continue to function | |||
through a disruption of the control plane.) | through a disruption of the control plane). | |||
Authentication Present (A) | Authentication Present (A) | |||
Set to 1 if authentication is in use on this session | Set to 1 if authentication is in use on this session | |||
(bfd.AuthType is nonzero), or 0 if not. | (bfd.AuthType is nonzero), or 0 if not. | |||
Demand (D) | Demand (D) | |||
Set to bfd.DemandMode if bfd.SessionState is Up and | Set to bfd.DemandMode if bfd.SessionState is Up and | |||
bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is | bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is | |||
skipping to change at page 16, line 37 ¶ | skipping to change at page 16, line 20 ¶ | |||
Set to bfd.RequiredMinRxInterval. | Set to bfd.RequiredMinRxInterval. | |||
Required Min Echo RX Interval | Required Min Echo RX Interval | |||
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 section 6.7 if | Included and set according to the rules in [RFC5880] section | |||
authentication is in use (bfd.AuthType is nonzero.) Otherwise | 6.7 if authentication is in use (bfd.AuthType is nonzero). | |||
this section is not present. | Otherwise this section is not present. | |||
5. Assumptions | 5. 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 | 6. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
7. Security Considerations | 7. Security Considerations | |||
Implementations that create MultpointTail sessions dynamically upon | The same security considerations as those described in [RFC5880] | |||
receipt of Multipoint BFD Control packets MUST implement protective | apply to this document. Additionally, implementations that create | |||
measures to prevent infinite number of MultipointTail sessions being | MultpointTail sessions dynamically upon receipt of Multipoint BFD | |||
created. Below are listed some points to be considered in such | Control packets MUST implement protective measures to prevent | |||
implementations. | infinite number of MultipointTail sessions being created. Below are | |||
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 (ex: on expected interface, with expected MPLS label, etc), | tree (e.g. on expected interface, with expected MPLS label, etc), | |||
then a MultipointTail session should not be created. | 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 | |||
skipping to change at page 18, line 10 ¶ | skipping to change at page 17, line 38 ¶ | |||
[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>. | |||
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. | [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. | |||
Pallagatti, "Seamless Bidirectional Forwarding Detection | Pallagatti, "Seamless Bidirectional Forwarding Detection | |||
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, | (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, | |||
<https://www.rfc-editor.org/info/rfc7880>. | <https://www.rfc-editor.org/info/rfc7880>. | |||
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., | ||||
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label | ||||
Switched (MPLS) Data-Plane Failures", RFC 8029, | ||||
DOI 10.17487/RFC8029, March 2017, | ||||
<https://www.rfc-editor.org/info/rfc8029>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
Authors' Addresses | Authors' Addresses | |||
Dave Katz | Dave Katz | |||
Juniper Networks | Juniper Networks | |||
1194 N. Mathilda Ave. | 1194 N. Mathilda Ave. | |||
Sunnyvale, California 94089-1206 | Sunnyvale, California 94089-1206 | |||
USA | USA | |||
Email: dkatz@juniper.net | Email: dkatz@juniper.net | |||
Dave Ward | Dave Ward | |||
Cisco Systems | Cisco Systems | |||
End of changes. 61 change blocks. | ||||
123 lines changed or deleted | 119 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/ |