< draft-ietf-ippm-stamp-07.txt | draft-ietf-ippm-stamp-09.txt > | |||
---|---|---|---|---|
Network Working Group G. Mirsky | Network Working Group G. Mirsky | |||
Internet-Draft ZTE Corp. | Internet-Draft ZTE Corp. | |||
Intended status: Standards Track G. Jun | Intended status: Standards Track G. Jun | |||
Expires: February 13, 2020 ZTE Corporation | Expires: April 18, 2020 ZTE Corporation | |||
H. Nydell | H. Nydell | |||
Accedian Networks | Accedian Networks | |||
R. Foote | R. Foote | |||
Nokia | Nokia | |||
August 12, 2019 | October 16, 2019 | |||
Simple Two-way Active Measurement Protocol | Simple Two-way Active Measurement Protocol | |||
draft-ietf-ippm-stamp-07 | draft-ietf-ippm-stamp-09 | |||
Abstract | Abstract | |||
This document describes a Simple Two-way Active Measurement Protocol | This document describes a Simple Two-way Active Measurement Protocol | |||
which enables the measurement of both one-way and round-trip | which enables the measurement of both one-way and round-trip | |||
performance metrics like delay, delay variation, and packet loss. | 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 Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
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 February 13, 2020. | This Internet-Draft will expire on April 18, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 14 ¶ | skipping to change at page 2, line 14 ¶ | |||
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 | |||
2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
3. Softwarization of Performance Measurement . . . . . . . . . . 3 | 3. Operation and Management of Performance Measurement Based on | |||
STAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | ||||
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Session-Sender Behavior and Packet Format . . . . . . . . 5 | 4.1. UDP Port Numbers in STAMP Testing . . . . . . . . . . . . 5 | |||
4.1.1. Session-Sender Packet Format in Unauthenticated Mode 5 | 4.2. Session-Sender Behavior and Packet Format . . . . . . . . 5 | |||
4.1.2. Session-Sender Packet Format in Authenticated Mode . 6 | 4.2.1. Session-Sender Packet Format in Unauthenticated Mode 5 | |||
4.2. Session-Reflector Behavior and Packet Format . . . . . . 7 | 4.2.2. Session-Sender Packet Format in Authenticated Mode . 7 | |||
4.2.1. Session-Reflector Packet Format in Unauthenticated | 4.3. Session-Reflector Behavior and Packet Format . . . . . . 8 | |||
Mode . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.3.1. Session-Reflector Packet Format in Unauthenticated | |||
4.2.2. Session-Reflector Packet Format in Authenticated Mode 9 | Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.3. Integrity and Confidentiality Protection in STAMP . . . . 10 | 4.3.2. Session-Reflector Packet Format in Authenticated Mode 10 | |||
4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 11 | 4.4. Integrity Protection in STAMP . . . . . . . . . . . . . . 11 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 4.5. Confidentiality Protection in STAMP . . . . . . . . . . . 12 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 4.6. Interoperability with TWAMP Light . . . . . . . . . . . . 12 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 13 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 14 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 | ||||
9.2. Informative References . . . . . . . . . . . . . . . . . 15 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
1. Introduction | 1. Introduction | |||
Development and deployment of 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] that defined | |||
features such as Reflect Octets and Symmetrical Size for TWAMP | Symmetrical Size for TWAMP, provided invaluable experience. Several | |||
provided invaluable experience. Several independent implementations | independent implementations of both TWAMP and TWAMP Light exist, have | |||
exist, have been deployed and provide important operational | been deployed, and provide important operational performance | |||
performance measurements. At the same time, there has been | measurements. | |||
noticeable interest in using a more straightforward mechanism for | ||||
active performance monitoring that can provide deterministic behavior | ||||
and inherit separation of control (vendor-specific configuration or | ||||
orchestration) and test functions. One of such is Performance | ||||
Measurement from IP Edge to Customer Equipment using TWAMP Light from | ||||
Broadband Forum [BBF.TR-390] used as the reference TWAMP Light that, | ||||
according to [RFC8545], includes sub-set of TWAMP-Test functions in | ||||
combination with other applications that provide, for example, | ||||
control and security. This document defines an active performance | ||||
measurement test protocol, Simple Two-way Active Measurement Protocol | ||||
(STAMP), that enables measurement of both one-way and round-trip | ||||
performance metrics like delay, delay variation, and packet loss. | ||||
Some TWAMP extensions, e.g., [RFC7750] are supported by the | ||||
extensions to STAMP base specification in | ||||
[I-D.ietf-ippm-stamp-option-tlv]. | ||||
2. Conventions used in this document | ||||
2.1. Terminology | ||||
AES Advanced Encryption Standard | At the same time, there has been noticeable interest in using a more | |||
straightforward mechanism for active performance monitoring that can | ||||
provide deterministic behavior and inherent separation of control | ||||
(vendor-specific configuration or orchestration) and test functions. | ||||
Recent work on IP Edge to Customer Equipment using TWAMP Light from | ||||
Broadband Forum [BBF.TR-390] demonstrated that interoperability among | ||||
implementations of TWAMP Light is difficult because the composition | ||||
and operation of TWAMP Light were not sufficiently specified in | ||||
[RFC5357]. According to [RFC8545], TWAMP Light includes a sub-set of | ||||
TWAMP-Test functions. Thus, to have a comprehensive tool to measure | ||||
packet loss and delay requires support by other applications that | ||||
provide, for example, control and security. | ||||
CBC Cipher Block Chaining | This document defines an active performance measurement test | |||
protocol, Simple Two-way Active Measurement Protocol (STAMP), that | ||||
enables measurement of both one-way and round-trip performance | ||||
metrics like delay, delay variation, and packet loss. Some TWAMP | ||||
extensions, e.g., [RFC7750] are supported by the extensions to STAMP | ||||
base specification in [I-D.ietf-ippm-stamp-option-tlv]. | ||||
ECB Electronic Cookbook | 2. Conventions used in this document | |||
KEK Key-encryption Key | 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 May be Zero | MBZ Must be Zero | |||
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 BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Softwarization of Performance Measurement | 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. The configuration and management of the STAMP Session- | session. In this document, a measurement session also referred to as | |||
Sender, Session-Reflector, and management of the STAMP sessions can | STAMP session, is the bi-directional packet flow between one specific | |||
be achieved through various means. Command Line Interface, OSS/BSS | Session-Sender and one particular Session-Reflector for a time | |||
(operations support system/business support system as a combination | duration. The configuration and management of the STAMP Session- | |||
of two systems used to support a range of telecommunication services) | Sender, Session-Reflector, and management of the STAMP sessions are | |||
using SNMP or controllers in Software-Defined Networking using | outside the scope of this document and can be achieved through | |||
Netconf/YANG are but a few examples. | various means. A few examples are: Command Line Interface, | |||
telecommunication services' OSS/BSS systems, SNMP, and Netconf/YANG- | ||||
based 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 | STAMP Session-Sender transmits test packets over UDP transport toward | |||
STAMP Session-Reflector. A STAMP Session-Sender MUST use UDP port | STAMP Session-Reflector. STAMP Session-Reflector receives Session- | |||
862 (TWAMP-Test Receiver Port) as the default destination UDP port | Sender's packet and acts according to the configuration. Two modes | |||
number. A STAMP implementation of Session-Sender MUST be able to use | of STAMP Session-Reflector characterize the expected behavior and, | |||
UDP port numbers from User, a.k.a. Registered, Ports and Dynamic, | consequently, performance metrics that can be measured: | |||
a.k.a. Private or Ephemeral, Ports ranges defined in [RFC6335]. | ||||
Before using numbers from the User Ports range, the possible impact | ||||
on the network MUST be carefully studied and agreed by all users of | ||||
the network. | ||||
STAMP Session-Reflector receives Session-Sender's packet and acts | o Stateless - STAMP Session-Reflector does not maintain test state | |||
according to the configuration and optional control information | and will use the value in the Sequence Number field in the | |||
communicated in the Session-Sender's test packet. An implementation | received packet as the value for the Sequence Number field in the | |||
of STAMP Session-Reflector by default MUST use receive STAMP test | reflected packet. As a result, values in Sequence Number and | |||
packets on UDP port 862. An implementation of Session-Reflector that | Session-Sender Sequence Number fields are the same, and only | |||
supports this specification MUST be able to define the port number to | round-trip packet loss can be calculated while the reflector is | |||
receive STAMP test packets from User Ports and Dynamic Ports ranges | operating in stateless mode. | |||
that are defined in [RFC6335]. STAMP defines two different test | ||||
packet formats, one for packets transmitted by the STAMP-Session- | ||||
Sender and one for packets transmitted by the STAMP-Session- | ||||
Reflector. | ||||
STAMP supports two modes: unauthenticated and authenticated. | o Stateful - STAMP Session-Reflector maintains test state thus | |||
Unauthenticated STAMP test packets, defined in Section 4.1.1 and | enabling the ability to determine forward loss, gaps recognized in | |||
Section 4.2.1, ensure interworking between STAMP and TWAMP Light as | the received sequence number. As a result, both near-end | |||
described in Section 4.4 packet formats. | (forward) and far-end (backward) packet loss can be computed. | |||
That implies that the STAMP Session-Reflector MUST keep a state | ||||
for each configured STAMP-test session, uniquely identifying | ||||
STAMP-test packets to one such session instance, and enabling | ||||
adding a sequence number in the test reply that is individually | ||||
incremented on a per-session basis. | ||||
STAMP supports two authentication modes: unauthenticated and | ||||
authenticated. Unauthenticated STAMP test packets, defined in | ||||
Section 4.2.1 and Section 4.3.1, ensure interworking between STAMP | ||||
and TWAMP Light as described in Section 4.6 packet formats. | ||||
By default, STAMP uses symmetrical packets, i.e., size of the packet | By default, STAMP uses symmetrical packets, i.e., size of the packet | |||
transmitted by Session-Reflector equals the size of the packet | transmitted by Session-Reflector equals the size of the packet | |||
received by the Session-Reflector. | received by the Session-Reflector. | |||
4.1. Session-Sender Behavior and Packet Format | 4.1. UDP Port Numbers in STAMP Testing | |||
Because STAMP supports symmetrical test packets, STAMP Session-Sender | A STAMP Session-Sender MUST use UDP port 862 (TWAMP-Test Receiver | |||
Port) as the default destination UDP port number. A STAMP | ||||
implementation of Session-Sender MUST be able to use as the | ||||
destination UDP port numbers from User, a.k.a. Registered, Ports and | ||||
Dynamic, a.k.a. Private or Ephemeral, Ports ranges defined in | ||||
[RFC6335]. Before using numbers from the User Ports range, the | ||||
possible impact on the network MUST be carefully studied and agreed | ||||
by all users of the network domain where the test has been planned. | ||||
An implementation of STAMP Session-Reflector by default MUST receive | ||||
STAMP test packets on UDP port 862. An implementation of Session- | ||||
Reflector that supports this specification MUST be able to define the | ||||
port number to receive STAMP test packets from User Ports and Dynamic | ||||
Ports ranges that are defined in [RFC6335]. STAMP defines two | ||||
different test packet formats, one for packets transmitted by the | ||||
STAMP-Session-Sender and one for packets transmitted by the STAMP- | ||||
Session-Reflector. | ||||
4.2. Session-Sender Behavior and Packet Format | ||||
A STAMP Session-Reflector supports the symmetrical size of test | ||||
packets [RFC6038] as the default behavior. A reflected test packet | ||||
includes more information and thus is larger. Because of that, the | ||||
base STAMP Session-Sender packet is padded to match the size of a | ||||
reflected STAMP test packet. Hence, the base STAMP Session-Sender | ||||
packet has a minimum size of 44 octets in unauthenticated mode, see | packet has a minimum size of 44 octets in unauthenticated mode, see | |||
Figure 2, and 112 octets in the authenticated mode, see Figure 4. | Figure 2, and 112 octets in the authenticated mode, see Figure 4. | |||
The variable length of a test packet in STAMP is supported by using | ||||
Extra Padding TLV defined in [I-D.ietf-ippm-stamp-option-tlv]. | ||||
4.1.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: | 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 | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
| | | | | | |||
| MBZ (30 octets) | | | Reserved (30 octets) | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: STAMP Session-Sender test packet format in unauthenticated | Figure 2: STAMP Session-Sender test packet format in unauthenticated | |||
mode | mode | |||
where fields are defined as the following: | where fields are defined as the following: | |||
o Sequence Number is four octets long field. For each new session | o Sequence Number is four octets long field. For each new session | |||
its value starts at zero and is incremented with each transmitted | its value starts at zero and is incremented with each transmitted | |||
packet. | packet. | |||
o Timestamp is eight octets long field. STAMP node MUST support | o Timestamp is eight octets long field. STAMP node MUST support | |||
Network Time Protocol (NTP) version 4 64-bit timestamp format | Network Time Protocol (NTP) version 4 64-bit timestamp format | |||
[RFC5905], the format used in [RFC5357]. STAMP node MAY support | [RFC5905], the format used in [RFC5357]. STAMP node MAY support | |||
IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp | IEEE 1588v2 Precision Time Protocol (PTP) truncated 64-bit | |||
format [IEEE.1588.2008], the format used in [RFC8186]. | timestamp format [IEEE.1588.2008], the format used in [RFC8186]. | |||
The use of the specific format, NTP or PTP, is part of | ||||
configuration of the Session-Sender or the particular test | ||||
session. | ||||
o Error Estimate is two octets long field with format displayed in | o Error Estimate is two octets long field with format displayed in | |||
Figure 3 | 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 | where S, Scale, and Multiplier fields are interpreted as they have | |||
been defined in section 4.1.2 [RFC4656]; and Z field - as has been | been defined in section 4.1.2 [RFC4656]; and Z field - as has been | |||
defined in section 2.3 [RFC8186]: | defined in section 2.3 [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 STAMP Session-Sender and Session-Reflector MAY use, not use, | The STAMP Session-Sender and Session-Reflector MUST use the NTP 64 | |||
or set value of the Z field in accordance with the timestamp | bits format of a timestamp (Z field value of 0), as the default. | |||
format in use. This optional field is to enhance operations, but | An operator, using configuration/management function, MAY | |||
local configuration or defaults could be used in its place. | configure STAMP Session-Sender and Session-Reflector to using the | |||
PTPv2 truncated format of a timestamp (Z field value of 1). Note, | ||||
that an implementation of a Session-Sender that supports this | ||||
specification MAY be configured to use PTPv2 format of a timestamp | ||||
even though the Session-Reflector is configured to use NTP format. | ||||
o May-be-Zero (MBZ) field in the session-sender unauthenticated | o Reserved field in the Session-Sender unauthenticated packet is 30 | |||
packet is 30 octets long. It MAY be all zeroed on the | octets long. It MUST be all zeroed on the transmission and MUST | |||
transmission and MUST be ignored on receipt. | be ignored on receipt. | |||
4.1.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: | 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) | | |||
skipping to change at page 7, line 33 ¶ | skipping to change at page 8, line 33 ¶ | |||
| | | | | | |||
| 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 authenticated | |||
mode | 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.1.1. Also, MBZ fields are used to align the | listed in Section 4.2.1. Also, Must-Be-Zero (MBZ) fields are used to | |||
packet on 16 octets boundary. The value of the field MAY be zeroed | to make the packet length a multiple of 16 octets. The value of the | |||
on transmission and MUST be ignored on receipt. Also, the packet | field MUST be zeroed on transmission and MUST be ignored on receipt. | |||
includes a key-hashed message authentication code (HMAC) ([RFC2104]) | Note, that the MBZ field is used to calculate a key-hashed message | |||
hash at the end of the PDU. The detailed use of the HMAC field is | authentication code (HMAC) ([RFC2104]) hash. Also, the packet | |||
described in Section 4.3. | includes HMAC hash at the end of the PDU. The detailed use of the | |||
HMAC field is described in Section 4.4. | ||||
4.2. Session-Reflector Behavior and Packet Format | ||||
The Session-Reflector receives the STAMP test packet, verifies it, | ||||
prepares and transmits the reflected test packet. | ||||
Two modes of STAMP Session-Reflector characterize the expected | ||||
behavior and, consequently, performance metrics that can be measured: | ||||
o Stateless - STAMP Session-Reflector does not maintain test state | 4.3. Session-Reflector Behavior and Packet Format | |||
and will reflect the received sequence number without | ||||
modification. As a result, only round-trip packet loss can be | ||||
calculated while the reflector is operating in stateless mode. | ||||
o Stateful - STAMP Session-Reflector maintains test state thus | The Session-Reflector receives the STAMP test packet and verifies it. | |||
enabling the ability to determine forward loss, gaps recognized in | If the base STAMP test packet validated, the Session-Reflector, that | |||
the received sequence number. As a result, both near-end | supports this specification, prepares and transmits the reflected | |||
(forward) and far-end (backward) packet loss can be computed. | test packet symmetric to the packet received from the Session-Sender | |||
That implies that the STAMP Session-Reflector MUST keep a state | copying the content beyond the size of the base STAMP packet (see | |||
for each accepted STAMP-test session, uniquely identifying STAMP- | Section 4.2). | |||
test packets to one such session instance, and enabling adding a | ||||
sequence number in the test reply that is individually incremented | ||||
on a per-session basis. | ||||
4.2.1. Session-Reflector Packet Format in Unauthenticated Mode | 4.3.1. Session-Reflector Packet Format in Unauthenticated Mode | |||
For 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 | | |||
| | | | | | |||
skipping to change at page 8, line 39 ¶ | skipping to change at page 9, line 29 ¶ | |||
| 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 | MBZ | | |Ses-Sender TTL | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
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: | where fields are defined as the following: | |||
o Sequence Number is four octets long field. The value of the | o Sequence Number is four octets long field. 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 received | * in the stateful mode, the Session-Reflector counts the | |||
STAMP test packets in each test session and uses that counter | transmitted STAMP test packets. It starts with zero and is | |||
to set the value of the Sequence Number field. | incremented by one for each subsequent packet for each test | |||
session. The Session-Reflector uses that counter to set the | ||||
value of the Sequence Number field. | ||||
o Timestamp and Receiver Timestamp fields are each eight octets | o Timestamp and Receive Timestamp fields are each eight octets long. | |||
long. The format of these fields, NTP or PTPv2, indicated by the | The format of these fields, NTP or PTPv2, indicated by the Z field | |||
Z flag of the Error Estimate field as described in Section 4.1. | of the Error Estimate field as described in Section 4.2. Receive | |||
Timestamp is the time the test packet was received by the Session- | ||||
Reflector. Timestamp - the time taken by the Session-Reflector at | ||||
the start of transmitting the test packet. | ||||
o Error Estimate has the same size and interpretation as described | o Error Estimate has the same size and interpretation as described | |||
in Section 4.1. | in Section 4.2. It is applicable to both Timestamp and Receive | |||
Timestamp. | ||||
o Session-Sender Sequence Number, Session-Sender Timestamp, and | o Session-Sender Sequence Number, Session-Sender Timestamp, and | |||
Session-Sender Error Estimate are copies of the corresponding | Session-Sender Error Estimate are copies of the corresponding | |||
fields in the STAMP test packet sent by the Session-Sender. | fields in the STAMP test packet sent by the Session-Sender. | |||
o Session-Sender TTL is one octet long field, and its value is the | o Session-Sender TTL is one octet long field, and its value is the | |||
copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the | copy of the TTL field in IPv4 (or Hop Limit in IPv6) from the | |||
received STAMP test packet. | received STAMP test packet. | |||
o MBZ is used to achieve alignment on a four octets boundary. The | o MBZ is used to achieve alignment of fields within the packet on a | |||
value of the field MAY be zeroed on transmission and MUST be | four octets boundary. The value of the field MUST be zeroed on | |||
ignored on receipt. | transmission and MUST be ignored on receipt. | |||
4.2.2. Session-Reflector Packet Format in Authenticated Mode | o Reserved field in the Session-Reflector unauthenticated packet is | |||
three octets long. It MUST be all zeroed on the transmission and | ||||
MUST be ignored on receipt. | ||||
4.3.2. Session-Reflector Packet Format in Authenticated Mode | ||||
For the 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) | | |||
| | | | | | |||
skipping to change at page 10, line 34 ¶ | skipping to change at page 11, line 35 ¶ | |||
| 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 authenticated | |||
mode | 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. Additionally, the MBZ field is used to | listed in Section 4.3.1. Additionally, the MBZ field is used to to | |||
align the packet on 16 octets boundary. The value of the field MAY | make the packet length a multiple of 16 octets. The value of the | |||
be zeroed on transmission and MUST be ignored on receipt. Also, | field MAY be zeroed on transmission and MUST be ignored on receipt. | |||
Note, that the MBZ field is used to calculate HMAC hash value. Also, | ||||
STAMP Session-Reflector test packet format in authenticated mode | STAMP Session-Reflector test packet format in authenticated mode | |||
includes a key (HMAC) ([RFC2104]) hash at the end of the PDU. The | includes HMAC ([RFC2104]) hash at the end of the PDU. The detailed | |||
detailed use of the HMAC field is in Section 4.3. | use of the HMAC field is in Section 4.4. | |||
4.3. Integrity and Confidentiality Protection in STAMP | 4.4. Integrity Protection in STAMP | |||
To provide integrity protection, each STAMP message is being | Authenticated mode provides integrity protection to each STAMP | |||
authenticated by adding Hashed Message Authentication Code (HMAC). | message by adding Hashed Message Authentication Code (HMAC). STAMP | |||
STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use | uses HMAC-SHA-256 truncated to 128 bits (similarly to the use of it | |||
of it in IPSec defined in [RFC4868]); hence the length of the HMAC | in IPSec defined in [RFC4868]); hence the length of the HMAC field is | |||
field is 16 octets. HMAC uses its own key, and the definition of the | 16 octets. In the Authenticated mode, HMAC covers the first six | |||
mechanism to distribute the HMAC key is outside the scope of this | blocks (96 octets). HMAC uses its own key that may be unique for | |||
specification. One example is to use an orchestrator to configure | each STAMP test session; key management and the mechanisms to | |||
HMAC key based on STAMP YANG data model [I-D.ietf-ippm-stamp-yang]. | distribute the HMAC key is outside the scope of this specification. | |||
One example is to use an orchestrator to configure HMAC key based on | ||||
STAMP YANG data model [I-D.ietf-ippm-stamp-yang]. HMAC MUST be | ||||
verified as early as possible to avoid using or propagating corrupted | ||||
data. | ||||
HMAC MUST be verified as early as possible to avoid using or | Future specifications may define the use of other, more advanced | |||
propagating corrupted data. | cryptographic algorithms, possibly providing an update to the STAMP | |||
YANG data model [I-D.ietf-ippm-stamp-yang]. | ||||
If confidentiality protection for STAMP is required, encryption at | 4.5. Confidentiality Protection in STAMP | |||
the higher level MUST be used. For example, STAMP packets could be | ||||
transmitted in the dedicated IPsec tunnel or share the IPsec tunnel | ||||
with the monitored flow. | ||||
4.4. Interoperability with TWAMP Light | If confidentiality protection for STAMP is required, a STAMP test | |||
session MUST use a secured transport. For example, STAMP packets | ||||
could be transmitted in the dedicated IPsec tunnel or share the IPsec | ||||
tunnel with the monitored flow. Also, Datagram Transport Layer | ||||
Security protocol would provide the desired confidentiality | ||||
protection. | ||||
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. There are two possible | interwork with a TWAMP Light device. Because STAMP and TWAMP use | |||
combinations for such use case: | different algorithms in Authenticated mode (HMAC-SHA-256 vs. HMAC- | |||
SHA-1), interoperability is only considered for Unauthenticated mode. | ||||
There are two possible combinations for such use case: | ||||
o STAMP Session-Sender with TWAMP Light Session-Reflector; | o STAMP Session-Sender with TWAMP Light Session-Reflector; | |||
o TWAMP Light Session-Sender with STAMP Session-Reflector. | o TWAMP Light Session-Sender with STAMP Session-Reflector. | |||
In the former case, the Session-Sender MAY 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 defined | Session-Reflector may not support the use of UDP port 862 as | |||
in [RFC8545]. Thus STAMP Session-Sender MAY use port numbers as | specified in [RFC8545]. Thus Section 4. permits a STAMP Session- | |||
defined in Section 4. If any of STAMP extensions are used, the TWAMP | Sender to use alternative ports. If any of STAMP extensions are | |||
Light Session-Reflector will view them as Packet Padding field. The | used, the TWAMP Light Session-Reflector will view them as Packet | |||
Session-Sender SHOULD use the default format for its timestamps - | Padding field. | |||
NTP. And it MAY use PTPv2 timestamp format. | ||||
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 defined in | STAMP Session-Reflector to use UDP port number, as permitted by | |||
Section 4. If the TWAMP Light Session-Sender includes Packet Padding | Section 4. The Session-Reflector MUST be set to use the default | |||
field in its transmitted packet, the STAMP Session-Reflector will | format for its timestamps, NTP. | |||
return the reflected packet of the symmetrical size if the size of | ||||
the received test packet is larger than the size of the STAMP base | ||||
packet. The Session-Reflector MUST be set to use the default format | ||||
for its timestamps, NTP. | ||||
STAMP does not support the Reflect Octets capability defined in | A STAMP Session-Reflector that supports this specification would | |||
transmit the base packet (Figure 5) regardless of the size of the | ||||
Padding field in the packet received from TWAMP Session-Sender. | ||||
Also, STAMP does not support the Reflect Octets capability defined in | ||||
[RFC6038]. If the Server Octets field is present in the TWAMP | [RFC6038]. If the Server Octets field is present in the TWAMP | |||
Session-Sender packet, STAMP Session-Reflector will not copy the | Session-Sender packet, STAMP Session-Reflector will not copy the | |||
content starting from the Server Octets field but will transmit the | content starting from the Server Octets field and will transmit the | |||
reflected packet of equal size. | reflected packet, as displayed in Figure 5. | |||
5. IANA Considerations | 5. Operational Considerations | |||
STAMP is intended to be used on production networks to enable the | ||||
operator to assess service level agreements based on packet delay, | ||||
delay variation, and loss. When using STAMP over the Internet, | ||||
especially when STAMP test packets are transmitted with the | ||||
destination UDP port number from the User Ports range, the possible | ||||
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 | ||||
the Session-Sender and Session-Reflector before starting the STAMP | ||||
test session. | ||||
Also, the use of the well-known port number as the destination UDP | ||||
port number in STAMP test packets transmitted by a Session-Sender | ||||
would not impede the ability to measure performance in an Equal Cost | ||||
Multipath environment and analysis in Section 5.3 [RFC8545] fully | ||||
applies to STAMP. | ||||
6. IANA Considerations | ||||
This document doesn't have any IANA action. This section may be | This document doesn't have any IANA action. This section may be | |||
removed before the publication. | removed before the publication. | |||
6. Security Considerations | 7. Security Considerations | |||
In general, all the security considerations related to TWAMP-Test, | [RFC5357] does not identify security considerations specific to | |||
discussed in [RFC5357] apply to STAMP. Since STAMP uses the well- | TWAMP-Test but refers to security considerations identified for OWAMP | |||
known UDP port number allocated for the OWAMP-Test/TWAMP-Test | in [RFC4656]. Since both OWAMP and TWAMP include control plane and | |||
Receiver port, the security considerations and measures to mitigate | data plane components, only security considerations related to OWAMP- | |||
the risk of the attack using the registered port number documented in | Test, discussed in Sections 6.2, 6.3 [RFC4656] apply to STAMP. | |||
Section 6 [RFC8545] equally apply to STAMP. Because of the control | ||||
and management of a STAMP test being outside the scope of this | STAMP uses the well-known UDP port number allocated for the OWAMP- | |||
specification only the more general requirement is set: | Test/TWAMP-Test Receiver port. Thus the security considerations and | |||
measures to mitigate the risk of the attack using the registered port | ||||
number documented in Section 6 [RFC8545] equally apply to STAMP. | ||||
Because of the control and management of a STAMP test being outside | ||||
the scope of this specification only the more general requirement is | ||||
set: | ||||
To mitigate the possible attack vector, the control, and | To mitigate the possible attack vector, the control, and | |||
management of a STAMP test session MUST use the secured transport. | management of a STAMP test session MUST use the secured transport. | |||
Load of STAMP test packets offered to a network MUST be carefully | The load of the STAMP test packets offered to a network MUST be | |||
estimated, and the possible impact on the existing services MUST | carefully estimated, and the possible impact on the existing | |||
be thoroughly analyzed before launching the test session. | services MUST be thoroughly analyzed before launching the test | |||
[RFC8085] section 3.1.5 provides guidance on handling network load | session. [RFC8085] section 3.1.5 provides guidance on handling | |||
for UDP-based protocol. While the characteristic of test traffic | network load for UDP-based protocol. While the characteristic of | |||
depends on the test objective, it is highly recommended to stay in | test traffic depends on the test objective, it is highly | |||
the limits as provided in [RFC8085]. | recommended to stay in the limits as provided in [RFC8085]. | |||
STAMP test packets can be transmitted with the destination UDP port | ||||
number from the User Ports range, as defined in Section 4, that is | ||||
already or will be assigned by IANA. The possible impact of the | ||||
STAMP test packets on the network MUST be thoroughly analyzed, and | ||||
the use of STAMP for each case MUST be agreed by all users on the | ||||
network before starting the STAMP test session. | ||||
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. | |||
7. Acknowledgments | 8. Acknowledgments | |||
Authors express their appreciation to Jose Ignacio Alvarez-Hamelin | Authors express their appreciation to Jose Ignacio Alvarez-Hamelin | |||
and Brian Weis for their great insights into the security and | and Brian Weis for their great insights into the security and | |||
identity protection, and the most helpful and practical suggestions. | identity protection, and the most helpful and practical suggestions. | |||
Also, our sincere thanks to David Ball and Rakesh Gandhi or their | Also, our sincere thanks to David Ball and Rakesh Gandhi or their | |||
thorough reviews and helpful comments. | thorough reviews and helpful comments. | |||
8. References | 9. References | |||
8.1. Normative References | 9.1. Normative References | |||
[I-D.ietf-ippm-stamp-option-tlv] | ||||
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 | "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- | ||||
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>. | |||
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. | |||
Zekauskas, "A One-way Active Measurement Protocol | Zekauskas, "A One-way Active Measurement Protocol | |||
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, | (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, | |||
<https://www.rfc-editor.org/info/rfc4656>. | <https://www.rfc-editor.org/info/rfc4656>. | |||
skipping to change at page 14, line 5 ¶ | skipping to change at page 15, line 42 ¶ | |||
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>. | |||
8.2. Informative References | 9.2. Informative References | |||
[BBF.TR-390] | [BBF.TR-390] | |||
"Performance Measurement from IP Edge to Customer | "Performance Measurement from IP Edge to Customer | |||
Equipment using TWAMP Light", BBF TR-390, May 2017. | Equipment using TWAMP Light", BBF TR-390, May 2017. | |||
[I-D.ietf-ippm-stamp-option-tlv] | ||||
Mirsky, G., Xiao, M., Jun, G., Nydell, H., and R. Foote, | ||||
"Simple Two-way Active Measurement Protocol Optional | ||||
Extensions", draft-ietf-ippm-stamp-option-tlv-00 (work in | ||||
progress), July 2019. | ||||
[I-D.ietf-ippm-stamp-yang] | [I-D.ietf-ippm-stamp-yang] | |||
Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active | Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active | |||
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- | Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- | |||
stamp-yang-03 (work in progress), March 2019. | stamp-yang-04 (work in progress), September 2019. | |||
[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>. | ||||
[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, | |||
End of changes. 62 change blocks. | ||||
216 lines changed or deleted | 277 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/ |