< 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/ |