<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-yang-spring-ach6-sr-00" ipr="trust200902">
  <front>
    <title abbrev="ACH6 in Segment Routing">ACH6 in Segment Routing</title>

    <author fullname="Fan Yang" initials="F." surname="Yang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>shirley.yangfan@huawei.com</email>
      </address>
    </author>

    <author fullname="Tianran Zhou" initials="T" surname="Zhou">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>zhoutianran@huawei.com</email>
      </address>
    </author>

    <date day="12" month="July" year="2021"/>

    <workgroup>SPRING Working Group</workgroup>

    <abstract>
      <t>Associated Channel over IPv6 (ACH6) provides a control channel to one
      specific IPv6 forwarding path for control and management purpose. When
      ACH6 is used in a Segment Routing network, it provides a control channel
      to an SRv6 path. This document specifies an SRv6 ACH6 mechanism and
      describes how ACH6 is applied in a Segment Routing network.</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 target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t/>

      <t>Segment Routing [RFC8402] leverages the source routing paradigm. By
      leveraging SR into IPv6 network, an ordered list of SRv6 SIDs provides
      the certainty of a packet forwarding path as restricted to a specific
      topological path. The Function part in SRv6 SIDs indicates instructions
      to be executed on network nodes to achieve network programming to an
      IPv6 forwarding path.</t>

      <t><xref target="I-D.yang-rtgwg-ipv6-associated-channel"/> proposes an
      Associated Channel over IPv6 (ACH6) to provide a control channel to one
      specific IPv6 forwarding path for control and management purpose. When
      ACH6 is used in a Segment Routing network, it provides a control channel
      to an SRv6 path. This document specifies an SRv6 ACH6 mechanism and
      describes how ACH6 is applied in a Segment Routing network.</t>
    </section>

    <section title="ACH6 in Segment Routing">
      <t>SRv6 ACH6 provides a control channel to carry control and management
      messages to an SRv6 path separately from data forwarding. It is a method
      to provide distributed control and management capabilities to an SRv6
      path, which complements the SDN centerialized control plane. In SRv6
      ACH6 control channel, different types of control and management messages
      to an SRv6 path are carried.</t>

      <section title="ACH6 Network Reference Model in Segment Routing">
        <t>In SRv6 network, IPv6 packet is generated and transported from one
        SRv6 endpoint to another with an ordered list of SRv6 SIDs in Segment
        Routing Header (SRH) <xref target="RFC8754"/>. SRv6 ACH6 is an inband
        path-based control channel from one SRv6 endpoint to another. SRv6
        ACH6 packet is also encapsulated with an Segment Routing Header. To
        guarantee ACH6 control packet is transported in the same path as data
        packets forward, ACH6 packet uses the same SRv6 SID list with the one
        in SRH of data packets associated with.</t>

        <t>Figure 1 shows an ACH6 network reference model used in an SRv6
        network.</t>

        <t><figure align="center">
            <preamble/>

            <artwork align="center"><![CDATA[             SRv6 Endpoint   SRv6 Endpoint   SRv6 Endpoint
    +----+     +-------+      +---------+      +------+      +----+
----| Ex |-----|  ACH6 |------|  ACH6   |------| ACH6 |------| Ey |----
    |    |     |Ingress|      |Mid-Point|      |Egress|      |    |
    +----+     +-------+      +---------+      +------+      +----+
               |<-------------SRv6 Path-------------->|
               |<-------------SRv6 ACH6 ------------->|   
    |<---------------------- SRv6 Domain ------------------------>|
]]></artwork>

            <postamble>Figure 1 ACH6 Network Reference Model in
            SRv6</postamble>
          </figure></t>

        <t>Ex/Ey: SRv6 endpoint</t>

        <t>ACH6 Ingress Node: is the node indicates the entering of control
        and management channel over an SRv6 path, where control and management
        messages are generated and encapsulated. ACH6 ingress node sets its
        local IPv6 address as source address of ACH6 packet.</t>

        <t>ACH6 Mid-Point Node: the SRv6 endpoints on SRv6 SID list of ACH6
        control packet are ACH6 Mid-Point Node, which would process ACH6
        packet when hop-by-hop processing on SRv6 endpoints is required by
        ACH6 control channel.</t>

        <t>ACH6 Egress Node: indicates the exiting of control and management
        channel over an SRv6 path, where the control and management messages
        are extracted and delivered to control or management plane for further
        process. ACH6 egress node sets its local IPv6 address as destination
        address of ACH6 packet.</t>

        <t/>
      </section>

      <section title="Identification of ACH6 in Segment Routing">
        <t>The Associated Channel ID is the identifier of ACH6 control
        channel, and indicates the path which control channel is associated
        with. In SRv6, Path Segment <xref
        target="I-D.ietf-spring-srv6-path-segment"/> is used to identify a
        specific SRv6 path. It can also be used as Associated Channel ID to
        identify the control channel of an SRv6 path. The encoding of Path
        Segment and how Path Segment is allocated keeps same specifications
        defined in <xref target="I-D.ietf-spring-srv6-path-segment"/>.</t>
      </section>

      <section title="ACH6 TLV Format in Segment Routing">
        <t>ACH6 TLV in Segment Routing is defined as:</t>

        <t><figure align="center">
            <preamble/>

            <artwork align="center"><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type=TBD   |    length     |          Channel Type         |  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                             Value                             ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

            <postamble>Figure 2 ACH6 TLV Format in SR</postamble>
          </figure></t>

        <t>Type: 8 bits, indicates it is an ACH6 TLV.</t>

        <t>Length: 8 bits, defines the length of Value field in bytes.</t>

        <t>Channel Type: is a 16-bit-length fixed portion as a part of Value
        field. It indicates the specific type of messages carried in SRv6 ACH6
        control channel. Note that a new ACH TLV Channel Type Registry would
        be requested to IANA. In later documents which specify application
        protocols of associated channel, MUST also specify the applicable
        Channel Type field value assigned by IANA.</t>

        <t>Value: is a variable portion of Value field. It specifies the
        messages indicated by Channel Type and carried in associated channel.
        Note that the Value field of ACH6 TLV MAY contain sub-TLVs to provide
        additional context information to ACH6 TLV.</t>
      </section>

      <section title="Encapsulation of ACH6 TLV in Segment Routing">
        <t>In SRv6, ACH6 control channel is used in either an end-to-end or a
        hop-by-hop approach.</t>

        <t>Regarding an end-to-end case, messages in ACH6 is encapsulated at
        ACH6 ingress node and decapsulated at ACH6 egress node. ACH6 TLV is
        recommended to be encapsulated in IPv6 Destination Options Header
        places after the Segment Routing Header. An alternative way to carry
        ACH6 TLV is using IPv6 payload. When ACH6 TLV format is encapsulated
        in payload, TLV Type and Length can be omitted. The method of taking
        advantage of SRH Flag field to indicate active probing packet <xref
        target=" I-D.song-spring-siam"/> can be used for ACH6 too.</t>

        <t>Regarding a hop-by-hop case, messages in ACH6 is encapsulated at
        ACH6 ingress node. ACH6 mid-points decapsulate and re-capsulate every
        ACH6 packet. At last, ACH6 egress node decapsulates ACH6 packet and
        delivers control and management messages for further process. In this
        case, ACH6 TLV is recommended to be encapsulated in IPv6 Destination
        Options Header preceding the Segment Routing Header.</t>

        <t>The encapsulation of ACH6 in IPv6 Destination Options Header is
        defined as:</t>

        <t><figure align="center">
            <preamble/>

            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                     Source Address                          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                   Destination Address                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 
