Internet-Draft SIAM March 2024
Song, et al. Expires 5 September 2024 [Page]
Intended Status:
Standards Track
H. Song
Futurewei Technologies
G. Mishra
Verizon Inc.
T. Pan

SRv6 In-situ Active Measurement


This draft describes an active measurement method for SRv6 which can support segment-by-segment and end-to-end measurement on any SRv6 path using existing protocols such as IOAM. A packet containing an SRH uses a flag bit to indicate the packet is an active probing packet and requires segment-by-segment processing. The measurement information, such as the IOAM header and data, is encapsulated in UDP payload, indicated by a dedicated port number. The probing packet originates from a segment source node, traverses an arbitrary segment path, and terminates at a segment endpoint node, as configured by the segment list in SRH. Each segment node on the path, when detecting the flag, shall parse the UDP header and the payload. In the case of IOAM, the node shall process the IOAM option conforming to the standard procedures defined in the IOAM documents. The method is compatible with some other SRv6 active measurement proposals and support multiple applications.

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.

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

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 5 September 2024.

Table of Contents

1. Introduction

SRv6 network OAM needs various means to collect data, detect issues, and measure its performance. [RFC9259] provides some mechanisms for SRv6 OAM. Some other general methods for performance measurement such as [RFC8762] can also be applied for SRv6. However, these methods have limited data coverage and measurement capability. More mechanisms should be provided to enrich the OAM coverage.

IOAM [RFC9197] can support extensible hop-by-hop data collection for user traffic. It is beneficial for SRv6 network monitor and measurement. Since it is designed for user-packet measurement, [I-D.ali-spring-ioam-srv6] proposes to encapsulate IOAM in SRH TLV options.

However, with its well-defined structure and functions, IOAM can also be used for active measurement (i.e., in dedicated probing packets without user payload) to fulfill many measurement tasks that are inconvenient or infeasible to be applied on user traffic. For active measurement, we can directly encapsulate the IOAM header and data in the UDP-based probing packet payload. The similar method has been proposed in [I-D.ietf-spring-stamp-srpm] to support STAMP for SRv6 measurement. IOAM is complement to STAMP by providing Segment-by-Segment (SbS) measurement capability. The high-level method can be generalized and extended to support other performance measurement protocols under the same framework.

Fully built on exiting protocol components, the SR-based active measurement method using IOAM can support some useful applications. For example, it can be used to support network-wide telemetry coverage by using pre-planned paths [I-D.tian-bupt-inwt-mechanism-policy]; it can be used to actively measure the backup paths for SRv6 traffic engineering; and by setting the path end as the path head in SRH, it can naturally support two-way or round-trip measurement.

2. An Active Measurement Framework for SRv6

As specified by [RFC8754], the Segment Routing Header (SRH) contains an 8-bit "Flags" field. This document defines the following flag bit 'T' to designate the packet as a dedicated probing packet for Segment-by Segment (SbS) active measurement.

                  0 1 2 3 4 5 6 7
                 | |T|           |

Figure 1: A Hierarchical Edge Network

The O-bit defined in [I-D.ietf-6man-spring-srv6-oam] servers for user traffic OAM, so the T-bit and O-bit are mutual exclusive. When T-bit is set, O-bit must be cleared, and vice versa.

Note that when applied for SRv6, the Edge-to-Edge (E2E) active measurements, such as STAMP [I-D.ietf-spring-stamp-srpm] and IOAM E2E option, do not need to set the T bit. The last segment endpoint node will be required to parse and process the UDP payload of a probing packet while the intermediate segment endpoint nodes simply forward the packet.

The Next Header of SRH is set to UDP. A destination UDP port is reserved to encode the type of the payload. For example, a port number has been proposed to be reserved for STAMP in [I-D.ietf-spring-stamp-srpm]. Similarly, another port number should be reserved for IOAM trace option. If the destination port number matches the reserved values, the UDP payload would encapsulate the corresponding protocol header. The source UDP port can be used or ignored depending on each use case. The UDP checksum processing procedure conforms to [RFC6936].

