Internet-Draft STAMP Extensions for DetNet December 2024
Min, et al. Expires 19 June 2025 [Page]
Workgroup:
IPPM Working Group
Internet-Draft:
draft-xp-ippm-detnet-stamp-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
X. Min
ZTE Corp.
S. Peng
ZTE Corp.
X. He
China Telecom

STAMP Extensions for DetNet

Abstract

Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router.

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 19 June 2025.

Table of Contents

1. Introduction

Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. DetNet is for networks that are under a single administrative control or within a closed group of administrative control. [RFC8578] presents the DetNet use cases and [RFC8655] provides the overall architecture for DetNet.

[I-D.peng-detnet-packet-timeslot-mechanism] specifies a queue scheduling mechanism that can be used for DetNet. To make the Timeslot based Queueing and Forwarding (TQF) mechanism work, it's required for every hop router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. The basic timeslot mapping relationship is not related to any individual flow, but to a network topological properties (such as the beginning time of the period configured by each node, link propagation delay, etc).

The Simple Two-Way Active Measurement Protocol (STAMP) provides a capability for the measurement of various performance metrics in IP networks. [RFC8762] defines the STAMP base functionalities and [RFC8972] specifies the use of optional STAMP extensions that use Type-Length-Value (TLV) encoding.

STAMP test packets are transmitted along an IP path between a Session-Sender and a Session-Reflector. The IP path can be either a single-hop path or a multi-hop path, depending on the application scenario of STAMP.

This document defines two STAMP TLVs, to acquire the timeslot mapping relationship between the local router and its adjacent router, i.e., the mapping direction is from the local router to its adjacent router.

2. Conventions

2.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.2. Abbreviations

DetNet: Deterministic Networking

OP: Orchestration Period

OPL: Orchestration Period Length

STAMP: Simple Two-Way Active Measurement Protocol

TLV: Type-Length-Value

TQF: Timeslot based Queueing and Forwarding

3. TLVs for DetNet

3.1. Timeslot Mapping TLV

The Timeslot Mapping TLV enables collection of the mapping relationship of timeslots between the Session-Sender and the Session-Reflector. The timeslot mapping is based on a specific orchestration period at both the Session-Sender and the Session-Reflector, and the timeslot mapping may be different among different orchestration periods.

 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|   Type=TBD1   |         Length=20             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Orchestration Period Length (OPL)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Session-Sender Slot Length  |     Session-Sender Slot X     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Session-Sender Trans-Deviation E               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Slot Length |   Session-Reflector Slot Y    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reflector's Slot Remaining Time|  Return Code  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Timeslot Mapping TLV

The fields are defined as follows:

The STAMP Session-Sender that includes the Timeslot Mapping TLV sets the value of the OPL field based on which the timeslot mapping is queried. Also, the Session-Sender sets the values of the Session-Sender Slot Length field, the Session-Sender Slot X field and the Session-Sender Trans-Deviation E field within the designated orchestration period.

The STAMP Session-Reflector that received the test packet with the Timeslot Mapping TLV MUST include the Timeslot Mapping TLV in the reflected test packet. The Session-Reflector MUST set the values of the OPL, Session-Sender Slot Length, Session-Sender Slot X, and Session-Sender Trans-Deviation E fields equal to the values of the corresponding fields from the test packet it has received. Also, the Session-Reflector MUST set the values of the Session-Reflector Slot Length field, the Session-Reflector Slot Y field, and the Reflector's Slot Remaining Time field within the designated orchestration period. The Session-Reflector Slot Y is determined by the expected time receiving the STAMP packet, which equals to the real time receiving the STAMP packet plus Session-Sender Slot Length and minus time difference E. Besides, the Session-Reflector MUST set the value of the Return Code field to reflect the operational result.

By the received Timeslot Mapping TLV in the reflected test packet, the Session-Sender can acquire the mapping relationship between the timeslot number (X) at the Session-Sender and the timeslot number (Y) at the Session-Reflector, as well as Y's remaining time. In addition, the Session-Sender can figure out the mapping relationship between any other timeslot number (I) at the Session-Sender and the timeslot number (J) at the Session-Reflector, by some calculations on the TLV fields' values. The mathematical formula to derive the timeslot mapping relationship between the Session-Sender's timeslot (I) and the Session-Reflector's timeslot (J) is outside the scope of this document and may refer to [I-D.peng-detnet-packet-timeslot-mechanism].