| DOH TLV(ACH6) |  Hdr Ext Len  |        Channel Type           |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   DOH1
|                                                               ~  (HbH
~              Value (depends on the specific protocol)         ~  case)
~                                                               |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 
| Next Header   |  Hdr Ext Len  |  Routing Type | Segments Left |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
|    Last Entry |    Flags      |              Tag              |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
~                  Segment List[0] (128 bits)                   ~    SRH
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
~                                ...                            ~     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
~                   Segment List[n] (128 bits)                  ~     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
~                    Path Segment (128 bits)                    ~     | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
~                   SRH TLV (Optional,variable)                 ~     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 
| DOH TLV(ACH6) |  Hdr Ext Len  |        Channel Type           |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   DOH2
|                                                               ~  (E2E 
~              Value (depends on the specific protocol)         ~  case)    
~                                                               |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 
]]></artwork>

            <postamble>Figure 3 ACH6 TLV Encapsulation in SRv6</postamble>
          </figure></t>
      </section>
    </section>

    <section title="Use Case of ACH6 in Segment Routing">
      <section title="OAM to an SRv6 Path">
        <t>In SRv6, several works are carrying on to establish an SRv6 OAM
        toolset. <xref target="I-D.ietf-6man-spring-srv6-oam"/> provides the
        mechanisms of continuity check, path discovery by reusing Ping and
        Traceroute, and defines a sampling flag for flow information
        telemetry. Simple Two-way Active Measurement Protocol (STAMP) <xref
        target="RFC8762"/> is encapsulated after UDP header to measure
        performance metrics in SRv6 network. <xref
        target="I-D.ietf-ippm-ioam-data"/> supports extensible data collection
        for SRv6 network monitor and measurement.</t>

        <t>ACH6 provides another method of supporting a group of OAM tools in
        a unified TLV format. In this method, a toolset of OAM functions is
        classified into three types of messages, including on-demand echo
        request/reply, proactive continuity check, and performance
        measurement. By using ACH6 to carry OAM messages, continuity check and
        performance management can be monitored either hop-by-hop on every SR
        endpoint or end-to-end from the first endpoint to the last. Leveraging
        IPv6 extension headers to carry OAM messages can facilitate data plane
        processing on OAM messages, and further improve processing efficiency
        and accuracy. At last, by leveraging the native semantics of IPv6
        extension headers, this method can naturally reduce OAM configuration
        and session management on SRv6 endpoints.</t>

        <t>Figure 4 gives the example format of ACH6 OAM TLV.</t>

        <t><figure align="center">
            <preamble/>

            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
                                |  Channel Type = ODERR/PCC/PM  |    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                                                               ~
