Individual Submission J. Yang Internet-Draft W. Cheng Intended status: Standards Track T. Han Expires: 3 May 2027 China Mobile J. Wang L. Wang Centec 30 October 2026 IPFIX Export of RoCEv2 Sequence Observations draft-yang-opsawg-ipfix-rocev2-sequence-00 Abstract This document specifies an IP Flow Information Export (IPFIX) metering and export profile for bounded Packet Sequence Number (PSN) observations on provisioned RoCEv2 Reliable Connection SEND and RDMA WRITE request streams. It defines cumulative observations of skipped, subsequently observed, expired, repeated, and unclassified sequence positions, with explicit observation epochs and qualification flags. The profile requires complete observation of the provisioned stream and defines no packet-loss estimator, retransmission detector, or congestion-control action. Twelve Information Elements describe the observation state. Existing RoCEv2 header Information Elements identify the monitored stream. 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 3 May 2027. Yang, et al. Expires 3 May 2027 [Page 1] Internet-Draft RoCEv2 Sequence Observations October 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Applicability and Provisioning . . . . . . . . . . . . . . . 3 4. Identity and Epoch Lifecycle . . . . . . . . . . . . . . . . 4 5. Bounded Sequence Observation Algorithm . . . . . . . . . . . 5 6. Export Profile and Template . . . . . . . . . . . . . . . . . 7 7. Collector Processing . . . . . . . . . . . . . . . . . . . . 9 8. Information Element Definitions . . . . . . . . . . . . . . . 10 8.1. rdmaSequenceEpochId . . . . . . . . . . . . . . . . . . . 10 8.2. rdmaSequenceReportId . . . . . . . . . . . . . . . . . . 11 8.3. rdmaSequenceWindow . . . . . . . . . . . . . . . . . . . 12 8.4. rdmaSequenceFlags . . . . . . . . . . . . . . . . . . . . 12 8.5. skippedPsnTotalCount . . . . . . . . . . . . . . . . . . 13 8.6. filledPsnTotalCount . . . . . . . . . . . . . . . . . . . 14 8.7. expiredPsnTotalCount . . . . . . . . . . . . . . . . . . 14 8.8. abandonedPsnTotalCount . . . . . . . . . . . . . . . . . 15 8.9. pendingPsnCount . . . . . . . . . . . . . . . . . . . . . 16 8.10. repeatedPsnTotalCount . . . . . . . . . . . . . . . . . . 16 8.11. requestPacketTotalCount . . . . . . . . . . . . . . . . . 17 8.12. unclassifiedLatePacketTotalCount . . . . . . . . . . . . 18 8.13. Qualification Flags . . . . . . . . . . . . . . . . . . . 18 9. Verification Examples . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 13. Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Yang, et al. Expires 3 May 2027 [Page 2] Internet-Draft RoCEv2 Sequence Observations October 2026 1. Introduction Two metering implementations can see the same PSNs yet report different gap counts if they use different history, initialization, or closure rules. A common export profile is useful when a collector consumes such observations from multiple implementations and must distinguish unresolved history from observed packets. The interoperability target is the interpretation of exported measurements, not an implementation-specific packet-processing architecture. [I-D.lin-opsawg-ipfix-rocev2] defines raw RoCEv2 BTH Information Elements. Those fields remain useful for packet traces and validation. This document reuses its destination QP and partition identifiers and adds an explicitly specified summary. A raw-field export need not export every packet; however, a sampled packet trace cannot reconstruct the exact state of this profile. No throughput or export-volume improvement is claimed without measurement. A shared collector may correlate queue and sequence observations, but such correlation alone does not establish which link lost a packet or whether an ECN policy is effective. A sequence position may be observed after reordering, a retry, duplication, or a capture fault. These causes cannot in general be distinguished by the counters defined here. 2. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 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. Applicability and Provisioning The profile covers only a provisioned, unidirectional RoCEv2 Reliable Connection request stream using BTH OpCodes 0x00 through 0x0B: SEND and RDMA WRITE, including the immediate-data variants in that range. Originally transmitted requests advance by one PSN modulo 2^24. Other RC operations, UC, UD, XRC, and inferred READ spans are outside this profile. Provisioning MUST establish the operation restriction for the whole connection, rather than merely filter the listed opcodes. RDMA READ can reserve sequence space for response packets; [LINUX-RXE] provides a public implementation example. Filtering READ from a mixed stream does not make its remaining request PSNs consecutive. An observed unsupported request or malformed request Yang, et al. Expires 3 May 2027 [Page 3] Internet-Draft RoCEv2 Sequence Observations October 2026 attributable to the provisioned connection MUST close the epoch with profileViolation and disable metering for that connection until explicitly reprovisioned. The offending packet is not counted. A subsequent SEND or WRITE MUST NOT automatically re-enable the profile. Response packets and CNPs do not change this request state. The observation point MUST process all request packets in the provisioned scope, without sampling, selective omission, or known capture loss, and MUST cover all paths carrying that stream. A single ECMP branch without complete coverage is not sufficient. Deployment provisioning MUST establish namespace separation and path coverage. If capture completeness cannot be established, this profile MUST NOT be enabled. A capture gap closes affected epochs with captureDiscontinuity; metering resumes only after complete observation has been re-established and starts fresh state. An unclassifiable capture fault affecting several contexts closes all contexts that may be affected. Serial interpretation also requires that a packet cannot legitimately be separated from the current high-water position by half or more of the PSN serial space, including very old retries. This is an applicability condition, not something a 24-bit field alone can verify. If endpoint behavior or retention bounds cannot establish it, this profile MUST NOT be used for that connection. Known violations close the epoch. An exactly half-space distance is always treated as ambiguous. 4. Identity and Epoch Lifecycle The record key comprises the IPFIX Transport Session, Observation Domain ID, observationPointId, source and destination IP addresses of the RoCEv2 packet, rdmaDestinationQP, rdmaPartitionKey, any additional tenant or tunnel namespace required to avoid collisions, and rdmaSequenceEpochId. A physical interface identifier alone is not a tenant namespace. Address family and encapsulation layer MUST be fixed and unambiguous in each Template. UDP source port MUST NOT split a connection context. Yang, et al. Expires 3 May 2027 [Page 4] Internet-Draft RoCEv2 Sequence Observations October 2026 The Exporting Process MUST allocate a nonzero, monotonically increasing epoch ID across all contexts in each Transport Session and Observation Domain when the first report of that epoch is serialized. Thus first reports are serialized in increasing epoch-ID order; the ID does not order the first packet times. An ID MUST NOT be reused in that scope. IDs need not be consecutive at a collector. A new Transport Session starts fresh metering state. An epoch is closed on a known connection-generation change, idle expiration, policy or window change, capture discontinuity, profile violation, resource eviction, serial discontinuity, or impending counter/report-ID exhaustion. Unless connection generation is independently established by trusted provisioning or endpoint integration, every report MUST set generationUnverified. A local epoch is not proof of a connection lifetime. Neither an idle timer nor an apparently new initial PSN proves that destination QP reuse was detected. Known connection restarts MUST NOT be joined even if addresses, QP, and PSN repeat. A serial discontinuity caused by a valid eligible request closes the old epoch before counting that request, then starts a new epoch with that request. The request is counted exactly once. Other closure causes require the applicable validity conditions to be re- established before restart. A final snapshot abandons all pending positions. If it cannot be exported because of failure or resource exhaustion, the collector sees an incomplete epoch; a final record is never fabricated by the collector. 5. Bounded Sequence Observation Algorithm Let M=2^24 and 1<=W<=2^22. The exporter maintains a local extended integer H, a fixed initial extended position S, and a retained interval [L,H], where L=max(S,H-W+1). Retained positions are either SEEN or PENDING. Positions before S or before L are unclassified, including positions numerically within W of H but preceding the first observed request. No initialized prefix is presumed seen or pending. Local extended integers are not exported PSN values. For an arriving PSN p, compute u=(p-(H mod M)) mod M. If u=M/2, comparison is ambiguous. Otherwise d=u for uM/2. This uses the serial comparison boundary in [RFC1982]. Implementations MUST use checked arithmetic for counters and local extended positions; they MUST close and restart before overflow rather than wrap a cumulative counter. Yang, et al. Expires 3 May 2027 [Page 5] Internet-Draft RoCEv2 Sequence Observations October 2026 +===========+=====================================================+ | Condition | Required action | +===========+=====================================================+ | No active | Set S=H=p; retain only p as SEEN; requests=1; all | | epoch | other counters=0. | +-----------+-----------------------------------------------------+ | u=M/2 or | Close with serialDiscontinuity; start fresh state | | d>W | with p; do not account p to the old epoch. | +-----------+-----------------------------------------------------+ | 1<=d<=W | Count request; add H+1 through H+d-1 as PENDING and | | | add d-1 to skipped; advance H by d; mark H SEEN; | | | expire each pending position below new L once. | +-----------+-----------------------------------------------------+ | d<=0 and | Count request; change that position to SEEN; | | H+d in | increment filled once. | | [L,H] is | | | PENDING | | +-----------+-----------------------------------------------------+ | d<=0 and | Count request; increment repeated. | | H+d in | | | [L,H] is | | | SEEN | | +-----------+-----------------------------------------------------+ | d<=0 and | Count request; increment unclassifiedLate; do not | | H+d. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 13. Informative References [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", . Yang, et al. Expires 3 May 2027 [Page 21] Internet-Draft RoCEv2 Sequence Observations October 2026 [LINUX-RXE] Linux Kernel Organization, "Linux Kernel Soft-RoCE (RXE) Requester PSN Allocation Implementation", . [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, September 2013, . [RFC8126] RFC Editor, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, June 2017, . [RFC9325] RFC Editor, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 9325, November 2022, . Authors' Addresses Jin Yang China Mobile Beijing 100053 China Email: yangjinwl@chinamobile.com Weiqiang Cheng China Mobile Beijing 100053 China Email: chengweiqiang@chinamobile.com Tingting Han China Mobile Beijing 100053 China Email: hantingting@chinamobile.com Yang, et al. Expires 3 May 2027 [Page 22] Internet-Draft RoCEv2 Sequence Observations October 2026 Junjie Wang Centec Suzhou 215000 China Email: wangjj@centec.com Li Wang Centec Suzhou 215000 China Email: wangl@centec.com Yang, et al. Expires 3 May 2027 [Page 23]