IP Performance Measurement Group                             G. FioccolaInternet-Draft                                                    K. ZhuIntended status: Informational                                   T. ZhouExpires: 20 April 2026                               Huawei Technologies                                                                  Y. Zhu                                                           China Telecom                                                                  X. Min                                                         ZTE Corporation                                                         17 October 2025         On-Path Telemetry for Active Performance Measurements             draft-ietf-ippm-on-path-active-measurements-01Abstract   This document describes how to employ active test packets in   combination with Hybrid Methods to perform On-path Active Performance   Measurements.  This procedure allows Hop-By-Hop measurements in   addition to the Edge-To-Edge measurements.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 20 April 2026.Copyright Notice   Copyright (c) 2025 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 ComponentsFioccola, et al.          Expires 20 April 2026                 [Page 1]Internet-Draft              on-path-active-pm               October 2025   extracted from this document must include Revised BSD License text as   described in Section 4.e of the Trust Legal Provisions and are   provided without warranty as described in the Revised BSD License.Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   2.  On-path Telemetry Options with Active Measurement Tools . . .   3     2.1.  ICMP and ICMPv6 . . . . . . . . . . . . . . . . . . . . .   3     2.2.  OWAMP, TWAMP and STAMP  . . . . . . . . . . . . . . . . .   4   3.  Telemetry Methods for On-path Active Metrics  . . . . . . . .   6     3.1.  Alternate-Marking . . . . . . . . . . . . . . . . . . . .   6     3.2.  IOAM  . . . . . . . . . . . . . . . . . . . . . . . . . .   6   4.  Example of On-path STAMP Performance Measurements . . . . . .   6   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  111.  Introduction   [RFC7799] defines the Active Metric or Method, which depends on a   dedicated measurement packet stream and observations of the stream.   Commonly, the packet stream of interest is generated as the basis of   measurement and sometimes is also classified as a "synthetic" stream.   The Source and Destination of the packet stream of interest are   usually known a priori.  The characteristics of the packet stream of   interest are known at the Source, and may be communicated to the   Destination as part of the method.  An accompanying packet stream or   streams may be generated to increase overall traffic load, though the   loading stream(s) may not be measured.   There are several active tools: Internet Control Message Protocol   (ICMP) [RFC792], ICMP version 6 (ICMPv6) [RFC4443], MPLS echo   request/reply [RFC8029], MPLS Loss and Delay Measurement [RFC6374],   One-way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active   Measurement Protocol (TWAMP) [RFC5357], Simple Two-way Active   Measurement Protocol (STAMP) [RFC8762].  In a test session, the   unidirectional or bidirectional packet flow is transmitted between a   Source and a Destination.  However, the performance of intermediate   nodes and links that the test packets traverse are not visible.   In several scenarios it is beneficial to perform Hop-By-Hop (HBH) and   Edge-To-Edge (E2E) active measurements.  Alternate Marking (AltMark)   [RFC9341] and In Situ Operations, Administration, and MaintenanceFioccola, et al.          Expires 20 April 2026                 [Page 2]Internet-Draft              on-path-active-pm               October 2025   (IOAM) [RFC9197] are Hybrid Methods, which can be employed to perform   HBH and E2E active measurements by using synthetic test packets and   by leveraging the existing AltMark and IOAM options.  AltMark and   IOAM data fields can be encoded in the Options Headers (Hop-by-Hop or   Destination), according to [RFC8200].  The AltMark IPv6 HBH option   [RFC9343] and the IOAM IPv6 HBH option [RFC9486] can be coupled with   a packet stream of interest and carried in each test packet to enable   HBH measurements.  Similarly to IPv6, MPLS packets can carry MPLS   Network Action (MNA) Sub-Stack as defined in [I-D.ietf-mpls-mna-hdr].2.  On-path Telemetry Options with Active Measurement Tools   As defined in [RFC7799], Hybrid Methods are characterized by the   augmentation or modification of the stream of interest.  AltMark and   IOAM are two examples of Hybrid Methods.  For IPv6, [RFC9343] and   [RFC9486] define the IPv6 HBH options of AltMark and IOAM   respectively.   The next sections explain how the packets look like in case of ICMP,   ICMPv6, OWAMP, TWAMP and STAMP.2.1.  ICMP and ICMPv6   ICMPv6 is an integral part of IPv6 and performs error reporting and   diagnostic functions.  The ICMPv6 Echo ("Ping") checks whether a   specified IPv6 address is reachable and exports corresponding   statistics.  The packet also contains the IPv6 Extension Headers, if   present.  In particular it may contain an IPv6 HBH Option for On-Path   Telemetry (e.g. AltMark [RFC9343], [I-D.fz-spring-srv6-alt-mark] or   IOAM [RFC9486]).                 +------------------------------------+                 | IPv6 Header                        |                 +------------------------------------+                 | IPv6 HBH Option                    |                 +------------------------------------+                 | ICMPv6 Header + Data               |                 +------------------------------------+                Figure 1: ICMPv6 Packet with IPv6 HbH Option   Figure 1 represents an example ICMPv6 packet, which includes an IPv6   HBH option.  The intermediate nodes can read and handle the IPv6 HBH   Option if they are configured to do so.  In this way, it can be   possible to perform On-path measurements with ICMPv6.Fioccola, et al.          Expires 20 April 2026                 [Page 3]Internet-Draft              on-path-active-pm               October 2025   Note that the same applies to the MPLS data plane with MNA Sub-Stacks   in the MPLS header, as showed in Figure 2 in case of MPLS LSP Ping   operation.  MNA Sub-Stacks for Performance Measurement are described   in [I-D.ietf-mpls-mna-ioam] and [I-D.cx-mpls-mna-inband-pm].                 +------------------------------------+                 | MPLS Header                        |                 +------------------------------------+                 | MNA Sub-Stack                      |                 +------------------------------------+                 | IP Header                          |                 +------------------------------------+                 | UDP Header                         |                 +------------------------------------+                 | MPLS echo request/reply            |                 +------------------------------------+        Figure 2: MPLS echo request/reply Packet with MNA Sub-Stack2.2.  OWAMP, TWAMP and STAMP   The OWAMP protocol provides a way for measuring one-way metrics   between network devices.  OWAMP can be used bidirectionally to   measure one-way metrics in both directions between two network   elements.   Since OWAMP does not accommodate round-trip or two-way measurements,   the TWAMP protocol is also specified.  It is based on the OWAMP and   adds two-way or round-trip measurement capabilities.  The TWAMP   measurement architecture is usually comprised of two hosts with   specific roles, and this allows for some protocol simplifications,   making it an attractive alternative in some circumstances.  Similarly   to OWAMP, TWAMP control packets are carried by TCP, and test packets   are carried by UDP.  The port numbers can be changed by   configuration.   Over time, there has been interest in using a simpler mechanism for   active performance monitoring that can provide deterministic behavior   and inherent separation of vendor-specific control and test   functions.  Therefore, STAMP has been defined and it enables the   measurement of both one-way and round-trip performance metrics, such   as delay, delay variation, and packet loss.   Figure 3 represents an example test packet, which includes an IPv6   HBH option.  Note that the test packet can be an OWAMP test packet or   a TWAMP test packet or a STAMP test packet, depending on whether it   is considered an OWAMP session or a TWAMP session or a STAMP session.Fioccola, et al.          Expires 20 April 2026                 [Page 4]Internet-Draft              on-path-active-pm               October 2025   The intermediate nodes do not need to perform any processing of OWAMP   or TWAMP or STAMP.  But the intermediate nodes can read and handle   the IPv6 HBH Option (i.e. [RFC9343], [RFC9486]), if they are   configured to do so.                 +------------------------------------+                 | IPv6 Header                        |                 +------------------------------------+                 | IPv6 HBH Option                    |                 +------------------------------------+                 | UDP Header                         |                 +------------------------------------+                 | OWAMP/TWAMP/STAMP Packet           |                 +------------------------------------+        Figure 3: OWAMP/TWAMP/STAMP Test Packet with IPv6 HbH Option   Considering the example of STAMP, it is possible to explain what   happens if it is used a STAMP test packet with the IPv6 HbH Option.   The STAMP Session-Sender initiates a Session-Sender test packet and   the STAMP Session-Reflector transmits a reply Session-Reflector test   packet.  The STAMP Session-Sender also adds the IPv6 HBH option in   the Session-Sender test packets to enable HBH measurements in the   forward direction.  Intermediate nodes do not perform any STAMP   processing, but must support the IPv6 HBH option related methodology.   The STAMP Session-Reflector receives test packets transmitted from   Session-Sender and acts according to the configuration.  The Session-   Reflector also adds the IPv6 HBH option in the reply Session-   Reflector test packets to enable HBH measurements in the backward   direction as well.   Note that the same applies to the MPLS data plane with MNA Sub-Stacks   ([I-D.ietf-mpls-mna-ioam] and [I-D.cx-mpls-mna-inband-pm]) in the   MPLS header, as showed in Figure 4.                 +------------------------------------+                 | MPLS Header                        |                 +------------------------------------+                 | MNA Sub-Stack                      |                 +------------------------------------+                 | IP Header                          |                 +------------------------------------+                 | UDP Header                         |                 +------------------------------------+                 | OWAMP/TWAMP/STAMP Packet           |                 +------------------------------------+         Figure 4: OWAMP/TWAMP/STAMP Test Packet with MNA Sub-StackFioccola, et al.          Expires 20 April 2026                 [Page 5]Internet-Draft              on-path-active-pm               October 20253.  Telemetry Methods for On-path Active Metrics3.1.  Alternate-Marking   The Alternate Marking method can be used in combination with the   active methods.  [RFC9343] defines the Hop-by-Hop Options Header and   the Destination Options Header to carry AltMark data fields.   The addition of the AltMark IPv6 HBH option augments the active   measurement method by enabling on-path HBH measurements together with   the usual E2E measurements.  It is worth highlighting that this   approach is not adding any new functionalities to ICMPv6, OWAMP,   TWAMP or STAMP.  But it is only leveraging the existing AltMark   mechanisms to measure the performance of intermediate nodes and links   that the test packets traverse.   Also, [RFC9714], [RFC9571] and [I-D.ietf-mpls-rfc6374-sr] are based   on the Alternate Marking method.  Therefore, they can be combined   with the MPLS LSP Ping.   it is possible to use YANG [I-D.ietf-ippm-alt-mark-yang] to configure   and IPFIX [I-D.ietf-opsawg-ipfix-alt-mark] or YANG notifications   [I-D.ietf-ippm-on-path-telemetry-yang] to report AltMark telemetry   information from each intermediate node to a collector.3.2.  IOAM   IOAM can also be used in combination with the active methods.   [RFC9486] defines the Hop-by-Hop Options Header and the Destination   Options Header to carry IOAM data fields.   [I-D.ietf-ippm-stamp-ext-hdr] extends STAMP to reflect back from the   Session-Reflector to the Session-Sender any IPv6 options and MPLS   Network Action Sub-Stacks for hop-by-hop and edge-to-edge active   measurements.  [I-D.ietf-6man-icmpv6-reflection] can also be used for   this purpose.   It is also be possible to use IPFIX/YANG notifications/IOAM DEX to   report AltMark telemetry information from each intermediate node to a   collector.4.  Example of On-path STAMP Performance Measurements   Figure 5 presents the STAMP Session-Sender, Intermediate-Node(s) and   Session-Reflector with a measurement session.  A measurement session   is also referred to as a STAMP session and it is the bidirectional   packet flow between one specific Session-Sender and one particular   Session-Reflector for a time duration.Fioccola, et al.          Expires 20 April 2026                 [Page 6]Internet-Draft              on-path-active-pm               October 2025   The Intermediate-Nodes are nodes which do not necessarily need to   perform any STAMP processing.   The configuration and management of the STAMP Session-Sender,   Intermediate-Node(s), Session-Reflector, and sessions are outside the   scope of this document and can be achieved through various means, as   mentioned in [RFC8762].     o------------------------------------------------------------o     |                     Configuration and                      |     |                        Management                          |     o------------------------------------------------------------o         ||                        ||                        ||         ||                        ||                        ||         ||                        ||                        ||   +--------------+     +--------------------+     +-----------------+   |Session-Sender| ... |Intermediate-Node(s)| ... |Session-Reflector|   +--------------+     +------------- ------+     +-----------------+    <---------------------------- STAMP ---------------------------->                    Figure 5: HbH STAMP Reference Model   If the Intermediate-Nodes support the AltMark method, the STAMP   Session-Sender and Session-Reflector add the AltMark IPv6 HBH option   [RFC9343] to the STAMP test packets.  The intermediate nodes can   apply the methodology according to [RFC9341] to perform loss and   delay measurements.  For Alternate Marking, the source node is the   only one that writes the IPv6 HBH Option while the intermediate nodes   can only read the IPv6 HBH Option, without modifying the packet.   If the Intermediate-Nodes support the IOAM methods, the STAMP   Session-Sender and Session-Reflector test packets carry the IOAM IPv6   HBH option for recording and collecting HBH and E2E operational and   telemetry information for active measurement.  The intermediate nodes   process the IOAM data fields.  For IOAM, the source node and the   intermediate nodes modify the IPv6 HBH Option to include the needed   information.   As already mentioned, it is possible to use YANG to configure and   IPFIX or YANG notifications to report telemetry information from each   intermediate node to a collector.5.  IANA Considerations   This document has no IANA actions.Fioccola, et al.          Expires 20 April 2026                 [Page 7]Internet-Draft              on-path-active-pm               October 20256.  Security Considerations   The security considerations specified in [RFC4443], [RFC4656],   [RFC5357], [RFC8762] apply to the stream of interest generated to   enable the On-path Active performance measurements.   In addition, the security considerations specified in [RFC9341] for   AltMark and in [RFC9197] for IOAM also apply when using the Hybrid   methods in combination with the Active tools.7.  Acknowledgements   The author would like to thank Greg Mirsky for the precious comments   and suggestions.8.  References8.1.  Normative References   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet              Control Message Protocol (ICMPv6) for the Internet              Protocol Version 6 (IPv6) Specification", STD 89,              RFC 4443, DOI 10.17487/RFC4443, March 2006,              <https://www.rfc-editor.org/info/rfc4443>.   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.              Zekauskas, "A One-way Active Measurement Protocol              (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,              <https://www.rfc-editor.org/info/rfc4656>.   [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>.   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay              Measurement for MPLS Networks", RFC 6374,              DOI 10.17487/RFC6374, September 2011,              <https://www.rfc-editor.org/info/rfc6374>.   [RFC792]   Postel, J., "Internet Control Message Protocol", STD 5,              RFC 792, DOI 10.17487/RFC0792, September 1981,              <https://www.rfc-editor.org/info/rfc792>.Fioccola, et al.          Expires 20 April 2026                 [Page 8]Internet-Draft              on-path-active-pm               October 2025   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label              Switched (MPLS) Data-Plane Failures", RFC 8029,              DOI 10.17487/RFC8029, March 2017,              <https://www.rfc-editor.org/info/rfc8029>.   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6              (IPv6) Specification", STD 86, RFC 8200,              DOI 10.17487/RFC8200, July 2017,              <https://www.rfc-editor.org/info/rfc8200>.   [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>.   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,              Ed., "Data Fields for In Situ Operations, Administration,              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,              May 2022, <https://www.rfc-editor.org/info/rfc9197>.   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,              and T. Zhou, "Alternate-Marking Method", RFC 9341,              DOI 10.17487/RFC9341, December 2022,              <https://www.rfc-editor.org/info/rfc9341>.   [RFC9343]  Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.              Pang, "IPv6 Application of the Alternate-Marking Method",              RFC 9343, DOI 10.17487/RFC9343, December 2022,              <https://www.rfc-editor.org/info/rfc9343>.   [RFC9486]  Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for              In Situ Operations, Administration, and Maintenance              (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,              <https://www.rfc-editor.org/info/rfc9486>.8.2.  Informative References   [I-D.cx-mpls-mna-inband-pm]              Cheng, W., Min, X., Gandhi, R., Mirsky, G., and G.              Fioccola, "MNA for Performance Measurement with Alternate              Marking Method", Work in Progress, Internet-Draft, draft-              cx-mpls-mna-inband-pm-07, 11 September 2025,              <https://datatracker.ietf.org/doc/html/draft-cx-mpls-mna-              inband-pm-07>.Fioccola, et al.          Expires 20 April 2026                 [Page 9]Internet-Draft              on-path-active-pm               October 2025   [I-D.fz-spring-srv6-alt-mark]              Fioccola, G., Zhou, T., Mishra, G. S., wang, X., Zhang,              G., and M. Cociglio, "Application of the Alternate Marking              Method to the Segment Routing Header", Work in Progress,              Internet-Draft, draft-fz-spring-srv6-alt-mark-17, 27              August 2025, <https://datatracker.ietf.org/doc/html/draft-              fz-spring-srv6-alt-mark-17>.   [I-D.ietf-6man-icmpv6-reflection]              Mizrahi, T., hexiaoming, X., Zhou, T., Bonica, R., and X.              Min, "Internet Control Message Protocol (ICMPv6)              Reflection", Work in Progress, Internet-Draft, draft-ietf-              6man-icmpv6-reflection-11, 3 September 2025,              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-              icmpv6-reflection-11>.   [I-D.ietf-ippm-alt-mark-yang]              Graf, T., Wang, M., Fioccola, G., Zhou, T., and X. Min, "A              YANG Data Model for the Alternate Marking Method", Work in              Progress, Internet-Draft, draft-ietf-ippm-alt-mark-yang-              01, 2 July 2025, <https://datatracker.ietf.org/doc/html/              draft-ietf-ippm-alt-mark-yang-01>.   [I-D.ietf-ippm-on-path-telemetry-yang]              Fioccola, G., Zhou, T., Zhu, Y., Zhang, W., and K. Zhu,              "On-Path Telemetry YANG Data Model", Work in Progress,              Internet-Draft, draft-ietf-ippm-on-path-telemetry-yang-01,              2 July 2025, <https://datatracker.ietf.org/doc/html/draft-              ietf-ippm-on-path-telemetry-yang-01>.   [I-D.ietf-ippm-stamp-ext-hdr]              Gandhi, R., Zhou, T., Li, Z., and W. Hawkins, "Simple Two-              Way Active Measurement Protocol (STAMP) Extensions for              Reflecting STAMP Packet IP Headers", Work in Progress,              Internet-Draft, draft-ietf-ippm-stamp-ext-hdr-06, 5              October 2025, <https://datatracker.ietf.org/doc/html/              draft-ietf-ippm-stamp-ext-hdr-06>.   [I-D.ietf-mpls-mna-hdr]              Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K.              Kompella, "MPLS Network Action (MNA) Sub-Stack Solution",              Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-              16, 3 October 2025,              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-              mna-hdr-16>.Fioccola, et al.          Expires 20 April 2026                [Page 10]Internet-Draft              on-path-active-pm               October 2025   [I-D.ietf-mpls-mna-ioam]              Gandhi, R., Mirsky, G., Li, T., Song, H., and B. Wen,              "Supporting In Situ Operations, Administration and              Maintenance Using MPLS Network Actions", Work in Progress,              Internet-Draft, draft-ietf-mpls-mna-ioam-03, 30 May 2025,              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-              mna-ioam-03>.   [I-D.ietf-mpls-rfc6374-sr]              Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M.              Chen, "Performance Measurement for Segment Routing              Networks with MPLS Data Plane", Work in Progress,              Internet-Draft, draft-ietf-mpls-rfc6374-sr-17, 17 October              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-              mpls-rfc6374-sr-17>.   [I-D.ietf-opsawg-ipfix-alt-mark]              Graf, T., Fioccola, G., Zhou, T., Zhu, Y., and M.              Cociglio, "IP Flow Information Export (IPFIX) Alternate-              Marking Information Elements", Work in Progress, Internet-              Draft, draft-ietf-opsawg-ipfix-alt-mark-03, 22 May 2025,              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-              ipfix-alt-mark-03>.   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,              May 2016, <https://www.rfc-editor.org/info/rfc7799>.   [RFC9571]  Bryant, S., Ed., Swallow, G., Chen, M., Fioccola, G., and              G. Mirsky, "Extension of RFC 6374-Based Performance              Measurement Using Synonymous Flow Labels", RFC 9571,              DOI 10.17487/RFC9571, May 2024,              <https://www.rfc-editor.org/info/rfc9571>.   [RFC9714]  Cheng, W., Ed., Min, X., Ed., Zhou, T., Dai, J., and Y.              Peleg, "Encapsulation for MPLS Performance Measurement              with the Alternate-Marking Method", RFC 9714,              DOI 10.17487/RFC9714, February 2025,              <https://www.rfc-editor.org/info/rfc9714>.Authors' Addresses   Giuseppe Fioccola   Huawei Technologies   Email: giuseppe.fioccola@huawei.comFioccola, et al.          Expires 20 April 2026                [Page 11]Internet-Draft              on-path-active-pm               October 2025   Keyi Zhu   Huawei Technologies   Email: zhukeyi@huawei.com   Tianran Zhou   Huawei Technologies   Email: zhoutianran@huawei.com   Yongqing Zhu   China Telecom   Email: zhuyq8@chinatelecom.cn   Xiao Min   ZTE Corporation   Email: xiao.min2@zte.com.cnFioccola, et al.          Expires 20 April 2026                [Page 12]