~                 OAM Message Body (Variable)                   ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
]]></artwork>

            <postamble>Figure 4 ACH6 OAM TLV</postamble>
          </figure></t>

        <t>ACH6 Channel Type to indicate which type of OAM message is
        encapsulated in the following OAM message body, for example on demand
        echo request/reply. OAM message can also re-utilize the format of
        existing protocols. For example, BFD or STAMP protocol formats can be
        encapsulated in IPv6 payload field after UDP header.</t>
      </section>

      <section title="Protection to an SRv6 Path">
        <t>Protection State Coordination (PSC) Protocol <xref
        target="RFC6378"/> provides a single-phased coordination mechanism
        used for linear protection between two endpoints. This coordination
        mechanism is useful when there is a need of traffic to be transported
        on two co-routed paths. In SRv6, active and backup candidate paths in
        SR policy can provide an end-to-end protection to a specific SRv6
        path. However, without a coordination mechanism like PSC, SR policy
        cannot guarantee the bidirectional traffics are transported on
        co-routed paths.</t>

        <t>ACH6 extends PSC protocol to exchange notification and coordination
        messages between SRv6 endpoints. An ordered segment list of working
        path and an ordered segment list of backup path are separately
        pre-created at the source and destination of an SRv6 path. Working
        paths on two SRv6 endpoints are co-routed, so does backup paths. When
        there is failure to indicate protection switchover on working path,
        ACH6 exchanges protection state coordination messages between SRv6
        endpoints to indicate synchronized switchover. When two SRv6 endpoints
        accomplish the switchover, the protection paths are co-routed for
        bidirectional traffics.</t>

        <t>Figure 5 gives the example format of ACH6 protection state
        coordination TLV.</t>

        <t><figure align="center">
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
                                |     Channel Type = PSC        |    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Ver|Request|PT |R|  Reserved1  |     FPath     |     Path      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
|                      Optional TLVs                            |                
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
]]></artwork>

            <postamble>Figure 5 ACH6 PSC TLV</postamble>
          </figure></t>

        <t>The definition and usage of Request, PT, R, FPath and Path fields
        are referenced to <xref target="RFC6378"/>.</t>
      </section>

      <section title="Resource Reservation to an SRv6 Path">
        <t>In current practice of SRv6, a distributed resource reservation
        protocol like RSVP-TE is not used. SDN controller plays the role of
        calculating forwarding path and reserving relevant resources to the
        path. It is feasible for controller to calculate bandwidth and send
        path setup information to headend via PCEP. But for the other metrics
        e.g. queues, same parameter may have different formats and values on
        each node. It is not effective for controller to separately establish
        PCE session with each node to provision the metrics.</t>

        <t>The second reason to use a distributed messages exchange mechanism
        among SRv6 endpoints is that modifications of path-based resource
        reservation are required to be accomplished fast enough to guarantee
        service's SLA when network failures happen, especially in the case
        when thousands of services with independent resource reservations are
        affected by the same failure on physical path.</t>

        <t>A proposed hybrid structure of resource reservation in SRv6 network
        is comprised of distributed ACH6 resource reservation mechanism and a
        centralized stateful PCE <xref target="RFC8231"/>.</t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t><list style="symbols">
          <t>This document requests IANA to assign a codepoint of Destination
          Options Header TLVs to indicate ACH6 TLV.</t>

          <t>This document request IANA to create a new registry of ACH6
          Channel Types to identify the usage of associated channel.</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>TBD</t>
    </section>

    <section title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.yang-rtgwg-ipv6-associated-channel'?>

      <?rfc include='reference.I-D.ietf-spring-srv6-path-segment'?>

      <?rfc include='reference.RFC.6378'?>

      <?rfc include='reference.I-D.ietf-6man-spring-srv6-oam'
?>

      <?rfc include='reference.I-D.ietf-ippm-ioam-data'
?>

      <?rfc include='reference.RFC.8762'?>

      <?rfc include='reference.RFC.8231'?>

      <?rfc include='reference.RFC.8754'?>

      <?rfc include='reference.I-D.song-spring-siam'?>
    </references>
  </back>
</rfc>
