draft-ietf-ippm-stamp-option-tlv-01.txt   draft-ietf-ippm-stamp-option-tlv-02.txt 
Network Working Group G. Mirsky Network Working Group G. Mirsky
Internet-Draft X. Min Internet-Draft X. Min
Intended status: Standards Track ZTE Corp. Intended status: Standards Track ZTE Corp.
Expires: March 23, 2020 G. Jun Expires: May 3, 2020 H. Nydell
ZTE Corporation
H. Nydell
Accedian Networks Accedian Networks
R. Foote R. Foote
Nokia Nokia
A. Masputra A. Masputra
Apple Inc. Apple Inc.
September 20, 2019 E. Ruffini
OutSys
October 31, 2019
Simple Two-way Active Measurement Protocol Optional Extensions Simple Two-way Active Measurement Protocol Optional Extensions
draft-ietf-ippm-stamp-option-tlv-01 draft-ietf-ippm-stamp-option-tlv-02
Abstract Abstract
This document describes optional extensions to Simple Two-way Active This document describes optional extensions to Simple Two-way Active
Measurement Protocol (STAMP) which enable measurement performance Measurement Protocol (STAMP) which enable measurement performance
metrics in addition to ones supported by the STAMP base metrics in addition to ones supported by the STAMP base
specification. specification.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 March 23, 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 2, line 26 skipping to change at page 2, line 26
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3
4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 4 4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 4
4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 6 4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 6
4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 8 4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 8
4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 9 4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 9
4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 10 4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 10
4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 11 4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 13
5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.2. Synchronization Source Sub-registry . . . . . . . . . . . 13 5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 14
5.3. Timestamping Method Sub-registry . . . . . . . . . . . . 14 5.2. Synchronization Source Sub-registry . . . . . . . . . . . 15
5.4. Access ID Sub-registry . . . . . . . . . . . . . . . . . 15 5.3. Timestamping Method Sub-registry . . . . . . . . . . . . 16
5.5. Return Code Sub-registry . . . . . . . . . . . . . . . . 16 5.4. Access ID Sub-registry . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5.5. Return Code Sub-registry . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Simple Two-way Active Measurement Protocol (STAMP) Simple Two-way Active Measurement Protocol (STAMP)
[I-D.ietf-ippm-stamp] supports the use of optional extensions that [I-D.ietf-ippm-stamp] supports the use of optional extensions that
use Type-Length-Value (TLV) encoding. Such extensions are to enhance use Type-Length-Value (TLV) encoding. Such extensions are to enhance
the STAMP base functions, such as measurement of one-way and round- the STAMP base functions, such as measurement of one-way and round-
trip delay, latency, packet loss, as well as ability to detect packet trip delay, latency, packet loss, as well as ability to detect packet
duplication and out-of-order delivery of the test packets. This duplication and out-of-order delivery of the test packets. This
specification provides definitions of optional STAMP extensions, specification provides definitions of optional STAMP extensions,
skipping to change at page 9, line 7 skipping to change at page 9, line 7
o Length - two octets long field, equals four octets. o Length - two octets long field, equals four octets.
o Sync Src In - one octet long field that characterizes the source o Sync Src In - one octet long field that characterizes the source
of clock synchronization at the ingress of Session-Reflector. of clock synchronization at the ingress of Session-Reflector.
There are several of methods to synchronize the clock, e.g., There are several of methods to synchronize the clock, e.g.,
Network Time Protocol (NTP) [RFC5905], Precision Time Protocol Network Time Protocol (NTP) [RFC5905], Precision Time Protocol
(PTP) [IEEE.1588.2008], Synchronization Supply Unit (SSU) or (PTP) [IEEE.1588.2008], Synchronization Supply Unit (SSU) or
Building Integrated Timing Supply (BITS), or Global Positioning Building Integrated Timing Supply (BITS), or Global Positioning
System (GPS), Global Orbiting Navigation Satellite System System (GPS), Global Orbiting Navigation Satellite System
(GLONASS) and Long Range Navigation System Version C (LORAN-C). (GLONASS) and Long Range Navigation System Version C (LORAN-C).
The value is one of Section 5.2. The value is one of the listed in Table 4.
o Timestamp In - one octet long field that characterizes the method o Timestamp In - one octet long field that characterizes the method
by which the ingress of Session-Reflector obtained the timestamp by which the ingress of Session-Reflector obtained the timestamp
T2. A timestamp may be obtained with hardware assist, via T2. A timestamp may be obtained with hardware assist, via
software API from a local wall clock, or from a remote clock (the software API from a local wall clock, or from a remote clock (the
latter referred to as "control plane"). The value is one of latter referred to as "control plane"). The value is one of the
Section 5.3. listed in Table 6.
o Sync Src Out - one octet long field that characterizes the source o Sync Src Out - one octet long field that characterizes the source
of clock synchronization at the egress of Session-Reflector. The of clock synchronization at the egress of Session-Reflector. The
value is one of Section 5.2. value is one of the listed in Table 4.
o Timestamp Out - one octet long field that characterizes the method o Timestamp Out - one octet long field that characterizes the method
by which the egress of Session-Reflector obtained the timestamp by which the egress of Session-Reflector obtained the timestamp
T3. The value is one of Section 5.3. T3. The value is one of the listed in Table 6.
4.4. Class of Service TLV 4.4. Class of Service TLV
The STAMP session-sender MAY include Class of Service (CoS) TLV in The STAMP session-sender MAY include Class of Service (CoS) TLV in
the STAMP test packet. If the CoS TLV is present in the STAMP test the STAMP test packet. If the CoS TLV is present in the STAMP test
packet and the value of the DSCP1 field is zero, then the STAMP packet and the value of the DSCP1 field is zero, then the STAMP
session-reflector MUST copy the values of Differentiated Services session-reflector MUST copy the values of Differentiated Services
Code Point (DSCP) ECN fields from the received STAMP test packet into Code Point (DSCP) ECN fields from the received STAMP test packet into
DSCP2 and ECN fields respectively of the CoS TLV of the reflected DSCP2 and ECN fields respectively of the CoS TLV of the reflected
STAMP test packet. If the value of the DSCP1 field is non-zero, then STAMP test packet. If the value of the DSCP1 field is non-zero, then
skipping to change at page 12, line 35 skipping to change at page 12, line 35
it reports on. Also, the Session-Sender sets the value of the Return it reports on. Also, the Session-Sender sets the value of the Return
Code field to reflect the operational state of the access network. Code field to reflect the operational state of the access network.
The mechanism to determine the state of the access network is outside The mechanism to determine the state of the access network is outside
the scope of this specification. A STAMP Session-Reflector that the scope of this specification. A STAMP Session-Reflector that
received the test packet with the Access Report TLV MUST include the received the test packet with the Access Report TLV MUST include the
Access Report TLV in the reflected test packet. The Session- Access Report TLV in the reflected test packet. The Session-
Reflector MUST set the value of the Access ID and Return Code fields Reflector MUST set the value of the Access ID and Return Code fields
equal to the values of the corresponding fields from the test packet equal to the values of the corresponding fields from the test packet
it has received. it has received.
The Session-Sender MUST also arm a retransmission timer after sending
a test packet that includes the Access Report TLV. This timer MUST
be disarmed upon the reception of the reflected STAMP test packet
that includes Access Report TLV. In the event the timer expires
before such a packet is received, the Session-Sender MUST retransmit
the STAMP test packet that contains the Access Report TLV. This
retransmission SHOULD be repeated up to four times before the
procedure is aborted. Setting the value for the retransmission timer
is based on local policies, network environment. The default value
of the retransmission timer for Access Report TLV SHOULD be three
seconds. An implementation MUST provide control of the
retransmission timer value and the number of retransmissions.
The Access Report TLV is used by the Performance Measurement Function The Access Report TLV is used by the Performance Measurement Function
(PMF) components of the Access Steering, Switching and Splitting (PMF) components of the Access Steering, Switching and Splitting
feature for 5G networks [TS23501]. The PMF component in the User feature for 5G networks [TS23501]. The PMF component in the User
Equipment acts as the STAMP Session-Sender, and the PMF component in Equipment acts as the STAMP Session-Sender, and the PMF component in
the User Plane Function acts as the STAMP Session-Reflector. the User Plane Function acts as the STAMP Session-Reflector.
4.7. Follow-up Telemetry TLV
A Session-Reflector might be able to put in the Timestamp field only
a "SW Local" (see Table 6) timestamp. But the hosting system might
provide the timestamp closer to the start of actual packet
transmission even though when it is not possible to deliver the
information to the Session-Sender in the packet itself. This
timestamp might nevertheless be important for the Session-Sender, as
it helps in to improve the accuracy of measuring network delay by
minimizing the impact of egress queuing delays on the measurement.
A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to
request information from the Session-Reflector. The Session-Sender
MUST set the Follow-up Telemetry Type and Length fields to their
appropriate values. Sequence Number and Timestamp fields MUST be
zeroed on transmission by the Session-Sender and ignored by the
Session-Reflector upon receipt of the STAMP test packet that includes
the Follow-up Telemetry TLV. The Session-Reflector MUST validate the
Length value of the STAMP test packet. If the value of the Length
field is invalid, the Session-Reflector MUST zero Sequence Number and
Timestamp fields. If the Session-Reflector is in stateless mode
(defined in Section 4.2 [I-D.ietf-ippm-stamp]), it MUST zero Sequence
Number and Timestamp fields.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Follow-up Telemetry Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Follow-up Telemetry TLV
where fields are defined as follows:
o Follow-up Telemetry Type - TBA7 allocated by IANA Section 5.1.
o Length - two octets long field, equals 12 octets.
o Sequence Number - four octets long field indicating the sequence
number of the last packet reflected in the same STAMP-test
session. Since the Session-Reflector runs in the stateful mode
(defined in Section 4.2 [I-D.ietf-ippm-stamp]), it is the Session-
Reflector's Sequence Number of the previous reflected packet.
o Timestamp - eight octets long field, with the format indicated by
the Z flag of the Error Estimate field as described in Section 4.1
[I-D.ietf-ippm-stamp]. It carries the timestamp when the
reflected packet with the specified sequence number was sent..
o Timestamp M(ode) - one octet long field that characterizes the
method by which the entity that transmits a reflected STAMP packet
obtained the timestamp. The value is one of the listed in
Table 6.
o Reserved - the field MUST be zeroed on transmission and ignored on
receipt.
5. IANA Considerations 5. IANA Considerations
5.1. STAMP TLV Registry 5.1. STAMP TLV Registry
IANA is requested to create the STAMP TLV Type registry. All code IANA is requested to create the STAMP TLV Type registry. All code
points in the range 1 through 32759 in this registry shall be points in the range 1 through 32759 in this registry shall be
allocated according to the "IETF Review" procedure as specified in allocated according to the "IETF Review" procedure as specified in
[RFC8126]. Code points in the range 32760 through 65279 in this [RFC8126]. Code points in the range 32760 through 65279 in this
registry shall be allocated according to the "First Come First registry shall be allocated according to the "First Come First
Served" procedure as specified in [RFC8126]. Remaining code points Served" procedure as specified in [RFC8126]. Remaining code points
skipping to change at page 13, line 31 skipping to change at page 15, line 13
registry: registry:
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| TBA1 | Extra Padding | This document | | TBA1 | Extra Padding | This document |
| TBA2 | Location | This document | | TBA2 | Location | This document |
| TBA3 | Timestamp Information | This document | | TBA3 | Timestamp Information | This document |
| TBA4 | Class of Service | This document | | TBA4 | Class of Service | This document |
| TBA6 | Access Report | This document | | TBA6 | Access Report | This document |
| TBA7 | Follow-up Telemetry | This document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
Table 2: STAMP Types Table 2: STAMP Types
5.2. Synchronization Source Sub-registry 5.2. Synchronization Source Sub-registry
IANA is requested to create Synchronization Source sub-registry as IANA is requested to create Synchronization Source sub-registry as
part of STAMP TLV Type registry. All code points in the range 1 part of STAMP TLV Type registry. All code points in the range 1
through 127 in this registry shall be allocated according to the through 127 in this registry shall be allocated according to the
"IETF Review" procedure as specified in [RFC8126]. Code points in "IETF Review" procedure as specified in [RFC8126]. Code points in
skipping to change at page 17, line 16 skipping to change at page 18, line 41
Use of HMAC in authenticated mode may be used to simultaneously Use of HMAC in authenticated mode may be used to simultaneously
verify both the data integrity and the authentication of the STAMP verify both the data integrity and the authentication of the STAMP
test packets. test packets.
7. Acknowledgments 7. Acknowledgments
Authors much appreciate the thorough review and thoughful comments Authors much appreciate the thorough review and thoughful comments
received from Tianran Zhou. received from Tianran Zhou.
8. References 8. Contributors
8.1. Normative References The following people contributed text to this document:
Guo Jun
ZTE Corporation
68# Zijinghua Road
Nanjing, Jiangsu 210012
P.R.China
Phone: +86 18105183663
Email: guo.jun2@zte.com.cn
9. References
9.1. Normative References
[I-D.ietf-ippm-stamp] [I-D.ietf-ippm-stamp]
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-way Active Measurement Protocol", draft-ietf-ippm- Two-way Active Measurement Protocol", draft-ietf-ippm-
stamp-07 (work in progress), August 2019. stamp-09 (work in progress), October 2019.
[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>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008, RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>. <https://www.rfc-editor.org/info/rfc5357>.
skipping to change at page 18, line 5 skipping to change at page 19, line 38
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <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>.
8.2. Informative References 9.2. Informative References
[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.
[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>.
skipping to change at page 18, line 34 skipping to change at page 20, line 22
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Xiao Min Xiao Min
ZTE Corp. ZTE Corp.
Email: xiao.min2@zte.com.cn Email: xiao.min2@zte.com.cn
Guo Jun
ZTE Corporation
68# Zijinghua Road
Nanjing, Jiangsu 210012
P.R.China
Phone: +86 18105183663
Email: guo.jun2@zte.com.cn
Henrik Nydell Henrik Nydell
Accedian Networks Accedian Networks
Email: hnydell@accedian.com Email: hnydell@accedian.com
Richard Foote Richard Foote
Nokia Nokia
Email: footer.foote@nokia.com Email: footer.foote@nokia.com
Adi Masputra Adi Masputra
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
skipping to change at line 843 skipping to change at page 20, line 39
Email: footer.foote@nokia.com Email: footer.foote@nokia.com
Adi Masputra Adi Masputra
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Email: adi@apple.com Email: adi@apple.com
Ernesto Ruffini
OutSys
via Caracciolo, 65
Milano 20155
Italy
Email: eruffini@outsys.org
 End of changes. 19 change blocks. 
36 lines changed or deleted 121 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/