Internet DRAFT - draft-yang-rtgwg-ipv6-associated-channel

draft-yang-rtgwg-ipv6-associated-channel







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


                      Associated Channel over IPv6
              draft-yang-rtgwg-ipv6-associated-channel-01

Abstract

   This document introduces a control channel based on IPv6, called
   Associated CHannel over IPv6 (ACH6), that may carry different types
   of control and management messages.  By using the associated channel,
   messages can be transmitted between network nodes to provide
   functions like path identification, OAM, automatic protection
   switchover signaling, resource reservation, etc., targeting to
   provide high quality SLA guarantees to IPv6 services.

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.







Yang, et al.            Expires January 13, 2022                [Page 1]

Internet-Draft           IPv6 Associated Channel               July 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 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture of Associated Channel over IPv6  . . . . . . . .   4
     3.1.  ACH6 Network Reference Model  . . . . . . . . . . . . . .   4
     3.2.  ACH6 Processing . . . . . . . . . . . . . . . . . . . . .   5
   4.  Format of Associated Channel over IPv6  . . . . . . . . . . .   5
     4.1.  Identification of ACH6  . . . . . . . . . . . . . . . . .   5
     4.2.  Carried Message of ACH6 . . . . . . . . . . . . . . . . .   6
     4.3.  ACH6 TLV Format . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Encapsulation of ACH6 TLV in IPv6 . . . . . . . . . . . .   7
       4.4.1.  Encapsulated in IPv6 Destination Options Header . . .   7
       4.4.2.  Encapsulated in IPv6 Hop-by-Hop Options Header  . . .   7
       4.4.3.  Encapsulated in IPv6 Segment Routing Header . . . . .   8
       4.4.4.  Encapsulated in Payload . . . . . . . . . . . . . . .   9
     4.5.  Considerations  . . . . . . . . . . . . . . . . . . . . .  10
   5.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Path Identification . . . . . . . . . . . . . . . . . . .  10
     5.2.  OAM . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Assist to Protection Switchover . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12








Yang, et al.            Expires January 13, 2022                [Page 2]

Internet-Draft           IPv6 Associated Channel               July 2021


1.  Introduction

   IPv6 is becoming widely accepted to provide connectivity in many new
   emerging scenarios, including Cloud Network convergence, Cloud-Cloud
   interconnection, 5G vertical industries, and Internet of Things etc.
   However, due to the best effort forwarding genes, native IP (for both
   IPv4 and IPv6) cannot provide the forwarding capabilities such as
   explicit path, control and management based on the forwarding path,
   to meet the requirements of services accordingly.

   Generic Associated Channel (G-ACh) [RFC5586] introduces an associated
   control channel to MPLS to provide a set of maintenance functions,
   including OAM, performance monitoring, automatic protection switching
   and support of management to MPLS Sections, MPLS Label Switched Paths
   (LSPs), and MPLS pseudowires (PWs).

   Triggered by MPLS G-ACh, to enhance the control and management
   capabilities to IPv6, this document introduces an associated channel
   to a specific IPv6 path, called Associated Channel over IPv6 (ACH6).
   Associated channel over IPv6 intends to create a control channel
   associated with the IPv6 data forwarding path for control and
   management purposes.  By using the associated channel, messages can
   be transmitted between the network nodes to provide functions like
   path identification, OAM, automatic protection switchover signaling,
   resource reservation, etc., targeting to provide high quality SLA
   guarantees to services.  To identify an IPv6 forwarding path,
   associated channel ID is also introduced.

   This document defines an ACH6 architecture, a TLV-based format of
   ACH6, and discusses how ACH6 format can be encapsulated in IPv6
   packet.  It also discusses the applicability of ACH6 in IPv6 network.

2.  Terminology

   This document uses the terminology defined in [RFC8200] , and it also
   introduces the following new terms:

   OAM: Operations, Administration, and Maintenance

   SLA: Service Level Agreement

   G-ACh: Generic Associated Channel

   ACH6: Associated CHannel over IPv6







Yang, et al.            Expires January 13, 2022                [Page 3]

Internet-Draft           IPv6 Associated Channel               July 2021


3.  Architecture of Associated Channel over IPv6

