draft-ietf-ippm-stamp-09.txt   draft-ietf-ippm-stamp-10.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: April 20, 2020 ZTE Corporation Expires: May 3, 2020 ZTE Corporation
H. Nydell H. Nydell
Accedian Networks Accedian Networks
R. Foote R. Foote
Nokia Nokia
October 18, 2019 October 31, 2019
Simple Two-way Active Measurement Protocol Simple Two-way Active Measurement Protocol
draft-ietf-ippm-stamp-09 draft-ietf-ippm-stamp-10
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 April 20, 2020. This Internet-Draft will expire on May 3, 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 5, line 37 skipping to change at page 5, line 37
Reflector that supports this specification MUST be able to define the Reflector that supports this specification MUST be able to define the
port number to receive STAMP test packets from User Ports and Dynamic port number to receive STAMP test packets from User Ports and Dynamic
Ports ranges that are defined in [RFC6335]. STAMP defines two Ports ranges that are defined in [RFC6335]. STAMP defines two
different test packet formats, one for packets transmitted by the different test packet formats, one for packets transmitted by the
STAMP-Session-Sender and one for packets transmitted by the STAMP- STAMP-Session-Sender and one for packets transmitted by the STAMP-
Session-Reflector. Session-Reflector.
4.2. Session-Sender Behavior and Packet Format 4.2. Session-Sender Behavior and Packet Format
A STAMP Session-Reflector supports the symmetrical size of test A STAMP Session-Reflector supports the symmetrical size of test
packets [RFC6038] as the default behavior. A reflected test packet packets, as defined in Section 3 [RFC6038], as the default behavior.
includes more information and thus is larger. Because of that, the A reflected test packet includes more information and thus is larger.
base STAMP Session-Sender packet is padded to match the size of a Because of that, the base STAMP Session-Sender packet is padded to
reflected STAMP test packet. Hence, the base STAMP Session-Sender match the size of a reflected STAMP test packet. Hence, the base
packet has a minimum size of 44 octets in unauthenticated mode, see STAMP Session-Sender packet has a minimum size of 44 octets in
Figure 2, and 112 octets in the authenticated mode, see Figure 4. unauthenticated mode, see Figure 2, and 112 octets in the
The variable length of a test packet in STAMP is supported by using authenticated mode, see Figure 4. The variable length of a test
Extra Padding TLV defined in [I-D.ietf-ippm-stamp-option-tlv]. packet in STAMP is supported by using Extra Padding TLV defined in
[I-D.ietf-ippm-stamp-option-tlv].
4.2.1. Session-Sender Packet Format in Unauthenticated Mode 4.2.1. Session-Sender Packet Format in Unauthenticated Mode
STAMP Session-Sender packet format in unauthenticated mode: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 50 skipping to change at page 12, line 50
Sender to use alternative ports. If any of STAMP extensions are Sender to use alternative ports. If any of STAMP extensions are
used, the TWAMP Light Session-Reflector will view them as Packet used, the TWAMP Light Session-Reflector will view them as Packet
Padding field. Padding field.
In the latter scenario, if a TWAMP Light Session-Sender does not In the latter scenario, if a TWAMP Light Session-Sender does not
support the use of UDP port 862, the test management system MUST set support the use of UDP port 862, the test management system MUST set
STAMP Session-Reflector to use UDP port number, as permitted by STAMP Session-Reflector to use UDP port number, as permitted by
Section 4. The Session-Reflector MUST be set to use the default Section 4. The Session-Reflector MUST be set to use the default
format for its timestamps, NTP. format for its timestamps, NTP.
A STAMP Session-Reflector that supports this specification would A STAMP Session-Reflector that supports this specification will
transmit the base packet (Figure 5) regardless of the size of the transmit the base packet (Figure 5) if it receives a packet smaller
Padding field in the packet received from TWAMP Session-Sender. than the STAMP base packet. If the packet received from TWAMP
Also, STAMP does not support the Reflect Octets capability defined in Session-Sender is larger than the STAMP base packet, the STAMP
[RFC6038]. If the Server Octets field is present in the TWAMP Session-Reflector that supports this specification will copy the
Session-Sender packet, STAMP Session-Reflector will not copy the content of the remainder of the received packet to transmit reflected
content starting from the Server Octets field and will transmit the packet of symmetrical size.
reflected packet, as displayed in Figure 5.
5. Operational Considerations 5. Operational Considerations
STAMP is intended to be used on production networks to enable the STAMP is intended to be used on production networks to enable the
operator to assess service level agreements based on packet delay, operator to assess service level agreements based on packet delay,
delay variation, and loss. When using STAMP over the Internet, delay variation, and loss. When using STAMP over the Internet,
especially when STAMP test packets are transmitted with the especially when STAMP test packets are transmitted with the
destination UDP port number from the User Ports range, the possible destination UDP port number from the User Ports range, the possible
impact of the STAMP test packets MUST be thoroughly analyzed. The impact of the STAMP test packets MUST be thoroughly analyzed. The
use of STAMP for each case MUST be agreed by users of nodes hosting use of STAMP for each case MUST be agreed by users of nodes hosting
skipping to change at page 15, line 51 skipping to change at page 15, line 51
9.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-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-04 (work in progress), September 2019. stamp-yang-05 (work in progress), October 2019.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated [RFC7750] Hedin, J., Mirsky, G., and S. Baillargeon, "Differentiated
Service Code Point and Explicit Congestion Notification Service Code Point and Explicit Congestion Notification
Monitoring in the Two-Way Active Measurement Protocol Monitoring in the Two-Way Active Measurement Protocol
(TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016, (TWAMP)", RFC 7750, DOI 10.17487/RFC7750, February 2016,
 End of changes. 7 change blocks. 
21 lines changed or deleted 21 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/