A STAMP Extension for Carrying Bidirectional Forwarding Detection Control Messages
draft-li-ippm-stamp-bfd-tlv-00

IPPM                                                               Z. Li
Internet-Draft                                                     Z. Du
Intended status: Standards Track                            China Mobile
Expires: 5 January 2027                                          J. Wang
                                                                W. Cheng
                                                                G. Zhang
                                                                  Centec
                                                                  X. Sun
                                                                   Inesa
                                                                 C. Zhao
                                                                    SAIA
                                                             4 July 2026

   A STAMP Extension for Carrying Bidirectional Forwarding Detection
                            Control Messages
                     draft-li-ippm-stamp-bfd-tlv-00

Abstract

   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.

Status of This Memo

   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.

Li, et al.               Expires 5 January 2027                 [Page 1]
Internet-Draft                STAMP BFD TLV                    July 2026

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  BFD TLV . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Session-Sender Behavior . . . . . . . . . . . . . . . . .   3
     3.2.  Session-Reflector Behavior  . . . . . . . . . . . . . . .   4
     3.3.  Path Consistency  . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   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

Li, et al.               Expires 5 January 2027                 [Page 2]
Internet-Draft                STAMP BFD TLV                    July 2026

   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.

1.1.  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.

2.  BFD TLV

   The BFD TLV follows the TLV format defined in Section 4 of [RFC8972]:

   *  Type: TBD1, to be assigned by IANA from the STAMP TLV Type
      registry created by [RFC8972].

   *  Length: the length of the Value field in octets, equal to the
      length of the carried BFD Control message.

   *  Value: a complete BFD Control message, exactly as specified in
      Section 4.1 of [RFC5880], including any BFD Authentication
      Section the BFD session is configured to use.

   A STAMP test packet MUST NOT carry more than one BFD TLV.

3.  Procedures

3.1.  Session-Sender Behavior

   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.

Li, et al.               Expires 5 January 2027                 [Page 3]
Internet-Draft                STAMP BFD TLV                    July 2026

3.2.  Session-Reflector Behavior

   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.

3.3.  Path Consistency

   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.

4.  Security Considerations

   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.

5.  IANA Considerations

   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.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Li, et al.               Expires 5 January 2027                 [Page 4]
Internet-Draft                STAMP BFD TLV                    July 2026

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
              Two-Way Active Measurement Protocol", RFC 8762,
              DOI 10.17487/RFC8762, March 2020,
              <https://www.rfc-editor.org/info/rfc8762>.

   [RFC8972]  Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
              and E. Ruffini, "Simple Two-Way Active Measurement
              Protocol Optional Extensions", RFC 8972,
              DOI 10.17487/RFC8972, January 2021,
              <https://www.rfc-editor.org/info/rfc8972>.

7.  Informative References

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, DOI 10.17487/RFC5357, October 2008,
              <https://www.rfc-editor.org/info/rfc5357>.

Acknowledgements

   The authors would like to thank the members of the IPPM and BFD
   Working Groups for their review and feedback.

Authors' Addresses

   Zhiqiang Li
   China Mobile
   Beijing
   100053
   China
   Email: lizhiqiangyjy@chinamobile.com

   Zongpeng Du
   China Mobile
   Beijing
   100053
   China
   Email: duzongpeng@chinamobile.com

Li, et al.               Expires 5 January 2027                 [Page 5]
Internet-Draft                STAMP BFD TLV                    July 2026

   Junjie Wang
   Centec
   Shanghai
   201203
   China
   Email: wangjj@centec.com

   Wei Cheng
   Centec
   Shanghai
   201203
   China
   Email: chengw@centec.com

   Guoying Zhang
   Centec
   Shanghai
   201203
   China
   Email: zhanggy@centec.com

   Xun Sun
   Inesa
   Shanghai
   200030
   China
   Email: sunxun@inesa.com

   Chunhao Zhao
   SAIA
   Shanghai
   200125
   China
   Email: chunhao.zhao@sh-aia.com

Li, et al.               Expires 5 January 2027                 [Page 6]