Skip to main content

SRv6 In-situ Active Measurement
draft-song-spring-siam-04

Document Type Active Internet-Draft (individual)
Authors Haoyu Song , Gyan Mishra , Tian Pan
Last updated 2022-09-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-song-spring-siam-04
SPRING                                                           H. Song
Internet-Draft                                    Futurewei Technologies
Intended status: Standards Track                               G. Mishra
Expires: 10 March 2023                                      Verizon Inc.
                                                                  T. Pan
                                                                    BUPT
                                                        6 September 2022

                    SRv6 In-situ Active Measurement
                       draft-song-spring-siam-04

Abstract

   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 https://datatracker.ietf.org/drafts/current/.

Song, et al.              Expires 10 March 2023                 [Page 1]
Internet-Draft                    SIAM                    September 2022

   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 10 March 2023.

Copyright Notice

   Copyright (c) 2022 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 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.  An Active Measurement Framework for SRv6  . . . . . . . . . .   3
   3.  SRv6 In-Situ Active Measurement with IOAM . . . . . . . . . .   4
   4.  Network Operation . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Probing Packet Type Extension . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   SRv6 network OAM needs various means to collect data, detect issues,
   and measure its performance.  [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.  More mechanisms should be provided to enrich
   the OAM coverage.

Song, et al.              Expires 10 March 2023                 [Page 2]
Internet-Draft                    SIAM                    September 2022

   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.

Song, et al.              Expires 10 March 2023                 [Page 3]
Internet-Draft                    SIAM                    September 2022

   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.

Song, et al.              Expires 10 March 2023                 [Page 4]
Internet-Draft                    SIAM                    September 2022

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
 |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)    |  ^
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 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.

Song, et al.              Expires 10 March 2023                 [Page 5]
Internet-Draft                    SIAM                    September 2022

   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.

   *  The method can be used as an alternative way for applying IOAM on
      user traffic in SRv6, because the forwarding behavior in SRv6
      networks is determined by the SRH.  As long as a probing packet
      has the same SRH as the user packet, the data collected can
      faithfully reflect the user packet's forwarding experience along
      the same path.  In this case, in order to collect the on-path data
      for a specific flow, all we need is to copy the SRH from the flow
      packet and construct the probing packets.  The probing packet rate
      can match the original flow or arbitrarily configured.  The edge
      of the SR domain must terminate the probing packets to avoid
      leakage.

   *  To support SRv6 traffic engineering, some alternative paths may be
      pre-computed.  It is desirable to constantly measure the
      performance of these paths so the best path can be picked when a
      flow is swapped.  Since each path can be represented by an SRH, we
      can construct the probing packets with these SRHs to actively
      measure their status and performance.

   *  In an SRv6 network, it is easy to conduct round trip measurement
      by setting the starting node and the end node of a path to the
      same segment source node, and setting the destination node as an
      intermediate node on the path.

Song, et al.              Expires 10 March 2023                 [Page 6]
Internet-Draft                    SIAM                    September 2022

   *  In order to detect or prevent gray network failures for SLA
      guarantee, it is necessary to collect network-wide telemetry data
      to gain full visibility within a SRv6 domain.  We can apply the
      algorithm described in [I-D.tian-bupt-inwt-mechanism-policy] to
      calculate the minimum number of optimal SR paths to acheive the
      full coverage, and construct probing packets on these paths.

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 [I-D.ietf-ippm-ioam-direct-export], and other OAM options.  It
   is easy to use different reserved UDP port numbers to differentiate
   the payload types.

7.  Security Considerations

   TBD

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

   [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>.

   [RFC6936]  Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the Use of IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, DOI 10.17487/RFC6936, April 2013,
              <https://www.rfc-editor.org/info/rfc6936>.

Song, et al.              Expires 10 March 2023                 [Page 7]
Internet-Draft                    SIAM                    September 2022

   [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>.

   [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>.

   [RFC8754]  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, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [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>.

10.2.  Informative References

   [I-D.ali-spring-ioam-srv6]
              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, 10 July 2022,
              <https://www.ietf.org/archive/id/draft-ali-spring-ioam-
              srv6-06.txt>.

   [I-D.ietf-6man-spring-srv6-oam]
              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-13, 23 January 2022,
              <https://www.ietf.org/archive/id/draft-ietf-6man-spring-
              srv6-oam-13.txt>.

   [I-D.ietf-ippm-ioam-direct-export]
              Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
              Mizrahi, "In-situ OAM Direct Exporting", Work in Progress,
              Internet-Draft, draft-ietf-ippm-ioam-direct-export-10, 18
              August 2022, <https://www.ietf.org/archive/id/draft-ietf-
              ippm-ioam-direct-export-10.txt>.

Song, et al.              Expires 10 March 2023                 [Page 8]
Internet-Draft                    SIAM                    September 2022

   [I-D.ietf-spring-stamp-srpm]
              Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens,
              B., and R. Foote, "Performance Measurement Using Simple
              TWAMP (STAMP) for Segment Routing Networks", Work in
              Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-05,
              25 August 2022, <https://www.ietf.org/archive/id/draft-
              ietf-spring-stamp-srpm-05.txt>.

   [I-D.tian-bupt-inwt-mechanism-policy]
              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, 25 October 2020,
              <https://www.ietf.org/archive/id/draft-tian-bupt-inwt-
              mechanism-policy-01.txt>.

   [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>.

Authors' Addresses

   Haoyu Song
   Futurewei Technologies
   Santa Clara,
   United States of America
   Email: haoyu.song@futurewei.com

   Gyan Mishra
   Verizon Inc.
   Email: gyan.s.mishra@verizon.com

   Tian Pan
   BUPT
   Email: pan@bupt.edu.cn

Song, et al.              Expires 10 March 2023                 [Page 9]