3.2. Orchestration Period Mapping TLV

The Orchestration Period Mapping TLV is an alternative to the Timeslot Mapping TLV, it also enables collection of the mapping relationship of timeslots between the Session-Sender and the Session-Reflector. The difference between the two TLVs is that the Timeslot Mapping TLV is used when the timeslot number (X) is provisioned at the Session-Sender, and the Orchestration Period Mapping TLV is used when the timeslot number (X) is not provisioned at the Session-Sender.

 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|   Type=TBD2   |         Length=16             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Orchestration Period Length (OPL)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Session-Sender Trans-Deviation E               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Session-Sender Slot Length  | Session-Reflector Slot Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflector's OP Remaining Time |  Return Code  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Orchestration Period Mapping TLV

The fields are defined as follows:

The STAMP Session-Sender that includes the Orchestration Period Mapping TLV sets the value of the OPL field based on which the timeslot mapping is queried. Also, the Session-Sender sets the values of the Session-Sender Slot Length field and the Session-Sender Trans-Deviation E field within the designated orchestration period.

The STAMP Session-Reflector that received the test packet with the Orchestration Period Mapping TLV MUST include the Orchestration Period Mapping TLV in the reflected test packet. The Session-Reflector MUST set the values of the OPL, Session-Sender Slot Length, and Session-Sender Trans-Deviation E fields equal to the values of the corresponding fields from the test packet it has received. Also, the Session-Reflector MUST set the values of the Session-Reflector Slot Length field and the Reflector's OP Remaining Time field within the designated orchestration period. Besides, the Session-Reflector MUST set the value of the Return Code field to reflect the operational result.

By the received Orchestration Period Mapping TLV in the reflected test packet, the Session-Sender can figure out the mapping relationship between any timeslot number (I) at the Session-Sender and the timeslot number (J) at the Session-Reflector, by some calculations on the TLV fields' values. The mathematical formula to derive the timeslot mapping relationship between the Session-Sender's timeslot (I) and the Session-Reflector's timeslot (J) is outside the scope of this document and may refer to [I-D.peng-detnet-packet-timeslot-mechanism].

4. Security Considerations

Security issues discussed in [RFC8762], [RFC8972], and [RFC9503] apply to this document.

Basic validation checks can be performed to mitigate the potential attacks, for example, the Orchestration Period Length field of the Timeslot Mapping TLV and the Orchestration Period Mapping TLV is larger than the Session-Sender Slot Length field of the two TLVs in the received STAMP packets at the Session-Reflector.

The usage of STAMP extensions defined in this document is intended for deployment between two neighbouring nodes in a single network administrative domain. As such, the Session-Sender and Session-Reflector can be configured to check the source address while the received STAMP packet carries the extensions defined in this document, and if it's determined the source address doesn't belong to its adjacent nodes, the received STAMP packet MUST be dropped with a notification sent to the network management system.

5. IANA Considerations

From the "STAMP TLV Types" registry in the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" namespace, two new values for the Timeslot Mapping TLV and the Orchestration Period Mapping TLV are requested from IANA as follows:

   +=======+=======================================+===========+
   | Value | Description                           | Reference |
   +=======+=======================================+===========+
   | TBD1  | Timeslot Mapping                      |This draft |
   +-------+---------------------------------------+-----------+
   | TBD2  | Orchestration Period Mapping          |This draft |
   +-------+---------------------------------------+-----------+

6. Acknowledgements

TBD.

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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8972>.

7.2. Informative References

[I-D.peng-detnet-packet-timeslot-mechanism]
Peng, S., Liu, P., Basu, K., Liu, A., Yang, D., and G. Peng, "Timeslot Queueing and Forwarding Mechanism", Work in Progress, Internet-Draft, draft-peng-detnet-packet-timeslot-mechanism-10, , <https://datatracker.ietf.org/doc/html/draft-peng-detnet-packet-timeslot-mechanism-10>.
[RFC8578]
Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, , <https://www.rfc-editor.org/info/rfc8578>.
[RFC8655]
Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, , <https://www.rfc-editor.org/info/rfc8655>.
[RFC9503]
Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks", RFC 9503, DOI 10.17487/RFC9503, , <https://www.rfc-editor.org/info/rfc9503>.

Authors' Addresses

Xiao Min
ZTE Corp.
Nanjing
China
Shaofu Peng
ZTE Corp.
Nanjing
China
Xiaoming He
China Telecom
Guangzhou
China