3.1.  ACH6 Network Reference Model

   Figure 1 gives a network reference model of associated channel over
   IPv6.  The key components in ACH6 network reference model include
   ACH6 Ingress Node, ACH6 Mid-Point Node, and ACH6 Egress Node.  These
   nodes must be IPv6-capable node.

           +----+   +-------+    +---------+   +------+   +----+
       ----| Nx |---|  ACH6 |----|  ACH6   |---| ACH6 |---| Ny |----
           |    |   |Ingress|    |Mid-Point|   |Egress|   |    |
           +----+   +-------+    +---------+   +------+   +----+
                    |<-----------IPv6 Path----------->|
                    |<--------------ACH6------------->|
       |<-----------------------IPv6 Network---------------------->|

                   Figure 1 ACH6 Network Reference Model

   In the network reference model,

   Nx/Ny: IPv6 node, can be either a host or a router.

   ACH6 Ingress Node: is the node indicates the entering of control and
   management channel over an IPv6 path, where control and management
   messages are generated and encapsulated.

   ACH6 Mid-Point Node: is the node that has the capability to process
   control and management messages over an IPv6 path.  For a strict
   explicit IPv6 path, all the IPv6 hop(s) forwarded from IPv6 source
   address to IPv6 destination address are mid-point node(s).

   ACH6 Egress Node: is the node indicates the exiting of control and
   management channel over an IPv6 path, where control and management
   messages are recovered and delivered to control or management plane
   for further process.

   IPv6 Path: a specific path from the source node to the destination
   node in IPv6 forwarding plane.  An IPv6 path can be explicitly or
   implicitly represented by forwarding hops from IPv6 source node to
   IPv6 destination node.

   ACH6: Associated Channel over IPv6








Yang, et al.            Expires January 13, 2022                [Page 4]

Internet-Draft           IPv6 Associated Channel               July 2021


3.2.  ACH6 Processing

   Regarding to an IPv6 path, an ACH6 control channel is established to
   this specific IPv6 path for a required purpose.  ACH6 ingress node
   acts as the IPv6 source node, and ACH6 egress node is the IPv6
   destination node.  ACH6 ingress node encapsulates control or
   management messages into IPv6 packets, identifies the specific
   channel type which carried messages belong to, and sends the IPv6
   ACH6 packets to the destination of IPv6 path.  The control and
   management messages can either piggyback with data packets, or
   generated and transmitted separately.

   When ACH6 Mid-Point Node receives ACH6 IPv6 packets, it firstly
   recognizes ACH6 associated channel to interpret the control protocol,
   and then processes the messages.  The processing of messages can
   include for example READ or/and WRITE, depending on the specification
   of protocols used in the associated channel.  ACH6 Mid-Point Node
   needs to transmit the IPv6 packets carried with the original or
   modified ACH6 messages to the destination of IPv6 packet.

   ACH6 Egress Node receives ACH6 IPv6 packets and recognizes itself as
   the destination.  Based on the specific type of control protocol, the
   message is delivered to control or management planes for further
   process.

4.  Format of Associated Channel over IPv6

   An associated channel provides a control channel that carries at
   least one or more types of control and management messages.  The type
   of message is not limited to any specific usage.  The associated
   channel is specified by two pieces of information, including the
   identification of the associated channel and the carried message.

4.1.  Identification of ACH6

   The identification of associated channel, called Associated Channel
   ID, indicates the path where the packets of the associated channel
   are transmitted on.  This identification also indicates the same path
   of the service forwarding path with which the associated channel is
   associated.  When the Associated Channel ID is carried in the
   associated channel, ACH6 edge nodes and intermediated nodes should
   interpret it to identify the same IPv6 path.

   The associated channel ID can be defined either globally unique or
   site local, or even link local.  The Associated Channel ID can be
   self-generated, or designated from management plane, or advertised
   and allocated via control protocol.




Yang, et al.            Expires January 13, 2022                [Page 5]

Internet-Draft           IPv6 Associated Channel               July 2021


4.2.  Carried Message of ACH6

   At least one control or management protocol messages are transmitted
   via associated channel over IPv6.  When multiple protocols are
   running over an IPv6 path, messages of different protocols can be
   sent either in separate ACH6 TLVs in one ACH6 packet or in separate
   ACH6 packets with only one type of ACH6 TLV.

