Network Working Group G. Mirsky
Internet-Draft Ericsson
Updates: 8972 (if approved) 31 March 2025
Intended status: Standards Track
Expires: 2 October 2025
Update of the Simple Two-way Active Measurement Protocol (STAMP) Class-
of-Service Optional Extension
draft-mirsky-ippm-stamp-cos-ext-00
Abstract
This document describes an optional extension to the Class of Service
monitoring functionality of Simple Two-way Active Measurement
Protocol that enables the upstream monitoring of the Explicit
Congestion Notification and thus updates RFC 8972.
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 2 October 2025.
Copyright Notice
Copyright (c) 2025 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.
Mirsky Expires 2 October 2025 [Page 1]
Internet-Draft Update of the STAMP CoS Extension March 2025
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 3
3.1. Class of Service TLV . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
[RFC8972] defined several extensions to Simple Two-way Active
Measurement Protocol (STAMP). Among those is Class of Service TLV
that enables monitoring of the Differential Services Code Point
(DSCP) marking in downstream and upstream directions. Also, Class of
Service TLV supports downstream monitoring of the Explicit Congestion
Notification (ECN). Experience deploying STAMP and its extensions
demonstrated that it is helpful to an operator to monitor ECN's
consistency in the upstream direction. This specification defines
the extension of the Class of Service TLV in a backward compatible
manner to support monitoring of ECN in the upstream direction of the
STAMP test session.
2. Conventions Used in This Document
2.1. Acronyms
CoS Class of Service
DSCP Differentiated Services Code Point
ECN Explicit Congestion Notification
STAMP Simple Two-way Active Measurement Protocol
Mirsky Expires 2 October 2025 [Page 2]
Internet-Draft Update of the STAMP CoS Extension March 2025
2.2. 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.
3. TLV Extensions to STAMP
3.1. Class of Service TLV
The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in
the STAMP test packet. The format of the CoS TLV is presented in
Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| CoS Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP1 | DSCP2 |ECN| RP|REC| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Class of Service TLV
where fields are defined as the following:
* STAMP TLV Flags - is an eight-bit-long field. Its format is
presented in Section 4 of [RFC8972].
* CoS (Class of Service) Type - is a one-octet-long field, the value
MUST be set to 4.
* Length - two-octet-long field, set equal to the value 4.
* DSCP1 - The Differentiated Services Code Point (DSCP) intended by
the Session-Sender to be used as the DSCP value of the reflected
test packet.
* DSCP2 - The received value in the DSCP field at the ingress of the
Session-Reflector.
* ECN - is a two-bit-long field. The received value in the ECN
field at the ingress of the Session-Reflector.
Mirsky Expires 2 October 2025 [Page 3]
Internet-Draft Update of the STAMP CoS Extension March 2025
* RP (Reverse Path) - is a two-bit-long field. A Session-Sender
MUST set the value of the RP field to 0 on transmission.
* REC - is a two-bit-long field. The value intended by the Session-
Sender to be used as the ECN value of the reflected test packet.
* Reserved - 14-bit-long field. It MUST be zeroed on transmission
and ignored on receipt.
Processing and handling of DSCP1, DSCP2, and ECN fields as defiend in
Section 4.4 of [RFC8972]. A system that supports this specification
MUST set the ECN value in the data plane encapsulation of the
reflected STAMP test packet to the value of the REC field.
Furthermore, such a system MUST add 0b10 to the value of the RP field
in the Class of Service TLV in the reflected test packet. As a
result, the Session-Sender can detect whether the recommended values
for DSCP and ECN fields in the reflected packets were used by
inspecting the value of the RP field in the received reflected test
packet.
The extended Class of Service TLV defined in this dradft s backward
compatible with the specification in Section 4.4 of [RFC8972].
Consider a case when implementation that supports this specification
performs as Session-Sender, nd the intended Session-Reflector support
of the Class of Service TLV is according to Session 4.4 of [RFC8972].
If the operator requires monitoring ECN in the upstream direction,
the value of the REC field will be set to a non-zero value. Because
the Session-Reflector would treat the REC field as part of the
Reserved field and ignore its value, the Session-Reflector would not
add 0b10 to the value of the RP field in the reflected STAMP packet.
Consequently, the Session-Sender will determine that the ECN value in
the IP/UDP encapsulation of the reflected test packet was not set to
the requested value.
4. IANA Considerations
This document makes no requests to IANA.
5. Security Considerations
This document extends the functionality of the Class of Service TLV
([RFC8972]) and inherits all the security considerations applicable
to the base STAMP specification [RFC8762] and [RFC8972].
Mirsky Expires 2 October 2025 [Page 4]
Internet-Draft Update of the STAMP CoS Extension March 2025
As this specification defined the mechanism to test ECN mapping, this
document inherits all the security considerations discussed in
[RFC2474]. Monitoring and optional control of ECN for a reflected
STAMP test packet using the extended CoS TLV may be used across the
Internet so that the Session-Sender and the Session-Reflector are
located in different domains.
6. Acknowledgments
TBA
7. References
7.1. 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>.
[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.2. Informative References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
Author's Address
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Mirsky Expires 2 October 2025 [Page 5]