draft-ietf-ippm-stamp-00.txt   draft-ietf-ippm-stamp-01.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: July 8, 2018 ZTE Corporation Expires: September 2, 2018 ZTE Corporation
H. Nydell H. Nydell
Accedian Networks Accedian Networks
January 4, 2018 R. Foote
Nokia
March 1, 2018
Simple Two-way Active Measurement Protocol Simple Two-way Active Measurement Protocol
draft-ietf-ippm-stamp-00 draft-ietf-ippm-stamp-01
Abstract Abstract
This document describes a Two-way Active Measurement Protocol which This document describes a Simple Two-way Active Measurement Protocol
enables measurement of both one-way and round-trip performance which enables measurement of both one-way and round-trip performance
metrics like delay, delay variation and packet loss. 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2018. This Internet-Draft will expire on September 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
2. Conventions used in this document . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Softwarization of Performance Measurement . . . . . . . . . . 3 3. Softwarization of Performance Measurement . . . . . . . . . . 3
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
4.1. Sender Behavior and Packet Format . . . . . . . . . . . . 4 4.1. Session-Sender Behavior and Packet Format . . . . . . . . 4
4.1.1. Sender Packet Format in Unauthenticated Mode . . . . 4 4.1.1. Session-Sender Packet Format in Unauthenticated Mode 4
4.1.2. Sender Packet Format in Authenticated and Encrypted 4.1.2. Session-Sender Packet Format in Authenticated and
Modes . . . . . . . . . . . . . . . . . . . . . . . . 6 Encrypted Modes . . . . . . . . . . . . . . . . . . . 7
4.2. Reflector Behavior and Packet Format . . . . . . . . . . 7 4.2. Session-Reflector Behavior and Packet Format . . . . . . 8
4.2.1. Reflector Packet Format in Unauthenticated Mode . . . 7 4.2.1. Session-Reflector Packet Format in Unauthenticated
4.2.2. Reflector Packet Format in Authenticated and Mode . . . . . . . . . . . . . . . . . . . . . . . . 9
Encrypted Modes . . . . . . . . . . . . . . . . . . . 8 4.2.2. Session-Reflector Packet Format in Authenticated and
5. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 9 Encrypted Modes . . . . . . . . . . . . . . . . . . . 10
5.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 10 4.3. Interoperability with TWAMP Light . . . . . . . . . . . . 12
5.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Synchronization Source Sub-registry . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
6.3. Timestamp Method Sub-registry . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. CoS Operation Sub-registry . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Development and deployment of Two-Way Active Measurement Protocol
(TWAMP) [RFC5357] and its extensions, e.g. [RFC6038] that defined
features such as Reflect Octets and Symmetrical Size for TWAMP,
provided invaluable experience. Several independent implementations
exist, have been deployed and provide important operational
performance measurements. At the same time there has been noticeable
interest in using a simpler mechanism for active performance
monitoring that can provide deterministic behaviour 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]). This document defines 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.
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
OWAMP One-Way Active Measurement Protocol
TWAMP Two-Way Active Measurement Protocol
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. Softwarization of Performance Measurement
Instance of a Simple Two-way Active Measurement Protocol (STAMP) Figure 1 presents Simple Two-way Active Measurement Protocol (STAMP)
session between a Sender and a Reflector controlled by communication Session-Sender and Session-Reflector with a measurement session. The
between a Configuration Client as a manager and Configuration Servers configuration and management of the STAMP Session-Sender, Session-
as agents of the configuration session that configures STAMP Reflector and management of the STAMP sessions can be achieved
measurement between Sender and Reflector. The Configuration Client through various means. Command Line Interface, OSS/BSS using SNMP or
also issues queries to obtain operational state information and/or SDN using Netconf/YANG are but a few examples.
measurement results.
o----------------------------------------------------------o o----------------------------------------------------------o
| Config client | | Configuration and |
| Management |
o----------------------------------------------------------o o----------------------------------------------------------o
|| || || ||
|| NETCONF/RESTCONF || || ||
|| || || ||
o-------------------o o-------------------o +----------------------+ +-------------------------+
| Config server | | Config server | | STAMP Session-Sender | <--- STAMP---> | STAMP Session-Reflector |
| | | | +----------------------+ +-------------------------+
+-------------------+ +-------------------+
| STAMP Sender | <--- STAMP---> | STAMP Reflector |
+-------------------+ +-------------------+
Figure 1: STAMP Reference Model Figure 1: STAMP Reference Model
4. Theory of Operation 4. Theory of Operation
STAMP Sender transmits test packets toward STAMP Reflector. STAMP STAMP Session-Sender transmits test packets toward STAMP Session-
Reflector receives Sender's packet and acts according to the Reflector. STAMP Session-Reflector receives Session-Sender's packet
configuration and optional control information communicated in the and acts according to the configuration and optional control
Sender's test packet. STAMP defines two different test packet information communicated in the Session-Sender's test packet. STAMP
formats, one for packets transmitted by the STAMP-Sender and one for defines two different test packet formats, one for packets
packets transmitted by the STAMP-Reflector. STAMP supports three transmitted by the STAMP-Session-Sender and one for packets
transmitted by the STAMP-Session-Reflector. STAMP supports three
modes: unauthenticated, authenticated, and encrypted. modes: unauthenticated, authenticated, and encrypted.
Unauthenticated STAMP test packets are compatible on the wire with Unauthenticated STAMP test packets are compatible on the wire with
unauthenticated TWAMP-Test [RFC5357] packet formats. unauthenticated TWAMP-Test [RFC5357] 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 Reflector equals to the size of the packet received by transmitted by Session-Reflector equals to the size of the packet
the Reflector. received by the Session-Reflector.
4.1. Sender Behavior and Packet Format 4.1. Session-Sender Behavior and Packet Format
4.1.1. Sender Packet Format in Unauthenticated Mode 4.1.1. Session-Sender Packet Format in Unauthenticated Mode
Because STAMP supports symmetrical test packets, STAMP Sender packet Because STAMP supports symmetrical test packets, STAMP Session-Sender
has minimum size of 44 octets in unauthenticated mode, see Figure 2, packet has minimum size of 44 octets in unauthenticated mode, see
and 48 octets in authenticated or encrypted modes , see Figure 4. Figure 2, and 48 octets in authenticated or encrypted modes , see
Figure 4.
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 4, line 38 skipping to change at page 5, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| | | |
| MBZ (27 octets) | | MBZ (27 octets) |
| | | |
| | | |
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Server Octets | | | | Server Octets | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Remaining Packet Padding (to be reflected) | | Remaining Packet Padding (to be reflected) |
~ (length in octets specified in command) ~ ~ (length in octets specified in Server Octets) ~
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| | Comp.MBZ | | | Comp.MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: STAMP Sender test packet format in unauthenticated mode Figure 2: STAMP Session-Sender test packet format in unauthenticated
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]. STAMP node MAY support IEEE 1588v2 Precision Time [RFC5905]. STAMP node MAY support IEEE 1588v2 Precision Time
skipping to change at page 5, line 33 skipping to change at page 6, line 20
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.
o Must-be-Zero (MBZ) field in the sender unauthenticated packet is The STAMP Session-Sender and Session-Reflector MAY use, not use,
27 octets long. It MUST be all zeroed on transmission and ignored or set value of the Z field in accordance with the timestamp
on receipt. format in use. This optional field is to enhance operations but
local configuration or defaults could be used in its place.
o Must-be-Zero (MBZ) field in the session-sender unauthenticated
packet is 27 octets long. It MUST be all zeroed on transmission
and ignored on receipt.
o Server Octets field is two octets long field. It MUST follow the o Server Octets field is two octets long field. It MUST follow the
27 octets long MBZ field. The Reflect Octets capability defined 27 octets long MBZ field. The Reflect Octets capability defined
in [RFC6038]. The value in the Server Octets field equals to the in [RFC6038]. The value in the Server Octets field equals to the
number of octets the Reflector is expected to copy back to the number of octets the Session-Reflector is expected to copy back to
Sender starting with the Server Octets field. Thus the minimal the Session-Sender starting with the Server Octets field. Thus
non-zero value for the Server Octets field is two and value of one the minimal non-zero value for the Server Octets field is two and
is invalid. If none of Payload to be copied the value of the value of one is invalid. If none of Payload to be copied the
Server Octets field MUST be set to zero on transmit. value of the Server Octets field MUST be set to zero on transmit.
o Remaining Packet Padding is optional field of variable length. o Remaining Packet Padding is optional field of variable length.
The number of octets in the Remaining Packet Padding field is the The number of octets in the Remaining Packet Padding field is the
value of the Server Octets field less the length of the Server value of the Server Octets field less the length of the Server
Octets field. Octets field.
o Comp.MBZ is variable length field used to achieve alignment on o Comp.MBZ is variable length field used to achieve alignment on
word boundary. Thus the length of Comp.MBZ field may be only 0, word boundary. Thus the length of Comp.MBZ field may be only 0,
1, 2 or 3 octets. The value of the field MUST be zeroed on 1, 2 or 3 octets. The value of the field MUST be zeroed on
transmission and ignored on receipt. transmission and ignored on receipt.
The unauthenticated STAMP Sender packet MAY include Type-Length-Value The unauthenticated STAMP Session-Sender packet MAY include Type-
encodings that immediately follow the Comp. MBZ field. Length-Value encodings that immediately follow the Comp. MBZ field.
o Type field is two octets long. The value of the Type field is the o Type field is two octets long. The value of the Type field is the
codepoint allocated by IANA Section 6 that identifies data in the codepoint allocated by IANA Section 5 that identifies data in the
Value field. Value field.
o Length is two octets long field and its value is the length of the o Length is two octets long field and its value is the length of the
Value field in octets. Value field in octets.
4.1.2. Sender Packet Format in Authenticated and Encrypted Modes o Value field contains the application specific information. The
length of the Value field MUST be four octets aligned.
4.1.2. Session-Sender Packet Format in Authenticated and Encrypted
Modes
For authenticated and encrypted modes: For authenticated and encrypted modes:
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 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) | ~ ~
| MBZ (70 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Comp.MBZ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: STAMP Sender test packet format in authenticated or Figure 4: STAMP Session-Sender test packet format in authenticated or
encrypted modes encrypted modes
4.2. Reflector Behavior and Packet Format The field definitions are the same as the unauthenticated mode,
listed in Section 4.1.1. In addition, Commp.MBZ field is variable
length filed to align the packet on 16 octets boundary. Also, the
packet includes a key-hashed message authentication code (HMAC)
([RFC2104]) hash at the end of the PDU.
The Reflector receives the STAMP test packet, verifies it, prepares The STAMP Session-Sender-packet format (Figure 4) is the same in
and transmits the reflected test packet. [Editor note: Verification authenticated and encrypted modes. The encryption and authentication
may include presence and content of TLVs in the STAMP test packet.] operations are, however, different and protect the data as following:
4.2.1. Reflector Packet Format in Unauthenticated Mode in authenticated mode the Sequence Number is protected while the
Timestamp and the Error Estimate are sent in clear text;
in encrypted mode all fields, including the timestamp and Error
Estimate, are protected to provide maximum data confidentiality
and integrity protection.
Sending the Timestamp in clear text in authenticated mode allows more
consistent reading of time by a Session-Sender on the transmission of
the test packet. Reading of the time in encrypted mode must be
followed by its encryption which introduces variable delay thus
affecting calculated timing metrics.
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 expected behavior
and, consequently, performance metrics that can be measured:
o Stateless - STAMP Session-Reflector does not maintain test state
and will reflect back 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
determining forward loss, gaps recognized in the received sequence
number. This means both near-end (forward) and far-end (backward)
packet loss can be computed. This implies that the STAMP Session-
Reflector MUST keep a state for each accepted 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.
4.2.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 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ | | Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number | | Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Session-Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ | | Session-Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | | |Ses-Sender TTL | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
| | | |
~ Packet Padding (reflected) ~ ~ Packet Padding (reflected) ~
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| | Comp.MBZ | | | Comp.MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: STAMP Reflector test packet format in unauthenticated mode Figure 5: STAMP Session-Reflector test packet format in
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
Reflector: Session-Reflector:
* in the stateless mode the Reflector copies the value from the * in the stateless mode the Session-Reflector copies the value
received STAMP test packet's Sequence Number field; from the received STAMP test packet's Sequence Number field;
* in the stateful mode the Reflector counts the received STAMP * in the stateful mode the Session-Reflector counts the received
test packets in each test session and uses that counter to set STAMP test packets in each test session and uses that counter
value of the Sequence Number field. to set value of the Sequence Number field.
o Timestamp and Receiver Timestamp fields are each 8 octets long. o Timestamp and Receiver Timestamp fields are each 8 octets long.
The format of these fields, NTP or PTPv2, indicated by the Z flag The format of these fields, NTP or PTPv2, indicated by the Z flag
of the Error Estimate field as described in Section 4.1. of the Error Estimate field as described in Section 4.1.
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.1.
o Sender Sequence Number, Sender Timestamp, and Sender Error o Session-Sender Sequence Number, Session-Sender Timestamp, and
Estimate are copies of the corresponding fields in the STAMP test Session-Sender Error Estimate are copies of the corresponding
packet send by the Sender. fields in the STAMP test packet send by the Session-Sender.
o Sender TTL is one octet long field and its value is the copy of o Ses(sion)-Sender TTL is one octet long field and its value is the
the TTL field from the received STAMP test packet. copy of the TTL field from the received STAMP test packet.
o Packet Padding (reflected) is optional variable length field. The o Packet Padding (reflected) is optional variable length field. The
length of the Packet Padding (reflected) field MUST be equal to length of the Packet Padding (reflected) field MUST be equal to
the value of the Server Octets field (Figure 2). If the value is the value of the Server Octets field (Figure 2). If the value is
non-zero, the Reflector copies octets starting with the Server non-zero, the Session-Reflector copies octets starting with the
Octets field. Server Octets field.
o Comp.MBZ is variable length field used to achieve alignment on o Comp.MBZ is variable length field used to achieve alignment on
word boundary. Thus the length of Comp.MBZ field may be only 0, word boundary. Thus the length of Comp.MBZ field may be only 0,
1, 2 or 3 octets. The value of the field MUST be zeroed on 1, 2 or 3 octets. The value of the field MUST be zeroed on
transmission and ignored on receipt. transmission and ignored on receipt.
4.2.2. Reflector Packet Format in Authenticated and Encrypted Modes 4.2.2. Session-Reflector Packet Format in Authenticated and Encrypted
Modes
For authenticated and encrypted modes: For authenticated and encrypted modes:
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 9, line 18 skipping to change at page 11, line 12
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) | | MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp | | Receive Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number | | Session-Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp | | Session-Sender Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | | | Session-Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) | | MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | | |Ses-Sender TTL | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
| | | |
| |
| MBZ (15 octets) | | MBZ (15 octets) |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| HMAC (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
Figure 6: STAMP Reflector test packet format in authenticated or
encrypted modes
5. TLV Extensions to STAMP
TBA
5.1. Extra Padding TLV
TBA
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extra Padding Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extra Padding ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
Figure 7: Extra Padding TLV
where fields are defined as the following:
o Extra Padding Type - TBA1 allocated by IANA Section 6.1
o Length - 2 octets long field equals length on the Extra Padding
field in octets.
o Extra Padding - pseudo-random sequence of numbers. The field MAY
be filled with all zeroes.
5.2. Location TLV
STAMP sender MAY include the Location TLV to request information from
the reflector. The sender SHOULD NOT fill any information fields
except for Type and Length. The reflector MUST validate the Length
value against address family of the transport encapsulating the STAMP
test packet. If the value of the Length field is invalid, the
reflector MUST zero all fields and MUST NOT return any information to
the sender. The reflector MUST ignore all other fields of the
received Location TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest.port | Src.Port | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Reflector Location TLV
where fields are defined as the following:
o Location Type - TBA1 allocated by IANA Section 6.1
o Length - 2 octets long field equals length on the Value field in
octets. Length field value MUST be 20 octets for IPv4 address
family. For IPv6 address family value of the Length field MUST be
44 octets. All other values are invalid
o Source MAC - 6 octets 48 bits long field. The reflector MUST copy
Source MAC of received STAMP packet into this field.
o MBZ - two octets long field. MUST be zeroed on transmission and
ignored on reception.
o Destination IP Address - IPv4 or IPv6 destination address of the
received by the reflector STAMP packet.
o Source IP Address - IPv4 or IPv6 source address of the received by
the reflector STAMP packet.
o Dest.port - one octet long UDP destination port number of the
received STAMP packet.
o Src.port - one octet long UDP source port number of the received
STAMP packet.
5.3. Timestamp Information TLV
STAMP sender MAY include the Timestamp Information TLV to request
information from the reflector. The sender SHOULD NOT fill any
information fields except for Type and Length. The reflector MUST
validate the Length value of the STAMP test packet. If the value of
the Length field is invalid, the reflector MUST zero all fields and
MUST NOT return any information to the sender.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Information Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source | Timestamp Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
Figure 9: Timestamp Information TLV
where fields are defined as the following:
o Timestamp Information Type - TBA1 allocated by IANA Section 6.1
o Length - 2 octets long field, equals 4 octets.
o Synchronization Source - two octets long field that characterizes
the source of clock synchronization at the reflector. The value
is one of Section 6.2.
o Timestamp Method - two octets long field that characterizes
timestamping method at the reflector. The value is one of
Section 6.3. [Ed.note: Should it be split for ingress and
egress?]
5.4. Class of Service TLV
The STAMP sender MAY include Class of Service TLV in the STAMP test
packet. If the Class of Service TLV is present in the STAMP test
packet and the value of the Op field equals Report (TBA5) value
Section 6.4, then the STAMP reflector MUST copy DSCP and ECN values
from the received STAMP test packet into DSCP and ECN fields of the
Class of Service TLV of the reflected STAMP test packet. If the
value of the Op field equals Set and Report (TBA6) Section 6.4, then
the STAMP reflector MUST use DSCP value from the Class of Service TLV
in the received STAMP test packet as DSCP value of STAMP reflected
test packet and MUST copy DSCP and ECN values of the received STAMP
test packet into DSCP and ECN fields of Class of Service TLV in the
STAMP reflected packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class of Service Type | Length | ~ Comp.MBZ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |ECN|Op | MBZ | | HMAC (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Class of Service TLV Figure 6: STAMP Session-Reflector test packet format in authenticated
or encrypted modes
where fields are defined as the following:
o
6. IANA Considerations
6.1. STAMP TLV Registry The field definitions are the same as the unauthenticated mode,
listed in Section 4.2.1, and includes a key-hashed message
authentication code (HMAC) ([RFC2104]) hash at the end of the PDU.
IANA is requested to create STAMP TLV Type registry. All code points 4.3. Interoperability with TWAMP Light
in the range 1 through 32759 in this registry shall be allocated
according to the "IETF Review" procedure as specified in [RFC8126].
Code points in the range 32760 through 65279 in this registry shall
be allocated according to the "First Come First Served" procedure as
specified in [RFC8126]. Remaining code points are allocated
according to the Table 1:
+---------------+--------------+-------------------------+ One of important requirements to STAMP is ability to interwork with
| Value | Description | Reference | TWAMP Light device. There are two possible combinations for such use
+---------------+--------------+-------------------------+ case:
| 0 | Reserved | This document |
| 1- 32759 | Unassigned | IETF Review |
| 32760 - 65279 | Unassigned | First Come First Served |
| 65280 - 65519 | Experimental | This document |
| 65520 - 65534 | Private Use | This document |
| 65535 | Reserved | This document |
+---------------+--------------+-------------------------+
Table 1: STAMP TLV Type Registry o STAMP Session-Sender with TWAMP Light Session-Reflector;
This document defines the following new values in STAMP TLV Type o TWAMP Light Session-Sender with STAMP Session-Reflector.
registry:
+-------+-----------------------+---------------+ In the former case, Session-Sender MAY not be aware that its Session-
| Value | Description | Reference | Reflector does not support STAMP. For example, TWAMP Light Session-
+-------+-----------------------+---------------+ Reflector may not support use of UDP port 862 as defined in
| TBA1 | Extra Padding | This document | [I-D.ietf-ippm-port-twamp-test]. But because STAMP Session-Sender
| TBA2 | Location | This document | MUST be able to send test packets to destination UDP port number from
| TBA3 | Timestamp Information | This document | the Dynamic and/or Private Ports range 49152-65535, test management
| TBA4 | Class of Service | This document | system should find port number that both devices can use. And if any
+-------+-----------------------+---------------+ of TLV-based STAMP extensions are used, the TWAMP Light Session-
Reflector will view them as Packet Padding field. The Session-Sender
SHOULD use the default format for its timestamps - NTP. And it MAY
use PTPv2 timestamp format.
Table 2: STAMP Types In the latter scenario, test management system should set STAMP
Session-Reflector to use UDP port number from the Dynamic and/or
Private Ports range. As for Packet Padding field that the TWAMP
Light Session-Sender includes in its transmitted packet, the STAMP
Session-Reflector will process it according to [RFC6038] and return
reflected packet of the symmetrical size. The Session-Reflector MUST
use the default format for its timestamps - NTP.
6.2. Synchronization Source Sub-registry 5. IANA Considerations
TBD This document doesn't have any IANA action. This section may be
removed before the publication.
6.3. Timestamp Method Sub-registry 6. Security Considerations
TBD Use of HMAC in authenticated and encrypted modes may be used to
simultaneously verify both the data integrity and the authentication
of the STAMP test packets.
6.4. CoS Operation Sub-registry 7. Acknowledgments
TBD TBD
7. Security Considerations 8. References
TBD
8. Acknowledgments 8.1. Normative References
TBD [BBF.TR-390]
"Performance Measurement from IP Edge to Customer
Equipment using TWAMP Light", BBF TR-390, May 2017.
9. Normative References [I-D.ietf-ippm-port-twamp-test]
Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port
Assignments", draft-ietf-ippm-port-twamp-test-00 (work in
progress), January 2018.
[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.
[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 20 skipping to change at page 13, line 48
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<https://www.rfc-editor.org/info/rfc6038>. <https://www.rfc-editor.org/info/rfc6038>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588
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>.
8.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
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 Corporation
68# Zijinghua Road 68# Zijinghua Road
skipping to change at page 16, line 4 skipping to change at page 14, line 32
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Guo Jun Guo Jun
ZTE Corporation ZTE Corporation
68# Zijinghua Road 68# Zijinghua Road
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
P.R.China P.R.China
Phone: +86 18105183663 Phone: +86 18105183663
Email: guo.jun2@zte.com.cn Email: guo.jun2@zte.com.cn
Henrik Nydell Henrik Nydell
Accedian Networks Accedian Networks
Email: hnydell@accedian.com Email: hnydell@accedian.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
 End of changes. 73 change blocks. 
310 lines changed or deleted 245 lines changed or added

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