<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-song-spring-siam-07" ipr="trust200902">
  <front>
    <title abbrev="SIAM">SRv6 In-situ Active Measurement</title>

    <author fullname="Haoyu Song" initials="H." surname="Song">
      <organization>Futurewei Technologies</organization>
      <address>
        <postal>
          <street></street>
          <city>Santa Clara</city>
          <country>USA</country>
        </postal>
        <email>haoyu.song@futurewei.com</email>
      </address>
    </author>

	<author fullname="Gyan Mishra" initials="G." surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country></country>
        </postal>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

	<author fullname="Tian Pan" initials="T." surname="Pan">
      <organization>BUPT</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country></country>
        </postal>
        <email>pan@bupt.edu.cn</email>
      </address>
    </author>

    <area>RTG</area>
    <workgroup>SPRING</workgroup>
    
    <!---->

    <keyword></keyword>

    <abstract>
	    <t>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. 
	    </t>    
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and only when, they appear in all
   capitals, as shown here.</t>
    </note>
  </front>

  <middle>

    <section title="Introduction">
	    
		<t>SRv6 network OAM needs various means to collect data, detect issues, and measure its performance. 
		   <xref target = "RFC9259"/> provides some mechanisms for SRv6 OAM. 
		   Some other general methods for performance measurement such as <xref target="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.</t>

		<t><xref target="RFC9197"> IOAM </xref> 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, <xref target="I-D.ali-spring-ioam-srv6"/> proposes to encapsulate IOAM in SRH TLV options. </t>
		
		<t>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 <xref target="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. </t>
		
		<t>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 <xref target="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. </t>
 		
    </section>


    <section title="An Active Measurement Framework for SRv6">  
	
		<t> As specified by <xref target="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. </t>

        <t><figure anchor="figure_flag" title="A Hierarchical Edge Network">
           <artwork><![CDATA[

                  0 1 2 3 4 5 6 7
                 +-+-+-+-+-+-+-+-+
                 | |T|           |
                 +-+-+-+-+-+-+-+-+

			]]></artwork>
		</figure></t>

		<t> The O-bit defined in <xref target= "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.</t>
			
		<t> Note that when applied for SRv6, the Edge-to-Edge (E2E) active measurements, such as STAMP <xref target="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. </t>   	

		<t> 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 <xref target="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 <xref target="RFC6936" />.</t> 
    
	</section>
	
    <section title="SRv6 In-Situ Active Measurement with IOAM">  
   
        <t> 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 <xref target="RFC9197" />. The complete 
			active probing packet format for IOAM is shown in <xref target="figure_packet" />. The source UDP port can be 
			used as sequence number to track the probing packets on a specific SR path. </t>
		
		<t><figure anchor="figure_packet" title="The active probing packet format for IOAM trace option">
				<artwork><![CDATA[

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
		
			]]></artwork>
			</figure></t>

	</section>
     
	<section title = "Network Operation">

		<t> 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. </t>

		<t> 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. </t>
			
		<t> 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. </t>
			
		<t> 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.	</t> 	
		
	</section>
	 
	<section title ="Applications">
		
		<t> This section summarizes a list of applications of the SRv6 In-situ Active Measurement (SIAM) approach.</t>
		
		<t><list style="symbols">
		
			<t> 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. </t>
			<t> 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. </t>
			<t> 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.</t>
			<t> 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 <xref target="I-D.tian-bupt-inwt-mechanism-policy" /> to calculate the minimum number of optimal SR paths to achieve the full coverage, and construct probing packets on these paths.</t>
				
		</list></t>
		
	</section>
	 
	<section title ="Probing Packet Type Extension">
		
		<t> The same framework can support other OAM protocols. In addition to STAMP <xref target="I-D.ietf-spring-stamp-srpm" />, 
		    the active probing packets can carry IOAM E2E option header and data <xref target="RFC9197" />, IOAM DEX option header <xref target="RFC9326"/>, and other OAM options. It is easy to use
			different reserved UDP port numbers to differentiate the payload types.</t> 
		
	</section>
	 
    <section anchor="Security" title="Security Considerations">
	    <t> TBD </t>		
    </section>

    <section anchor="IANA" title="IANA Considerations">
	    <t> An SRH Flag bit 'T'. The bit position TBD </t>
		<t> Optional UDP destination port numbers indicating different IOAM options (TBD) </t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
		<t> We acknowledge the comments and suggestions from Greg Mirsky and Tianran Zhou which help to improve this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.8174'?>
	  <?rfc include='reference.RFC.8754'?>
	  <?rfc include='reference.RFC.8200'?>
	  <?rfc include='reference.RFC.6936'?>
	  <?rfc include='reference.RFC.9197'?>
	  <?rfc include='reference.RFC.9326'?>
    </references>

    <references title="Informative References">
	  <?rfc include='reference.RFC.8762'?>
	  <?rfc include='reference.RFC.9259'?>
	  <?rfc include='reference.I-D.ietf-6man-spring-srv6-oam'?>
	  <?rfc include='reference.I-D.tian-bupt-inwt-mechanism-policy'?>
	  <?rfc include='reference.I-D.ali-spring-ioam-srv6'?>
	  <?rfc include='reference.I-D.ietf-spring-stamp-srpm'?>
    </references>
  </back>
</rfc>