4.3.  ACH6 TLV Format

   An Associated CHannel over IPv6 (ACH6) TLV is designed to carry the
   identification and carried message of an associated channel.  ACH6
   TLV has the following format:

      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=TBD1  |    length     |          Channel Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                 Associated Channel ID                       //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               ~
     ~                             Value                             ~
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 2 ACH6 TLV Format

   Type: 8 bits, indicates it is an associated channel ACH6 TLV, and
   request a value assigned by IANA.  The uniform type of TLV
   generalizes the applicability of ACH6 TLV to support various types of
   messages.

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

   Channel Type: is a 16-bit-length fixed portion of Value field.  It
   indicates the specific type of messages carried in associated
   channel.  Note that a new ACH6 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.

   Associated Channel ID: indicates the identification of associated
   channel.  The length is TBD.

   Value: is a variable portion of Value field.  It specifies the
   messages indicated by Channel Type and carried in associated channel.




Yang, et al.            Expires January 13, 2022                [Page 6]

Internet-Draft           IPv6 Associated Channel               July 2021


   Note that the Value field of ACH6 TLV MAY contain sub-TLVs to provide
   additional context information to ACH6 TLV.

4.4.  Encapsulation of ACH6 TLV in IPv6

   In the context of IPv6, ACH6 TLV can be encapsulated in different
   types of IPv6 extension headers, or as an independent IPv6 payload.
   Note that, no matter which way ACH6 TLV is applied, there is no
   semantic change to IPv6 extension headers.

4.4.1.  Encapsulated in IPv6 Destination Options Header

   ACH6 TLV can be encapsulated in IPv6 Destination Options Header as
   the TLV-encoded options.  Figure 2 gives an example of an ACH6 TLV
   encapsulated in IPv6 Destination Options Header.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header   |  Hdr Ext Len  | Opt Type(ACH6)|  Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+
|         Channel Type          |      Associated Channel ID   //   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|                                                               ~ Option
~             Value (depends on the specific protocol)          ~  Data
~                                                               |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-+

           Figure 3 ACH6 TLV in IPv6 Destination Options Header

   According to the note 1 and note 3 described in section 4.1
   of[RFC8200], ACH6 TLV encapsulated in IPv6 Destination Options Header
   can provide two semantics of an associated channel.  When only IPv6
   Destination Options Header exists or IPv6 Destination Options Header
   exists after the Routing Header, an end to end associated channel is
   provided to transmit the messages between two endpoints.  When both
   IPv6 Destination Options Header and Routing Header exist, and IPv6
   Destination Options Header exists before the Routing Header, an
   associated channel is provided at network nodes of the first
   destination that appears in the IPv6 Destination Address field plus
   subsequent destinations listed in the Routing header.

4.4.2.  Encapsulated in IPv6 Hop-by-Hop Options Header

   ACH6 TLV can be encapsulated in IPv6 Hop-by-Hop Options Header as the
   TLV-encoded options.  Same option type numbering space is used for
   both Hop-by-Hop Options header and Destination Options header.




Yang, et al.            Expires January 13, 2022                [Page 7]

Internet-Draft           IPv6 Associated Channel               July 2021


   Similarly, the ACH6 TLV in IPv6 Hop-by-Hop Options Header shares the
   same encapsulation shown in Figure 3.

   When it is encapsulated in IPv6 Hop-by-Hop Options Header, it
   provides an associated channel at every node along the forwarding
   path.  ACH6 ingress node inserts the IPv6 HbH Option Header with ACH6
   Option Type, every mid-point node examines, processes and transmits
   the IPv6 packet to next forwarding hop.  ACH6 egress node receives
   the IPv6 packet as the destination node, ACH6 messages are processed
   and delivered to control or management plane for further usage.
   Processing is limited, can be READ and/or REWRITE.

   Routers that are not configured to support Hop-by-Hop Options SHOULD
   ignore this option and SHOULD forward the packet.

   Routers that support Hop-by-Hop Options, but that are not configured
   to support this option SHOULD ignore the option and SHOULD forward
   the packet.

4.4.3.  Encapsulated in IPv6 Segment Routing Header

   ACH6 TLV can be encapsulated in IPv6 Segment Routing Header, as SRH
   optional TLV.  Figure 3 gives an example of an ACH6 TLV encapsulated
   in IPv6 Segment Routing Header.



























Yang, et al.            Expires January 13, 2022                [Page 8]

Internet-Draft           IPv6 Associated Channel               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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header   |  Hdr Ext Len  |  Routing Type | Segments Left |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Last Entry |    Flags      |              Tag              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                  Segment List[0] (128 bits)                   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                ...                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   Segment List[n] (128 bits)                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=ACH6   |  Length       |           Channel Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                 Associated Channel ID                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~             Value (depends on the specific protocol)          ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~     Other Optional Type Length Value objects (variable)       ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4 ACH6 TLV in IPv6 Segment Routing Header

   When ACH6 TLV is encapsulated in IPv6 Segment Routing Header, it
   provides an associated channel at every SRv6 endpoints along the
   path.

