| Internet-Draft | STAMP BFD TLV | July 2026 |
| Li, et al. | Expires 5 January 2027 | [Page] |
Network operators frequently run both Bidirectional Forwarding Detection (BFD) for rapid fault detection and an active measurement protocol such as STAMP for delay and loss measurement between the same pair of nodes, resulting in two parallel packet streams with overlapping timing requirements.¶
This document defines an optional STAMP TLV that carries a BFD Control message within STAMP test packets, using the extension format of RFC 8972. A single test packet stream can then drive both the BFD state machine and STAMP performance measurement. The BFD protocol itself is unchanged.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Bidirectional Forwarding Detection (BFD) [RFC5880] provides rapid detection of path failures. The Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762] provides delay and loss measurement, with an extension format defined in [RFC8972] that allows optional TLVs to follow the base test packet fields. In many deployments, both run concurrently between the same node pair: BFD at sub-second intervals for fault detection, and STAMP for performance measurement.¶
Operating two packet streams consumes additional bandwidth and processing, and the two streams may take different paths in multipath environments, so the measured path may not be the path whose liveness is being verified.¶
This document defines a BFD TLV for STAMP test packets. When present, the TLV carries a complete BFD Control message as specified in Section 4.1 of [RFC5880]. The receiving node passes the carried BFD Control message to its BFD state machine and includes its own current BFD Control message in the reflected packet, so that a single STAMP session simultaneously sustains a BFD session over the same path. The BFD protocol state machine, message format, and timer negotiation are used unchanged; this document defines only the carriage of BFD Control messages within STAMP.¶
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.¶
The BFD TLV follows the TLV format defined in Section 4 of [RFC8972]:¶
A STAMP test packet MUST NOT carry more than one BFD TLV.¶
A Session-Sender configured to run BFD over a STAMP session includes a BFD TLV in transmitted test packets. The carried BFD Control message MUST reflect the current local BFD session state (State, Discriminators, Detect Mult, and timer values), exactly as if it were sent in a standalone BFD Control packet.¶
The STAMP transmission interval MUST satisfy the negotiated BFD transmission interval that results from the procedures of Section 6.8.2 of [RFC5880]; otherwise the peer's BFD Detection Timer may expire despite path liveness. If the operator configures a STAMP interval larger than the BFD requirement, the implementation MUST either reject the configuration or renegotiate BFD timers accordingly.¶
A Session-Reflector that supports this TLV and receives a test packet containing a BFD TLV MUST (a) process the STAMP base fields per [RFC8762], and (b) deliver the carried BFD Control message to the local BFD state machine, which processes it per [RFC5880].¶
In the reflected test packet, the Session-Reflector MUST include a BFD TLV carrying its own current BFD Control message. BFD Detection Time expiry at either node is handled exactly as in standalone BFD, including session state transition and fault notification.¶
A Session-Reflector that does not support this TLV handles it per the unrecognized-TLV procedures of [RFC8972]; the Session-Sender detects the lack of support through the TLV flags of the reflected packet and MUST NOT treat the absence of BFD processing as a path failure.¶
Because the BFD Control message and the measurement fields travel in the same packet, fault detection and performance measurement apply to the same forwarding path, including in ECMP environments. This is a primary motivation for combined operation.¶
The security considerations of [RFC8762], [RFC8972], and [RFC5880] apply. The carried BFD Control message retains BFD's native authentication: if the BFD session uses an Authentication Section, it is carried and validated unchanged. In addition, STAMP authenticated mode SHOULD be used to protect the integrity of the test packet as a whole. An attacker able to inject test packets with forged BFD TLVs could tear down BFD sessions; the combination of BFD authentication and STAMP authenticated mode mitigates this.¶
IANA is requested to assign one new TLV Type (TBD1, "BFD") from the "STAMP TLV Types" registry defined by [RFC8972], with this document as the reference.¶
The authors would like to thank the members of the IPPM and BFD Working Groups for their review and feedback.¶