draft-ietf-ippm-stamp-option-tlv-07.txt   draft-ietf-ippm-stamp-option-tlv-08.txt 
Network Working Group G. Mirsky Network Working Group G. Mirsky
Internet-Draft X. Min Internet-Draft X. Min
Updates: 8762 (if approved) ZTE Corp. Updates: 8762 (if approved) ZTE Corp.
Intended status: Standards Track H. Nydell Intended status: Standards Track H. Nydell
Expires: January 9, 2021 Accedian Networks Expires: February 5, 2021 Accedian Networks
R. Foote R. Foote
Nokia Nokia
A. Masputra A. Masputra
Apple Inc. Apple Inc.
E. Ruffini E. Ruffini
OutSys OutSys
July 8, 2020 August 4, 2020
Simple Two-way Active Measurement Protocol Optional Extensions Simple Two-way Active Measurement Protocol Optional Extensions
draft-ietf-ippm-stamp-option-tlv-07 draft-ietf-ippm-stamp-option-tlv-08
Abstract Abstract
This document describes optional extensions to Simple Two-way Active This document describes optional extensions to Simple Two-way Active
Measurement Protocol (STAMP) that enable measurement of performance Measurement Protocol (STAMP) that enable measurement of performance
metrics, in addition to ones supported by the STAMP base metrics. The document also defines a STAMP Test Session Identifier
specification. The document also defines a STAMP Test Session and thus updates RFC 8762.
Identifier and thus updates RFC 8762.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2021. This Internet-Draft will expire on February 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. STAMP Test Session Identifier . . . . . . . . . . . . . . . . 4 3. STAMP Test Session Identifier . . . . . . . . . . . . . . . . 4
4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 8 4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 8
4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 11 4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 11
4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 13 4.2.1. Location Sub-TLVs . . . . . . . . . . . . . . . . . . 13
4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 14 4.2.2. Theory of Operation of Location TLV . . . . . . . . . 14
4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 15 4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 16
4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 17 4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 17
4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 18 4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 18
4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 21
5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 21 4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. STAMP TLV Flags Sub-registry . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
5.3. Synchronization Source Sub-registry . . . . . . . . . . . 22 5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 24
5.4. Timestamping Method Sub-registry . . . . . . . . . . . . 23 5.2. STAMP TLV Flags Sub-registry . . . . . . . . . . . . . . 25
5.5. Return Code Sub-registry . . . . . . . . . . . . . . . . 24 5.3. Sub-TLV Type Sub-registry . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5.4. Synchronization Source Sub-registry . . . . . . . . . . . 26
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 5.5. Timestamping Method Sub-registry . . . . . . . . . . . . 27
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 5.6. Return Code Sub-registry . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 26 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 26 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] supports Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defined
the use of optional extensions that use Type-Length-Value (TLV) the STAMP base functionalities. This document specifies the use of
encoding. Such extensions enhance the STAMP base functions, such as optional extensions that use Type-Length-Value (TLV) encoding. Such
measurement of one-way and round-trip delay, latency, packet loss, extensions enhance the STAMP base functions, such as measurement of
packet duplication, and out-of-order delivery of test packets. This one-way and round-trip delay, latency, packet loss, packet
duplication, and out-of-order delivery of test packets. This
specification defines optional STAMP extensions, their formats, and specification defines optional STAMP extensions, their formats, and
the theory of operation. Also, a STAMP Test Session Identifier is the theory of operation. Also, a STAMP Test Session Identifier is
defined as an update of the base STAMP specification [RFC8762]. defined as an update of the base STAMP specification [RFC8762].
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Acronyms 2.1. Acronyms
BDS BeiDou Navigation Satellite System BDS BeiDou Navigation Satellite System
skipping to change at page 4, line 25 skipping to change at page 4, line 27
packets are compatible on the wire with unauthenticated TWAMP-Test packets are compatible on the wire with unauthenticated TWAMP-Test
[RFC5357] packets. [RFC5357] packets.
By default, STAMP uses symmetrical packets, i.e., the size of the By default, STAMP uses symmetrical packets, i.e., the size of the
packet transmitted by the Session-Reflector equals the size of the packet transmitted by the Session-Reflector equals the size of the
packet received by the Session-Reflector. packet received by the Session-Reflector.
A STAMP Session is identified by the 4-tuple (source and destination A STAMP Session is identified by the 4-tuple (source and destination
IP addresses, source and destination UDP port numbers). A STAMP IP addresses, source and destination UDP port numbers). A STAMP
Session-Sender MAY generate a locally unique STAMP Session Identifier Session-Sender MAY generate a locally unique STAMP Session Identifier
(SSID). SSID is a two-octet-long non-zero unsigned integer. A (SSID). The SSID is a two-octet-long non-zero unsigned integer.
Session-Sender MAY use SSID to identify a STAMP test session. If SSID generation policy is implementation-specific.
SSID is used, it MUST be present in each test packet of the given [I-D.gont-numeric-ids-generation] thoroughly analyzes common
test session. In the unauthenticated mode, SSID is located as algorithms for identifier generation and their vulnerabilities. For
displayed in Figure 1. example, an implementation can use algorithms described in
Section 7.1 of [I-D.gont-numeric-ids-generation]. An implementation
MUST NOT assign the same identifier to different STAMP test sessions.
A Session-Sender MAY use the SSID to identify a STAMP test session.
If the SSID is used, it MUST be present in each test packet of the
given test session. In the unauthenticated mode, the SSID is located
as displayed in Figure 1.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SSID | | Error Estimate | SSID |
skipping to change at page 5, line 26 skipping to change at page 5, line 26
| | | |
| MBZ (28 octets) | | MBZ (28 octets) |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: An example of an extended STAMP Session-Sender test packet Figure 1: The format of an extended STAMP Session-Sender test packet
format in unauthenticated mode in unauthenticated mode
An implementation of the STAMP Session-Reflector that supports this An implementation of the STAMP Session-Reflector that supports this
specification SHOULD identify a STAMP Session using the SSID in specification MUST identify a STAMP Session using the SSID in
combination with elements of the usual 4-tuple for the session. combination with elements of the usual 4-tuple for the session.
Before a test session commences, a Session-Reflector MUST be Before a test session commences, a Session-Reflector MUST be
provisioned with all the elements that identify the STAMP Session. A provisioned with all the elements that identify the STAMP Session. A
STAMP Session-Reflector MUST discard non-matching STAMP test STAMP Session-Reflector MUST discard non-matching STAMP test
packet(s). The means of provisioning the STAMP Session packet(s). The means of provisioning the STAMP Session
identification is outside the scope of this specification. A identification is outside the scope of this specification. A
conforming implementation of STAMP Session-Reflector MUST copy the conforming implementation of STAMP Session-Reflector MUST copy the
SSID value from the received test packet and put it into the SSID value from the received test packet and put it into the
reflected packet, as displayed in Figure 2. reflected packet, as displayed in Figure 2.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
| Session-Sender Timestamp | | Session-Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | MBZ | | Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | MBZ | |Ses-Sender TTL | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: An example of an extended STAMP Session-Reflector test Figure 2: The format of an extended STAMP Session-Reflector test
packet format in unauthenticated mode packet in unauthenticated mode
A STAMP Session-Reflector that does not support this specification A STAMP Session-Reflector that does not support this specification
will return the zeroed SSID field in the reflected STAMP test packet. will return the zeroed SSID field in the reflected STAMP test packet.
The Session-Sender MAY stop the session if it receives a zeroed SSID The Session-Sender MAY stop the session if it receives a zeroed SSID
field. An implementation of a Session-Sender MUST support control of field. An implementation of a Session-Sender MUST support control of
its behavior in such a scenario. If the test session is not stopped, its behavior in such a scenario. If the test session is not stopped,
the Session-Sender, can, for example, send a base STAMP packet the Session-Sender, can, for example, send a base STAMP packet
[RFC8762]. [RFC8762] or continue transmitting STAMP test packets with the SSID.
Location of the SSID field in the authenticated mode is shown in Location of the SSID field in the authenticated mode is shown in
Figure 3 and Figure 4. Figure 3 and Figure 4.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 7, line 28 skipping to change at page 7, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| MBZ (68 octets) | | MBZ (68 octets) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Base STAMP Session-Sender test packet format in Figure 3: Base STAMP Session-Sender test packet format in
authenticated mode authenticated mode
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
skipping to change at page 8, line 29 skipping to change at page 8, line 31
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
| | | |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Base STAMP Session-Reflector test packet format in Figure 4: Base STAMP Session-Reflector test packet format in
authenticated mode authenticated mode
4. TLV Extensions to STAMP 4. TLV Extensions to STAMP
The Type-Length-Value (TLV) encoding scheme provides a flexible The Type-Length-Value (TLV) encoding scheme provides a flexible
extension mechanism for optional informational elements. TLV is an extension mechanism for optional informational elements. TLV is an
optional field in the STAMP test packet. Multiple TLVs MAY be placed optional field in the STAMP test packet. Multiple TLVs MAY be placed
in a STAMP test packet. A TLV MAY be enclosed in a TLV. TLVs have a in a STAMP test packet. Additional TLVs may be enclosed within a
one-octet-long STAMP TLV Flags field, one-octet-long Type field, and given TLV, subject to the semantics of the (outer) TLV in question.
two-octet-long Length field that is equal to the length of the Value TLVs have a one-octet-long STAMP TLV Flags field, a one-octet-long
field in octets. If a Type value for TLV or sub-TLV is in the range Type field, and a two-octet-long Length field that is equal to the
for Vendor Private Use, the Length MUST be at least 4, and the first length of the Value field in octets. If a Type value for TLV or sub-
four octets MUST be that vendor's the Structure of Management TLV is in the range for Vendor Private Use, the Length MUST be at
Information (SMI) Private Enterprise Code, as recorded in IANA's SMI least 4, and the first four octets MUST be that vendor's Structure of
Private Enterprise Codes sub-registry, in network octet order. The Management Information (SMI) Private Enterprise Code, as recorded in
rest of the Value field is private to the vendor. The following IANA's SMI Private Enterprise Codes sub-registry, in network octet
sections describe the use of TLVs for STAMP that extend STAMP order. The rest of the Value field is private to the vendor. The
capability beyond its base specification. following sections describe the use of TLVs for STAMP that extend the
STAMP capability beyond its base specification.
0 1 2 3 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 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 | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TLV Format in a STAMP Extended Packet Figure 5: TLV Format in a STAMP Extended Packet
skipping to change at page 9, line 30 skipping to change at page 9, line 33
o Type - one-octet-long field that characterizes the interpretation o Type - one-octet-long field that characterizes the interpretation
of the Value field. It is allocated by IANA, as specified in of the Value field. It is allocated by IANA, as specified in
Section 5.1. Section 5.1.
o Length - two-octet-long field equal to the length of the Value o Length - two-octet-long field equal to the length of the Value
field in octets. field in octets.
o Value - a variable-length field. Its interpretation and encoding o Value - a variable-length field. Its interpretation and encoding
is determined by the value of the Type field. is determined by the value of the Type field.
All multibyte fields in the defined in this specification TLVs are in
network byte order.
The format of the STAMP TLV Flags displayed in Figure 6 and the The format of the STAMP TLV Flags displayed in Figure 6 and the
location of flags is according to Section 5.2. location of flags is according to Section 5.2.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|U|L|A|R|R|R|R|R| |U|M|I|R|R|R|R|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: STAMP TLV Flags Format Figure 6: STAMP TLV Flags Format
where fields are defined as the following: where fields are defined as the following:
o U - a one-bit flag. A Session-Sender MUST set the U flag to 0 o U (Unrecognized) is a one-bit flag. A Session-Sender MUST set the
before transmitting an extended STAMP test packet. A Session- U flag to 1 before transmitting an extended STAMP test packet. A
Reflector MUST set the U flag to 1 if the Session-Reflector has Session-Reflector MUST set the U flag to 1 if the Session-
not understood the TLV. Reflector has not understood the TLV. Otherwise, the Session-
Reflector MUST set the U flag in the reflected packet to 0.
o L - a one-bit flag. A Session-Sender MUST set the L flag to 0 o M (Malformed) is a one-bit flag. A Session-Sender MUST set the M
before transmitting an extended STAMP test packet. A Session- flag to 0 before transmitting an extended STAMP test packet. A
Reflector MUST set the L flag to 1 if the Session-Reflector Session-Reflector MUST set the M flag to 1 if the Session-
determined the TLV is malformed, i.e., the Length field value of Reflector determined the TLV is malformed, i.e., the Length field
the fixed-size TLV is not equal to the value defined for the value is not valid for the particular type, or the remaining
particular type, or the remaining length of the extended STAMP length of the extended STAMP packet is less than the size of the
packet is less than the size of the TLV. TLV. Otherwise, the Session-Reflector MUST set the M flag in the
reflected packet to 0.
o A - a one-bit flag. A Session-Sender MUST set the A flag to 0 o I (Integrity) is a one-bit flag. A Session-Sender MUST set the I
before transmitting an extended STAMP test packet. A Session- flag to 0 before transmitting an extended STAMP test packet. A
Reflector MUST set the A flag to 1 if the STAMP extensions have Session-Reflector MUST set the I flag to 1 if the STAMP extensions
failed HMAC verification (Section 4.8). have failed HMAC verification (Section 4.8). Otherwise, the
Session-Reflector MUST set the I flag in the reflected packet to
0.
o R - reserved flags for future use. These flags MUST be zeroed on o R - reserved flags for future use. These flags MUST be zeroed on
transmit and ignored on receipt. transmit and ignored on receipt.
A STAMP node, whether Session-Sender or Session-Reflector, receiving A STAMP node, whether Session-Sender or Session-Reflector, receiving
a test packet MUST determine whether the packet is a base STAMP a test packet MUST determine whether the packet is a base STAMP
packet or includes one or more TLVs. The node MUST compare the value packet or includes one or more TLVs. The node MUST compare the value
in the Length field of the UDP header and the length of the base in the Length field of the UDP header and the length of the base
STAMP test packet in the mode, unauthenticated or authenticated based STAMP test packet in the mode, unauthenticated or authenticated based
on the configuration of the particular STAMP test session. If the on the configuration of the particular STAMP test session. If the
difference between the two values is larger than the length of the difference between the two values is larger than the length of the
UDP header, then the test packet includes one or more STAMP TLVs that UDP header, then the test packet includes one or more STAMP TLVs that
immediately follow the base STAMP test packet. A Session-Reflector immediately follow the base STAMP test packet. A Session-Reflector
that does not support STAMP extensions is not expected to compare the that does not support STAMP extensions will not process but copy them
value in the Length field of the UDP header and the length of the into the reflected packet, as defined in Section 4.3 [RFC8762]. A
STAMP base packet. Hence the Session-Reflector will transmit the Session-Reflector that supports TLVs will indicate specific TLVs that
base STAMP packet. It is the local policy on the Session-Sender it did not process by setting the U flag to 1 in those TLVs.
(similar to the handling of SSID == 0 scenario described in
Section 3) that will control the sender's behavior.
A system that has received a STAMP test packet with extension TLVs A STAMP system, i.e., either a Session-Sender or a Session-Reflector,
MUST validate each TLV: that has received a STAMP test packet with extension TLVs MUST
validate each TLV:
If the U flag is set, the STAMP system MUST skip the processing of If the U flag is set, the STAMP system MUST skip the processing of
the TLV. The implementation MUST try to process the next TLV if the TLV.
present in the extended STAMP packet.
If the L flag is set, the STAMP system MUST stop processing the If the M flag is set, the STAMP system MUST stop processing the
remainder of the extended STAMP packet. remainder of the extended STAMP packet.
If the A flag is set, the STAMP system MUST discard all TLVs and If the I flag is set, the STAMP system MUST discard all TLVs and
MUST stop processing the remainder of the extended STAMP packet. MUST stop processing the remainder of the extended STAMP packet.
If an implementation of a Session-Reflector does not recognize the If an implementation of a Session-Reflector does not recognize the
Type field value, it MUST include a copy of the TLV into the Type field value, it MUST include a copy of the TLV into the
reflected STAMP packet. The Session-Reflector MUST set the U flag reflected STAMP packet. The Session-Reflector MUST set the U flag
to 1. The Session-Reflector MUST try to process the next TLV in to 1. The Session-Reflector MUST skip the processing of the
the extended STAMP packet. unrecognized TLV.
If a TLV is malformed, the processing of extension TLVs MUST be If a TLV is malformed, the processing of extension TLVs MUST be
stopped. The Session-Reflector MUST copy the remainder of the stopped. The Session-Reflector MUST copy the remainder of the
received extended STAMP packet into the reflected STAMP packet. received extended STAMP packet into the reflected STAMP packet.
The Session-Reflector MUST set the L flag to 1. The Session-Reflector MUST set the M flag to 1.
Detected error events MUST be logged. Note that rate of logging MUST
be controlled.
4.1. Extra Padding TLV 4.1. Extra Padding TLV
0 1 2 3 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 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|Extra Pad Type | Length | |STAMP TLV Flags|Extra Pad Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extra Padding ~ ~ Extra Padding ~
skipping to change at page 11, line 35 skipping to change at page 11, line 41
o STAMP TLV Flags - is an eight-bit-long field. Its format is o STAMP TLV Flags - is an eight-bit-long field. Its format is
presented in Figure 6. presented in Figure 6.
o Extra Padding Type - is a one-octet-long field, value TBA1 o Extra Padding Type - is a one-octet-long field, value TBA1
allocated by IANA Section 5.1. allocated by IANA Section 5.1.
o Length - two-octet-long field equal to the length of the Extra o Length - two-octet-long field equal to the length of the Extra
Padding field in octets. Padding field in octets.
o Extra Padding - a pseudo-random sequence of bits. The field MAY o Extra Padding - SHOULD be filled by a sequence of a pseudo-random
be filled with all zeros. numbers. The field MAY be filled with all zeros. An
implementation MUST control the type of filling of the Extra
Padding field.
The Extra Padding TLV is similar to the Packet Padding field in a The Extra Padding TLV is similar to the Packet Padding field in a
TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is
RECOMMENDED to perform a STAMP test using test packets of larger size RECOMMENDED to perform a STAMP test using test packets of larger size
than the base STAMP packet [RFC8762]. The length of the base STAMP than the base STAMP packet [RFC8762]. The length of the base STAMP
packet is 44 octets in the unauthenticated mode or 112 octets in the packet is 44 octets in the unauthenticated mode or 112 octets in the
authenticated mode. The Extra Padding TLV MAY be present more than authenticated mode. The Extra Padding TLV MAY be present more than
one time in an extended STAMP test packet. one time in an extended STAMP test packet.
4.2. Location TLV 4.2. Location TLV
STAMP Session-Senders MAY include the Location TLV to request STAMP Session-Senders MAY include the variable-size Location TLV to
information from the Session-Reflector. The Session-Sender SHOULD query location information from the Session-Reflector. The Session-
NOT fill any information fields except for STAMP TLV Flags, Type, and Sender MUST NOT fill any information fields except for STAMP TLV
Length. The Session-Reflector MUST validate the Length value against Flags, Type, and Length. The Session-Reflector MUST verify that the
the address family of the transport encapsulating the STAMP test TLV is well-formed. If it is not, the Session-Reflector follows the
packet. If the Length field's value is invalid, the Session- procedure defined in Section 4 for a malformed TLV.
Reflector MUST zero all fields and MUST NOT return any information to
the Session-Sender. The Session-Reflector MUST ignore all other
fields of the received Location TLV.
0 1 2 3 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 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| Location Type | Length | |STAMP TLV Flags| Location Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port | Source Port | | Destination Port | Source Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Session-Reflector Location TLV Figure 8: Location TLV
where fields are defined as the following: where fields are defined as the following:
o STAMP TLV Flags - is an eight-bit-long field. Its format is o STAMP TLV Flags - is an eight-bit-long field. Its format is
presented in Figure 6. presented in Figure 6.
o Location Type - is a one-octet-long field, value TBA2 allocated by o Location Type - is a one-octet-long field, value TBA2 allocated by
IANA Section 5.1. IANA Section 5.1.
o Length - two-octet-long field equal to the length of the Value o Length - two-octet-long field equal to the length of the Value
field in octets. The Length field value MUST equal 20 octets for field in octets.
the IPv4 address family. For the IPv6 address family, the value
of the Length field MUST equal 44 octets. All other values are
invalid.
o Source MAC - 6-octet-long field. The Session-Reflector MUST copy
the Source MAC of the received STAMP packet into this field.
o Reserved - two-octet-long field. MUST be zeroed on transmission
and ignored on reception.
o Destination IP Address - IPv4 or IPv6 destination address of the
packet received by the STAMP Session-Reflector.
o Source IP Address - IPv4 or IPv6 source address of the packet
received by the STAMP Session-Reflector.
o Destination Port - two-octet-long UDP destination port number of o Destination Port - two-octet-long UDP destination port number of
the received STAMP packet. the received STAMP packet.
o Source Port - two-octet-long UDP source port number of the o Source Port - two-octet-long UDP source port number of the
received STAMP packet. received STAMP packet.
o Sub-TLVs - a sequence of sub-TLVs, as defined further in this
section. The sub-TLVs are used by the Session-Sender to request
location information with generic sub-TLV types, and the Session-
Reflector responds with the corresponding more-specific sub-TLVs
for the type of address (e.g., IPv4 or IPv6) used at the Session-
Reflector.
4.2.1. Location Sub-TLVs
A sub-TLV in the Location TLV uses the format displayed in Figure 5.
Handling of the U and M flags in the sub-TLV is as defined in
Section 4. The I flag MUST be set by a Session-Sender and Session-
Reflector to 0 before transmission and its value ignored on receipt.
The following types of sub-TLV for the Location TLV are defined in
this specification (type values are assigned according to Table 5):
o Source MAC Address sub-TLV - is a 12-octet-long sub-TLV. The Type
value is TBA9. The value of the Length field MUST equal to 8.
The Value field is a 12-octet-long MBZ field that MUST be zeroed
on transmission and ignored on receipt.
o Source EUI-48 Address sub-TLV - is a 12-octet-long sub-TLV that
includes the EUI-48 source MAC address. The Type value is TBA10.
The value of the Length field MUST equal to 8.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI-48 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Value Field of the Source EUI-48 Address sub-TLV
The Value field consists of the following fields (Figure 9):
* The EUI-48 is a six-octet-long field.
* Two-octet-ling MBZ field MUST be zeroed on transmission and
ignored on receipt.
o Source EUI-64 Address sub-TLV - is a 12-octet-long sub-TLV that
includes the EUI-64 source MAC address. The Type value is TBA11.
The value of the Length field MUST equal to 12. The Value field
consists of an eight-octet-long EUI-64 field.
o Destination IP Address sub-TLV - is a 20-octet-long sub-TLV. The
Type value is TBA12. The value of the Length field MUST equal to
16. The Value field consists of a 16-octet-long MBZ field that
MUST be zeroed on transmit and ignored on receipt
o Destination IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that
includes IPv4 destination address. The Type value is TBA13. The
value of the Length field MUST equal to 16.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MBZ (12 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IPv4 Address in a Sub-TLV's Value Field
The Value field consists of the following fields (Figure 10):
* The IPv4 Address is a four-octet-long field.
* 12-octet-long MBZ field MUST be zeroed on transmit and ignored
on receipt.
o Destination IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that
includes IPv6 destination address. The Type value is TBA14. The
value of the Length field MUST equal to 16. The Value field is a
16-octet-long IP v6 Address field.
o Source IP Address sub-TLV - is a 20-octet-long sub-TLV. The Type
value is TBA15. The value of the Length field MUST equal to 16.
The Value field is a 16-octet-long MBZ field that MUST be zeroed
on transmit and ignored on receipt
o Source IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that
includes IPv4 source address. The Type value is TBA16. The value
of the Length field MUST equal to 16. The Value field consists of
the following fields (Figure 10):
* The IPv4 Address is a four-octet-long field.
* 12-octet-long MBZ field that MUST be zeroed on transmit and
ignored on receipt.
o Source IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that
includes IPv6 source address. The Type value is TBA17. The value
of the Length field MUST equal to 16. The Value field is a 16-
octet-long IPv6 Address field.
4.2.2. Theory of Operation of Location TLV
The Session-Reflector that received an extended STAMP packet with the
Location TLV MUST include the Location TLV of the size equal to the
size of Location TLV in the received packet in the reflected packet.
Based on the local policy, the Session-Reflector MAY leave some
fields unreported by filling them with zeroes. An implementation of
the stateful Session-Reflector MUST provide control for managing such
policies.
A Session-Sender MAY include the Source MAC Address sub-TLV is the
Location TLV. If the Session-Reflector receives the Location TLV
that includes the Source MAC Address sub-TLV, it MUST include the
Source EUI-48 Address sub-TLV if the source MAC address of the
received extended test packet is in EUI-48 format. And the Session-
Reflector MUST copy the value of the source MAC address in the EUI-48
field. Otherwise, the Session-Reflector MUST use the Source EUI-64
Address sub-TLV and MUST copy the value of the Source MAC address
from the received packet into the EUI-64 field. If the received
extended STAMP test packet does not have the Source MAC address, the
Session-Reflector MUST zero the EUI-64 field before transmitting the
reflected packet.
A Session-Sender MAY include the Destination IP Address sub-TLV is
the Location TLV. If the Session-Reflector receives the Location TLV
that includes the Destination IP Address sub-TLV, it MUST include the
Destination IPv4 Address sub-TLV if the source IP address of the
received extended test packet is of IPv4 address family. And the
Session-Reflector MUST copy the value of the destination IP address
in the IPv4 Address field. Otherwise, the Session-Reflector MUST use
the Destination IPv6 Address sub-TLV and MUST copy the value of the
destination IP address from the received packet into the IPv6 Address
field.
A Session-Sender MAY include the Source IP Address sub-TLV is the
Location TLV. If the Session-Reflector receives the Location TLV
that includes the Source IP Address sub-TLV, it MUST include the
Source IPv4 Address sub-TLV if the source IP address of the received
extended test packet is of IPv4 address family. And the Session-
Reflector MUST copy the value of the source IP address in the IPv4
Address field. Otherwise, the Session-Reflector MUST use the Source
IPv6 Address sub-TLV and MUST copy the value of the source IP address
from the received packet into the IPv6 Address field.
The Location TLV MAY be used to determine the last-hop IP addresses, The Location TLV MAY be used to determine the last-hop IP addresses,
ports, and last-hop MAC address for STAMP packets. The MAC address ports, and last-hop MAC address for STAMP packets. The MAC address
can indicate a path switch on the last hop. The IP addresses and UDP can indicate a path switch on the last hop. The IP addresses and UDP
ports will indicate if there is a NAT router on the path. It allows ports will indicate if there is a NAT router on the path. It allows
the Session-Sender to identify the IP address of the Session- the Session-Sender to identify the IP address of the Session-
Reflector behind the NAT, and detect changes in the NAT mapping that Reflector behind the NAT, and detect changes in the NAT mapping that
could cause sending the STAMP packets to the wrong Session-Reflector. could cause sending the STAMP packets to the wrong Session-Reflector.
4.3. Timestamp Information TLV 4.3. Timestamp Information TLV
The STAMP Session-Sender MAY include the Timestamp Information TLV to The STAMP Session-Sender MAY include the Timestamp Information TLV to
request information from the Session-Reflector. The Session-Sender request information from the Session-Reflector. The Session-Sender
SHOULD NOT fill any information fields except for STAMP TLV Flags, MUST NOT fill any information fields except for STAMP TLV Flags,
Type, and Length. The Session-Reflector MUST validate the Length Type, and Length. All other fields MUST be filled with zeroes The
value of the TLV. If the value of the Length field is invalid, the Session-Reflector MUST validate the Length value of the TLV. If the
Session-Reflector MUST zero all fields and MUST NOT return any value of the Length field is invalid, the Session-Reflector follows
information to the Session-Sender. the procedure defined in Section 4 for a malformed TLV.
0 1 2 3 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 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|Times Info Type| Length | |STAMP TLV Flags|Times Info Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out | | Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Timestamp Information TLV Figure 11: Timestamp Information TLV
where fields are defined as the following: where fields are defined as the following:
o STAMP TLV Flags - is an eight-bit-long field. Its format is o STAMP TLV Flags - is an eight-bit-long field. Its format is
presented in Figure 6. presented in Figure 6.
o Timestamp Information Type - is a one-octet-long field, value TBA3 o Timestamp Information Type - is a one-octet-long field, value TBA3
allocated by IANA Section 5.1. allocated by IANA Section 5.1.
o Length - two-octet-long field, set equal to the value 4. o Length - two-octet-long field, set equal to the length of the
Value field in octets (Figure 5).
o Sync Src In - one-octet-long field that characterizes the source o Sync Src In - one-octet-long field that characterizes the source
of clock synchronization at the ingress of a Session-Reflector. of clock synchronization at the ingress of a Session-Reflector.
There are several methods to synchronize the clock, e.g., Network There are several methods to synchronize the clock, e.g., Network
Time Protocol (NTP) [RFC5905]. The value is one of those listed Time Protocol (NTP) [RFC5905]. The value is one of those listed
in Table 5. in Table 7.
o Timestamp In - one-octet-long field that characterizes the method o Timestamp In - one-octet-long field that characterizes the method
by which the ingress of the Session-Reflector obtained the by which the ingress of the Session-Reflector obtained the
timestamp T2. A timestamp may be obtained with hardware timestamp T2. A timestamp may be obtained with hardware
assistance, via software API from a local wall clock, or from a assistance, via software API from a local wall clock, or from a
remote clock (the latter is referred to as "control plane"). The remote clock (the latter is referred to as "control plane"). The
value is one of those listed in Table 7. value is one of those listed in Table 9.
o Sync Src Out - one-octet-long field that characterizes the source o Sync Src Out - one-octet-long field that characterizes the source
of clock synchronization at the egress of the Session-Reflector. of clock synchronization at the egress of the Session-Reflector.
The value is one of those listed in Table 5. The value is one of those listed in Table 7.
o Timestamp Out - one-octet-long field that characterizes the method o Timestamp Out - one-octet-long field that characterizes the method
by which the egress of the Session-Reflector obtained the by which the egress of the Session-Reflector obtained the
timestamp T3. The value is one of those listed in Table 7. timestamp T3. The value is one of those listed in Table 9.
o Optional sub-TLVs - optional variable-length field.
4.4. Class of Service TLV 4.4. Class of Service TLV
The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in 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 the STAMP test packet. The format of the CoS TLV is presented in
Figure 10. Figure 12.
0 1 2 3 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 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 | |STAMP TLV Flags| CoS Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP1 | DSCP2 |ECN| Reserved | | DSCP1 | DSCP2 |ECN| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Class of Service TLV Figure 12: Class of Service TLV
where fields are defined as the following: where fields are defined as the following:
o STAMP TLV Flags - is an eight-bit-long field. Its format is o STAMP TLV Flags - is an eight-bit-long field. Its format is
presented in Figure 6. presented in Figure 6.
o CoS (Class of Service) Type - is a one-octet-long field, value o CoS (Class of Service) Type - is a one-octet-long field, value
TBA4 allocated by IANA Section 5.1. TBA4 allocated by IANA Section 5.1.
o Length - two-octet-long field, set equal to the value 4. o Length - two-octet-long field, set equal to the value 4.
o DSCP1 - The Differentiated Services Code Point (DSCP) intended by o DSCP1 - The Differentiated Services Code Point (DSCP) intended by
the Session-Sender to be used as the DSCP value of the reflected the Session-Sender to be used as the DSCP value of the reflected
test packet. test packet.
o DSCP2 - The received value in the DSCP field at the Session- o DSCP2 - The received value in the DSCP field at the ingress of the
Reflector in the forward direction. Session-Reflector.
o ECN - The received value in the ECN field at the Session-Reflector o ECN - The received value in the ECN field at the ingress of the
in the forward direction. Session-Reflector.
o Reserved - 18-bit-long field, MUST be zeroed on transmission and o Reserved - 18-bit-long field, MUST be zeroed on transmission and
ignored on receipt. ignored on receipt.
A STAMP Session-Reflector that receives a test packet with the CoS A STAMP Session-Reflector that receives a test packet with the CoS
TLV MUST include the CoS TLV in the reflected test packet. Also, the TLV MUST include the CoS TLV in the reflected test packet. Also, the
Session-Reflector MUST copy the value of the DSCP and ECN fields of Session-Reflector MUST copy the value of the DSCP and ECN fields of
the IP header of the received STAMP test packet into the DSCP2 field the IP header of the received STAMP test packet into the DSCP2 field
in the reflected test packet. Finally, the Session-Reflector MUST in the reflected test packet. Finally, the Session-Reflector MUST
set the DSCP field's value in the IP header of the reflected test set the DSCP field's value in the IP header of the reflected test
skipping to change at page 15, line 41 skipping to change at page 18, line 28
it is misconfigured, then it is often difficult to diagnose the root it is misconfigured, then it is often difficult to diagnose the root
cause of excessive packet drops of higher-level service while packet cause of excessive packet drops of higher-level service while packet
drops for lower service packets are at a normal level. Using a CoS drops for lower service packets are at a normal level. Using a CoS
TLV in STAMP testing helps to troubleshoot the existing problem and TLV in STAMP testing helps to troubleshoot the existing problem and
also verify whether DiffServ policies are processing CoS as required also verify whether DiffServ policies are processing CoS as required
by the configuration. by the configuration.
4.5. Direct Measurement TLV 4.5. Direct Measurement TLV
The Direct Measurement TLV enables collection of the number of in- The Direct Measurement TLV enables collection of the number of in-
profile packets that had been transmitted and received by the profile packets, i.e., packets that form a specific data flow, that
Session-Sender and Session-Reflector, respectively. The definition had been transmitted and received by the Session-Sender and Session-
of "in-profile packet" is outside the scope of this document and is Reflector, respectively. The definition of "in-profile packet" is
left to the test operators to determine. outside the scope of this document and is left to the test operators
to determine.
0 1 2 3 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 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| Direct Type | Length | |STAMP TLV Flags| Direct Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Tx counter (S_TxC) | | Session-Sender Tx counter (S_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Rx counter (R_RxC) | | Session-Reflector Rx counter (R_RxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Reflector Tx counter (R_TxC) | | Session-Reflector Tx counter (R_TxC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Direct Measurement TLV Figure 13: Direct Measurement TLV
where fields are defined as the following: where fields are defined as the following:
o STAMP TLV Flags - is an eight-bit-long field. Its format is o STAMP TLV Flags - is an eight-bit-long field. Its format is
presented in Figure 6. presented in Figure 6.
o Direct (Measurement) Type - is a one-octet-long field, value TBA5 o Direct (Measurement) Type - is a one-octet-long field, value TBA5
allocated by IANA Section 5.1. allocated by IANA Section 5.1.
o Length - two-octet-long field equals length of the Value field in o Length - two-octet-long field equals the length of the Value field
octets. The Length field value MUST equal 12 octets. in octets. The Length field value MUST equal 12 octets.
o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The
Session-Sender MUST set its value equal to the number of the Session-Sender MUST set its value equal to the number of the
transmitted in-profile packets. transmitted in-profile packets.
o Session-Reflector Rx counter (R_RxC) is a four-octet-long field. o Session-Reflector Rx counter (R_RxC) is a four-octet-long field.
MUST be zeroed by the Session-Sender on transmit and ignored by MUST be zeroed by the Session-Sender on transmit and ignored by
the Session-Reflector on receipt. The Session-Reflector MUST fill the Session-Reflector on receipt. The Session-Reflector MUST fill
it with the value of in-profile packets received. it with the value of in-profile packets received.
o Session-Reflector Tx counter (R_TxC) is a four-octet-long field. o Session-Reflector Tx counter (R_TxC) is a four-octet-long field.
MUST be zeroed by the Session-Sender and ignored by the Session- MUST be zeroed by the Session-Sender and ignored by the Session-
Reflector on receipt. The Session-Reflector MUST fill it with the Reflector on receipt. The Session-Reflector MUST fill it with the
value of the transmitted in-profile packets. value of the transmitted in-profile packets.
A Session-Sender MAY include the Direct Measurement TLV in a STAMP A Session-Sender MAY include the Direct Measurement TLV in a STAMP
test packet. The Session-Sender MUST zero the R_RxC and R_TxC fields test packet. If the received STAMP test packet includes the Direct
before the transmission of the STAMP test packet. If the received Measurement TLV, the Session-Reflector MUST include it in the
STAMP test packet includes the Direct Measurement TLV, the Session- reflected test packet. The Session-Reflector MUST copy the value
Reflector MUST include it in the reflected test packet. The Session- from the S_TxC field of the received test packet into the same field
Reflector MUST copy the value from the S_TxC field of the received of the reflected packet before its transmission.
test packet into the same field of the reflected packet before its
transmission.
4.6. Access Report TLV 4.6. Access Report TLV
A STAMP Session-Sender MAY include an Access Report TLV (Figure 12) A STAMP Session-Sender MAY include an Access Report TLV (Figure 14)
to indicate changes to the access network status to the Session- to indicate changes to the access network status to the Session-
Reflector. The definition of an access network is outside the scope Reflector. The definition of an access network is outside the scope
of this document. of this document.
0 1 2 3 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 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|Acc Report Type| Length | |STAMP TLV Flags|Acc Report Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Resv | Return Code | Reserved | | ID | Resv | Return Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Access Report TLV Figure 14: Access Report TLV
where fields are defined as follows: where fields are defined as follows:
o STAMP TLV Flags - is an eight-bit-long field. Its format o STAMP TLV Flags - is an eight-bit-long field. Its format
presented in Figure 6. presented in Figure 6.
o Access Report Type - is a one-octet-long field, value TBA6 o Access Report Type - is a one-octet-long field, value TBA6
allocated by IANA Section 5.1. allocated by IANA Section 5.1.
o Length - two-octet-long field, set equal to the value 4. o Length - two-octet-long field, set equal to the value 4.
skipping to change at page 17, line 51 skipping to change at page 20, line 29
All other values are invalid and the TLV that contains it MUST be All other values are invalid and the TLV that contains it MUST be
discarded. discarded.
o Resv - four-bit-long field, MUST be zeroed on transmission and o Resv - four-bit-long field, MUST be zeroed on transmission and
ignored on receipt. ignored on receipt.
o Return Code - one-octet-long field that identifies the report o Return Code - one-octet-long field that identifies the report
signal, e.g., available or unavailable. The value is supplied to signal, e.g., available or unavailable. The value is supplied to
the STAMP end-point through some mechanism that is outside the the STAMP end-point through some mechanism that is outside the
scope of this document. The value is one of those listed in scope of this document. The value is one of those listed in
Section 5.5. Section 5.6.
o Reserved - two-octet-long field, MUST be zeroed on transmission o Reserved - two-octet-long field, MUST be zeroed on transmission
and ignored on receipt. and ignored on receipt.
The STAMP Session-Sender that includes the Access Report TLV sets the The STAMP Session-Sender that includes the Access Report TLV sets the
value of the Access ID field according to the type of access network value of the Access ID field according to the type of access network
it reports on. Also, the Session-Sender sets the value of the Return it reports on. Also, the Session-Sender sets the value of the Return
Code field to reflect the operational state of the access network. Code field to reflect the operational state of the access network.
The mechanism to determine the state of the access network is outside The mechanism to determine the state of the access network is outside
the scope of this specification. A STAMP Session-Reflector that the scope of this specification. A STAMP Session-Reflector that
skipping to change at page 18, line 42 skipping to change at page 21, line 19
The Access Report TLV is used by the Performance Measurement Function The Access Report TLV is used by the Performance Measurement Function
(PMF) components of the Access Steering, Switching and Splitting (PMF) components of the Access Steering, Switching and Splitting
feature for 5G networks [TS23501]. The PMF component in the User feature for 5G networks [TS23501]. The PMF component in the User
Equipment acts as the STAMP Session-Sender, and the PMF component in Equipment acts as the STAMP Session-Sender, and the PMF component in
the User Plane Function acts as the STAMP Session-Reflector. the User Plane Function acts as the STAMP Session-Reflector.
4.7. Follow-up Telemetry TLV 4.7. Follow-up Telemetry TLV
A Session-Reflector might be able to put in the Timestamp field only A Session-Reflector might be able to put in the Timestamp field only
an "SW Local" (see Table 7) timestamp. But the hosting system might an "SW Local" (see Table 9) timestamp. But the hosting system might
provide a timestamp closer to the start of the actual packet provide a timestamp closer to the start of the actual packet
transmission even though it is not possible to deliver the transmission even though it is not possible to deliver the
information to the Session-Sender in time for the packet itself. information to the Session-Sender in time for the packet itself.
This timestamp might nevertheless be important for the Session- This timestamp might nevertheless be important for the Session-
Sender, as it improves the accuracy of measuring network delay by Sender, as it improves the accuracy of measuring network delay by
minimizing the impact of egress queuing delays on the measurement. minimizing the impact of egress queuing delays on the measurement.
A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to
request information from the Session-Reflector. The Session-Sender request information from the Session-Reflector. The Session-Sender
MUST set the Follow-up Telemetry Type and Length fields to their MUST set the Follow-up Telemetry Type and Length fields to their
appropriate values. The Sequence Number and Timestamp fields MUST be appropriate values. The Sequence Number and Timestamp fields MUST be
zeroed on transmission by the Session-Sender and ignored by the zeroed on transmission by the Session-Sender and ignored by the
Session-Reflector upon receipt of the STAMP test packet that includes Session-Reflector upon receipt of the STAMP test packet that includes
the Follow-up Telemetry TLV. The Session-Reflector MUST validate the the Follow-up Telemetry TLV. The Session-Reflector MUST validate the
Length value of the STAMP test packet. If the value of the Length Length value of the STAMP test packet. If the value of the Length
field is invalid, the Session-Reflector MUST zero the Sequence Number field is invalid, the Session-Reflector MUST zero the Sequence Number
and Timestamp fields and set the L flag in the STAMP TLV Flags field and Timestamp fields and set the M flag in the STAMP TLV Flags field
in the reflected packet. If the Session-Reflector is in stateless in the reflected packet. If the Session-Reflector is in stateless
mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence
Number and Timestamp fields. Number and Timestamp fields.
0 1 2 3 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 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| Follow-up Type| Length | |STAMP TLV Flags| Follow-up Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Follow-up Timestamp | | Follow-up Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp M | Reserved | | Timestamp M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Follow-up Telemetry TLV Figure 15: Follow-up Telemetry TLV
where fields are defined as follows: where fields are defined as follows:
o STAMP TLV Flags - is an eight-bit-long field. Its format o STAMP TLV Flags - is an eight-bit-long field. Its format
presented in Figure 6. presented in Figure 6.
o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7 o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7
allocated by IANA Section 5.1. allocated by IANA Section 5.1.
o Length - two-octet-long field, set equal to the value 16 octets. o Length - two-octet-long field, set equal to the value 16 octets.
o Sequence Number - four-octet-long field indicating the sequence o Sequence Number - four-octet-long field indicating the sequence
number of the last packet reflected in the same STAMP-test number of the last packet reflected in the same STAMP-test
session. Since the Session-Reflector runs in the stateful mode session. Since the Session-Reflector runs in the stateful mode
(defined in Section 4.2 [RFC8762]), it is the Session-Reflector's (defined in Section 4.2 [RFC8762]), it is the Session-Reflector's
Sequence Number of the previous reflected packet. Sequence Number of the previous reflected packet.
o Follow-up Timestamp - eight-octet-long field, with the format o Follow-up Timestamp - eight-octet-long field, with the format
indicated by the Z flag of the Error Estimate field of the packet indicated by the Z flag of the Error Estimate field of the STAMP
transmitted by a Session-Reflector, as described in Section 4.1 base packet, which is contained in this reflected test packet
transmitted by a Session-Reflector, as described in Section 4.2.1
[RFC8762]. It carries the timestamp when the reflected packet [RFC8762]. It carries the timestamp when the reflected packet
with the specified sequence number was sent. with the specified sequence number was sent.
o Timestamp M(ode) - one-octet-long field that characterizes the o Timestamp M(ode) - one-octet-long field that characterizes the
method by which the entity that transmits a reflected STAMP packet method by which the entity that transmits a reflected STAMP packet
obtained the Follow-up Timestamp. The value is one of those obtained the Follow-up Timestamp. The value is one of those
listed in Table 7. listed in Table 9.
o Reserved - three-octet-long field. Its value MUST be zeroed on o Reserved - three-octet-long field. Its value MUST be zeroed on
transmission and ignored on receipt. transmission and ignored on receipt.
4.8. HMAC TLV 4.8. HMAC TLV
The STAMP authenticated mode protects the integrity of data collected The STAMP authenticated mode protects the integrity of data collected
in the STAMP base packet. STAMP extensions are designed to provide in the STAMP base packet. STAMP extensions are designed to provide
valuable information about the condition of a network, and protecting valuable information about the condition of a network, and protecting
the integrity of that data is also essential. The keyed Hashed the integrity of that data is also essential. All authenticated
Message Authentication Code (HMAC) TLV MUST be included in a STAMP STAMP base packets (per Section 4.2.2 and Section 4.3.2 [RFC8762])
test packet in the authenticated mode, excluding when the only TLV compatible with this specification MUST additionally authenticate the
present is Extra Padding TLV. The HMAC TLV MUST follow all TLVs option TLVs by including the keyed Hashed Message Authentication Code
included in a STAMP test packet, except for the Extra Padding TLV. (HMAC) TLV, with the sole exception of when there is only one TLV
present, and it is the Extended Padding TLV. The HMAC TLV MUST
follow all TLVs included in a STAMP test packet, except for the Extra
Padding TLV. If the HMAC TLV appears in any other position in a
STAMP extended test packet, then the situation MUST be processed as
HMAC verification failure, as defined in this section, further below.
The HMAC TLV MAY be used to protect the integrity of STAMP extensions The HMAC TLV MAY be used to protect the integrity of STAMP extensions
in STAMP unauthenticated mode. in STAMP unauthenticated mode. An implementation of STAMP extensions
MUST provide controls to enable the integrity protection of STAMP
extensions in STAMP unauthenticated mode.
0 1 2 3 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 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| HMAC Type | Length | |STAMP TLV Flags| HMAC Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC | | HMAC |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: HMAC TLV Figure 16: HMAC TLV
where fields are defined as follows: where fields are defined as follows:
o STAMP TLV Flags - is an eight-bit-long field. Its format is o STAMP TLV Flags - is an eight-bit-long field. Its format is
presented in Figure 6. presented in Figure 6.
o HMAC Type - is a one-octet-long field, value TBA8 allocated by o HMAC Type - is a one-octet-long field, value TBA8 allocated by
IANA Section 5.1. IANA Section 5.1.
o Length - two-octet-long field, set equal to 16 octets. o Length - two-octet-long field, set equal to 16 octets.
o HMAC - is a 16-octet-long field that carries HMAC digest of the o HMAC - is a 16-octet-long field that carries HMAC digest of the
text of all preceding TLVs. text of all preceding TLVs.
As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128 As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
bits ([RFC4868]). All considerations regarding using the key and key bits ([RFC4868]). All considerations regarding using the key and key
distribution and management listed in Section 4.4 of [RFC8762] are distribution and management listed in Section 4.4 of [RFC8762] are
fully applicable to the use of the HMAC TLV. HMAC is calculated as fully applicable to the use of the HMAC TLV. HMAC TLV is anticipated
defined in [RFC2104] over text as the concatenation of all preceding to track updates in the base STAMP protocol [RFC8762], including the
TLVs. The digest then MUST be truncated to 128 bits and written into use of more advanced cryptographic algorithms. HMAC is calculated as
the HMAC field. In the authenticated mode, HMAC MUST be verified defined in [RFC2104] over text as the concatenation of the Sequence
before using any data in the included STAMP TLVs. If HMAC Number field of the base STAMP packet and all preceding TLVs. The
verification by the Session-Reflector fails, then the Session- digest then MUST be truncated to 128 bits and written into the HMAC
Reflector MUST stop processing the received extended STAMP test field. If the HMAC TLV is present in the extended STAMP test packet,
packet. The Session-Reflector MUST copy the remainder of the e.g., in the authenticated mode, HMAC MUST be verified before using
extended STAMP test packet into the reflected packet. The Session- any data in the included STAMP TLVs. If HMAC verification by the
Reflector MUST set the A flag in the copy of the HMAC TLV in the Session-Reflector fails, then the Session-Reflector MUST stop
reflected packet to 1 before transmitting the reflected test packet. processing the received extended STAMP test packet. The Session-
Also, both the Session-Sender and Session-Reflector SHOULD log the Reflector MUST copy the TLVs from the received STAMP test packet into
notification that HMAC verification of STAMP TLVs failed. the reflected packet. The Session-Reflector MUST set the I flag in
each TLV copied over into the reflected packet to 1 before
transmitting the reflected test packet. If the Session-Sender
receives the extended STAMP test packet with I flag set to 1, then
the Session-Sender MUST stop processing TLVs in the reflected test
packet. If HMAC verification by the Session-Sender fails, then the
Session-Sender MUST stop processing TLVs in the reflected extended
STAMP packet.
5. IANA Considerations 5. IANA Considerations
5.1. STAMP TLV Registry 5.1. STAMP TLV Registry
IANA is requested to create the STAMP TLV Type registry. All code IANA is requested to create the STAMP TLV Type registry. All code
points in the range 1 through 175 in this registry shall be allocated points in the range 1 through 175 in this registry shall be allocated
according to the "IETF Review" procedure as specified in [RFC8126]. according to the "IETF Review" procedure as specified in [RFC8126].
Code points in the range 176 through 239 in this registry shall be Code points in the range 176 through 239 in this registry shall be
allocated according to the "First Come First Served" procedure as allocated according to the "First Come First Served" procedure as
specified in [RFC8126]. The remaining code points are allocated specified in [RFC8126]. The remaining code points are allocated
according to Table 1: according to Table 1:
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1- 175 | Unassigned | IETF Review | | 1- 175 | Unassigned | This document |
| 176 - 239 | Unassigned | First Come First Served | | 176 - 239 | Unassigned | This document |
| 240 - 251 | Experimental | This document | | 240 - 251 | Experimental | This document |
| 252 - 254 | Private Use | This document | | 252 - 254 | Private Use | This document |
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
Table 1: STAMP TLV Type Registry Table 1: STAMP TLV Type Registry
This document defines the following new values in the STAMP Extension This document defines the following new values in the IETF Review
TLV range of the STAMP TLV Type registry: range of the STAMP TLV Type registry:
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| TBA1 | Extra Padding | This document | | TBA1 | Extra Padding | This document |
| TBA2 | Location | This document | | TBA2 | Location | This document |
| TBA3 | Timestamp Information | This document | | TBA3 | Timestamp Information | This document |
| TBA4 | Class of Service | This document | | TBA4 | Class of Service | This document |
| TBA5 | Direct Measurement | This document | | TBA5 | Direct Measurement | This document |
| TBA6 | Access Report | This document | | TBA6 | Access Report | This document |
| TBA7 | Follow-up Telemetry | This document | | TBA7 | Follow-up Telemetry | This document |
| TBA8 | HMAC | This document | | TBA8 | HMAC | This document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
Table 2: STAMP Types Table 2: STAMP TLV Types
5.2. STAMP TLV Flags Sub-registry 5.2. STAMP TLV Flags Sub-registry
IANA is requested to create the STAMP TLV Flags sub-registry as part IANA is requested to create the STAMP TLV Flags sub-registry as part
of the STAMP TLV Type registry. The registration procedure is "IETF of the STAMP TLV Type registry. The registration procedure is "IETF
Review" [RFC8126]. Flags are 8 bits. This document defines the Review" [RFC8126]. Flags are 8 bits. This document defines the
following bit positions in the STAMP TLV Flags sub-registry: following bit positions in the STAMP TLV Flags sub-registry:
+--------------+--------+-----------------------+---------------+ +--------------+--------+------------------------+---------------+
| Bit position | Symbol | Description | Reference | | Bit position | Symbol | Description | Reference |
+--------------+--------+-----------------------+---------------+ +--------------+--------+------------------------+---------------+
| 0 | U | Unrecognized TLV | This document | | 0 | U | Unrecognized TLV | This document |
| 1 | L | Malformed TLV | This document | | 1 | M | Malformed TLV | This document |
| 2 | A | Authentication failed | This document | | 2 | I | Integrity check failed | This document |
+--------------+--------+-----------------------+---------------+ +--------------+--------+------------------------+---------------+
Table 3: STAMP TLV Flags Table 3: STAMP TLV Flags
5.3. Synchronization Source Sub-registry 5.3. Sub-TLV Type Sub-registry
IANA is requested to create the sub-TLV Type sub-registry as part of
the STAMP TLV Type registry. All code points in the range 1 through
175 in this registry shall be allocated according to the "IETF
Review" procedure as specified in [RFC8126]. Code points in the
range 176 through 239 in this registry shall be allocated according
to the "First Come First Served" procedure as specified in [RFC8126].
The remaining code points are allocated according to Table 4:
+-----------+--------------+---------------+
| Value | Description | Reference |
+-----------+--------------+---------------+
| 0 | Reserved | This document |
| 1- 175 | Unassigned | This document |
| 176 - 239 | Unassigned | This document |
| 240 - 251 | Experimental | This document |
| 252 - 254 | Private Use | This document |
| 255 | Reserved | This document |
+-----------+--------------+---------------+
Table 4: Location Sub-TLV Type Sub-registry
This document defines the following new values in the IETF Review
range of the Location sub-TLV Type sub-registry:
+-------+--------------------------+----------+---------------+
| Value | Description | TLV Used | Reference |
+-------+--------------------------+----------+---------------+
| TBA9 | Source MAC Address | Location | This document |
| TBA10 | Source EUI-48 Address | Location | This document |
| TBA11 | Source EUI-64 Address | Location | This document |
| TBA12 | Destination IP Address | Location | This document |
| TBA13 | Destination IPv4 Address | Location | This document |
| TBA14 | Destination IPv6 Address | Location | This document |
| TBA15 | Source IP Address | Location | This document |
| TBA16 | Source IPv4 Address | Location | This document |
| TBA17 | Source IPv6 Address | Location | This document |
+-------+--------------------------+----------+---------------+
Table 5: STAMP sub-TLV Types
5.4. Synchronization Source Sub-registry
IANA is requested to create the Synchronization Source sub-registry IANA is requested to create the Synchronization Source sub-registry
as part of the STAMP TLV Type registry. All code points in the range as part of the STAMP TLV Type registry. All code points in the range
1 through 127 in this registry shall be allocated according to the 1 through 127 in this registry shall be allocated according to the
"IETF Review" procedure as specified in [RFC8126]. Code points in "IETF Review" procedure as specified in [RFC8126]. Code points in
the range 128 through 239 in this registry shall be allocated the range 128 through 239 in this registry shall be allocated
according to the "First Come First Served" procedure as specified in according to the "First Come First Served" procedure as specified in
[RFC8126]. Remaining code points are allocated according to Table 4: [RFC8126]. Remaining code points are allocated according to Table 6:
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1- 127 | Unassigned | IETF Review | | 1- 127 | Unassigned | This document |
| 128 - 239 | Unassigned | First Come First Served | | 128 - 239 | Unassigned | This document |
| 240 - 249 | Experimental | This document | | 240 - 249 | Experimental | This document |
| 250 - 254 | Private Use | This document | | 250 - 254 | Private Use | This document |
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
Table 4: Synchronization Source Sub-registry Table 6: Synchronization Source Sub-registry
This document defines the following new values in the Synchronization This document defines the following new values in the Synchronization
Source sub-registry: Source sub-registry:
+-------+-------------------------+---------------+ +-------+---------------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------+---------------+ +-------+---------------------------------+---------------+
| 1 | NTP | This document | | 1 | NTP | This document |
| 2 | PTP | This document | | 2 | PTP | This document |
| 3 | SSU/BITS | This document | | 3 | SSU/BITS | This document |
| 4 | GPS/GLONASS/LORAN-C/BDS | This document | | 4 | GPS/GLONASS/LORAN-C/BDS/Galileo | This document |
| 5 | Local free-running | This document | | 5 | Local free-running | This document |
+-------+-------------------------+---------------+ +-------+---------------------------------+---------------+
Table 5: Synchronization Sources Table 7: Synchronization Sources
5.4. Timestamping Method Sub-registry 5.5. Timestamping Method Sub-registry
IANA is requested to create the Timestamping Method sub-registry as IANA is requested to create the Timestamping Method sub-registry as
part of the STAMP TLV Type registry. All code points in the range 1 part of the STAMP TLV Type registry. All code points in the range 1
through 127 in this registry shall be allocated according to the through 127 in this registry shall be allocated according to the
"IETF Review" procedure as specified in [RFC8126]. Code points in "IETF Review" procedure as specified in [RFC8126]. Code points in
the range 128 through 239 in this registry shall be allocated the range 128 through 239 in this registry shall be allocated
according to the "First Come First Served" procedure as specified in according to the "First Come First Served" procedure as specified in
[RFC8126]. Remaining code points are allocated according to Table 6: [RFC8126]. Remaining code points are allocated according to Table 8:
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1- 127 | Unassigned | IETF Review | | 1- 127 | Unassigned | This document |
| 128 - 239 | Unassigned | First Come First Served | | 128 - 239 | Unassigned | This document |
| 240 - 249 | Experimental | This document | | 240 - 249 | Experimental | This document |
| 250 - 254 | Private Use | This document | | 250 - 254 | Private Use | This document |
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
Table 6: Timestamping Method Sub-registry Table 8: Timestamping Method Sub-registry
This document defines the following new values in the Timestamping This document defines the following new values in the Timestamping
Methods sub-registry: Methods sub-registry:
+-------+---------------+---------------+ +-------+---------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------+---------------+ +-------+---------------+---------------+
| 1 | HW Assist | This document | | 1 | HW Assist | This document |
| 2 | SW local | This document | | 2 | SW local | This document |
| 3 | Control plane | This document | | 3 | Control plane | This document |
+-------+---------------+---------------+ +-------+---------------+---------------+
Table 7: Timestamping Methods Table 9: Timestamping Methods
5.5. Return Code Sub-registry 5.6. Return Code Sub-registry
IANA is requested to create the Return Code sub-registry as part of IANA is requested to create the Return Code sub-registry as part of
the STAMP TLV Type registry. All code points in the range 1 through the STAMP TLV Type registry. All code points in the range 1 through
127 in this registry shall be allocated according to the "IETF 127 in this registry shall be allocated according to the "IETF
Review" procedure as specified in [RFC8126]. Code points in the Review" procedure as specified in [RFC8126]. Code points in the
range 128 through 239 in this registry shall be allocated according range 128 through 239 in this registry shall be allocated according
to the "First Come First Served" procedure as specified in [RFC8126]. to the "First Come First Served" procedure as specified in [RFC8126].
Remaining code points are allocated according to Table 8: Remaining code points are allocated according to Table 10:
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1- 127 | Unassigned | IETF Review | | 1- 127 | Unassigned | This document |
| 128 - 239 | Unassigned | First Come First Served | | 128 - 239 | Unassigned | This document |
| 240 - 249 | Experimental | This document | | 240 - 249 | Experimental | This document |
| 250 - 254 | Private Use | This document | | 250 - 254 | Private Use | This document |
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+--------------+-------------------------+ +-----------+--------------+---------------+
Table 8: Return Code Sub-registry Table 10: Return Code Sub-registry
This document defines the following new values in the Return Code This document defines the following new values in the Return Code
sub-registry: sub-registry:
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| 1 | Network available | This document | | 1 | Network available | This document |
| 2 | Network unavailable | This document | | 2 | Network unavailable | This document |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
Table 9: Return Codes Table 11: Return Codes
6. Security Considerations 6. Security Considerations
This document defines extensions to STAMP [RFC8762] and inherits all This document defines extensions to STAMP [RFC8762] and inherits all
the security considerations applicable to the base protocol. the security considerations applicable to the base protocol.
Additionally, the HMAC TLV is defined in this document to protect the Additionally, the HMAC TLV is defined in this document to protect the
integrity of optional STAMP extensions. The use of HMAC TLV is integrity of optional STAMP extensions. The use of HMAC TLV is
discussed in detail in Section 4.8. discussed in detail in Section 4.8.
To protect against a malformed TLV an implementation of a Session-
Sender and Session-Reflector MUST:
o check the setting of the M flag;
o validate the Length field value.
Monitoring and optional control of DSCP do not appear to introduce
any additional security threat to hosts that communicate with STAMP
as defined in [RFC8762]. As this specification defined the mechanism
to test DSCP mapping, this document inherits all the security
considerations discussed in [RFC2474].
7. Acknowledgments 7. Acknowledgments
Authors much appreciate the thorough review and thoughtful comments Authors much appreciate the thorough review and thoughtful comments
received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali
Wang. The authors express their gratitude to Al Morton for his Wang. The authors express their gratitude to Al Morton for his
comments and the most valuable suggestions. The authors greatly comments and the most valuable suggestions. The authors greatly
appreciate comments and thoughtful suggestions received from Martin appreciate comments and thoughtful suggestions received from Martin
Duke. Duke.
8. Contributors 8. Contributors
skipping to change at page 26, line 4 skipping to change at page 30, line 15
Guo Jun Guo Jun
ZTE Corporation ZTE Corporation
68# Zijinghua Road 68# Zijinghua Road
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
P.R.China P.R.China
Phone: +86 18105183663 Phone: +86 18105183663
Email: guo.jun2@zte.com.cn Email: guo.jun2@zte.com.cn
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762, Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020, DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>. <https://www.rfc-editor.org/info/rfc8762>.
[TS23501] 3GPP (3rd Generation Partnership Project), "Technical
Specification Group Services and System Aspects; System
Architecture for the 5G System; Stage 2 (Release 16)",
3GPP TS23501, 2019.
9.2. Informative References 9.2. Informative References
[GPS] "Global Positioning System (GPS) Standard Positioning [GPS] "Global Positioning System (GPS) Standard Positioning
Service (SPS) Performance Standard", GPS SPS 5th Edition, Service (SPS) Performance Standard", GPS SPS 5th Edition,
April 2020. April 2020.
[I-D.gont-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", draft-gont-numeric-ids-generation-04
(work in progress), July 2019.
[IEEE.1588.2008] [IEEE.1588.2008]
"Standard for a Precision Clock Synchronization Protocol "Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", for Networked Measurement and Control Systems",
IEEE Standard 1588, March 2008. IEEE Standard 1588, March 2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Hashing for Message Authentication", RFC 2104, "Definition of the Differentiated Services Field (DS
DOI 10.17487/RFC2104, February 1997, Field) in the IPv4 and IPv6 Headers", RFC 2474,
<https://www.rfc-editor.org/info/rfc2104>. DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[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>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[TS23501] 3GPP (3rd Generation Partnership Project), "Technical
Specification Group Services and System Aspects; System
Architecture for the 5G System; Stage 2 (Release 16)",
3GPP TS23501, 2019.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Xiao Min Xiao Min
ZTE Corp. ZTE Corp.
 End of changes. 91 change blocks. 
269 lines changed or deleted 493 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/