< draft-ietf-ippm-stamp-07.txt   draft-ietf-ippm-stamp-08.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: February 27, 2020 ZTE Corporation
H. Nydell H. Nydell
Accedian Networks Accedian Networks
R. Foote R. Foote
Nokia Nokia
August 12, 2019 August 26, 2019
Simple Two-way Active Measurement Protocol Simple Two-way Active Measurement Protocol
draft-ietf-ippm-stamp-07 draft-ietf-ippm-stamp-08
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 February 27, 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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . . . . 4 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
4.1. Session-Sender Behavior and Packet Format . . . . . . . . 5 4.1. Session-Sender Behavior and Packet Format . . . . . . . . 5
4.1.1. Session-Sender Packet Format in Unauthenticated Mode 5 4.1.1. Session-Sender Packet Format in Unauthenticated Mode 5
4.1.2. Session-Sender Packet Format in Authenticated Mode . 6 4.1.2. Session-Sender Packet Format in Authenticated Mode . 6
4.2. Session-Reflector Behavior and Packet Format . . . . . . 7 4.2. Session-Reflector Behavior and Packet Format . . . . . . 7
4.2.1. Session-Reflector Packet Format in Unauthenticated 4.2.1. Session-Reflector Packet Format in Unauthenticated
Mode . . . . . . . . . . . . . . . . . . . . . . . . 8 Mode . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Session-Reflector Packet Format in Authenticated Mode 9 4.2.2. Session-Reflector Packet Format in Authenticated Mode 9
4.3. Integrity and Confidentiality Protection in STAMP . . . . 10 4.3. Integrity Protection in STAMP . . . . . . . . . . . . . . 10
4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 11 4.4. Confidentiality Protection in STAMP . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.5. Interoperability with TWAMP Light . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Development and deployment of Two-Way Active Measurement Protocol Development and deployment of 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 features such as Reflect Octets and Symmetrical Size for TWAMP
provided invaluable experience. Several independent implementations provided invaluable experience. Several independent implementations
exist, have been deployed and provide important operational of both TWAMP and TWAMP Light exist, have been deployed, and provide
performance measurements. At the same time, there has been important operational performance 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 inherit 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 challenged because the composition
and operation of TWAMP Light were not sufficiently specified in
[RFC5357]. According to [RFC8545], TWAMP Light includes sub-set of
TWAMP-Test functions to provide comprehensive solution 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
skipping to change at page 4, line 47 skipping to change at page 4, line 45
supports this specification MUST be able to define the port number to supports this specification MUST be able to define the port number to
receive STAMP test packets from User Ports and Dynamic Ports ranges receive STAMP test packets from User Ports and Dynamic Ports ranges
that are defined in [RFC6335]. STAMP defines two different test that are defined in [RFC6335]. STAMP defines two different test
packet formats, one for packets transmitted by the STAMP-Session- packet formats, one for packets transmitted by the STAMP-Session-
Sender and one for packets transmitted by the STAMP-Session- Sender and one for packets transmitted by the STAMP-Session-
Reflector. Reflector.
STAMP supports two modes: unauthenticated and authenticated. STAMP supports two modes: unauthenticated and authenticated.
Unauthenticated STAMP test packets, defined in Section 4.1.1 and Unauthenticated STAMP test packets, defined in Section 4.1.1 and
Section 4.2.1, ensure interworking between STAMP and TWAMP Light as Section 4.2.1, ensure interworking between STAMP and TWAMP Light as
described in Section 4.4 packet formats. described in Section 4.5 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. Session-Sender Behavior and Packet Format
Because STAMP supports symmetrical test packets, STAMP Session-Sender Because STAMP supports symmetrical test packets, 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.
skipping to change at page 6, line 7 skipping to change at page 6, line 4
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 truncated 64-bit timestamp
format [IEEE.1588.2008], the format used in [RFC8186]. format [IEEE.1588.2008], the format used in [RFC8186].
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 flag - 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 MAY use, not use,
or set value of the Z field in accordance with the timestamp or set value of the Z flag in accordance with the timestamp format
format in use. This optional field is to enhance operations, but in use. This optional field is to enhance operations, but local
local configuration or defaults could be used in its place. configuration or defaults could be used in its place.
o May-be-Zero (MBZ) field in the session-sender unauthenticated o May-be-Zero (MBZ) field in the session-sender unauthenticated
packet is 30 octets long. It MAY be all zeroed on the packet is 30 octets long. It MAY be all zeroed on the
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
4.1.2. Session-Sender Packet Format in Authenticated Mode 4.1.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
skipping to change at page 10, line 41 skipping to change at page 10, line 41
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.2.1. Additionally, the MBZ field is used to
align the packet on 16 octets boundary. The value of the field MAY align the packet on 16 octets boundary. The value of the field MAY
be zeroed on transmission and MUST be ignored on receipt. Also, be zeroed on transmission and MUST be ignored on receipt. 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 a key (HMAC) ([RFC2104]) hash at the end of the PDU. The
detailed use of the HMAC field is in Section 4.3. detailed use of the HMAC field is in Section 4.3.
4.3. Integrity and Confidentiality Protection in STAMP 4.3. Integrity Protection in STAMP
To provide integrity protection, each STAMP message is being To provide integrity protection, each STAMP message is being
authenticated by adding Hashed Message Authentication Code (HMAC). authenticated by adding Hashed Message Authentication Code (HMAC).
STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use
of it in IPSec defined in [RFC4868]); hence the length of the HMAC of it in IPSec defined in [RFC4868]); hence the length of the HMAC
field is 16 octets. HMAC uses its own key, and the definition of the field is 16 octets. HMAC uses its own key, and the definition of the
mechanism to distribute the HMAC key is outside the scope of this mechanism to distribute the HMAC key is outside the scope of this
specification. One example is to use an orchestrator to configure 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 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 HMAC MUST be verified as early as possible to avoid using or
propagating corrupted data. propagating corrupted data.
If confidentiality protection for STAMP is required, encryption at 4.4. 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.5. 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. There are two possible
combinations for such use case: 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 MAY not be aware that its
 End of changes. 19 change blocks. 
47 lines changed or deleted 48 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/