3. SRv6 In-Situ Active Measurement with IOAM

We focus on a specific use case of the framework: using IOAM trace option for segment-by-segment measurement. The IOAM header and data format are specified in [RFC9197]. The complete active probing packet format for IOAM is shown in Figure 2. The source UDP port can be used as sequence number to track the probing packets on a specific SR path.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|Ver (6)| Traffic Class |           Flow Label                  |  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|         Payload Length        |  NH : SRH     |   Hop Limit   |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|               Source Address (128 bits)                       | RFC
|                                                               + 8200
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|               Destination Address (128 bits)                  |  |
|                                                               |  V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|  NH : UDP     |  Hdr Ext Len  | Routing Type  | Segments Left |  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|  Last Entry   | |1|  Flags    |              Tag              |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC
|                                                               | 8754
|                   Segment List (m * 128 bits)                 |  |
|                                                               |  |
|                                                               |  V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|   Source Port (TBD)           |     Destination Port (TBD)    |  ^
|   Length                      |     Checksum                  |  V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|        Namespace-ID           |NodeLen  | Flags | RemainingLen|  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|               IOAM-Trace-Type                 |  Reserved     |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IOAM
|                                                               |  |
|                   Node Data List (n * 32 bits)                |  |
|                                                               |  |
|                                                               |  V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---

Figure 2: The active probing packet format for IOAM trace option

4. Network Operation

To initiate an IOAM active measurement on a path, the probing packets are generated at the SR source node. The source address is the address of the SR source node and the destination address is the address of first SR segment endpoint node. The SRH lists all the SR segment endpoint nodes for which IOAM data will be collected.

Each SR node on the path including the source node, when detecting the T-flag, in addition to normal SRH processing, will further parse the UDP header and IOAM header, and as directed by the IOAM header, add data to the IOAM node data list.

The last SR segment endpoint node will terminate the probing packet. The collected data can be exported according to the specifications for IOAM data export.

If an SR segment endpoint node on the path is incapable of processing the probing packet, it should ignore the T-flag and continue forwarding the packet. The last SR segment endpoint node MUST be able to process and terminate the probing packets.

5. Applications

This section summarizes a list of applications of the SRv6 In-situ Active Measurement (SIAM) approach.

6. Probing Packet Type Extension

The same framework can support other OAM protocols. In addition to STAMP [I-D.ietf-spring-stamp-srpm], the active probing packets can carry IOAM E2E option header and data [RFC9197], IOAM DEX option header [RFC9326], and other OAM options. It is easy to use different reserved UDP port numbers to differentiate the payload types.

7. Security Considerations


8. IANA Considerations

An SRH Flag bit 'T'. The bit position TBD

Optional UDP destination port numbers indicating different IOAM options (TBD)

9. Acknowledgments

We acknowledge the comments and suggestions from Greg Mirsky and Tianran Zhou which help to improve this document.

10. References

10.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <>.
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <>.
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, , <>.
Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, , <>.

10.2. Informative References

Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar, N. K., Pignataro, C., Li, C., Chen, M., and G. Dawra, "Segment Routing Header encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-ali-spring-ioam-srv6-06, , <>.
Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Chen, "Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)", Work in Progress, Internet-Draft, draft-ietf-6man-spring-srv6-oam-13, , <>.
Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and R. F. Foote, "Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks", Work in Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-12, , <>.
Pan, T., Gao, M., Song, E., Bian, Z., and X. Lin, "In-band Network-Wide Telemetry", Work in Progress, Internet-Draft, draft-tian-bupt-inwt-mechanism-policy-01, , <>.
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, , <>.
Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Chen, "Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)", RFC 9259, DOI 10.17487/RFC9259, , <>.

Authors' Addresses

Haoyu Song
Futurewei Technologies
Santa Clara,
United States of America
Gyan Mishra
Verizon Inc.
Tian Pan