draft-ietf-ippm-stamp-10.txt   rfc8762.txt 
Network Working Group G. Mirsky Internet Engineering Task Force (IETF) G. Mirsky
Internet-Draft ZTE Corp. Request for Comments: 8762 G. Jun
Intended status: Standards Track G. Jun Category: Standards Track ZTE Corp.
Expires: May 3, 2020 ZTE Corporation ISSN: 2070-1721 H. Nydell
H. Nydell
Accedian Networks Accedian Networks
R. Foote R. Foote
Nokia Nokia
October 31, 2019 March 2020
Simple Two-way Active Measurement Protocol Simple Two-Way Active Measurement Protocol
draft-ietf-ippm-stamp-10
Abstract Abstract
This document describes a Simple Two-way Active Measurement Protocol This document describes the Simple Two-way Active Measurement
which enables the measurement of both one-way and round-trip Protocol (STAMP), which enables the measurement of both one-way and
performance metrics like delay, delay variation, and packet loss. round-trip performance metrics, like delay, delay variation, and
packet loss.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on May 3, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8762.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language
3. Operation and Management of Performance Measurement Based on 3. Operation and Management of Performance Measurement Based on
STAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 STAMP
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. Theory of Operation
4.1. UDP Port Numbers in STAMP Testing . . . . . . . . . . . . 5 4.1. UDP Port Numbers in STAMP Testing
4.2. Session-Sender Behavior and Packet Format . . . . . . . . 5 4.2. Session-Sender Behavior and Packet Format
4.2.1. Session-Sender Packet Format in Unauthenticated Mode 5 4.2.1. Session-Sender Packet Format in Unauthenticated Mode
4.2.2. Session-Sender Packet Format in Authenticated Mode . 7 4.2.2. Session-Sender Packet Format in Authenticated Mode
4.3. Session-Reflector Behavior and Packet Format . . . . . . 8 4.3. Session-Reflector Behavior and Packet Format
4.3.1. Session-Reflector Packet Format in Unauthenticated 4.3.1. Session-Reflector Packet Format in Unauthenticated Mode
Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3.2. Session-Reflector Packet Format in Authenticated Mode
4.3.2. Session-Reflector Packet Format in Authenticated Mode 10 4.4. Integrity Protection in STAMP
4.4. Integrity Protection in STAMP . . . . . . . . . . . . . . 11 4.5. Confidentiality Protection in STAMP
4.5. Confidentiality Protection in STAMP . . . . . . . . . . . 12 4.6. Interoperability with TWAMP Light
4.6. Interoperability with TWAMP Light . . . . . . . . . . . . 12 5. Operational Considerations
5. Operational Considerations . . . . . . . . . . . . . . . . . 13 6. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 Acknowledgments
9.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Development and deployment of the Two-Way Active Measurement Protocol Development and deployment of the Two-Way Active Measurement Protocol
(TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined (TWAMP) [RFC5357] and its extensions (e.g., [RFC6038], which defines
Symmetrical Size for TWAMP, provided invaluable experience. Several Symmetrical Size for TWAMP) provided invaluable experience. Several
independent implementations of both TWAMP and TWAMP Light exist, have independent implementations of both TWAMP and TWAMP Light exist, have
been deployed, and provide important operational performance been deployed, and provide important operational performance
measurements. measurements.
At the same time, there has been noticeable interest in using a more At the same time, there has been noticeable interest in using a more
straightforward mechanism for active performance monitoring that can straightforward mechanism for active performance monitoring that can
provide deterministic behavior and inherent separation of control provide deterministic behavior and inherent separation of control
(vendor-specific configuration or orchestration) and test functions. (vendor-specific configuration or orchestration) and test functions.
Recent work on IP Edge to Customer Equipment using TWAMP Light from Recent work on "Performance Measurement from IP Edge to Customer
Broadband Forum [BBF.TR-390] demonstrated that interoperability among Equipment using TWAMP Light" [BBF.TR-390] by the Broadband Forum
implementations of TWAMP Light is difficult because the composition demonstrates that interoperability among implementations of TWAMP
and operation of TWAMP Light were not sufficiently specified in Light is difficult because the composition and operation of TWAMP
[RFC5357]. According to [RFC8545], TWAMP Light includes a sub-set of Light were not sufficiently specified in [RFC5357]. According to
TWAMP-Test functions. Thus, to have a comprehensive tool to measure [RFC8545], TWAMP Light includes a subset of TWAMP-Test functions.
packet loss and delay requires support by other applications that Thus, to have a comprehensive tool to measure packet loss and delay
provide, for example, control and security. requires support by other applications that provide, for example,
control and security.
This document defines an active performance measurement test This document defines an active performance measurement test
protocol, Simple Two-way Active Measurement Protocol (STAMP), that protocol, Simple Two-way Active Measurement Protocol (STAMP), that
enables measurement of both one-way and round-trip performance enables measurement of both one-way and round-trip performance
metrics like delay, delay variation, and packet loss. Some TWAMP metrics, like delay, delay variation, and packet loss. Support of
extensions, e.g., [RFC7750] are supported by the extensions to STAMP some optional TWAMP extensions, e.g., [RFC7750], is discussed in
base specification in [I-D.ietf-ippm-stamp-option-tlv]. [STAMP-OPTION].
2. Conventions used in this document 2. Conventions Used in This Document
2.1. Terminology 2.1. Terminology
STAMP - Simple Two-way Active Measurement Protocol STAMP: Simple Two-way Active Measurement Protocol
NTP - Network Time Protocol NTP: Network Time Protocol
PTP - Precision Time Protocol PTP: Precision Time Protocol
HMAC Hashed Message Authentication Code HMAC: Hashed Message Authentication Code
OWAMP One-Way Active Measurement Protocol OWAMP: One-Way Active Measurement Protocol
TWAMP Two-Way Active Measurement Protocol TWAMP: Two-Way Active Measurement Protocol
MBZ Must be Zero MBZ: Must be Zero
PDU: Protocol Data Unit
2.2. Requirements Language 2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Operation and Management of Performance Measurement Based on STAMP 3. Operation and Management of Performance Measurement Based on STAMP
Figure 1 presents the Simple Two-way Active Measurement Protocol Figure 1 presents the Simple Two-way Active Measurement Protocol
(STAMP) Session-Sender, and Session-Reflector with a measurement (STAMP) Session-Sender and Session-Reflector with a measurement
session. In this document, a measurement session also referred to as session. In this document, a measurement session, also referred to
STAMP session, is the bi-directional packet flow between one specific as a "STAMP session", is the bidirectional packet flow between one
Session-Sender and one particular Session-Reflector for a time specific Session-Sender and one particular Session-Reflector for a
duration. The configuration and management of the STAMP Session- time duration. The configuration and management of the STAMP
Sender, Session-Reflector, and management of the STAMP sessions are Session-Sender, Session-Reflector, and sessions are outside the scope
outside the scope of this document and can be achieved through of this document and can be achieved through various means. A few
various means. A few examples are: Command Line Interface, examples are Command Line Interface, telecommunication services'
telecommunication services' OSS/BSS systems, SNMP, and Netconf/YANG- Operational Support System (OSS) / Business Support System (BSS),
based SDN controllers. SNMP, and NETCONF/YANG-based Software-Defined Networking (SDN)
controllers.
o----------------------------------------------------------o o----------------------------------------------------------o
| Configuration and | | Configuration and |
| Management | | Management |
o----------------------------------------------------------o o----------------------------------------------------------o
|| || || ||
|| || || ||
|| || || ||
+----------------------+ +-------------------------+ +----------------------+ +-------------------------+
| STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector | | STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector |
+----------------------+ +-------------------------+ +----------------------+ +-------------------------+
Figure 1: STAMP Reference Model Figure 1: STAMP Reference Model
4. Theory of Operation 4. Theory of Operation
STAMP Session-Sender transmits test packets over UDP transport toward The STAMP Session-Sender transmits test packets over UDP transport
STAMP Session-Reflector. STAMP Session-Reflector receives Session- toward the STAMP Session-Reflector. The STAMP Session-Reflector
Sender's packet and acts according to the configuration. Two modes receives the Session-Sender's packet and acts according to the
of STAMP Session-Reflector characterize the expected behavior and, configuration. Two modes of the STAMP Session-Reflector characterize
consequently, performance metrics that can be measured: the expected behavior and, consequently, performance metrics that can
be measured:
o Stateless - STAMP Session-Reflector does not maintain test state Stateless:
and will use the value in the Sequence Number field in the The STAMP Session-Reflector does not maintain test state and will
received packet as the value for the Sequence Number field in the use the value in the Sequence Number field in the received packet
reflected packet. As a result, values in Sequence Number and as the value for the Sequence Number field in the reflected
Session-Sender Sequence Number fields are the same, and only packet. As a result, values in the Sequence Number and Session-
round-trip packet loss can be calculated while the reflector is Sender Sequence Number fields are the same, and only round-trip
operating in stateless mode. packet loss can be calculated while the reflector is operating in
stateless mode.
o Stateful - STAMP Session-Reflector maintains test state thus Stateful:
enabling the ability to determine forward loss, gaps recognized in STAMP Session-Reflector maintains the test state, thus allowing
the received sequence number. As a result, both near-end the Session-Sender to determine directionality of loss using the
(forward) and far-end (backward) packet loss can be computed. combination of gaps recognized in the Session Sender Sequence
That implies that the STAMP Session-Reflector MUST keep a state Number and Sequence Number fields, respectively. As a result,
for each configured STAMP-test session, uniquely identifying both near-end (forward) and far-end (backward) packet loss can be
STAMP-test packets to one such session instance, and enabling computed. That implies that the STAMP Session-Reflector MUST
adding a sequence number in the test reply that is individually maintain a state for each configured STAMP-Test session, thereby
incremented on a per-session basis. uniquely associating STAMP-Test packets with one such session
instance and, thus, enabling the addition of a sequence number in
the test reply that is individually incremented by one on a per-
session basis.
STAMP supports two authentication modes: unauthenticated and STAMP supports two authentication modes: unauthenticated and
authenticated. Unauthenticated STAMP test packets, defined in authenticated. Unauthenticated STAMP-Test packets, defined in
Section 4.2.1 and Section 4.3.1, ensure interworking between STAMP Sections 4.2.1 and 4.3.1, ensure interworking between STAMP and TWAMP
and TWAMP Light as described in Section 4.6 packet formats. Light, as described in Section 4.6 regarding packet formats.
By default, STAMP uses symmetrical packets, i.e., size of the packet By default, STAMP uses symmetrical packets, i.e., the size of the
transmitted by Session-Reflector equals the size of the packet packet transmitted by the Session-Reflector equals the size of the
received by the Session-Reflector. packet received by the Session-Reflector.
4.1. UDP Port Numbers in STAMP Testing 4.1. UDP Port Numbers in STAMP Testing
A STAMP Session-Sender MUST use UDP port 862 (TWAMP-Test Receiver A STAMP Session-Sender MUST use UDP port 862 (TWAMP-Test Receiver
Port) as the default destination UDP port number. A STAMP Port) as the default destination UDP port number. A STAMP
implementation of Session-Sender MUST be able to use as the implementation of the Session-Sender MUST be able to be used as the
destination UDP port numbers from User, a.k.a. Registered, Ports and destination UDP port numbers from the User Ports (aka Registered
Dynamic, a.k.a. Private or Ephemeral, Ports ranges defined in Ports) and Dynamic Ports (aka Private or Ephemeral Ports) ranges
[RFC6335]. Before using numbers from the User Ports range, the defined in [RFC6335]. Before using numbers from the User Ports
possible impact on the network MUST be carefully studied and agreed range, the possible impact on the network MUST be carefully studied
by all users of the network domain where the test has been planned. and agreed on by all users of the network domain where the test has
been planned.
An implementation of STAMP Session-Reflector by default MUST receive By default, an implementation of the STAMP Session-Reflector MUST
STAMP test packets on UDP port 862. An implementation of Session- receive STAMP-Test packets on UDP port 862. An implementation of the
Reflector that supports this specification MUST be able to define the Session-Reflector that supports this specification MUST be able to
port number to receive STAMP test packets from User Ports and Dynamic define the port number to receive STAMP-Test packets from User Ports
Ports ranges that are defined in [RFC6335]. STAMP defines two and Dynamic Ports ranges, which are defined in [RFC6335]. STAMP
different test packet formats, one for packets transmitted by the defines two different test packet formats: one for packets
STAMP-Session-Sender and one for packets transmitted by the STAMP- transmitted by the STAMP Session-Sender and one for packets
Session-Reflector. transmitted by the STAMP Session-Reflector.
4.2. Session-Sender Behavior and Packet Format 4.2. Session-Sender Behavior and Packet Format
A STAMP Session-Reflector supports the symmetrical size of test A STAMP Session-Reflector supports the symmetrical size of test
packets, as defined in Section 3 [RFC6038], as the default behavior. packets, as defined in Section 3 of [RFC6038], as the default
A reflected test packet includes more information and thus is larger. behavior. A reflected base test packet includes information from the
Because of that, the base STAMP Session-Sender packet is padded to Session-Reflector and, thus, is larger. To maintain the symmetry
match the size of a reflected STAMP test packet. Hence, the base between base STAMP packets, the base STAMP Session-Sender packet
STAMP Session-Sender packet has a minimum size of 44 octets in includes the Must-Be-Zero (MBZ) field to match to the size of a base
unauthenticated mode, see Figure 2, and 112 octets in the reflected STAMP test packet. Hence, the base STAMP Session-Sender
authenticated mode, see Figure 4. The variable length of a test packet has a minimum size of 44 octets in unauthenticated mode (see
packet in STAMP is supported by using Extra Padding TLV defined in Figure 2) and 112 octets in the authenticated mode (see Figure 4).
[I-D.ietf-ippm-stamp-option-tlv]. Generating variable length of a test packet in STAMP is defined in
[STAMP-OPTION].
4.2.1. Session-Sender Packet Format in Unauthenticated Mode 4.2.1. Session-Sender Packet Format in Unauthenticated Mode
STAMP Session-Sender packet format in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| | | |
| Reserved (30 octets) | | MBZ (30 octets) |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: STAMP Session-Sender test packet format in unauthenticated Figure 2: STAMP Session-Sender Test Packet Format in
mode Unauthenticated Mode
where fields are defined as the following: The fields are defined as following:
o Sequence Number is four octets long field. For each new session * The Sequence Number field is four octets long. For each new
its value starts at zero and is incremented with each transmitted session, its value starts at zero and is incremented by one with
packet. each transmitted packet.
o Timestamp is eight octets long field. STAMP node MUST support * The Timestamp field is eight octets long. The STAMP node MUST
Network Time Protocol (NTP) version 4 64-bit timestamp format support the Network Time Protocol (NTP) version 4 64-bit timestamp
[RFC5905], the format used in [RFC5357]. STAMP node MAY support format [RFC5905], the format used in [RFC5357]. The STAMP node
IEEE 1588v2 Precision Time Protocol (PTP) truncated 64-bit MAY support the IEEE 1588v2 Precision Time Protocol (PTP)
timestamp format [IEEE.1588.2008], the format used in [RFC8186]. truncated 64-bit timestamp format [IEEE.1588.2008], the format
The use of the specific format, NTP or PTP, is part of used in [RFC8186]. The use of the specific format, NTP or PTP, is
configuration of the Session-Sender or the particular test part of configuration of the Session-Sender or the particular test
session. session.
o Error Estimate is two octets long field with format displayed in * The Error Estimate field is two octets long with the format
Figure 3 displayed in Figure 3:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier | |S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Error Estimate Format Figure 3: Error Estimate Format
where S, Scale, and Multiplier fields are interpreted as they have The S, Scale, and Multiplier fields are interpreted as they are
been defined in section 4.1.2 [RFC4656]; and Z field - as has been defined in Section 4.1.2 of [RFC4656]. The Z field is interpreted
defined in section 2.3 [RFC8186]: as it is defined in Section 2.3 of [RFC8186]:
* 0 - NTP 64 bit format of a timestamp; 0: NTP 64-bit format of a timestamp
* 1 - PTPv2 truncated format of a timestamp. 1: PTPv2 truncated format of a timestamp
The default behavior of the STAMP Session-Sender and Session- The default behavior of the STAMP Session-Sender and Session-
Reflector is to use the NTP 64-bit timestamp format (Z field value Reflector is to use the NTP 64-bit timestamp format (Z field value
of 0) An operator, using configuration/management function, MAY of 0). An operator using configuration/management function MAY
configure STAMP Session-Sender and Session-Reflector to using the configure the STAMP Session-Sender and Session-Reflector to use
PTPv2 truncated format of a timestamp (Z field value of 1). Note, the PTPv2 truncated format of a timestamp (Z field value of 1).
that an implementation of a Session-Sender that supports this Note that an implementation of a Session-Sender that supports this
specification MAY be configured to use PTPv2 format of a timestamp specification MAY be configured to use the PTPv2 format of a
even though the Session-Reflector is configured to use NTP format. timestamp even though the Session-Reflector is configured to use
NTP format.
o Reserved field in the Session-Sender unauthenticated packet is 30 * The MBZ field in the Session-Sender unauthenticated packet is 30
octets long. It MUST be all zeroed on the transmission and MUST octets long. It MUST be all zeroed on the transmission and MUST
be ignored on receipt. be ignored on receipt.
4.2.2. Session-Sender Packet Format in Authenticated Mode 4.2.2. Session-Sender Packet Format in Authenticated Mode
STAMP Session-Sender packet format in 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) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
skipping to change at page 8, line 29 skipping to change at line 336
~ ~ ~ ~
| MBZ (70 octets) | | MBZ (70 octets) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: STAMP Session-Sender test packet format in authenticated Figure 4: STAMP Session-Sender Test Packet Format in
mode Authenticated Mode
The field definitions are the same as the unauthenticated mode, The field definitions are the same as the unauthenticated mode,
listed in Section 4.2.1. Also, Must-Be-Zero (MBZ) fields are used to listed in Section 4.2.1. Also, MBZ fields are used to make the
to make the packet length a multiple of 16 octets. The value of the packet length a multiple of 16 octets. The value of the field MUST
field MUST be zeroed on transmission and MUST be ignored on receipt. be zeroed on transmission and MUST be ignored on receipt. Note, that
Note, that the MBZ field is used to calculate a key-hashed message both MBZ fields are used to calculate a key hashed message
authentication code (HMAC) ([RFC2104]) hash. Also, the packet authentication code (HMAC) [RFC2104] hash. Also, the packet includes
includes HMAC hash at the end of the PDU. The detailed use of the an HMAC hash at the end of the PDU. The detailed use of the HMAC
HMAC field is described in Section 4.4. field is described in Section 4.4.
4.3. Session-Reflector Behavior and Packet Format 4.3. Session-Reflector Behavior and Packet Format
The Session-Reflector receives the STAMP test packet and verifies it. The Session-Reflector receives the STAMP-Test packet and verifies it.
If the base STAMP test packet validated, the Session-Reflector, that If the base STAMP-Test packet is validated, the Session-Reflector
supports this specification, prepares and transmits the reflected that supports this specification prepares and transmits the reflected
test packet symmetric to the packet received from the Session-Sender test packet symmetric to the packet received from the Session-Sender
copying the content beyond the size of the base STAMP packet (see copying the content beyond the size of the base STAMP packet (see
Section 4.2). Section 4.2).
4.3.1. Session-Reflector Packet Format in Unauthenticated Mode 4.3.1. Session-Reflector Packet Format in Unauthenticated Mode
For 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ | | Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Sequence Number | | Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Timestamp | | Session-Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate | MBZ | | Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL | Reserved | |Ses-Sender TTL | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: STAMP Session-Reflector test packet format in Figure 5: STAMP Session-Reflector Test Packet Format in
unauthenticated mode Unauthenticated Mode
where fields are defined as the following: Fields are defined as the following:
o Sequence Number is four octets long field. The value of the * The Sequence Number field is four octets long. The value of the
Sequence Number field is set according to the mode of the STAMP Sequence Number field is set according to the mode of the STAMP
Session-Reflector: Session-Reflector:
* in the stateless mode, the Session-Reflector copies the value - In the stateless mode, the Session-Reflector copies the value
from the received STAMP test packet's Sequence Number field; from the received STAMP-Test packet's Sequence Number field.
* in the stateful mode, the Session-Reflector counts the - In the stateful mode, the Session-Reflector counts the
transmitted STAMP test packets. It starts with zero and is transmitted STAMP-Test packets. It starts with zero and is
incremented by one for each subsequent packet for each test incremented by one for each subsequent packet for each test
session. The Session-Reflector uses that counter to set the session. The Session-Reflector uses that counter to set the
value of the Sequence Number field. value of the Sequence Number field.
o Timestamp and Receive Timestamp fields are each eight octets long. * The Timestamp and Receive Timestamp fields are each eight octets
The format of these fields, NTP or PTPv2, indicated by the Z field long. The format of these fields, NTP or PTPv2, is indicated by
of the Error Estimate field as described in Section 4.2. Receive the Z field of the Error Estimate field, as described in
Timestamp is the time the test packet was received by the Session- Section 4.2.1. Receive Timestamp is the time the test packet was
Reflector. Timestamp - the time taken by the Session-Reflector at received by the Session-Reflector. Timestamp is the time taken by
the start of transmitting the test packet. the Session-Reflector at the start of transmitting the test
packet.
o Error Estimate has the same size and interpretation as described
in Section 4.2. It is applicable to both Timestamp and Receive
Timestamp.
o Session-Sender Sequence Number, Session-Sender Timestamp, and * The Error Estimate field has the same size and interpretation as
Session-Sender Error Estimate are copies of the corresponding described in Section 4.2.1. It is applicable to both Timestamp
fields in the STAMP test packet sent by the Session-Sender. and Receive Timestamp.
o Session-Sender TTL is one octet long field, and its value is the * The Session-Sender Sequence Number, Session-Sender Timestamp, and
copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the Session-Sender Error Estimate fields are copies of the
received STAMP test packet. corresponding fields in the STAMP-Test packet sent by the Session-
Sender.
o MBZ is used to achieve alignment of fields within the packet on a * The Session-Sender TTL field is one octet long, and its value is
four octets boundary. The value of the field MUST be zeroed on the copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the
transmission and MUST be ignored on receipt. received STAMP-Test packet.
o Reserved field in the Session-Reflector unauthenticated packet is * The MBZ fields are used to achieve alignment of fields within the
three octets long. It MUST be all zeroed on the transmission and packet on a four-octet boundary. The value of each MBZ field MUST
MUST be ignored on receipt. be zeroed on transmission and MUST be ignored on receipt.
4.3.2. Session-Reflector Packet Format in Authenticated Mode 4.3.2. Session-Reflector Packet Format in Authenticated Mode
For the 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) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
skipping to change at page 11, line 31 skipping to change at line 474
| | | |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: STAMP Session-Reflector test packet format in authenticated Figure 6: STAMP Session-Reflector Test Packet Format in
mode Authenticated Mode
The field definitions are the same as the unauthenticated mode, The field definitions are the same as the unauthenticated mode,
listed in Section 4.3.1. Additionally, the MBZ field is used to to listed in Section 4.3.1. Additionally, the MBZ field is used to make
make the packet length a multiple of 16 octets. The value of the the packet length a multiple of 16 octets. The value of the field
field MUST be zeroed on transmission and MUST be ignored on receipt. MUST be zeroed on transmission and MUST be ignored on receipt. Note
Note, that the MBZ field is used to calculate HMAC hash value. Also, that the MBZ field is used to calculate the HMAC hash value. Also,
STAMP Session-Reflector test packet format in authenticated mode the STAMP Session-Reflector test packet format in authenticated mode
includes HMAC ([RFC2104]) hash at the end of the PDU. The detailed includes the HMAC [RFC2104] hash at the end of the PDU. The detailed
use of the HMAC field is in Section 4.4. use of the HMAC field is in Section 4.4.
4.4. Integrity Protection in STAMP 4.4. Integrity Protection in STAMP
Authenticated mode provides integrity protection to each STAMP Authenticated mode provides integrity protection to each STAMP
message by adding Hashed Message Authentication Code (HMAC). STAMP message by adding Hashed Message Authentication Code (HMAC). STAMP
uses HMAC-SHA-256 truncated to 128 bits (similarly to the use of it uses HMAC-SHA-256 truncated to 128 bits (similarly to the use of it
in IPSec defined in [RFC4868]); hence the length of the HMAC field is in IPsec defined in [RFC4868]); hence, the length of the HMAC field
16 octets. In the Authenticated mode, HMAC covers the first six is 16 octets. In the authenticated mode, HMAC covers the first six
blocks (96 octets). HMAC uses its own key that may be unique for blocks (96 octets). HMAC uses its own key, which may be unique for
each STAMP test session; key management and the mechanisms to each STAMP-Test session; key management and the mechanisms to
distribute the HMAC key are outside the scope of this specification. distribute the HMAC key are outside the scope of this specification.
One example is to use an orchestrator to configure HMAC key based on One example is to use an orchestrator to configure the HMAC key based
STAMP YANG data model [I-D.ietf-ippm-stamp-yang]. HMAC MUST be on the STAMP YANG data model [STAMP-YANG]. HMAC MUST be verified as
verified as early as possible to avoid using or propagating corrupted early as possible to avoid using or propagating corrupted data.
data.
Future specifications may define the use of other, more advanced Future specifications may define the use of other, more advanced
cryptographic algorithms, possibly providing an update to the STAMP cryptographic algorithms, possibly providing an update to the STAMP
YANG data model [I-D.ietf-ippm-stamp-yang]. YANG data model [STAMP-YANG].
4.5. Confidentiality Protection in STAMP 4.5. Confidentiality Protection in STAMP
If confidentiality protection for STAMP is required, a STAMP test If confidentiality protection for STAMP is required, a STAMP-Test
session MUST use a secured transport. For example, STAMP packets session MUST use a secured transport. For example, STAMP packets
could be transmitted in the dedicated IPsec tunnel or share the IPsec could be transmitted in the dedicated IPsec tunnel or share the IPsec
tunnel with the monitored flow. Also, Datagram Transport Layer tunnel with the monitored flow. Also, the Datagram Transport Layer
Security protocol would provide the desired confidentiality Security protocol would provide the desired confidentiality
protection. protection.
4.6. Interoperability with TWAMP Light 4.6. Interoperability with TWAMP Light
One of the essential requirements to STAMP is the ability to One of the essential requirements to STAMP is the ability to
interwork with a TWAMP Light device. Because STAMP and TWAMP use interwork with a TWAMP Light device. Because STAMP and TWAMP use
different algorithms in Authenticated mode (HMAC-SHA-256 vs. HMAC- different algorithms in authenticated mode (HMAC-SHA-256 versus HMAC-
SHA-1), interoperability is only considered for Unauthenticated mode. SHA-1), interoperability is only considered for unauthenticated mode.
There are two possible combinations for such use case: There are two possible combinations for such a use case:
o STAMP Session-Sender with TWAMP Light Session-Reflector; * STAMP Session-Sender with TWAMP Light Session-Reflector
o TWAMP Light Session-Sender with STAMP Session-Reflector. * TWAMP Light Session-Sender with STAMP Session-Reflector
In the former case, the Session-Sender might not be aware that its In the former case, the Session-Sender might not be aware that its
Session-Reflector does not support STAMP. For example, a TWAMP Light Session-Reflector does not support STAMP. For example, a TWAMP Light
Session-Reflector may not support the use of UDP port 862 as Session-Reflector may not support the use of UDP port 862, as
specified in [RFC8545]. Thus Section 4. permits a STAMP Session- specified in [RFC8545]. Thus, Section 4 permits a STAMP Session-
Sender to use alternative ports. If any of STAMP extensions are Sender to use alternative ports. If any of STAMP extensions are
used, the TWAMP Light Session-Reflector will view them as Packet used, the TWAMP Light Session-Reflector will view them as the Packet
Padding field. Padding field.
In the latter scenario, if a TWAMP Light Session-Sender does not In the latter scenario, if a TWAMP Light Session-Sender does not
support the use of UDP port 862, the test management system MUST set support the use of UDP port 862, the test management system MUST set
STAMP Session-Reflector to use UDP port number, as permitted by the STAMP Session-Reflector to use UDP port number, as permitted by
Section 4. The Session-Reflector MUST be set to use the default Section 4. The Session-Reflector MUST be set to use the default
format for its timestamps, NTP. format for its timestamps, NTP.
A STAMP Session-Reflector that supports this specification will A STAMP Session-Reflector that supports this specification will
transmit the base packet (Figure 5) if it receives a packet smaller transmit the base packet (Figure 5) if it receives a packet smaller
than the STAMP base packet. If the packet received from TWAMP than the STAMP base packet. If the packet received from the TWAMP
Session-Sender is larger than the STAMP base packet, the STAMP Session-Sender is larger than the STAMP base packet, the STAMP
Session-Reflector that supports this specification will copy the Session-Reflector that supports this specification will copy the
content of the remainder of the received packet to transmit reflected content of the remainder of the received packet to transmit a
packet of symmetrical size. reflected packet of symmetrical size.
5. Operational Considerations 5. Operational Considerations
STAMP is intended to be used on production networks to enable the STAMP is intended to be used on production networks to enable the
operator to assess service level agreements based on packet delay, operator to assess service level agreements based on packet delay,
delay variation, and loss. When using STAMP over the Internet, delay variation, and loss. When using STAMP over the Internet,
especially when STAMP test packets are transmitted with the especially when STAMP-Test packets are transmitted with the
destination UDP port number from the User Ports range, the possible destination UDP port number from the User Ports range, the possible
impact of the STAMP test packets MUST be thoroughly analyzed. The impact of the STAMP-Test packets MUST be thoroughly analyzed. The
use of STAMP for each case MUST be agreed by users of nodes hosting use of STAMP for each case MUST be agreed by users of nodes hosting
the Session-Sender and Session-Reflector before starting the STAMP the Session-Sender and Session-Reflector before starting the STAMP-
test session. Test session.
Also, the use of the well-known port number as the destination UDP Also, the use of the well-known port number as the destination UDP
port number in STAMP test packets transmitted by a Session-Sender port number in STAMP-Test packets transmitted by a Session-Sender
would not impede the ability to measure performance in an Equal Cost would not impede the ability to measure performance in an Equal-Cost
Multipath environment and analysis in Section 5.3 [RFC8545] fully Multipath environment, and analysis in Section 5.3 of [RFC8545] fully
applies to STAMP. applies to STAMP.
6. IANA Considerations 6. IANA Considerations
This document doesn't have any IANA action. This section may be This document has no IANA actions.
removed before the publication.
7. Security Considerations 7. Security Considerations
[RFC5357] does not identify security considerations specific to [RFC5357] does not identify security considerations specific to
TWAMP-Test but refers to security considerations identified for OWAMP TWAMP-Test but refers to security considerations identified for OWAMP
in [RFC4656]. Since both OWAMP and TWAMP include control plane and in [RFC4656]. Since both OWAMP and TWAMP include control-plane and
data plane components, only security considerations related to OWAMP- data-plane components, only security considerations related to OWAMP-
Test, discussed in Sections 6.2, 6.3 [RFC4656] apply to STAMP. Test discussed in Sections 6.2 and 6.3 of [RFC4656] apply to STAMP.
STAMP uses the well-known UDP port number allocated for the OWAMP- STAMP uses the well-known UDP port number allocated for the OWAMP-
Test/TWAMP-Test Receiver port. Thus the security considerations and Test/TWAMP-Test Receiver Port. Thus, the security considerations and
measures to mitigate the risk of the attack using the registered port measures to mitigate the risk of the attack using the registered port
number documented in Section 6 [RFC8545] equally apply to STAMP. number documented in Section 6 of [RFC8545] equally apply to STAMP.
Because of the control and management of a STAMP test being outside Because of the control and management of a STAMP-Test being outside
the scope of this specification only the more general requirement is the scope of this specification, only the more general requirement is
set: set:
To mitigate the possible attack vector, the control, and To mitigate the possible attack vector, the control and management
management of a STAMP test session MUST use the secured transport. of a STAMP-Test session MUST use the secured transport.
The load of the STAMP test packets offered to a network MUST be The load of the STAMP-Test packets offered to a network MUST be
carefully estimated, and the possible impact on the existing carefully estimated, and the possible impact on the existing
services MUST be thoroughly analyzed before launching the test services MUST be thoroughly analyzed before launching the test
session. [RFC8085] section 3.1.5 provides guidance on handling session. Section 3.1.5 of [RFC8085] provides guidance on handling
network load for UDP-based protocol. While the characteristic of network load for UDP-based protocol. While the characteristic of
test traffic depends on the test objective, it is highly test traffic depends on the test objective, it is highly
recommended to stay in the limits as provided in [RFC8085]. recommended to stay in the limits, as provided in [RFC8085].
Use of HMAC-SHA-256 in the authenticated mode protects the data Use of HMAC-SHA-256 in the authenticated mode protects the data
integrity of the STAMP test packets. integrity of the STAMP-Test packets.
8. Acknowledgments
Authors express their appreciation to Jose Ignacio Alvarez-Hamelin
and Brian Weis for their great insights into the security and
identity protection, and the most helpful and practical suggestions.
Also, our sincere thanks to David Ball and Rakesh Gandhi or their
thorough reviews and helpful comments.
9. References
9.1. Normative References 8. References
[I-D.ietf-ippm-stamp-option-tlv] 8.1. Normative References
Mirsky, G., Xiao, M., Jun, G., Nydell, H., Foote, R., and
A. Masputra, "Simple Two-way Active Measurement Protocol
Optional Extensions", draft-ietf-ippm-stamp-option-tlv-01
(work in progress), September 2019.
[IEEE.1588.2008] [IEEE.1588.2008]
"Standard for a Precision Clock Synchronization Protocol IEEE, "IEEE Standard for a Precision Clock Synchronization
for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
IEEE Standard 1588, March 2008. IEEE Standard 1588, July 2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <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>.
skipping to change at page 15, line 42 skipping to change at line 660
Timestamp Format in a Two-Way Active Measurement Protocol Timestamp Format in a Two-Way Active Measurement Protocol
(TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
<https://www.rfc-editor.org/info/rfc8186>. <https://www.rfc-editor.org/info/rfc8186>.
[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port [RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port
Assignments for the One-Way Active Measurement Protocol Assignments for the One-Way Active Measurement Protocol
(OWAMP) and the Two-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol
(TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019,
<https://www.rfc-editor.org/info/rfc8545>. <https://www.rfc-editor.org/info/rfc8545>.
9.2. Informative References 8.2. Informative References
[BBF.TR-390] [BBF.TR-390]
"Performance Measurement from IP Edge to Customer Broadband Forum, "Performance Measurement from IP Edge to
Equipment using TWAMP Light", BBF TR-390, May 2017. Customer Equipment using TWAMP Light", TR-390 Issue 1, May
2017.
[I-D.ietf-ippm-stamp-yang]
Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-
stamp-yang-05 (work in progress), October 2019.
[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>.
[RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated [RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated
Service Code Point and Explicit Congestion Notification Service Code Point and Explicit Congestion Notification
Monitoring in the Two-Way Active Measurement Protocol Monitoring in the Two-Way Active Measurement Protocol
(TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016, (TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016,
<https://www.rfc-editor.org/info/rfc7750>. <https://www.rfc-editor.org/info/rfc7750>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[STAMP-OPTION]
Mirsky, G., Xiao, M., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-way Active Measurement
Protocol Optional Extensions", Work in Progress, Internet-
Draft, draft-ietf-ippm-stamp-option-tlv-03, 21 February
2020, <https://tools.ietf.org/html/draft-ietf-ippm-stamp-
option-tlv-03>.
[STAMP-YANG]
Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", Work in
Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-05,
25 October 2019, <https://tools.ietf.org/html/draft-ietf-
ippm-stamp-yang-05>.
Acknowledgments
The authors express their appreciation to Jose Ignacio Alvarez-
Hamelin and Brian Weis for their great insights into the security and
identity protection as well as the most helpful and practical
suggestions. Also, our sincere thanks to David Ball, Rakesh Gandhi,
and Xiao Min for their thorough reviews and helpful comments.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Guo Jun Guo Jun
ZTE Corporation ZTE Corp.
68# Zijinghua Road 68# Zijinghua Road
Nanjing, Jiangsu 210012 Nanjing
P.R.China Jiangsu, 210012
China
Phone: +86 18105183663 Phone: +86 18105183663
Email: guo.jun2@zte.com.cn Email: guo.jun2@zte.com.cn
Henrik Nydell Henrik Nydell
Accedian Networks Accedian Networks
Email: hnydell@accedian.com Email: hnydell@accedian.com
Richard Foote Richard Foote
 End of changes. 100 change blocks. 
302 lines changed or deleted 303 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/