[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



IP Performance Measurement Group                                 Y. Wang
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                                  Huawei
Expires: January 11, 2021                                  July 10, 2020


Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM
                            Data Collection
                draft-wang-ippm-stamp-hbh-extensions-00

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
   collection at every node that STAMP test packets traverse.

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 on January 11, 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



Wang & Zhou             Expires January 11, 2021                [Page 1]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


   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) enables the
   measurement of both one-way and round-trip performance metrics, such
   as delay, delay variation, and packet loss [RFC8762].  In the STAMP
   session, the bidirectional packet flow is transmited between STAMP
   Session-Sender and STAMP Session-Reflector.  The STAMP Session-
   Reflector receives packets transmited from Session-Sender and acts
   according to the configuration.  However, the performance of
   intermediate nodes that STAMP test packets traverse are invisible.
   And the STAMP instance must be configured at every intermediate node
   to measure the performance per node 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 several
   optionnal 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].  The following sections describe
   the use of TLVs for STAMP that extend STAMP capability beyond its
   base specification.






Wang & Zhou             Expires January 11, 2021                [Page 2]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


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 in STAMP
   Session-Sender test packets to record the IOAM tracing data of every
   IOAM capable node that the STAMP Session-Sender test packet traverses
   in the forward path.  As STAMP uses symmetrical packets, the Session-
   Sender MUST set the Length value as a multiple of 4 octets according
   to the number of intermediate nodes 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 the node-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:

   IOAM-Tracing-Data Type: To be assigned by IANA.




Wang & Zhou             Expires January 11, 2021                [Page 3]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


   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.

   node data copied list [0..n]: A variable-length field, which record
   the copied content of each node data element determined by the 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 the STAMP test packet with the IOAM
   Tracing Data TLV.  For applying the IOAM Trace-Option functionalities
   to the STAMP Session-Sender test packet, the STAMP Session-Sender
   must inserts the "trace option header" and allocate an node-data-list
   array [I-D.ietf-ippm-ioam-data] into "option data" fields of Hop-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 allocates an node-data-list array which is used
   to store OAM data retrieved from every IOAM transit nodes while the
   Session-Sender test packets traverse the 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 the reflected test packet before
   transmission and MUST remove the IOAM-Data-Fields.  Hence, using
   IOAM-Tracing-Data TLV in STAMP testing enables hop-by-hop OAM data
   collection.

   Also the STAMP Session-Reflector MAY be configured as IOAM
   encapsulating node to apply the IOAM Trace-Option functionalities to
   the reflected test packet.  Hence, hop-by-hop OAM data collection can
   be also enabled for the backward path that the reflected packets
   traverse.  When the reflected packet arrives at the Session-Sender
   receives, 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 and engress
   timestamp at every intermediate nodes in the forward path that STAMP
   test packets traverse.  The Session-Sender MUST set the Length value



Wang & Zhou             Expires January 11, 2021                [Page 4]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


   according to the number of 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]) fields MUST be
   set to zero upon Session-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]                     |
   |                                                               |
   +---------------------------------------------------------------+
   |                     Engress Timestamp [0]                     |
   |                                                               |
   +---------------------------------------------------------------+
   ~                              ...                              ~
   +---------------------------------------------------------------+
   |                     Ingress Timestamp [n]                     |
   |                                                               |
   +---------------------------------------------------------------+
   |                     Engress Timestamp [n]                     |
   |                                                               |
   +---------------------------------------------------------------+


                    Fig. 2 Forward HbH Delay TLV Format

   where fields are defined as the following:

   Forward HbH Delay Type: To be assigned by IANA.

   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 intermediate nodes in the forward path.

   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.




Wang & Zhou             Expires January 11, 2021                [Page 5]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


   Timestamp Tuple list (Ingress Timestamp [0..n], Engress Timestamp
   [0..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 and the timestamp when the Session-Sender test
   packet is sent at engress 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]) 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 node sends the packet to control
   plane and fills the Ingress Timestamp [n] filed in the Forward HbH
   Delay TLV.  Then the time taken by the intermediate node transmitting
   the test packet is recorded in to Engress Timestamp [n] field in the




Wang & Zhou             Expires January 11, 2021                [Page 6]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


   Forward HbH Delay TLV.  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
   the reflected test packet before its transmission.  Using Forward HbH
   Delay TLV in STAMP testing enables hop-by-hop delay measurement 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 and engress
   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 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]) 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]                     |
   |                                                               |
   +---------------------------------------------------------------+
   |                     Engress Timestamp [0]                     |
   |                                                               |
   +---------------------------------------------------------------+
   ~                              ...                              ~
   +---------------------------------------------------------------+
   |                     Ingress Timestamp [n]                     |
   |                                                               |
   +---------------------------------------------------------------+
   |                     Engress Timestamp [n]                     |
   |                                                               |
   +---------------------------------------------------------------+


                   Fig. 4 Backward HbH Delay TLV Format



Wang & Zhou             Expires January 11, 2021                [Page 7]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


   where fields are defined as the following:

   Backward HbH Delay Type: To be assigned by IANA.

   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 nodes in a path.

   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.

   Timestamp Tuple list (Ingress Timestamp [0..n], Engress Timestamp
   [0..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 at engress 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]) 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 the reflected 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 enables hop-by-hop delay
   measurement 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].





Wang & Zhou             Expires January 11, 2021                [Page 8]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


          +------------+------------------------+---------------+
          | 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 document introduces new TLV extensions 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>.







Wang & Zhou             Expires January 11, 2021                [Page 9]


Internet-Draft   draft-wang-ippm-stamp-hbh-extensions-00       July 2020


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

































Wang & Zhou             Expires January 11, 2021               [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/