Internet-Draft SRv6 In-situ Active Measurement December 2021
Song & Pan Expires 9 June 2022 [Page]
Intended Status:
Standards Track
H. Song
Futurewei Technologies
T. Pan

SRv6 In-situ Active Measurement


This draft describes a data-plane in-band active measurement method for SRv6. A packet containing an SRH uses a flag bit to indicate it is an active probing packet. The measurement information, such as the IOAM header and data, is encapsulated in UDP payload. The probing packet originates from a segment source node and terminates at a configured segment endpoint node. Each segment node on the path, when detecting the flag, parses the UDP header and the payload. In case of IOAM, the node adds data to the IOAM node data fields. The method avoids the performance and encapsulation issues for applying IOAM as well as other measurement techniques in SRv6 networks. Multiple applications can be supported by the method.

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 9 June 2022.

Table of Contents

1. Introduction

To support SRv6 network operation, we need various means to collect data and measure the performance of SRv6 network. [I-D.ietf-6man-spring-srv6-oam] 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.

[I-D.ietf-ippm-ioam-data] supports extensible data collection for user traffic. It is beneficial for SRv6 network monitor and measurement. [I-D.ali-spring-ioam-srv6] proposes to encapsulate IOAM in SRH TLV. However, when applying to user packets, IOAM's overhead may cause packet fragmentation and its processing may affect the packet forwarding throughput. Moreover, due to the extension header limitations asserted by [RFC8200], it is not easy to come up with a scheme to encapsulate the IOAM header and data in other locations in SRv6 user packets.

Fortunately, the forwarding behavior in SRv6 networks is determined by the SRH. To conduct in-band measurement, the IOAM header and data do not need to be added to user packets. Instead, they can be encapsulated in an independent packet dedicated for measurement. As long as this packet has the same SRH as the user packet, the data collected can faithfully reflect the user packet's forwarding experience, so the result is similar to that by applying IOAM on SRv6 user packets. This approach retains the benefits of in-situ measurement but avoids the aforementioned issues.

In this case, the IOAM header and data processing can even be done in slow path, without worrying about delaying the user traffic. Because of this, the potential limitation of the forwarding hardware's header processing capability (e.g., the header parsing depth) is no longer an issue.

This SR-based active measurement approach also supports some other 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.

The approach is built on existing protocol components with limited extra requirements.

2. In-situ Active Measurement 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 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.

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 is reserved for IOAM. If the destination port number is of the IOAM type, the UDP payload would encapsulate the IOAM header and data as specified in [I-D.ietf-ippm-ioam-data]. The source UDP port can be used as sequence number to track the probing packets on a specific SR path.

The complete active probing packet format for IOAM is shown in Figure 2.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |Ver (6)| Traffic Class |           Flow Label                  |  ^
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |         Payload Length        |  NH : SRH     |   Hop Limit   |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |               Source Address (128 bits)                       | RFC8200
   |                                                               +  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |               Destination Address (128 bits)                  |  |
   |                                                               |  V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |  NH : UDP     |  Hdr Ext Len  | Routing Type  | Segments Left |  ^
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
   |  Last Entry   | |1|  Flags    |              Tag              |  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC8754
   |                                                               |  |
   |                   Segment List (m * 128 bits)                 |  |
   |                                                               |  |
   |                                                               |  V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |   Source Port (TBD)           |     Destination Port (TBD)    |  ^
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC768
   |   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

3. Network Operation

The SR source node constructs the probing packets. 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, 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 and analyzed according to configuration.

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.

4. Applications

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

5. Probing Packet Type Extension

The same scheme is also suitable for other types of probing packets. For example, The probing packets can carry IOAM E2E option header and data, IOAM DEX option header, and other OAM headers and data. It is easy to use different reserved UDP port numbers to differentiate the payload types.

6. Security Considerations

7. IANA Considerations

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

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

8. Acknowledgments

9. References

9.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
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, , <>.

9.2. Informative References

Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar, N., 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-04, , <>.
Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Chen, "Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)", Work in Progress, Internet-Draft, draft-ietf-6man-spring-srv6-oam-12, , <>.
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-16, , <>.
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, , <>.

Authors' Addresses

Haoyu Song
Futurewei Technologies
Santa Clara,
United States of America
Tian Pan