Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Haoyu Song , Tian Pan
Last updated 2021-12-06 (Latest revision 2021-06-14)
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-02
SPRING                                                           H. Song
Internet-Draft                                    Futurewei Technologies
Intended status: Standards Track                                  T. Pan
Expires: 9 June 2022                                                BUPT
                                                         6 December 2021

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

Abstract

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

Song & Pan                 Expires 9 June 2022                  [Page 1]
Internet-Draft       SRv6 In-situ Active Measurement       December 2021

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 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.  In-situ Active Measurement for SRv6 . . . . . . . . . . . . .   3
   3.  Network Operation . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Probing Packet Type Extension . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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.

Song & Pan                 Expires 9 June 2022                  [Page 2]
Internet-Draft       SRv6 In-situ Active Measurement       December 2021

   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.

Song & Pan                 Expires 9 June 2022                  [Page 3]
Internet-Draft       SRv6 In-situ Active Measurement       December 2021

   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

Song & Pan                 Expires 9 June 2022                  [Page 4]
Internet-Draft       SRv6 In-situ Active Measurement       December 2021

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.

   *  As described in Section 1, this is an easy way to apply IOAM in
      SRv6.  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 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 & Pan                 Expires 9 June 2022                  [Page 5]
Internet-Draft       SRv6 In-situ Active Measurement       December 2021

   *  To collect the network wide telemetry data and gain global
      visibility within a SRv6 domain, we can apply the algorithm
      described in [I-D.tian-bupt-inwt-mechanism-policy] to calculate
      the optimal SR paths, and construct probing packets on these
      paths.

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

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

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

Song & Pan                 Expires 9 June 2022                  [Page 6]
Internet-Draft       SRv6 In-situ Active Measurement       December 2021

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

9.2.  Informative References

   [I-D.ali-spring-ioam-srv6]
              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, 12 July 2021, <https://www.ietf.org/
              internet-drafts/draft-ali-spring-ioam-srv6-04.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-12, 28 November 2021,
              <https://www.ietf.org/archive/id/draft-ietf-6man-spring-
              srv6-oam-12.txt>.

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
              for In-situ OAM", Work in Progress, Internet-Draft, draft-
              ietf-ippm-ioam-data-16, 8 November 2021,
              <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
              data-16.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

Song & Pan                 Expires 9 June 2022                  [Page 7]
Internet-Draft       SRv6 In-situ Active Measurement       December 2021

   Haoyu Song
   Futurewei Technologies
   Santa Clara,
   United States of America

   Email: haoyu.song@futurewei.com

   Tian Pan
   BUPT
   Beijing
   China

   Email: pan@bupt.edu.cn

Song & Pan                 Expires 9 June 2022                  [Page 8]