IP Performance Measurement Group Y. Wang Internet-Draft T. Zhou Intended status: Standards Track Huawei Expires:January 11,April 30, 2021July 10,October 27, 2020 Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM Data Collectiondraft-wang-ippm-stamp-hbh-extensions-00draft-wang-ippm-stamp-hbh-extensions-01 Abstract This document defines optional TLVs which are carried in Simple Two- way Active Measurement Protocol (STAMP) test packets to enhance the STAMP base functions. Such extensions to STAMP enable OAM data measurement and collection at every nodethatand link along a STAMP testpackets traverse.packet's delivery path. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onJanuary 11,April 30, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 3 3.1. IOAM Tracing Data TLV . . . . . . . . . . . . . . . . . . 3 3.2. Forward HbH Delay TLV . . . . . . . . . . . . . . . . . . 4 3.3. Backward HbH Delay TLV . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] enables the measurement of both one-way and round-trip performance metrics, such as delay, delay variation, and packetloss [RFC8762].loss. In the STAMP session, the bidirectional packet flow is transmited between STAMP Session-Sender and STAMP Session-Reflector. The STAMP Session- Reflector receives test packets transmited from Session-Sender and acts according to the configuration. However, the performance of intermediate nodes and links that STAMP test packets traverse are invisible.AndIn additon, the STAMP instance must be configured at every intermediate node to measure the performance per node and link that test packets traverse, which increases the complexity of OAM in large-scale networks.This document extents optional TLVs to STAMP which enable OAM data collection at every node that STAMP test packets traverse, such as measurement of delay, packet loss, delay variation per hop, and record of route information.STAMP Extensions have defined severaloptionnaloptional TLVs to enhance the STAMP base functions. These optional TLVs are defined as updates of the STAMP Optional Extensions [I-D.ietf-ippm-stamp-option-tlv]. This document extents optional TLVs to STAMP, which enable performance measurement at every intermediate node and link along a STAMP test packet's delivery path, such as measurement of delay, delay variation, packet loss, and record of route information. The following sections describe the use of TLVs for STAMP that extend STAMP capability beyond its base specification. 2. Terminology Following are abbreviations used in this document: STAMP: Simple Two-way Active Measurement Protocol. IOAM: In-situ OAM. HbH: Hop-by-Hop. 3. TLV Extensions to STAMP 3.1. IOAM Tracing Data TLV STAMP Session-Sender MAY place the IOAM Tracing Data TLV inSTAMP Session-SenderSession- Sender test packets to record the IOAM tracing dataofat every IOAM capable nodethatalong theSTAMPSession-Sender testpacket traverses in the forwardpacket's forward-delivery path. As STAMP uses symmetrical packets, theSession- SenderSession-Sender MUST set the Length value as a multiple of 4 octets according to the number ofintermediatenodes and the IOAM-Trace-Type (i.e. a 24-bit identifier which specifies which data types are used in the node data list [I-D.ietf-ippm-ioam-data]). And thenode-data-copied- listnode-data-copied-list fields MUST be set to zero upon Session-Sender test packets transmission and ignored upon receipt. The IOAM Tracing Data 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 +-------------------------------+-------------------------------+ | IOAM-Tracing-Data Type | Length | +---------------------------------------------------------------+ | node data copied list [0] | +---------------------------------------------------------------+ | node data copied list [1] | +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | node data copied list [n] | +---------------------------------------------------------------+ Fig. 1 IOAM Tracing Data TLV Format where fields are defined as the following: o IOAM-Tracing-Data Type: To be assigned by IANA. o Length: A 2-octet field that indicates the length of the value field in octets and equal to a multiple of 4 octets dependent on the number of nodes and IOAM-Trace-Type bits. o node data copied list [0..n]: A variable-length field, which record the copied content of each node data element determined by theIOAM- Trace-Type.IOAM-Trace-Type. The order of packing the data fields in each node data element follows the bit order of the IOAM-Trace-Type field (see section 4.4.1 of [I-D.ietf-ippm-ioam-data]). The last node data element in this list is the node data of the first IOAM trace capable node in the path. In an IOAM domain, the STAMP Session-Sender and the STAMP Session- Reflector MAY be configured as the IOAM encapsulating node and the IOAM decapsulating node. The STAMP Session-Sender (i.e. the IOAM encapsulating node) generates theSTAMPtest packet with the IOAM Tracing Data TLV. For applying the IOAM Trace-Option functionalities to theSTAMPSession-Sender test packet, theSTAMPSession-Sender must inserts the "trace option header" and allocate an node-data-list array [I-D.ietf-ippm-ioam-data] into "option data" fields ofHop-by- HopHop-by-Hop Options header in IPv6 packets [I-D.ietf-ippm-ioam-ipv6-options], and sets the corresponding bits in the IOAM-Trace-Type. Also, the STAMP Session-Sender allocatesan node-data-lista node-data-copied-list arraywhich is usedin the optional IOAM Tracing Data TLV to store OAM data retrieved from every IOAM transitnodes whilenode along the Session-Sender testpackets traverse thepacket's delivery path. When the STAMP Session-Reflector (i.e. the IOAM decapsulating node) received the STAMP Session-Sender test packet with the IOAM-Tracing- Data TLV, it MUST copy the node-data-list array into the node-data- copied-list array carried in thereflectedSession-Reflector test packet before transmission and MUST remove the IOAM-Data-Fields. Hence,usingcarrying IOAM-Tracing-Data TLV in STAMPtestingtest packets enableshop-by-hopOAM datacollection.collection and measurement at every node and link. Also the STAMP Session-Reflector MAY be configured as IOAM encapsulating node to apply the IOAM Trace-Option functionalities to thereflectedSession-Reflector test packet. Hence,hop-by-hopOAM data collection and measurement can be also enabledforat every node and link along the Session-Reflector test packet's backwardpath that the reflected packets traverse.delivery path. When the reflected packet arrives at theSession-Sender receives,Session-Sender, it can be either locally processed or sent to the centralized controller. 3.2. Forward HbH Delay TLV STAMP Session-Sender MAY place the Forward HbH Delay TLV in Session- Sender test packets to record the ingress timestamp andengressthe egress timestamp at every intermediate nodesinalong theforward path that STAMPSession-Sender testpackets traverse.packet's forward path. The Session-Sender MUST set the Length value according to the number of explicitly listed intermediate nodes in the forward path and the timestamp formats. There are several methods to synchronize the clock, e.g., Network Time Protocol (NTP) [RFC5905]. For example, if a 64-bit timestamp format defined in NTP is used, the Length value MUST be set as a multiple of 8 octets. The Timestamp Tuple list(Ingress Timestamp [0..n], Engress Timestamp [0..n])[1..n] fields MUST be set to zero uponSession-SenderSession- Sender test packets transmission and ignored upon receipt. The Forward HbH Delay 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 +-------------------------------+---------------+---------------+ | Forward HbH Delay Type | Length | Node Left | +-------------------------------+---------------+---------------+ |Ingress Timestamp [0]| | Timestamp Tuple list [1] |+---------------------------------------------------------------+|Engress Timestamp [0]| | | +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ |Ingress Timestamp [n]| || +---------------------------------------------------------------+ | EngressTimestamp Tuple list [n] | | | | | +---------------------------------------------------------------+ Fig. 2 Forward HbH Delay TLV Format where fields are defined as the following: o Forward HbH Delay Type: To be assigned by IANA. 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 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 exlicitly 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 Tuple list(Ingress Timestamp [0..n], Engress Timestamp [0..n]):[1..n]: A variable-length field, which record the timestamp when the Session-Sender test packet is received at the ingress of the n-th intermediate node Ingress Timestamp [n] and the timestamp when the Session-Sender test packet is sent atengressegress of the n-th intermediatenode.node Engress Timestamp [n]. For example, if a 64-bit timestamp format defined in NTP is used, the length of each Timestamp tuple (Ingress Timestamp [n], Engress Timestamp [n]) must be 16 octets. The Timestamp Tuple list is encoded starting from the last intermediate node which is exlicitly listed. That is, the first element of the Timestamp Tuple(Ingress Timestamp [0], Engress Timestamp [0])list [1] records the timestamps when the Session-Sender test packet received and forwarded at the last intermediate node of a explicit path, the second element records the penultimate Timestamp Tuple when the Session-Sender test packet received and forwarded at the penultimate intermediate node of a explicit path, and so on. 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 is the STAMP Session-Reflector. T1 is the Timestamp taken by the Session-Sender (i.e. N1) at the start of transmitting the test packet. T2 is the Receive Timestamp when the test packet was received by the Session-Reflector (i.e. N5). T3 is the Timestamp taken by the Session-Reflector at the start of transmitting the test packet. T4 is the Receive Timestamp when the test packet was received by the Session-Sender. Timestamp tuples (t1,t2), (t3,t4) and (t5,t6) are the timestamps when the test packet received and transmited by sequence of intermediate nodes in the forward path. Timestamp Tuples (t7,t8), (t9,t10) and (t11,t12) are the timestamps when the test packet received and transmited by sequence of intermediate nodes in the backward path. ====== ====== ====== ====== ====== | | T1--->t1 | | t2--->t3 | | t4--->t5 | | t6--->T2| | | N1 |==========| N2 |==========| N3 |==========| N4 |=========| N5 | | | T4<---t12| |t11<---t10| | t9<---t8 | | t7<---T3| | ====== ====== ====== ====== ====== Fig. 3 Reference Topology The STAMP Session-Sender (i.e. Node N1) generates the STAMP test packet with the Forward HbH Delay TLV. When an intermediate node receives the STAMP test packet, the nodesendspunts the packet to control plane and fills the Ingress Timestamp [n] filed in theForward HbH Delay TLV.Timestamp Tuple list [n]. Then the time taken by the intermediate node transmitting the test packet is recorded in to Engress Timestamp [n]field in the Forward HbH Delay TLV.field. The mechanism of timestamping and punting packet to control plane is outside the scope of this specification. When the STAMP Session-Reflector received the test packet with the Forward HbH Delay TLV, it MUST copy the Forward HbH Delay TLV into thereflectedSession-Reflector test packet before its transmission. Using Forward HbH Delay TLV in STAMP testing enableshop-by-hopdelay measurement per link in the forward path. 3.3. Backward HbH Delay TLV STAMP Session-Sender MAY place the Backward HbH Delay TLV in Session- Sender test packets to record the ingress timestamp andengressegress timestamp when Session-Reflector test packets are received and sent at every intermediate nodes in the backward path. The Session-Sender MUST set the Length value according to the number of explicitly listed intermediate nodes in the backward path and the timestamp formats. There are several methods to synchronize the clock, e.g., Network Time Protocol (NTP) [RFC5905]. For example, if a 64-bit timestamp format defined in NTP is used, the Length value MUST be set as a multiple of 8 octets. The Timestamp Tuple list(Ingress Timestamp [0..n], Engress Timestamp [0..n])[1..n] fields MUST be set to zero upon Session-Sender test packets transmission and ignored upon receipt. The Backward HbH Delay 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 +-------------------------------+---------------+---------------+ | Backward HbH Delay Type | Length | Node Left | +-------------------------------+---------------+---------------+ |Ingress Timestamp [0]| | Timestamp Tuple list [1] |+---------------------------------------------------------------+|Engress Timestamp [0]| | | +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ |Ingress Timestamp [n]| || +---------------------------------------------------------------+ | EngressTimestamp Tuple list [n] | | | | | +---------------------------------------------------------------+ Fig. 4 Backward HbH Delay TLV Format where fields are defined as the following: o Backward HbH Delay 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 inathe backward path. o Node Left: A 8-bit unsigned integer, which indicates the number of intermediate nodes remaining. That is, number of exlicitly listed intermediate nodes still to be visited before reaching the destination node in the backward path. The Node Left field is set to n-1, where n is the number of intermediate nodes. o Timestamp Tuple list(Ingress Timestamp [0..n], Engress Timestamp [0..n]):[1..n]: A variable-length field, which record the timestamp when the reflected test packet is received at the ingress of the n-th intermediate node and the timestamp when the reflected test packet is sent atengressegress of the n-th intermediate node. For example, if a 64-bit timestamp format defined in NTP is used, the length of each Timestamp tuple (Ingress Timestamp [n], Engress Timestamp [n]) must be 16 octets. The Timestamp Tuple list is encoded starting from the last intermediate node which is exlicitly listed. That is, the first element of the Timestamp Tuple(Ingress Timestamp [0], Engress Timestamp [0])list [1] records the timestamps when the reflected test packet received and forwarded at the last intermediate node of a explicit path, the second element records the penultimate Timestamp Tuple when the reflected test packet received and forwarded at the penultimate intermediate node of a explicit path, and so on. When the STAMP Session-Reflector received the Session-Sender test packet with the Backward HbH Delay TLV, it MUST copy the Backward HbH Delay TLV into thereflectedSession-Reflector test packet. When an intermediate node receives the reflected test packet, the node sends the packet to control plane and fills the Ingress Timestamp [n] filed of Backward HbH Delay TLV. Then the time taken by the intermediate node transmitting the test packet is recorded in to Engress Timestamp [n] field of Backward HbH Delay TLV. Using Backward HbH Delay TLV in STAMP testing enableshop-by-hopdelay measurement per link in the backward path. 4. IANA Considerations IANA is requested to allocate values for the following TLV Type from the "STAMP TLV Type" registry [I-D.ietf-ippm-stamp-option-tlv]. +------------+------------------------+---------------+ | Code Point | Description | Reference | +------------+------------------------+---------------+ | TBA1 | IOAM Tracing Data TLV | This document | | TBA2 | Forward HBH Delay TLV | This document | | TBA3 | Backward HBH Delay TLV | This document | +------------+------------------------+---------------+ 5. Security Considerations This documentintroduces new TLVextensions new optional TLVs to STAMP. It does not introduce any new security risks to STAMP. 6. References 6.1. Normative References [I-D.ietf-ippm-ioam-data] "Data Fields for In-situ OAM", <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam- data/>. [I-D.ietf-ippm-ioam-ipv6-options] "In-situ OAM IPv6 Options", <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam- ipv6-options/>. [I-D.ietf-ippm-stamp-option-tlv] "Simple Two-way Active Measurement Protocol Optional Extensions", <https://datatracker.ietf.org/doc/draft-ietf- ippm-stamp-option-tlv/>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8762] "Simple Two-Way Active Measurement Protocol", <https://datatracker.ietf.org/doc/rfc8762/>. 6.2. Informative References [RFC5905] "Network Time Protocol Version 4: Protocol and Algorithms Specification", <https://www.rfc-editor.org/info/rfc5905>. Authors' Addresses Yali Wang Huawei 156 Beiqing Rd., Haidian District Beijing China Email: wangyali11@huawei.com Tianran Zhou Huawei 156 Beiqing Rd., Haidian District Beijing China Email: zhoutianran@huawei.com