4.4.4.  Encapsulated in Payload

   ACH6 TLV can also be encapsulated in the payload of an IPv6 packet.
   The term payload here means the octets after the IPv6 header and
   extension headers.  A synthetic packet is created with the payload of
   messages. and transmitted in an associated channel.  The synthetic
   packet can use the same routing information with service data whose
   associated channel it is associated.  For example, synthetic packet
   can encapsulate the same segment list as the one used in IPv6 SRH of
   service data.  If ACH6 TLV format is encapsulated in payload, TLV
   Type and Length can be omitted, a new codepoint of IP Protocol
   Numbers should be assigned.







Yang, et al.            Expires January 13, 2022                [Page 9]

Internet-Draft           IPv6 Associated Channel               July 2021


4.5.  Considerations

   When ACH6 TLV is deployed in either IPv6 extension headers or payload
   in IPv6 networks, there are serveral considerations needs to be taken
   into account:

   C1: MTU Increase

   Given that ACH6 messages increases the packet size of IPv6 packet, it
   may face the risk of exceeding the PMTU.  This problem can be solved
   by taking two things into considerations.  Firstly, the mechanism of
   each protocol should clearly specify the maximum size limit of
   carried messages in one IPv6 packet.  Secondly, operators or hosts
   who makes use of ACH6 to carry control and management messages should
   carefully design and ensure the addition of messages would not exceed
   the agreed PMTU.

   C2: Processing of IPv6 Extension Header

   Though IPv6 Extension Headers especially IPv6 Hop-by-Hop Option
   Header is not widely used in the Internet, there are some limited
   environments like Data Centers and Interconnections between Data
   Centers are experimentally using IPv6 Option Headers.  It is worth to
   keep the possibility of carrying ACH6 messages as Option in IPv6
   Extension Headers.

5.  Applicability

5.1.  Path Identification

   In a native IPv6 network, packets are transmitted hop by hop, there
   is no way to identify an IPv6 forwarding path.  The path needs to be
   identified when OAM or protection switchover is applied to the path.

5.2.  OAM

   OAM includes a group of functions such as connectivity verification,
   fault indication and detection, and performance measurement of loss
   and delay etc.  For example, BFD defines a generic control packet
   format that can be encapsulated in different data planes to provide
   low-overhead and short-duration failure detection function.  The
   format can also be encapsulated in ACH6 TLV as the option TLV of
   Destination Options Header, to provide the same connectivity
   verification and fault detect functions without introducing upper
   layer protocols.  Another example is to encapsulate PDU formats of
   Ethernet OAM [ITU-T G.8013] in Value field of ACH6 TLV to provide a
   set of OAM functions.  By using ACH6 TLV to carry OAM messages in an
   associated channel, different OAM functions can be easily integrated.



Yang, et al.            Expires January 13, 2022               [Page 10]

Internet-Draft           IPv6 Associated Channel               July 2021


   The OAM functions can be performed in either end-to-end or hop-by-hop
   mode.  For example, signal degradation that happens on the
   intermediate node could be discovered and further indicated in
   associated channel to monitor the path status.

5.3.  Assist to Protection Switchover

   Linear protection [RFC6378] provides a very flexible protection
   mechanism in a mesh network because it can operate between any pair
   of endpoints.  ACH6 TLV can be used to transmit the protection state
   control messages on an IPv6 forwarding path to provide the function
   of bidirectional protection switchover.

6.  IANA Considerations

   o  This document requests IANA to assign a codepoint of Destination
      Options and Hop-by-Hop Options.

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

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

7.  Security Considerations

   TBD

8.  Acknowledgements

   TBD

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







Yang, et al.            Expires January 13, 2022               [Page 11]

Internet-Draft           IPv6 Associated Channel               July 2021


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

9.2.  Informative References

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

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

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

Authors' Addresses

   Fan Yang
   Huawei Technologies
   Beijing
   China

   Email: shirley.yangfan@huawei.com










Yang, et al.            Expires January 13, 2022               [Page 12]

Internet-Draft           IPv6 Associated Channel               July 2021


   Mach(Guoyi) Chen
   Huawei Technologies
   Beijing
   China

   Email: mach.chen@huawei.com


   Tianran Zhou
   Huawei Technologies
   Beijing
   China

   Email: zhoutianran@huawei.com





































Yang, et al.            Expires January 13, 2022               [Page 13]