< draft-wang-ippm-stamp-hbh-extensions-01.txt   draft-wang-ippm-stamp-hbh-extensions-02.txt >
IP Performance Measurement Group Y. Wang IP Performance Measurement Group Y. Wang
Internet-Draft T. Zhou Internet-Draft T. Zhou
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: April 30, 2021 October 27, 2020 Expires: May 19, 2021 H. Yang
China Mobile
C. Liu
China Unicom
November 15, 2020
Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM
Data Collection Data Collection
draft-wang-ippm-stamp-hbh-extensions-01 draft-wang-ippm-stamp-hbh-extensions-02
Abstract Abstract
This document defines optional TLVs which are carried in Simple Two- This document defines optional TLVs which are carried in Simple Two-
way Active Measurement Protocol (STAMP) test packets to enhance the way Active Measurement Protocol (STAMP) test packets to enhance the
STAMP base functions. Such extensions to STAMP enable OAM data STAMP base functions. Such extensions to STAMP enable OAM data
measurement and collection at every node and link along a STAMP test measurement and collection at every node and link along a STAMP test
packet's delivery path. packet's delivery path without maintaining a state for each
configured STAMP-Test session at every devices.
Requirements Language 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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 41 skipping to change at page 1, line 46
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 30, 2021. This Internet-Draft will expire on May 19, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 18 skipping to change at page 2, line 26
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 3 3. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 3
3.1. IOAM Tracing Data TLV . . . . . . . . . . . . . . . . . . 3 3.1. IOAM Tracing Data TLV . . . . . . . . . . . . . . . . . . 3
3.2. Forward HbH Delay TLV . . . . . . . . . . . . . . . . . . 4 3.2. Forward HbH Delay TLV . . . . . . . . . . . . . . . . . . 5
3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7 3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3.4. HbH Packet Loss TLV . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3.5. HbH Bandwidth Utilization TLV . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. HbH Timestamp Information TLV . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] enables Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] enables
the measurement of both one-way and round-trip performance metrics, the measurement of both one-way and round-trip performance metrics,
such as delay, delay variation, and packet loss. In the STAMP such as delay, delay variation, and packet loss. In the STAMP
session, the bidirectional packet flow is transmited between STAMP session, the bidirectional packet flow is transmitted between STAMP
Session-Sender and STAMP Session-Reflector. The STAMP Session- Session-Sender and STAMP Session-Reflector. The STAMP Session-
Reflector receives test packets transmited from Session-Sender and Reflector receives test packets transmitted from Session-Sender and
acts according to the configuration. However, the performance of acts according to the configuration. However, the performance of
intermediate nodes and links that STAMP test packets traverse are intermediate nodes and links that STAMP test packets traverse are
invisible. In additon, the STAMP instance must be configured at invisible. In addition, the STAMP instance must be configured at
every intermediate node to measure the performance per node and link every intermediate node to measure the performance per node and link
that test packets traverse, which increases the complexity of OAM in that test packets traverse, which increases the complexity of OAM in
large-scale networks. large-scale networks.
STAMP Extensions have defined several optional TLVs to enhance the STAMP Extensions have defined several optional TLVs to enhance the
STAMP base functions. These optional TLVs are defined as updates of STAMP base functions. These optional TLVs are defined as updates of
the STAMP Optional Extensions [I-D.ietf-ippm-stamp-option-tlv]. This the STAMP Optional Extensions [I-D.ietf-ippm-stamp-option-tlv]. This
document extents optional TLVs to STAMP, which enable performance document extents optional TLVs to STAMP, which enables performance
measurement at every intermediate node and link along a STAMP test measurement at every intermediate node and link along a STAMP test
packet's delivery path, such as measurement of delay, delay packet's delivery path, such as measurement of delay, delay
variation, packet loss, and record of route information. The variation, packet loss, and record of route information. The
following sections describe the use of TLVs for STAMP that extend following sections describe the use of TLVs for STAMP that extend
STAMP capability beyond its base specification. STAMP capability beyond its base specification.
2. Terminology 2. Terminology
Following are abbreviations used in this document: Following are abbreviations used in this document:
skipping to change at page 4, line 48 skipping to change at page 5, line 21
collection and measurement at every node and link. collection and measurement at every node and link.
Also the STAMP Session-Reflector MAY be configured as IOAM Also the STAMP Session-Reflector MAY be configured as IOAM
encapsulating node to apply the IOAM Trace-Option functionalities to encapsulating node to apply the IOAM Trace-Option functionalities to
the Session-Reflector test packet. Hence, OAM data collection and the Session-Reflector test packet. Hence, OAM data collection and
measurement can be also enabled at every node and link along the measurement can be also enabled at every node and link along the
Session-Reflector test packet's backward delivery path. When the Session-Reflector test packet's backward delivery path. When the
reflected packet arrives at the Session-Sender, it can be either reflected packet arrives at the Session-Sender, it can be either
locally processed or sent to the centralized controller. locally processed or sent to the centralized controller.
In addition to IOAM, other telemetry data (e.g. alternate marking)
could be transmitted by STAMP optional TLV extensions. The draft
will keep the option open for future augmentations.
3.2. Forward HbH Delay TLV 3.2. Forward HbH Delay TLV
STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session- STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session-
Sender test packets to record the ingress timestamp and the egress Sender test packets to record the ingress timestamp and the egress
timestamp at every intermediate nodes along the Session-Sender test timestamp at every intermediate nodes along the Session-Sender test
packet's forward path. The Session-Sender MUST set the Length value packet's forward path. The Session-Sender MUST set the Length value
according to the number of explicitly listed intermediate nodes in according to the number of explicitly listed intermediate nodes in
the forward path and the timestamp formats. There are several the forward path and the timestamp formats. There are several
methods to synchronize the clock, e.g., Network Time Protocol (NTP) methods to synchronize the clock, e.g., Network Time Protocol (NTP)
[RFC5905]. For example, if a 64-bit timestamp format defined in NTP [RFC5905] and IEEE 1588v2 Precision Time Protocol (PTP)
is used, the Length value MUST be set as a multiple of 8 octets. The [IEEE.1588.2008]. For example, if a 64-bit timestamp format defined
Timestamp Tuple list [1..n] fields MUST be set to zero upon Session- in NTP is used, the Length value MUST be set as a multiple of 16
Sender test packets transmission and ignored upon receipt. octets. The Timestamp Tuple list [1..n] fields MUST be set to zero
upon Session-Sender test packets transmission.
The Forward HbH Delay TLV has the following format: The Forward HbH Delay TLV has the following format:
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
+-------------------------------+---------------+---------------+ +-------------------------------+---------------+---------------+
| Forward HbH Delay Type | Length | Node Left | | Forward HbH Delay Type | Length | Node Left |
+-------------------------------+---------------+---------------+ +-------------------------------+---------------+---------------+
| | | |
| Timestamp Tuple list [1] | | Timestamp Tuple list [1] |
skipping to change at page 5, line 40 skipping to change at page 6, line 30
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Fig. 2 Forward HbH Delay TLV Format Fig. 2 Forward HbH Delay TLV Format
where fields are defined as the following: where fields are defined as the following:
o Forward HbH Delay Type: To be assigned by IANA. o Forward HbH Delay Type: To be assigned by IANA.
o Length: A 8-bit field that indicates the length of the value o Length: A 8-bit field that indicates the length of the value
portion in octets and MUST be a multiple of 8 octets according to portion in octets and MUST be a multiple of 16 octets according to
the number of explicitly listed intermediate nodes in the forward the number of explicitly listed intermediate nodes in the forward
path. path.
o Node Left: A 8-bit unsigned integer, which indicates the number of o Node Left: A 8-bit unsigned integer, which indicates the number of
intermediate nodes remaining. That is, number of exlicitly listed intermediate nodes remaining. That is, number of explicitly
intermediate nodes still to be visited before reaching the listed intermediate nodes still to be visited before reaching the
destination node in the forward path. The Node Left field is set destination node in the forward path. The Node Left field is set
to n-1, where n is the number of intermediate nodes. to n-1, where n is the number of intermediate nodes.
o Timestamp Tuple list [1..n]: A variable-length field, which record o Timestamp Tuple list [1..n]: A variable-length field, which record
the timestamp when the Session-Sender test packet is received at the timestamp when the Session-Sender test packet is received at
the ingress of the n-th intermediate node Ingress Timestamp [n] the ingress of the n-th intermediate node Ingress Timestamp [n]
and the timestamp when the Session-Sender test packet is sent at and the timestamp when the Session-Sender test packet is sent at
egress of the n-th intermediate node Engress Timestamp [n]. For egress of the n-th intermediate node Egress Timestamp [n]. For
example, if a 64-bit timestamp format defined in NTP is used, the example, if a 64-bit timestamp format defined in NTP is used, the
length of each Timestamp tuple (Ingress Timestamp [n], Engress length of each Timestamp tuple (Ingress Timestamp [n], Egress
Timestamp [n]) must be 16 octets. The Timestamp Tuple list is Timestamp [n]) must be 16 octets. The Timestamp Tuple list is
encoded starting from the last intermediate node which is encoded starting from the last intermediate node which is
exlicitly listed. That is, the first element of the Timestamp explicitly listed. That is, the first element of the Timestamp
Tuple list [1] records the timestamps when the Session-Sender test Tuple list [1] records the timestamps when the Session-Sender test
packet received and forwarded at the last intermediate node of a packet received and forwarded at the last intermediate node of a
explicit path, the second element records the penultimate explicit path, the second element records the penultimate
Timestamp Tuple when the Session-Sender test packet received and Timestamp Tuple when the Session-Sender test packet received and
forwarded at the penultimate intermediate node of a explicit path, forwarded at the penultimate intermediate node of a explicit path,
and so on. and so on.
In the following reference topology, Node N1, N2, N3, N4 and N5 are In the following reference topology, Node N1, N2, N3, N4 and N5 are
SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5 SRv6 capable nodes. Node N1 is the STAMP Session-Sender and Node N5
is the STAMP Session-Reflector. T1 is the Timestamp taken by the is the STAMP Session-Reflector. T1 is the Timestamp taken by the
Session-Sender (i.e. N1) at the start of transmitting the test Session-Sender (i.e. N1) at the start of transmitting the test
packet. T2 is the Receive Timestamp when the test packet was packet. T2 is the Receive Timestamp when the test packet was
received by the Session-Reflector (i.e. N5). T3 is the Timestamp received by the Session-Reflector (i.e. N5). T3 is the Timestamp
taken by the Session-Reflector at the start of transmitting the test taken by the Session-Reflector at the start of transmitting the test
packet. T4 is the Receive Timestamp when the test packet was packet. T4 is the Receive Timestamp when the test packet was
received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4) received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4)
and (t5,t6) are the timestamps when the test packet received and and (t5,t6) are the timestamps when the test packet received and
transmited by sequence of intermediate nodes in the forward path. transmitted by sequence of intermediate nodes in the forward path.
Timestamp Tuples (t7,t8), (t9,t10) and (t11,t12) are the timestamps Timestamp Tuples (t7,t8), (t9,t10) and (t11,t12) are the timestamps
when the test packet received and transmited by sequence of when the test packet received and transmitted by sequence of
intermediate nodes in the backward path. intermediate nodes in the backward path.
====== ====== ====== ====== ====== ====== ====== ====== ====== ======
| | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| | | | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| |
| N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 | | N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 |
| | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| | | | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| |
====== ====== ====== ====== ====== ====== ====== ====== ====== ======
Fig. 3 Reference Topology Fig. 3 Reference Topology
The STAMP Session-Sender (i.e. Node N1) generates the STAMP test The STAMP Session-Sender (i.e. Node N1) generates the STAMP test
packet with the Forward HbH Delay TLV. When an intermediate node packet with the Forward HbH Delay TLV. When an intermediate node
receives the STAMP test packet, the node punts the packet to control receives the STAMP test packet, the node punts the packet to control
plane and fills the Ingress Timestamp [n] filed in the Timestamp plane and fills the Ingress Timestamp [n] filed in the Timestamp
Tuple list [n]. Then the time taken by the intermediate node Tuple list [n]. Then the time taken by the intermediate node
transmitting the test packet is recorded in to Engress Timestamp [n] transmitting the test packet is recorded in to Egress Timestamp [n]
field. The mechanism of timestamping and punting packet to control field. The mechanism of timestamping and punting packet to control
plane is outside the scope of this specification. plane is outside the scope of this specification.
When the STAMP Session-Reflector received the test packet with the When the STAMP Session-Reflector received the test packet with the
Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into
the Session-Reflector test packet before its transmission. Using the Session-Reflector test packet before its transmission. Using
Forward HbH Delay TLV in STAMP testing enables delay measurement per Forward HbH Delay TLV in STAMP testing enables delay measurement per
link in the forward path. link in the forward path.
3.3. Backward HbH Delay TLV 3.3. Backward HbH Delay TLV
STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session- STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session-
Sender test packets to record the ingress timestamp and egress Sender test packets to record the ingress timestamp and egress
timestamp when Session-Reflector test packets are received and sent timestamp when Session-Reflector test packets are received and sent
at every intermediate nodes in the backward path. The Session-Sender at every intermediate nodes in the backward path. The Session-Sender
MUST set the Length value according to the number of explicitly MUST set the Length value according to the number of explicitly
listed intermediate nodes in the backward path and the timestamp listed intermediate nodes in the backward path and the timestamp
formats. There are several methods to synchronize the clock, e.g., formats. There are several methods to synchronize the clock, e.g.,
Network Time Protocol (NTP) [RFC5905]. For example, if a 64-bit Network Time Protocol (NTP) [RFC5905] and IEEE 1588v2 Precision Time
timestamp format defined in NTP is used, the Length value MUST be set Protocol (PTP) [IEEE.1588.2008]. For example, if a 64-bit timestamp
as a multiple of 8 octets. The Timestamp Tuple list [1..n] fields format defined in NTP is used, the Length value MUST be set as a
MUST be set to zero upon Session-Sender test packets transmission and multiple of 16 octets. The Timestamp Tuple list [1..n] fields MUST
be set to zero upon Session-Sender test packets transmission and
ignored upon receipt. ignored upon receipt.
The Backward HbH Delay TLV has the following format: The Backward HbH Delay TLV has the following format:
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
+-------------------------------+---------------+---------------+ +-------------------------------+---------------+---------------+
| Backward HbH Delay Type | Length | Node Left | | Backward HbH Delay Type | Length | Node Left |
+-------------------------------+---------------+---------------+ +-------------------------------+---------------+---------------+
| | | |
skipping to change at page 8, line 6 skipping to change at page 8, line 42
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Fig. 4 Backward HbH Delay TLV Format Fig. 4 Backward HbH Delay TLV Format
where fields are defined as the following: where fields are defined as the following:
o Backward HbH Delay Type: To be assigned by IANA. o Backward HbH Delay Type: To be assigned by IANA.
o Length: A 8-bit field that indicates the length of the value o Length: A 8-bit field that indicates the length of the value
portion in octets and will be a multiple of 8 octets dependent on portion in octets and will be a multiple of 16 octets dependent on
the number of explicitly listed intermediate nodes in the backward the number of explicitly listed intermediate nodes in the backward
path. path.
o Node Left: A 8-bit unsigned integer, which indicates the number of o Node Left: A 8-bit unsigned integer, which indicates the number of
intermediate nodes remaining. That is, number of exlicitly listed intermediate nodes remaining. That is, number of explicitly
intermediate nodes still to be visited before reaching the listed intermediate nodes still to be visited before reaching the
destination node in the backward path. The Node Left field is set destination node in the backward path. The Node Left field is set
to n-1, where n is the number of intermediate nodes. to n-1, where n is the number of intermediate nodes.
o Timestamp Tuple list [1..n]: A variable-length field, which record o Timestamp Tuple list [1..n]: A variable-length field, which record
the timestamp when the reflected test packet is received at the the timestamp when the reflected test packet is received at the
ingress of the n-th intermediate node and the timestamp when the ingress of the n-th intermediate node and the timestamp when the
reflected test packet is sent at egress of the n-th intermediate reflected test packet is sent at egress of the n-th intermediate
node. For example, if a 64-bit timestamp format defined in NTP is node. For example, if a 64-bit timestamp format defined in NTP is
used, the length of each Timestamp tuple (Ingress Timestamp [n], used, the length of each Timestamp tuple (Ingress Timestamp [n],
Engress Timestamp [n]) must be 16 octets. The Timestamp Tuple Egress Timestamp [n]) must be 16 octets. The Timestamp Tuple list
list is encoded starting from the last intermediate node which is is encoded starting from the last intermediate node which is
exlicitly listed. That is, the first element of the Timestamp explicitly listed. That is, the first element of the Timestamp
Tuple list [1] records the timestamps when the reflected test Tuple list [1] records the timestamps when the reflected test
packet received and forwarded at the last intermediate node of a packet received and forwarded at the last intermediate node of a
explicit path, the second element records the penultimate explicit path, the second element records the penultimate
Timestamp Tuple when the reflected test packet received and Timestamp Tuple when the reflected test packet received and
forwarded at the penultimate intermediate node of a explicit path, forwarded at the penultimate intermediate node of a explicit path,
and so on. and so on.
When the STAMP Session-Reflector received the Session-Sender test When the STAMP Session-Reflector received the Session-Sender test
packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH
Delay TLV into the Session-Reflector test packet. Delay TLV into the Session-Reflector test packet.
When an intermediate node receives the reflected test packet, the When an intermediate node receives the reflected test packet, the
node sends the packet to control plane and fills the Ingress node sends the packet to control plane and fills the Ingress
Timestamp [n] filed of Backward HbH Delay TLV. Then the time taken Timestamp [n] filed of Backward HbH Delay TLV. Then the time taken
by the intermediate node transmitting the test packet is recorded in by the intermediate node transmitting the test packet is recorded in
to Engress Timestamp [n] field of Backward HbH Delay TLV. Using to Egress Timestamp [n] field of Backward HbH Delay TLV. Using
Backward HbH Delay TLV in STAMP testing enables delay measurement per Backward HbH Delay TLV in STAMP testing enables delay measurement per
link in the backward path. link in the backward path.
3.4. HbH Packet Loss TLV
STAMP Session-Sender MAY place the HbH Packet Loss TLV in Session-
Sender test packets to record the number of Session-Sender test
packets received at and transmitted by every intermediate nodes along
the forward path. The Session-Sender MUST set the Length value
according to the number of explicitly listed intermediate nodes in
the forward path. A Counter Tuple is composed of a 64-bit Receive
Counter field and a 64-bit Transmit Counter field. The Counter Tuple
list [1..n] fields MUST be set to zero upon Session-Sender test
packets transmission.
The HbH Packet Loss TLV has the following format:
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
+-------------------------------+---------------+---------------+
| HbH Packet Loss Type | Length | Node Left |
+-------------------------------+---------------+---------------+
| |
| Counter Tuple list [1] |
| |
| |
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| |
| Counter Tuple list [n] |
| |
| |
+---------------------------------------------------------------+
Fig. 5 HbH Packet Loss TLV Format
where fields are defined as the following:
o HbH Packet Loss Type: To be assigned by IANA.
o Length: A 8-bit field that indicates the length of the value
portion in octets and will be a multiple of 16 octets dependent on
the number of explicitly listed intermediate nodes in the forward
path.
o Node Left: A 8-bit unsigned integer, which indicates the number of
intermediate nodes remaining. That is, number of explicitly
listed intermediate nodes still to be visited before reaching the
destination node in the forward path. The Node Left field is set
to n-1, where n is the number of intermediate nodes.
o Counter Tuple list [1..n]: A variable-length field, which record
the Receive Counter and the Transmit Counter when the test packet
is received at and transmitted by the n-th intermediate node. The
Counter Tuple list is encoded starting from the last intermediate
node which is explicitly listed. That is, the first element of
the Counter Tuple list [1] records the Receive Counter and the
Transmit Counter when the test packet is received at and
transmitted by the last intermediate node of a explicit path, the
second element records the penultimate Counter Tuple when the test
packet received and forwarded at the penultimate intermediate node
of a explicit path, and so on.
The STAMP Session-Sender generates the STAMP test packet with the HbH
Packet Loss TLV. When an intermediate node receives the STAMP test
packet, the node punts the packet to control plane and writes the
Receive Counter and the Transmit Counter at the Counter Tuple list
[n] in the Session-Sender test packet. The mechanism of punting
packet to control plane is outside the scope of this specification.
When the STAMP Session-Reflector received the test packet with the
HbH Packet Loss TLV, it MUST copy the HbH Packet Loss TLV into the
Session-Reflector test packet before its transmission. Using HbH
Packet Loss TLV in STAMP testing enables packet loss measurement per
node/link in the forward path.
3.5. HbH Bandwidth Utilization TLV
STAMP Session-Sender MAY place the HbH Bandwidth Utilization TLV in
Session-Sender test packets to record the ingress and egress
bandwidth utilization at every intermediate nodes along the forward
path. The Session-Sender MUST set the Length value according to the
number of explicitly listed intermediate nodes in the forward path.
A BW Utilization Tuple is composed of a 32-bit ingress bandwidth
utilization field and a 32-bit egress bandwidth utilization field.
The BW Utilization Tuple list [1..n] fields MUST be set to zero upon
Session-Sender test packets transmission.
The HbH Bandwidth Utilization TLV has the following format:
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
+-------------------------------+---------------+---------------+
| HbH BW Utilization Type | Length | Node Left |
+-------------------------------+---------------+---------------+
| BW Utilization Tuple list [1] |
| |
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| BW Utilization Tuple list [n] |
| |
+---------------------------------------------------------------+
Fig. 6 HbH Bandwidth Utilization TLV Format
where fields are defined as the following:
o HbH BW Utilization Type: To be assigned by IANA.
o Length: A 8-bit field that indicates the length of the value
portion in octets and will be a multiple of 8 octets dependent on
the number of explicitly listed intermediate nodes in the forward
path.
o Node Left: A 8-bit unsigned integer, which indicates the number of
intermediate nodes remaining. That is, number of explicitly
listed intermediate nodes still to be visited before reaching the
destination node in the forward path. The Node Left field is set
to n-1, where n is the number of intermediate nodes.
o BW Utilization Tuple list [1..n]: A variable-length field, which
record the ingress and egress bandwidth utilization when the test
packet is received at and transmitted by the n-th intermediate
node. The BW Utilization Tuple list is encoded starting from the
last intermediate node which is explicitly listed. That is, the
first element of the BW Utilization Tuple list [1] records the
ingress and the egress bandwidth utilization when the test packet
is received at and transmitted by the last intermediate node of a
explicit path, the second element records the penultimate BW
Utilization Tuple when the test packet received at and transmitted
by the penultimate intermediate node of a explicit path, and so
on.
The STAMP Session-Sender generates the STAMP test packet with the HbH
BW Utilization TLV. When an intermediate node receives the STAMP
test packet, the node punts the packet to control plane and writes
the ingress and egress bandwidth utilization at the BW Utilization
Tuple list [n] in the Session-Sender test packet. The mechanism of
punting packet to control plane is outside the scope of this
specification.
When the STAMP Session-Reflector received the test packet with the
HbH BW Utilization TLV, it MUST copy the HbH BW Utilization TLV into
the Session-Reflector test packet before its transmission. The HbH
BW Utilization TLV carried in STAMP test packet is usable to detect
and troubleshoot the link congestion in the forward path.
3.6. HbH Timestamp Information TLV
STAMP Session-Sender MAY place the HbH Timestamp Information TLV in
Session-Sender test packets to query the ingress and egress Timestamp
Information at every intermediate nodes along the forward path. The
Timestamp Information includes the source of clock synchronization
and the method of timestamp obtainment. There are several types of
clock synchronization source, e.g., NTP, PTP. The method of
timestamp obtainment may be from control plane (e.g. NTP) or from
data plane (e.g. PTP). A Timestamp Info Tuple is composed of a
8-bit ingress clock source field, a 8-bit ingress timestamp
obtainment field, a 8-bit egress clock source field, and a 8-bit
egress timestamp obtainment field. The Session-Sender MUST set the
Length value according to the number of explicitly listed
intermediate nodes in the forward path. The Timestamp Info Tuple
list [1..n] fields MUST be set to zero upon Session-Sender test
packets transmission.
The HbH Timestamp Information TLV has the following format:
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
+-------------------------------+---------------+---------------+
| HbH Timestamp Info Type | Length | Node Left |
+-------------------------------+---------------+---------------+
| Timestamp Info Tuple list [1] |
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| Timestamp Info Tuple list [n] |
+---------------------------------------------------------------+
Fig. 6 HbH Timestamp Information TLV Format
where fields are defined as the following:
o HbH Timestamp Info Type: To be assigned by IANA.
o Length: A 8-bit field that indicates the length of the value
portion in octets and will be a multiple of 4 octets dependent on
the number of explicitly listed intermediate nodes in the forward
path.
o Node Left: A 8-bit unsigned integer, which indicates the number of
intermediate nodes remaining. That is, number of explicitly
listed intermediate nodes still to be visited before reaching the
destination node in the forward path. The Node Left field is set
to n-1, where n is the number of intermediate nodes.
o Timestamp Info Tuple list [1..n]: A variable-length field, which
record the source of clock synchronization and the method of
timestamp obtainment at the ingress and egress when the test
packet is received at and transmitted by the n-th intermediate
node. The Timestamp Info Tuple list is encoded starting from the
last intermediate node which is explicitly listed. That is, the
first element of the Timestamp Info Tuple list [1] records the
source of clock synchronization and the method of timestamp
obtainment at the ingress and egress when the test packet is
received at and transmitted by the last intermediate node of a
explicit path, the second element records the penultimate
Timestamp Info Tuple when the test packet received at and
transmitted by the penultimate intermediate node of a explicit
path, and so on.
The STAMP Session-Sender generates the STAMP test packet with the HbH
Timestamp Information TLV. When an intermediate node receives the
STAMP test packet, the node punts the packet to control plane and
writes the source of clock synchronization and the method of
timestamp obtainment at the Timestamp Info Tuple list [n] in the
Session-Sender test packet. The mechanism of punting packet to
control plane is outside the scope of this specification.
When the STAMP Session-Reflector received the test packet with the
HbH Timestamp Information TLV, it MUST copy the HbH Timestamp
Information TLV into the Session-Reflector test packet before its
transmission. The HbH Timestamp Information TLV carried in STAMP
test packet is usable to query timestamp information from every nodes
in the forward path.
Note that the source of clock synchronization, NTP or PTP, is part of
configuration of the Session-Sender/Reflector or a particular test
session [RFC8762]. This draft recommends every intermediate nodes to
be configured to use the same source of clock synchronization.
4. IANA Considerations 4. IANA Considerations
IANA is requested to allocate values for the following TLV Type from IANA is requested to allocate values for the following TLV Type from
the "STAMP TLV Type" registry [I-D.ietf-ippm-stamp-option-tlv]. the "STAMP TLV Type" registry [I-D.ietf-ippm-stamp-option-tlv].
+------------+------------------------+---------------+ +------------+-------------------------------+---------------+
| Code Point | Description | Reference | | Code Point | Description | Reference |
+------------+------------------------+---------------+ +------------+-------------------------------+---------------+
| TBA1 | IOAM Tracing Data TLV | This document | | TBA1 | IOAM Tracing Data TLV | This document |
| TBA2 | Forward HBH Delay TLV | This document | | TBA2 | Forward HbH Delay TLV | This document |
| TBA3 | Backward HBH Delay TLV | This document | | TBA3 | Backward HbH Delay TLV | This document |
+------------+------------------------+---------------+ | TBA4 | HbH Packet Loss TLV | This document |
| TBA5 | HbH BW Utilization TLV | This document |
| TBA6 | HbH Timestamp Information TLV | This document |
+------------+-------------------------------+---------------+
5. Security Considerations 5. Security Considerations
This document extensions new optional TLVs to STAMP. It does not This document extensions new optional TLVs to STAMP. It does not
introduce any new security risks to STAMP. introduce any new security risks to STAMP.
6. References 6. Acknowledgements
6.1. Normative References The authors would like to thank Hongwei Yang, Giuseppe Fioccola and
Chang Liu for the reviews and comments.
7. References
7.1. Normative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
"Data Fields for In-situ OAM", "Data Fields for In-situ OAM",
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam- <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-
data/>. data/>.
[I-D.ietf-ippm-ioam-ipv6-options] [I-D.ietf-ippm-ioam-ipv6-options]
"In-situ OAM IPv6 Options", "In-situ OAM IPv6 Options",
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam- <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-
ipv6-options/>. ipv6-options/>.
skipping to change at page 9, line 45 skipping to change at page 15, line 37
ippm-stamp-option-tlv/>. ippm-stamp-option-tlv/>.
[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>.
[RFC8762] "Simple Two-Way Active Measurement Protocol", [RFC8762] "Simple Two-Way Active Measurement Protocol",
<https://datatracker.ietf.org/doc/rfc8762/>. <https://datatracker.ietf.org/doc/rfc8762/>.
6.2. Informative References 7.2. Informative References
[IEEE.1588.2008]
"IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
<https://ieeexplore.ieee.org/document/4579760>.
[RFC5905] "Network Time Protocol Version 4: Protocol and Algorithms [RFC5905] "Network Time Protocol Version 4: Protocol and Algorithms
Specification", <https://www.rfc-editor.org/info/rfc5905>. Specification", <https://www.rfc-editor.org/info/rfc5905>.
Authors' Addresses Authors' Addresses
Yali Wang Yali Wang
Huawei Huawei
156 Beiqing Rd., Haidian District 156 Beijing Rd., Haidian District
Beijing Beijing
China China
Email: wangyali11@huawei.com Email: wangyali11@huawei.com
Tianran Zhou Tianran Zhou
Huawei Huawei
156 Beiqing Rd., Haidian District 156 Beijing Rd., Haidian District
Beijing Beijing
China China
Email: zhoutianran@huawei.com Email: zhoutianran@huawei.com
Hongwei Yang
China Mobile
Beijing
China
Email: yanghongwei@chinamobile.com
Chang Liu
China Unicom
Beijing
China
Email: liuc131@chinaunicom.cn
 End of changes. 34 change blocks. 
52 lines changed or deleted 309 lines changed or added

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