SPRING Working Group                                             F. Yang
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                     Huawei Technologies
Expires: January 13, 2022                                  July 12, 2021


                        ACH6 in Segment Routing
                      draft-yang-spring-ach6-sr-00

Abstract

   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.

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 January 13, 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Yang & Zhou             Expires January 13, 2022                [Page 1]


Internet-Draft           ACH6 in Segment Routing               July 2021


   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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  ACH6 in Segment Routing . . . . . . . . . . . . . . . . . . .   3
     2.1.  ACH6 Network Reference Model in Segment Routing . . . . .   3
     2.2.  Identification of ACH6 in Segment Routing . . . . . . . .   4
     2.3.  ACH6 TLV Format in Segment Routing  . . . . . . . . . . .   4
     2.4.  Encapsulation of ACH6 TLV in Segment Routing  . . . . . .   5
   3.  Use Case of ACH6 in Segment Routing . . . . . . . . . . . . .   6
     3.1.  OAM to an SRv6 Path . . . . . . . . . . . . . . . . . . .   6
     3.2.  Protection to an SRv6 Path  . . . . . . . . . . . . . . .   7
     3.3.  Resource Reservation to an SRv6 Path  . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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.

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






Yang & Zhou             Expires January 13, 2022                [Page 2]


Internet-Draft           ACH6 in Segment Routing               July 2021


2.  ACH6 in Segment Routing

   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.

2.1.  ACH6 Network Reference Model in Segment Routing

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

   Figure 1 shows an ACH6 network reference model used in an SRv6
   network.

              SRv6 Endpoint   SRv6 Endpoint   SRv6 Endpoint
     +----+     +-------+      +---------+      +------+      +----+
 ----| Ex |-----|  ACH6 |------|  ACH6   |------| ACH6 |------| Ey |----
     |    |     |Ingress|      |Mid-Point|      |Egress|      |    |
     +----+     +-------+      +---------+      +------+      +----+
                |<-------------SRv6 Path-------------->|
                |<-------------SRv6 ACH6 ------------->|
     |<---------------------- SRv6 Domain ------------------------>|

               Figure 1 ACH6 Network Reference Model in SRv6

   Ex/Ey: SRv6 endpoint

   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.

   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.

   ACH6 Egress Node: indicates the exiting of control and management
   channel over an SRv6 path, where the control and management messages



Yang & Zhou             Expires January 13, 2022                [Page 3]


Internet-Draft           ACH6 in Segment Routing               July 2021


   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.

2.2.  Identification of ACH6 in Segment Routing

   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 [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 [I-D.ietf-spring-srv6-path-segment].

2.3.  ACH6 TLV Format in Segment Routing

   ACH6 TLV in Segment Routing is defined as:

      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                             ~
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2 ACH6 TLV Format in SR

   Type: 8 bits, indicates it is an ACH6 TLV.

   Length: 8 bits, defines the length of Value field in bytes.

   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.

   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.






Yang & Zhou             Expires January 13, 2022                [Page 4]


Internet-Draft           ACH6 in Segment Routing               July 2021


2.4.  Encapsulation of ACH6 TLV in Segment Routing

   In SRv6, ACH6 control channel is used in either an end-to-end or a
   hop-by-hop approach.

   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
   [I-D.song-spring-siam] can be used for ACH6 too.

   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.

   The encapsulation of ACH6 in IPv6 Destination Options Header is
   defined as:




























Yang & Zhou             Expires January 13, 2022                [Page 5]


Internet-Draft           ACH6 in Segment Routing               July 2021


 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)
~                                                               |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+

                  Figure 3 ACH6 TLV Encapsulation in SRv6

3.  Use Case of ACH6 in Segment Routing

3.1.  OAM to an SRv6 Path

   In SRv6, several works are carrying on to establish an SRv6 OAM
   toolset.  [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-



Yang & Zhou             Expires January 13, 2022                [Page 6]


Internet-Draft           ACH6 in Segment Routing               July 2021


   way Active Measurement Protocol (STAMP) [RFC8762] is encapsulated
   after UDP header to measure performance metrics in SRv6 network.
   [I-D.ietf-ippm-ioam-data] supports extensible data collection for
   SRv6 network monitor and measurement.

   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.

   Figure 4 gives the example format of ACH6 OAM TLV.

    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)                   ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 4 ACH6 OAM TLV

   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.

3.2.  Protection to an SRv6 Path

   Protection State Coordination (PSC) Protocol [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.



Yang & Zhou             Expires January 13, 2022                [Page 7]


Internet-Draft           ACH6 in Segment Routing               July 2021


   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.

   Figure 5 gives the example format of ACH6 protection state
   coordination TLV.

    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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 5 ACH6 PSC TLV

   The definition and usage of Request, PT, R, FPath and Path fields are
   referenced to [RFC6378].

3.3.  Resource Reservation to an SRv6 Path

   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.

   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.




Yang & Zhou             Expires January 13, 2022                [Page 8]


Internet-Draft           ACH6 in Segment Routing               July 2021


   A proposed hybrid structure of resource reservation in SRv6 network
   is comprised of distributed ACH6 resource reservation mechanism and a
   centralized stateful PCE [RFC8231].

4.  IANA Considerations

   o  This document requests IANA to assign a codepoint of Destination
      Options Header TLVs to indicate ACH6 TLV.

   o  This document request IANA to create a new registry of ACH6
      Channel Types to identify the usage of associated channel.

5.  Security Considerations

   TBD

6.  Acknowledgements

   TBD

7.  References

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

7.2.  Informative References

   [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)",
              draft-ietf-6man-spring-srv6-oam-10 (work in progress),
              April 2021.

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
              for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in
              progress), February 2021.





Yang & Zhou             Expires January 13, 2022                [Page 9]


Internet-Draft           ACH6 in Segment Routing               July 2021


   [I-D.ietf-spring-srv6-path-segment]
              Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi,
              "Path Segment for SRv6 (Segment Routing in IPv6)", draft-
              ietf-spring-srv6-path-segment-00 (work in progress),
              November 2020.

   [I-D.song-spring-siam]
              Song, H. and T. Pan, "SRv6 In-situ Active Measurement",
              draft-song-spring-siam-00 (work in progress), December
              2020.

   [I-D.yang-rtgwg-ipv6-associated-channel]
              Yang, F., Chen, M., and T. Zhou, "Associated Channel over
              IPv6", draft-yang-rtgwg-ipv6-associated-channel-00 (work
              in progress), February 2021.

   [RFC6378]  Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
              N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
              TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
              October 2011, <https://www.rfc-editor.org/info/rfc6378>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

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

   [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

   Fan Yang
   Huawei Technologies
   Beijing
   China

   Email: shirley.yangfan@huawei.com






Yang & Zhou             Expires January 13, 2022               [Page 10]


Internet-Draft           ACH6 in Segment Routing               July 2021


   Tianran Zhou
   Huawei Technologies
   Beijing
   China

   Email: zhoutianran@huawei.com













































Yang & Zhou             Expires January 13, 2022               [Page 11]