doc: Add RFC documents

1 files changed, 1512 insertions, 0 deletions

diff --git a/doc/rfc/rfc8972.txt b/doc/rfc/rfc8972.txt
new file mode 100644
index 0000000..71e3577
--- /dev/null
+++ b/doc/rfc/rfc8972.txt
@@ -0,0 +1,1512 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         G. Mirsky
+Request for Comments: 8972                                        X. Min
+Updates: 8762                                                  ZTE Corp.
+Category: Standards Track                                      H. Nydell
+ISSN: 2070-1721                                        Accedian Networks
+                                                                R. Foote
+                                                                   Nokia
+                                                             A. Masputra
+                                                              Apple Inc.
+                                                              E. Ruffini
+                                                                  OutSys
+                                                            January 2021
+
+
+     Simple Two-Way Active Measurement Protocol Optional Extensions
+
+Abstract
+
+   This document describes optional extensions to Simple Two-way Active
+   Measurement Protocol (STAMP) that enable measurement of performance
+   metrics.  The document also defines a STAMP Test Session Identifier
+   and thus updates RFC 8762.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8972.
+
+Copyright Notice
+
+   Copyright (c) 2021 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.  Conventions Used in This Document
+     2.1.  Acronyms
+     2.2.  Requirements Language
+   3.  STAMP Test Session Identifier
+   4.  TLV Extensions to STAMP
+     4.1.  Extra Padding TLV
+     4.2.  Location TLV
+       4.2.1.  Location Sub-TLVs
+       4.2.2.  Theory of Operation of Location TLV
+     4.3.  Timestamp Information TLV
+     4.4.  Class of Service TLV
+     4.5.  Direct Measurement TLV
+     4.6.  Access Report TLV
+     4.7.  Follow-Up Telemetry TLV
+     4.8.  HMAC TLV
+   5.  IANA Considerations
+     5.1.  STAMP TLV Types Subregistry
+     5.2.  STAMP TLV Flags Subregistry
+     5.3.  STAMP Sub-TLV Types Subregistry
+     5.4.  STAMP Synchronization Sources Subregistry
+     5.5.  STAMP Timestamping Methods Subregistry
+     5.6.  STAMP Return Codes Subregistry
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   The Simple Two-way Active Measurement Protocol (STAMP) [RFC8762]
+   defines the STAMP base functionalities.  This document specifies the
+   use of optional extensions that use Type-Length-Value (TLV) encoding.
+   Such extensions enhance the STAMP base functions, such as measurement
+   of one-way and round-trip delay, latency, packet loss, packet
+   duplication, and out-of-order delivery of test packets.  This
+   specification defines optional STAMP extensions, their formats, and
+   the theory of operation.  Also, a STAMP Test Session Identifier is
+   defined as an update of the base STAMP specification [RFC8762].
+
+2.  Conventions Used in This Document
+
+2.1.  Acronyms
+
+   BDS         BeiDou Navigation Satellite System
+
+   BITS        Building Integrated Timing Supply
+
+   CoS         Class of Service
+
+   DSCP        Differentiated Services Code Point
+
+   ECN         Explicit Congestion Notification
+
+   GLONASS     Global Orbiting Navigation Satellite System
+
+   GPS         Global Positioning System [GPS]
+
+   HMAC        Hashed Message Authentication Code
+
+   LORAN-C     Long Range Navigation System Version C
+
+   MBZ         Must Be Zero
+
+   NTP         Network Time Protocol [RFC5905]
+
+   PMF         Performance Measurement Function
+
+   PTP         Precision Time Protocol [IEEE.1588.2008]
+
+   RP          Reverse Path
+
+   SMI         Structure of Management Information
+
+   SSID        STAMP Session Identifier
+
+   SSU         Synchronization Supply Unit
+
+   STAMP       Simple Two-way Active Measurement Protocol
+
+   TLV         Type-Length-Value
+
+2.2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  STAMP Test Session Identifier
+
+   The STAMP Session-Sender transmits test packets to the STAMP Session-
+   Reflector.  The STAMP Session-Reflector receives the Session-Sender's
+   packet and acts according to the configuration and optional control
+   information communicated in the Session-Sender's test packet.  STAMP
+   defines two different test packet formats: one for packets
+   transmitted by the STAMP Session-Sender and one for packets
+   transmitted by the STAMP Session-Reflector.  STAMP supports two
+   modes: unauthenticated and authenticated.  Unauthenticated STAMP test
+   packets are compatible on the wire with unauthenticated TWAMP-Test
+   [RFC5357] packets.
+
+   By default, STAMP uses symmetrical packets, i.e., the size of the
+   packet transmitted by the Session-Reflector equals the size of the
+   packet received by the Session-Reflector.
+
+   A STAMP Session is identified by the 4-tuple (source and destination
+   IP addresses, source and destination UDP port numbers).  A STAMP
+   Session-Sender MAY generate a locally unique STAMP Session Identifier
+   (SSID).  The SSID is a two-octet, non-zero unsigned integer.  The
+   SSID generation policy is implementation specific.  [NUM-IDS-GEN]
+   thoroughly analyzes common algorithms for identifier generation and
+   their vulnerabilities.  For example, an implementation can use the
+   algorithms described in Section 7.1 of [NUM-IDS-GEN].  An
+   implementation MUST NOT assign the same identifier to different STAMP
+   test sessions.  A Session-Sender MAY use the SSID to identify a STAMP
+   test session.  If the SSID is used, it MUST be present in each test
+   packet of the given test session.  In the unauthenticated mode, the
+   SSID is located as displayed in Figure 1.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Sequence Number                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Timestamp                            |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Error Estimate        |             SSID              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                                                               |
+      |                         MBZ (28 octets)                       |
+      |                                                               |
+      |                                                               |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                            TLVs                               ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 1: The Format of an Extended STAMP Session-Sender Test
+                       Packet in Unauthenticated Mode
+
+   An implementation of the STAMP Session-Reflector that supports this
+   specification MUST identify a STAMP Session using the SSID in
+   combination with elements of the usual 4-tuple for the session.
+   Before a test session commences, a Session-Reflector MUST be
+   provisioned with all the elements that identify the STAMP Session.  A
+   STAMP Session-Reflector MUST discard non-matching STAMP test packets.
+   The means of provisioning the STAMP Session identification is outside
+   the scope of this specification.  A conforming implementation of a
+   STAMP Session-Reflector MUST copy the SSID value from the received
+   test packet and put it into the reflected packet, as displayed in
+   Figure 2.
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Sequence Number                        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Timestamp                            |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |         Error Estimate        |           SSID                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          Receive Timestamp                    |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                 Session-Sender Sequence Number                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                  Session-Sender Timestamp                     |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Session-Sender Error Estimate |           MBZ                 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |Ses-Sender TTL |                   MBZ                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                            TLVs                               ~
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 2: The Format of an Extended STAMP Session-Reflector Test
+                       Packet in Unauthenticated Mode
+
+   A STAMP Session-Reflector that does not support this specification
+   will return the zeroed SSID field in the reflected STAMP test packet.
+   The Session-Sender MAY stop the session if it receives a zeroed SSID
+   field.  An implementation of a Session-Sender MUST support control of
+   its behavior in such a scenario.  If the test session is not stopped,
+   the Session-Sender can, for example, send a base STAMP packet
+   [RFC8762] or continue transmitting STAMP test packets with the SSID.
+
+   The location of the SSID field in the authenticated mode is shown in
+   Figures 3 and 4.
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      Sequence Number                          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                      MBZ (12 octets)                          |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        Timestamp                              |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |        Error Estimate         |            SSID               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                                                               ~
+    |                         MBZ (68 octets)                       |
+    ~                                                               ~
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                       HMAC (16 octets)                        |
+    |                                                               |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                            TLVs                               ~
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 3: The Format of an Extended STAMP Session-Sender Test
+                        Packet in Authenticated Mode
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Sequence Number                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        MBZ (12 octets)                        |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Timestamp                            |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Error Estimate        |            SSID               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        MBZ (4 octets)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Receive Timestamp                      |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        MBZ (8 octets)                         |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Session-Sender Sequence Number                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        MBZ (12 octets)                        |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Session-Sender Timestamp                      |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Session-Sender Error Estimate |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                        MBZ (6 octets)                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |Ses-Sender TTL |                                               |
+      +-+-+-+-+-+-+-+-+                                               +
+      |                                                               |
+      |                        MBZ (15 octets)                        |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        HMAC (16 octets)                       |
+      |                                                               |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                            TLVs                               ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 4: The Format of an Extended STAMP Session-Reflector Test
+                        Packet in Authenticated Mode
+
+4.  TLV Extensions to STAMP
+
+   The Type-Length-Value (TLV) encoding scheme provides a flexible
+   extension mechanism for optional informational elements.  TLV is an
+   optional field in the STAMP test packet.  Multiple TLVs MAY be placed
+   in a STAMP test packet.  Additional TLVs may be enclosed within a
+   given TLV, subject to the semantics of the (outer) TLV in question.
+   TLVs have a one-octet STAMP TLV Flags field, a one-octet Type field,
+   and a two-octet Length field that is equal to the length of the Value
+   field in octets.  If a Type value for a TLV or sub-TLV is in the
+   range for Private Use [RFC8126], the length MUST be at least 4, and
+   the first four octets MUST be that vendor's Structure of Management
+   Information (SMI) Private Enterprise Code, as recorded in IANA's "SMI
+   Network Management Private Enterprise Codes" subregistry, in network
+   octet order.  The rest of the Value field is private to the vendor.
+   The following sections describe the use of TLVs for STAMP that extend
+   the STAMP capability beyond its base specification.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |STAMP TLV Flags|     Type      |           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                            Value                              ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 5: TLV Format in a STAMP Extended Packet
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  The detailed format and
+      interpretation of flags defined in this specification are below.
+
+   Type:  A one-octet field that characterizes the interpretation of the
+      Value field.  It is allocated by IANA, as specified in
+      Section 5.1.
+
+   Length:  A two-octet field equal to the length of the Value field in
+      octets.
+
+   Value:  A variable-length field.  Its interpretation and encoding are
+      determined by the value of the Type field.
+
+   All multi-byte fields in TLVs defined in this specification are in
+   network byte order.
+
+   The format of the STAMP TLV Flags is displayed in Figure 6, and the
+   location of flags is defined in Section 5.2.
+
+       0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+
+      |U|M|I|R|R|R|R|R|
+      +-+-+-+-+-+-+-+-+
+
+                      Figure 6: STAMP TLV Flags Format
+
+   The fields are defined as follows:
+
+   U (Unrecognized):  A one-bit flag.  A Session-Sender MUST set the U
+      flag to 1 before transmitting an extended STAMP test packet.  A
+      Session-Reflector MUST set the U flag to 1 if the Session-
+      Reflector has not understood the TLV.  Otherwise, the Session-
+      Reflector MUST set the U flag in the reflected packet to 0.
+
+   M (Malformed):  A one-bit flag.  A Session-Sender MUST set the M flag
+      to 0 before transmitting an extended STAMP test packet.  A
+      Session-Reflector MUST set the M flag to 1 if the Session-
+      Reflector determined the TLV is malformed, i.e., the Length field
+      value is not valid for the particular type, or the remaining
+      length of the extended STAMP packet is less than the size of the
+      TLV.  Otherwise, the Session-Reflector MUST set the M flag in the
+      reflected packet to 0.
+
+   I (Integrity):  A one-bit flag.  A Session-Sender MUST set the I flag
+      to 0 before transmitting an extended STAMP test packet.  A
+      Session-Reflector MUST set the I flag to 1 if the STAMP extensions
+      have failed HMAC verification (Section 4.8).  Otherwise, the
+      Session-Reflector MUST set the I flag in the reflected packet to
+      0.
+
+   R:  Reserved flags for future use.  These flags MUST be zeroed on
+      transmit and ignored on receipt.
+
+   A STAMP node, whether Session-Sender or Session-Reflector, receiving
+   a test packet MUST determine whether the packet is a base STAMP
+   packet or whether it includes one or more TLVs.  The node MUST
+   compare the value in the Length field of the UDP header and the
+   length of the base STAMP test packet in the mode, unauthenticated or
+   authenticated, based on the configuration of the particular STAMP
+   test session.  If the difference between the two values is greater
+   than the length of the UDP header, then the test packet includes one
+   or more STAMP TLVs that immediately follow the base STAMP test
+   packet.  A Session-Reflector that does not support STAMP extensions
+   will not process but copy them into the reflected packet, as defined
+   in Section 4.3 of [RFC8762].  A Session-Reflector that supports TLVs
+   will indicate specific TLVs that it did not process by setting the U
+   flag to 1 in those TLVs.
+
+   A STAMP Session-Sender that has received a reflected STAMP test
+   packet with extension TLVs MUST validate each TLV:
+
+   *  If the U flag is set, the STAMP system MUST skip the processing of
+      the TLV.
+
+   *  If the M flag is set, the STAMP system MUST stop processing the
+      remainder of the extended STAMP packet.
+
+   *  If the I flag is set, the STAMP system MUST discard all TLVs and
+      MUST stop processing the remainder of the extended STAMP packet.
+
+   *  If an implementation of a Session-Reflector does not recognize the
+      Type field value, it MUST include a copy of the TLV in the
+      reflected STAMP packet.  The Session-Reflector MUST set the U flag
+      to 1.  The Session-Reflector MUST skip the processing of the
+      unrecognized TLV.
+
+   *  If a TLV is malformed, the processing of extension TLVs MUST be
+      stopped.  The Session-Reflector MUST copy the remainder of the
+      received extended STAMP packet into the reflected STAMP packet.
+      The Session-Reflector MUST set the M flag to 1.
+
+
+4.1.  Extra Padding TLV
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |STAMP TLV Flags|      Type     |           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                         Extra Padding                         ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 7: Extra Padding TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 1 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field equal to the length of the Extra Padding
+      field in octets.
+
+   Extra Padding:  This field SHOULD be filled by a sequence of
+      pseudorandom numbers.  The field MAY be filled with all zeros.  An
+      implementation MUST control the content of the Extra Padding
+      field.
+
+   The Extra Padding TLV is similar to the Packet Padding field in a
+   TWAMP-Test packet [RFC5357].  The use of the Extra Padding TLV is
+   RECOMMENDED to perform a STAMP test using test packets that are
+   larger than the base STAMP packet [RFC8762].  The length of the base
+   STAMP packet is 44 octets in the unauthenticated mode or 112 octets
+   in the authenticated mode.  The Extra Padding TLV MAY be present more
+   than one time in an extended STAMP test packet.
+
+4.2.  Location TLV
+
+   STAMP Session-Senders MAY include the variable-size Location TLV to
+   query location information from the Session-Reflector.  The Session-
+   Sender MUST NOT fill any information fields except for the STAMP TLV
+   Flags, Type, and Length fields.  The Session-Reflector MUST verify
+   that the TLV is well formed.  If it is not, the Session-Reflector
+   follows the procedure defined in Section 4 for a malformed TLV.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |STAMP TLV Flags|      Type     |           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Destination Port       |          Source Port          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                         Sub-TLVs                              ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                           Figure 8: Location TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 2 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field equal to the length of the Value field in
+      octets.
+
+   Destination Port:  A two-octet UDP destination port number of the
+      received STAMP packet.
+
+   Source Port:  A two-octet UDP source port number of the received
+      STAMP packet.
+
+   Sub-TLVs:  A sequence of sub-TLVs, as defined further in this
+      section.  The sub-TLVs are used by the Session-Sender to request
+      location information with generic sub-TLV types, and the Session-
+      Reflector responds with the corresponding more-specific sub-TLVs
+      for the type of address (e.g., IPv4 or IPv6) used at the Session-
+      Reflector.
+
+   Note that all fields not filled by either a Session-Sender or
+   Session-Reflector are transmitted with all bits set to zero.
+
+4.2.1.  Location Sub-TLVs
+
+   A sub-TLV in the Location TLV uses the format displayed in Figure 5.
+   Handling of the U and M flags in the sub-TLV is as defined in
+   Section 4.  The I flag MUST be set by a Session-Sender and Session-
+   Reflector to 0 before transmission and its value ignored on receipt.
+   The following types of sub-TLVs for the Location TLV are defined in
+   this specification (Table 5 lists the Type values):
+
+   Source MAC Address sub-TLV:  A 12-octet sub-TLV.  The Type value is
+      1.  The value of the Length field MUST be equal to 8.  The Value
+      field is an 8-octet MBZ field that MUST be zeroed on transmission
+      and ignored on receipt.
+
+   Source EUI-48 Address sub-TLV:  A 12-octet sub-TLV that includes the
+      EUI-48 source MAC address.  The Type value is 2.  The value of the
+      Length field MUST be equal to 8.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        EUI-48  Address                        |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |            MBZ                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 9: The Value Field of the Source EUI-48 Address Sub-TLV
+
+      The Value field consists of the following fields (Figure 9):
+
+      EUI-48 Address:  A six-octet field.
+
+      MBZ:  A two-octet field.  It MUST be zeroed on transmission and
+         ignored on receipt.
+
+   Source EUI-64 Address sub-TLV:  A 12-octet sub-TLV that includes the
+      EUI-64 source MAC address.  The Type value is 3.  The value of the
+      Length field MUST be equal to 8.  The Value field consists of an
+      eight-octet EUI-64 field.
+
+   Destination IP Address sub-TLV:  A 20-octet sub-TLV.  The Type value
+      is 4.  The value of the Length field MUST be equal to 16.  The
+      Value field consists of a 16-octet MBZ field that MUST be zeroed
+      on transmit and ignored on receipt.
+
+   Destination IPv4 Address sub-TLV:  A 20-octet sub-TLV that includes
+      the IPv4 destination address.  The Type value is 5.  The value of
+      the Length field MUST be equal to 16.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         IPv4 Address                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                        MBZ (12 octets)                        ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 10: IPv4 Address in a Sub-TLV's Value Field
+
+      The Value field consists of the following fields (Figure 10):
+
+      IPv4 Address:  A four-octet field.
+
+      MBZ:  A 12-octet field.  It MUST be zeroed on transmit and ignored
+         on receipt.
+
+   Destination IPv6 Address sub-TLV:  A 20-octet sub-TLV that includes
+      the IPv6 destination address.  The Type value is 6.  The value of
+      the Length field MUST be equal to 16.  The Value field is a
+      16-octet IPv6 Address field.
+
+   Source IP Address sub-TLV:  A 20-octet sub-TLV.  The Type value is 7.
+      The value of the Length field MUST be equal to 16.  The Value
+      field is a 16-octet MBZ field that MUST be zeroed on transmit and
+      ignored on receipt.
+
+   Source IPv4 Address sub-TLV:  A 20-octet sub-TLV that includes the
+      IPv4 source address.  The Type value is 8.  The value of the
+      Length field MUST be equal to 16.  The Value field consists of the
+      following fields (Figure 10):
+
+      IPv4 Address:  A four-octet field.
+
+      MBZ:  A 12-octet field.  It MUST be zeroed on transmit and ignored
+         on receipt.
+
+   Source IPv6 Address sub-TLV:  A 20-octet sub-TLV that includes the
+      IPv6 source address.  The Type value is 9.  The value of the
+      Length field MUST be equal to 16.  The Value field is a 16-octet
+      IPv6 Address field.
+
+4.2.2.  Theory of Operation of Location TLV
+
+   The Session-Reflector that received an extended STAMP packet with the
+   Location TLV MUST include in the reflected packet the Location TLV
+   with a length equal to the Location TLV length in the received
+   packet.  Based on the local policy, the Session-Reflector MAY leave
+   some fields unreported by filling them with zeroes.  An
+   implementation of the stateful Session-Reflector MUST provide control
+   for managing such policies.
+
+   A Session-Sender MAY include the Source MAC Address sub-TLV in the
+   Location TLV.  If the Session-Reflector receives the Location TLV
+   that includes the Source MAC Address sub-TLV, it MUST include the
+   Source EUI-48 Address sub-TLV if the source MAC address of the
+   received extended test packet is in EUI-48 format.  And the Session-
+   Reflector MUST copy the value of the source MAC address in the EUI-48
+   field.  Otherwise, the Session-Reflector MUST use the Source EUI-64
+   Address sub-TLV and MUST copy the value of the Source MAC Address
+   from the received packet into the EUI-64 field.  If the received
+   extended STAMP test packet does not have the Source MAC Address, the
+   Session-Reflector MUST zero the EUI-64 field before transmitting the
+   reflected packet.
+
+   A Session-Sender MAY include the Destination IP Address sub-TLV in
+   the Location TLV.  If the Session-Reflector receives the Location TLV
+   that includes the Destination IP Address sub-TLV, it MUST include the
+   Destination IPv4 Address sub-TLV if the source IP address of the
+   received extended test packet is of the IPv4 address family.  And the
+   Session-Reflector MUST copy the value of the destination IP address
+   in the IPv4 Address field.  Otherwise, the Session-Reflector MUST use
+   the Destination IPv6 Address sub-TLV and MUST copy the value of the
+   destination IP address from the received packet into the IPv6 Address
+   field.
+
+   A Session-Sender MAY include the Source IP Address sub-TLV in the
+   Location TLV.  If the Session-Reflector receives the Location TLV
+   that includes the Source IP Address sub-TLV, it MUST include the
+   Source IPv4 Address sub-TLV if the source IP address of the received
+   extended test packet is of the IPv4 address family.  And the Session-
+   Reflector MUST copy the value of the source IP address in the IPv4
+   Address field.  Otherwise, the Session-Reflector MUST use the Source
+   IPv6 Address sub-TLV and MUST copy the value of the source IP address
+   from the received packet into the IPv6 Address field.
+
+   The Location TLV MAY be used to determine the last-hop IP addresses,
+   ports, and last-hop MAC address for STAMP packets.  The MAC address
+   can indicate a path switch on the last hop.  The IP addresses and UDP
+   ports will indicate if there is a NAT router on the path.  It allows
+   the Session-Sender to identify the IP address of the Session-
+   Reflector behind the NAT and detect changes in the NAT mapping that
+   could result in sending the STAMP packets to the wrong Session-
+   Reflector.
+
+4.3.  Timestamp Information TLV
+
+   The STAMP Session-Sender MAY include the Timestamp Information TLV to
+   request information from the Session-Reflector.  The Session-Sender
+   MUST NOT fill any information fields except for STAMP TLV Flags,
+   Type, and Length.  All other fields MUST be filled with zeroes.  The
+   Session-Reflector MUST validate the Length value of the TLV.  If the
+   value of the Length field is invalid, the Session-Reflector follows
+   the procedure defined in Section 4 for a malformed TLV.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |STAMP TLV Flags|      Type     |           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Sync Src In  | Timestamp In  | Sync Src Out  | Timestamp Out |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                    Optional sub-TLVs                          ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 11: Timestamp Information TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 3 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field, set equal to the length of the Value
+      field in octets (Figure 5).
+
+   Sync Src In:  A one-octet field that characterizes the source of
+      clock synchronization at the ingress of a Session-Reflector.
+      There are several methods for synchronizing the clock, e.g., the
+      Network Time Protocol (NTP) [RFC5905].  Table 7 lists the possible
+      values.
+
+   Timestamp In:  A one-octet field that characterizes the method by
+      which the ingress of the Session-Reflector obtained the timestamp
+      T2.  A timestamp may be obtained with hardware assistance via a
+      software API from a local wall clock or from a remote clock (the
+      latter is referred to as a "control plane").  Table 9 lists the
+      possible values.
+
+   Sync Src Out:  A one-octet field that characterizes the source of
+      clock synchronization at the egress of the Session-Reflector.
+      Table 7 lists the possible values.
+
+   Timestamp Out:  A one-octet field that characterizes the method by
+      which the egress of the Session-Reflector obtained the timestamp
+      T3.  Table 9 lists the possible values.
+
+   Optional sub-TLVs:  An optional variable-length field.
+
+4.4.  Class of Service TLV
+
+   The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in
+   the STAMP test packet.  The format of the CoS TLV is presented in
+   Figure 12.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |STAMP TLV Flags|      Type     |           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   DSCP1   |   DSCP2   |ECN| RP|          Reserved             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 12: Class of Service TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 4 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field, set equal to the value 4.
+
+   DSCP1:  The Differentiated Services Code Point (DSCP) intended by the
+      Session-Sender to be used as the DSCP value of the reflected test
+      packet.
+
+   DSCP2:  The received value in the DSCP field at the ingress of the
+      Session-Reflector.
+
+   ECN:  The received value in the ECN field at the ingress of the
+      Session-Reflector.
+
+   RP (Reverse Path):  A two-bit field.  A Session-Sender MUST set the
+      value of the RP field to 0 on transmission.
+
+   Reserved:  A 16-bit field that MUST be zeroed on transmission and
+      ignored on receipt.
+
+   A STAMP Session-Reflector that receives a test packet with the CoS
+   TLV MUST include the CoS TLV in the reflected test packet.  Also, the
+   Session-Reflector MUST copy the value of the DSCP and ECN fields of
+   the IP header of the received STAMP test packet into the DSCP2 field
+   in the reflected test packet.  Finally, the Session-Reflector MUST
+   use the local policy to verify whether the CoS corresponding to the
+   value of the DSCP1 field is permitted in the domain.  If it is, the
+   Session-Reflector MUST set the DSCP field's value in the IP header of
+   the reflected test packet equal to the value of the DSCP1 field of
+   the received test packet.  Otherwise, the Session-Reflector MUST use
+   the DSCP value of the received STAMP packet and set the value of the
+   RP field to 1.  Upon receiving the reflected packet, if the value of
+   the RP field is 0, the Session-Sender will save the DSCP and ECN
+   values for analysis of the CoS in the reverse direction.  If the
+   value of the RP field in the received reflected packet is 1, only CoS
+   in the forward direction can be analyzed.
+
+   Re-mapping of CoS can be used to provide multiple services (e.g., 2G,
+   3G, LTE in mobile backhaul networks) over the same network.  But if
+   it is misconfigured, then it is often difficult to diagnose the root
+   cause of excessive packet drops of higher-level service while packet
+   drops for lower service packets are at a normal level.  Using a CoS
+   TLV in STAMP testing helps to troubleshoot the existing problem and
+   also verify whether Diffserv policies are processing CoS as required
+   by the configuration.
+
+4.5.  Direct Measurement TLV
+
+   The Direct Measurement TLV enables collection of the number of in-
+   profile packets, i.e., packets that form a specific data flow, that
+   had been transmitted and received by the Session-Sender and Session-
+   Reflector, respectively.  The definition of "in-profile packet" is
+   outside the scope of this document and is left to the test operators
+   to determine.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |STAMP TLV Flags|      Type     |           Length              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Session-Sender Tx counter  (S_TxC)               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Session-Reflector Rx counter  (R_RxC)             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Session-Reflector Tx counter  (R_TxC)             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 13: Direct Measurement TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 5 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field equal to the length of the Value field in
+      octets.  The Length field value MUST equal 12 octets.
+
+   Session-Sender Tx counter (S_TxC):  A four-octet field.  The Session-
+      Sender MUST set its value equal to the number of the transmitted
+      in-profile packets.
+
+   Session-Reflector Rx counter (R_RxC):  A four-octet field.  It MUST
+      be zeroed by the Session-Sender on transmit and ignored by the
+      Session-Reflector on receipt.  The Session-Reflector MUST fill it
+      with the value of in-profile packets received.
+
+   Session-Reflector Tx counter (R_TxC):  A four-octet field.  It MUST
+      be zeroed by the Session-Sender and ignored by the Session-
+      Reflector on receipt.  The Session-Reflector MUST fill it with the
+      value of the transmitted in-profile packets.
+
+   A Session-Sender MAY include the Direct Measurement TLV in a STAMP
+   test packet.  If the received STAMP test packet includes the Direct
+   Measurement TLV, the Session-Reflector MUST include it in the
+   reflected test packet.  The Session-Reflector MUST copy the value
+   from the S_TxC field of the received test packet into the same field
+   of the reflected packet before its transmission.
+
+4.6.  Access Report TLV
+
+   A STAMP Session-Sender MAY include an Access Report TLV (Figure 14)
+   to indicate changes to the access network status to the Session-
+   Reflector.  The definition of an access network is outside the scope
+   of this document.
+
+        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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |STAMP TLV Flags|     Type      |           Length              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |   ID  |  Resv |  Return Code  |          Reserved             |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 14: Access Report TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 6 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field, set equal to the value 4.
+
+   ID (Access ID):  A four-bit field that identifies the access network,
+      e.g., 3GPP (Radio Access Technologies specified by 3GPP) or non-
+      3GPP (accesses that are not specified by 3GPP) [TS23501].  The
+      value is one of the following:
+
+      1:  3GPP Network
+
+      2:  Non-3GPP Network
+
+      All other values are invalid; a TLV that contains values other
+      than '1' or '2' MUST be discarded.
+
+   Resv:  A four-bit field that MUST be zeroed on transmission and
+      ignored on receipt.
+
+   Return Code:  A one-octet field that identifies the report signal,
+      e.g., available or unavailable.  The value is supplied to the
+      STAMP endpoint through some mechanism that is outside the scope of
+      this document.  Section 5.6 lists the possible values.
+
+   Reserved:  A two-octet field that MUST be zeroed on transmission and
+      ignored on receipt.
+
+   The STAMP Session-Sender that includes the Access Report TLV sets the
+   value of the Access ID field according to the type of access network
+   it reports on.  Also, the Session-Sender sets the value of the Return
+   Code field to reflect the operational state of the access network.
+   The mechanism to determine the state of the access network is outside
+   the scope of this specification.  A STAMP Session-Reflector that
+   received the test packet with the Access Report TLV MUST include the
+   Access Report TLV in the reflected test packet.  The Session-
+   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
+   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 reception of the reflected STAMP test packet that
+   includes the 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 and the network environment.  The default
+   value of the retransmission timer for the 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
+   (PMF) components of the Access Steering, Switching, and Splitting
+   feature for 5G networks [TS23501].  The PMF component in the User
+   Equipment acts as the STAMP Session-Sender, and the PMF component in
+   the User Plane Function acts as the STAMP Session-Reflector.
+
+4.7.  Follow-Up Telemetry TLV
+
+   A Session-Reflector might be able to put only an "SW Local" (see
+   Table 9) timestamp in the Follow-Up Timestamp field.  But the hosting
+   system might provide a timestamp closer to the start of the actual
+   packet transmission even though it is not possible to deliver the
+   information to the Session-Sender in time for the packet itself.
+   This timestamp might nevertheless be important for the Session-
+   Sender, as it improves the accuracy of network delay measurement 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.  The Sequence Number and Follow-Up 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 the Sequence Number and Follow-Up Timestamp fields and set
+   the M flag in the STAMP TLV Flags field in the reflected packet.  If
+   the Session-Reflector is in the stateless mode (defined in
+   Section 4.2 of [RFC8762]), it MUST zero the Sequence Number and
+   Follow-Up 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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |STAMP TLV Flags|      Type     |           Length              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        Sequence Number                        |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                      Follow-Up Timestamp                      |
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |  Timestamp M  |                     Reserved                  |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 15: Follow-Up Telemetry TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 7 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field, set equal to the value 16 octets.
+
+   Sequence Number:  A four-octet 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 of [RFC8762]), it is the Session-Reflector's Sequence
+      Number of the previous reflected packet.
+
+   Follow-Up Timestamp:  An eight-octet field, with the format indicated
+      by the Z flag of the Error Estimate field of the STAMP base
+      packet, which is contained in this reflected test packet
+      transmitted by a Session-Reflector, as described in Section 4.2.1
+      of [RFC8762].  It carries the timestamp when the reflected packet
+      with the specified sequence number was sent.
+
+   Timestamp M(ode):  A one-octet field that characterizes the method by
+      which the entity that transmits a reflected STAMP packet obtained
+      the Follow-Up Timestamp.  Table 9 lists the possible values.
+
+   Reserved:  A three-octet field.  Its value MUST be zeroed on
+      transmission and ignored on receipt.
+
+4.8.  HMAC TLV
+
+   The STAMP authenticated mode protects the integrity of data collected
+   in the STAMP base packet.  STAMP extensions are designed to provide
+   valuable information about the condition of a network, and protecting
+   the integrity of that data is also essential.  All authenticated
+   STAMP base packets (per Sections 4.2.2 and 4.3.2 of [RFC8762])
+   compatible with this specification MUST additionally authenticate the
+   optional TLVs by including the keyed Hashed Message Authentication
+   Code (HMAC) TLV, with the sole exception of when there is only one
+   TLV present and it is the Extended Padding TLV.  The HMAC TLV MUST
+   follow all TLVs included in a STAMP test packet except for the Extra
+   Padding TLV.  If the HMAC TLV appears in any other position in a
+   STAMP extended test packet, then the situation MUST be processed as
+   HMAC verification failure, as defined below in this section.  The
+   HMAC TLV MAY be used to protect the integrity of STAMP extensions in
+   the STAMP unauthenticated mode.  An implementation of STAMP
+   extensions MUST provide controls to enable the integrity protection
+   of STAMP extensions in the STAMP unauthenticated mode.
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |STAMP TLV Flags|      Type     |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                              HMAC                             |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                            Figure 16: HMAC TLV
+
+   The fields are defined as follows:
+
+   STAMP TLV Flags:  An eight-bit field.  Its format is presented in
+      Figure 6.
+
+   Type:  A one-octet field.  Value 8 has been allocated by IANA
+      (Section 5.1).
+
+   Length:  A two-octet field, set equal to the value 16 octets.
+
+   HMAC:  A 16-octet field that carries the HMAC digest of the text of
+      all preceding TLVs.
+
+   As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
+   bits (see [RFC4868]).  All considerations regarding using the key
+   listed in Section 4.4 of [RFC8762] are fully applicable to the use of
+   the HMAC TLV.  Key management and the mechanisms to distribute the
+   HMAC key are outside the scope of this specification.  The HMAC TLV
+   is anticipated to track updates in the base STAMP protocol [RFC8762],
+   including the use of more advanced cryptographic algorithms.  HMAC is
+   calculated as defined in [RFC2104] over text as the concatenation of
+   the Sequence Number field of the base STAMP packet and all preceding
+   TLVs.  The digest then MUST be truncated to 128 bits and written into
+   the HMAC field.  If the HMAC TLV is present in the extended STAMP
+   test packet, e.g., in the authenticated mode, HMAC MUST be verified
+   before using any data in the included STAMP TLVs.  If HMAC
+   verification by the Session-Reflector fails, then the Session-
+   Reflector MUST stop processing the received extended STAMP test
+   packet.  The Session-Reflector MUST copy the TLVs from the received
+   STAMP test packet into the reflected packet.  The Session-Reflector
+   MUST set the I flag in each TLV copied over into the reflected packet
+   to 1 before transmitting the reflected test packet.  If the Session-
+   Sender receives the extended STAMP test packet with I flag set to 1,
+   then the Session-Sender MUST stop processing TLVs in the reflected
+   test packet.  If HMAC verification by the Session-Sender fails, then
+   the Session-Sender MUST stop processing TLVs in the reflected
+   extended STAMP packet.
+
+5.  IANA Considerations
+
+   IANA has created the following subregistries under the "Simple Two-
+   way Active Measurement Protocol (STAMP) TLV Types" registry.
+
+5.1.  STAMP TLV Types Subregistry
+
+   IANA has created the "STAMP TLV Types" subregistry.  The code points
+   in this registry are allocated according to the registration
+   procedures [RFC8126] described in Table 1.
+
+                  +===========+=========================+
+                  | Range     | Registration Procedures |
+                  +===========+=========================+
+                  | 1 - 175   |       IETF Review       |
+                  +-----------+-------------------------+
+                  | 176 - 239 | First Come First Served |
+                  +-----------+-------------------------+
+                  | 240 - 251 |     Experimental Use    |
+                  +-----------+-------------------------+
+                  | 252 - 254 |       Private Use       |
+                  +-----------+-------------------------+
+
+                      Table 1: Registration Procedures
+                    for the STAMP TLV Types Subregistry
+
+   Per this document, IANA has allocated the following values in the
+   "STAMP TLV Types" subregistry:
+
+               +=======+=======================+===========+
+               | Value |      Description      | Reference |
+               +=======+=======================+===========+
+               | 0     |        Reserved       | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 1     |     Extra Padding     | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 2     |        Location       | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 3     | Timestamp Information | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 4     |    Class of Service   | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 5     |   Direct Measurement  | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 6     |     Access Report     | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 7     |  Follow-Up Telemetry  | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 8     |          HMAC         | RFC 8972  |
+               +-------+-----------------------+-----------+
+               | 255   |        Reserved       | RFC 8972  |
+               +-------+-----------------------+-----------+
+
+                          Table 2: STAMP TLV Types
+
+5.2.  STAMP TLV Flags Subregistry
+
+   IANA has created the "STAMP TLV Flags" subregistry.  The registration
+   procedure is "IETF Review" [RFC8126].  The flags are 8 bits.  Per
+   this document, IANA has allocated the following bit positions in the
+   "STAMP TLV Flags" subregistry.
+
+      +==============+========+========================+===========+
+      | Bit position | Symbol |      Description       | Reference |
+      +==============+========+========================+===========+
+      |      0       |   U    |    Unrecognized TLV    |  RFC 8972 |
+      +--------------+--------+------------------------+-----------+
+      |      1       |   M    |     Malformed TLV      |  RFC 8972 |
+      +--------------+--------+------------------------+-----------+
+      |      2       |   I    | Integrity check failed |  RFC 8972 |
+      +--------------+--------+------------------------+-----------+
+
+                         Table 3: STAMP TLV Flags
+
+5.3.  STAMP Sub-TLV Types Subregistry
+
+   IANA has created the "STAMP Sub-TLV Types" subregistry.  The code
+   points in this registry are allocated according to the registration
+   procedures [RFC8126] described in Table 4.
+
+                  +===========+=========================+
+                  |   Range   | Registration Procedures |
+                  +===========+=========================+
+                  | 1 - 175   |       IETF Review       |
+                  +-----------+-------------------------+
+                  | 176 - 239 | First Come First Served |
+                  +-----------+-------------------------+
+                  | 240 - 251 |     Experimental Use    |
+                  +-----------+-------------------------+
+                  | 252 - 254 |       Private Use       |
+                  +-----------+-------------------------+
+
+                      Table 4: Registration Procedures
+                        for the STAMP Sub-TLV Types
+                                Subregistry
+
+   Per this document, IANA has allocated the following values in the
+   "STAMP Sub-TLV Types" subregistry:
+
+        +=======+==========================+==========+===========+
+        | Value |       Description        | TLV Used | Reference |
+        +=======+==========================+==========+===========+
+        | 0     |         Reserved         |          | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 1     |    Source MAC Address    | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 2     |  Source EUI-48 Address   | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 3     |  Source EUI-64 Address   | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 4     |  Destination IP Address  | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 5     | Destination IPv4 Address | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 6     | Destination IPv6 Address | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 7     |    Source IP Address     | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 8     |   Source IPv4 Address    | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 9     |   Source IPv6 Address    | Location | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+        | 255   |         Reserved         |          | RFC 8972  |
+        +-------+--------------------------+----------+-----------+
+
+                        Table 5: STAMP Sub-TLV Types
+
+5.4.  STAMP Synchronization Sources Subregistry
+
+   IANA has created the "STAMP Synchronization Sources" subregistry.
+   The code points in this registry are allocated according to the
+   registration procedures [RFC8126] described in Table 6.
+
+                  +===========+=========================+
+                  | Range     | Registration Procedures |
+                  +===========+=========================+
+                  | 1 - 127   |       IETF Review       |
+                  +-----------+-------------------------+
+                  | 128 - 239 | First Come First Served |
+                  +-----------+-------------------------+
+                  | 240 - 249 |     Experimental Use    |
+                  +-----------+-------------------------+
+                  | 250 - 254 |       Private Use       |
+                  +-----------+-------------------------+
+
+                      Table 6: Registration Procedures
+                       for the STAMP Synchronization
+                            Sources Subregistry
+
+   Per this document, IANA has allocated the following values in the
+   "STAMP Synchronization Sources" subregistry:
+
+          +=======+=================================+===========+
+          | Value |           Description           | Reference |
+          +=======+=================================+===========+
+          | 0     |             Reserved            | RFC 8972  |
+          +-------+---------------------------------+-----------+
+          | 1     |               NTP               | RFC 8972  |
+          +-------+---------------------------------+-----------+
+          | 2     |               PTP               | RFC 8972  |
+          +-------+---------------------------------+-----------+
+          | 3     |             SSU/BITS            | RFC 8972  |
+          +-------+---------------------------------+-----------+
+          | 4     | GPS/GLONASS/LORAN-C/BDS/Galileo | RFC 8972  |
+          +-------+---------------------------------+-----------+
+          | 5     |        Local free-running       | RFC 8972  |
+          +-------+---------------------------------+-----------+
+          | 255   |             Reserved            | RFC 8972  |
+          +-------+---------------------------------+-----------+
+
+                   Table 7: STAMP Synchronization Sources
+
+5.5.  STAMP Timestamping Methods Subregistry
+
+   IANA has created the "STAMP Timestamping Methods" subregistry.  The
+   code points in this registry are allocated according to the
+   registration procedures [RFC8126] described in Table 8.
+
+                  +===========+=========================+
+                  | Range     | Registration Procedures |
+                  +===========+=========================+
+                  | 1 - 127   |       IETF Review       |
+                  +-----------+-------------------------+
+                  | 128 - 239 | First Come First Served |
+                  +-----------+-------------------------+
+                  | 240 - 249 |     Experimental Use    |
+                  +-----------+-------------------------+
+                  | 250 - 254 |       Private Use       |
+                  +-----------+-------------------------+
+
+                      Table 8: Registration Procedures
+                     for the STAMP Timestamping Methods
+                                Subregistry
+
+   Per this document, IANA has allocated the following values in the
+   "STAMP Timestamping Methods" subregistry:
+
+                   +=======+===============+===========+
+                   | Value |  Description  | Reference |
+                   +=======+===============+===========+
+                   | 0     |    Reserved   | RFC 8972  |
+                   +-------+---------------+-----------+
+                   | 1     |   HW Assist   | RFC 8972  |
+                   +-------+---------------+-----------+
+                   | 2     |    SW Local   | RFC 8972  |
+                   +-------+---------------+-----------+
+                   | 3     | Control Plane | RFC 8972  |
+                   +-------+---------------+-----------+
+                   | 255   |    Reserved   | RFC 8972  |
+                   +-------+---------------+-----------+
+
+                    Table 9: STAMP Timestamping Methods
+
+5.6.  STAMP Return Codes Subregistry
+
+   IANA has created the "STAMP Return Codes" subregistry.  The code
+   points in this registry are allocated according to the registration
+   procedures [RFC8126] described in Table 10.
+
+                  +===========+=========================+
+                  | Range     | Registration Procedures |
+                  +===========+=========================+
+                  | 1 - 127   |       IETF Review       |
+                  +-----------+-------------------------+
+                  | 128 - 239 | First Come First Served |
+                  +-----------+-------------------------+
+                  | 240 - 249 |     Experimental Use    |
+                  +-----------+-------------------------+
+                  | 250 - 254 |       Private Use       |
+                  +-----------+-------------------------+
+
+                     Table 10: Registration Procedures
+                         for the STAMP Return Codes
+                                Subregistry
+
+   Per this document, IANA has allocated the following values in the
+   "STAMP Return Codes" subregistry:
+
+                +=======+=====================+===========+
+                | Value |     Description     | Reference |
+                +=======+=====================+===========+
+                | 0     |       Reserved      | RFC 8972  |
+                +-------+---------------------+-----------+
+                | 1     |  Network available  | RFC 8972  |
+                +-------+---------------------+-----------+
+                | 2     | Network unavailable | RFC 8972  |
+                +-------+---------------------+-----------+
+                | 255   |       Reserved      | RFC 8972  |
+                +-------+---------------------+-----------+
+
+                        Table 11: STAMP Return Codes
+
+6.  Security Considerations
+
+   This document defines extensions to STAMP [RFC8762] and inherits all
+   the security considerations applicable to the base protocol.
+   Additionally, the HMAC TLV is defined in this document.  Though the
+   HMAC TLV protects the integrity of STAMP extensions, it does not
+   protect against a replay attack.  The use of the HMAC TLV is
+   discussed in detail in Section 4.8.
+
+   To protect against a malformed TLV, an implementation of a Session-
+   Sender and Session-Reflector MUST:
+
+   *  check the setting of the M flag and
+
+   *  validate the Length field value.
+
+   As this specification defines the mechanism to test DSCP mapping,
+   this document inherits all the security considerations discussed in
+   [RFC2474].  Monitoring and optional control of DSCP using the CoS TLV
+   may be used across the Internet so that the Session-Sender and the
+   Session-Reflector are located in domains that use different CoS
+   profiles.  Thus, it is essential that an operator verify the set of
+   CoS values that is used in the Session-Reflector's domain.  Also, an
+   implementation of a Session-Reflector SHOULD support a local policy
+   to confirm whether the value sent by the Session-Sender can be used
+   as the value of the DSCP field.  Section 4.4 defines the use of that
+   local policy.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <https://www.rfc-editor.org/info/rfc2104>.
+
+   [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>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
+              Two-Way Active Measurement Protocol", RFC 8762,
+              DOI 10.17487/RFC8762, March 2020,
+              <https://www.rfc-editor.org/info/rfc8762>.
+
+7.2.  Informative References
+
+   [GPS]      "Global Positioning System (GPS) Standard Positioning
+              Service (SPS) Performance Standard", GPS SPS 5th Edition,
+              April 2020.
+
+   [IEEE.1588.2008]
+              "IEEE Standard for a Precision Clock Synchronization
+              Protocol for Networked Measurement and Control Systems",
+              IEEE Std. 1588-2008, DOI 10.1109/IEEESTD.2008.4579760,
+              July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
+
+   [NUM-IDS-GEN]
+              Gont, F. and I. Arce, "On the Generation of Transient
+              Numeric Identifiers", Work in Progress, Internet-Draft,
+              draft-irtf-pearg-numeric-ids-generation-06, 13 January
+              2021, <https://tools.ietf.org/html/draft-irtf-pearg-
+              numeric-ids-generation-06>.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474,
+              DOI 10.17487/RFC2474, December 1998,
+              <https://www.rfc-editor.org/info/rfc2474>.
+
+   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
+              384, and HMAC-SHA-512 with IPsec", RFC 4868,
+              DOI 10.17487/RFC4868, May 2007,
+              <https://www.rfc-editor.org/info/rfc4868>.
+
+   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
+              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
+              RFC 5357, DOI 10.17487/RFC5357, October 2008,
+              <https://www.rfc-editor.org/info/rfc5357>.
+
+   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+              "Network Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
+              <https://www.rfc-editor.org/info/rfc5905>.
+
+   [TS23501]  3GPP, "Technical Specification Group Services and System
+              Aspects; System Architecture for the 5G System (5GS);
+              Stage 2 (Release 16)", 3GPP TS 23.501, 2019.
+
+Acknowledgments
+
+   The authors very much appreciate the thorough review and thoughtful
+   comments received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song,
+   and Yali Wang.  The authors express their gratitude to Al Morton for
+   his comments and valuable suggestions.  The authors greatly
+   appreciate the comments and thoughtful suggestions received from
+   Martin Duke.
+
+Contributors
+
+   The following individual contributed text to this document:
+
+   Guo Jun
+   ZTE Corporation
+   68# Zijinghua Road
+   Nanjing
+   Jiangsu, 210012
+   China
+
+   Phone: +86 18105183663
+   Email: guo.jun2@zte.com.cn
+
+
+Authors' Addresses
+
+   Greg Mirsky
+   ZTE Corp.
+
+   Email: gregimirsky@gmail.com
+
+
+   Xiao Min
+   ZTE Corp.
+
+   Email: xiao.min2@zte.com.cn
+
+
+   Henrik Nydell
+   Accedian Networks
+
+   Email: hnydell@accedian.com
+
+
+   Richard Foote
+   Nokia
+
+   Email: footer.foote@nokia.com
+
+
+   Adi Masputra
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, CA 95014
+   United States of America
+
+   Email: adi@apple.com
+
+
+   Ernesto Ruffini
+   OutSys
+   via Caracciolo, 65
+   20155 Milan
+   Italy
+
+   Email: eruffini@outsys.org