]> China Mobile

Beijing100053 China lizhiqiangyjy@chinamobile.com

China Mobile

Beijing100053 China duzongpeng@chinamobile.com

Centec

Shanghai201203 China wangjj@centec.com

Centec

Shanghai201203 China chengw@centec.com

Centec

Shanghai201203 China zhanggy@centec.com

Inesa

Shanghai200030 China sunxun@inesa.com

SAIA

Shanghai200125 China chunhao.zhao@sh-aia.com

TSV IPPM STAMP BFD TLV performance measurement fault detection 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.

Introduction Bidirectional Forwarding Detection (BFD) provides rapid detection of path failures. The Simple Two-Way Active Measurement Protocol (STAMP) provides delay and loss measurement, with an extension format defined in 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 . 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.

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 when, and only when, they appear in all capitals, as shown here.

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

• Type: TBD1, to be assigned by IANA from the STAMP TLV Type registry created by .
• 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 , including any BFD Authentication Section the BFD session is configured to use.

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

Procedures

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

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 , and (b) deliver the carried BFD Control message to the local BFD state machine, which processes it per . 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 ; 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.

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.

Security Considerations The security considerations of , , and 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 Considerations IANA is requested to assign one new TLV Type (TBD1, "BFD") from the "STAMP TLV Types" registry defined by , with this document as the reference.

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