RTGWG Working Group F. Yang
Internet-Draft M. Chen
Intended status: Standards Track T. Zhou
Expires: August 26, 2021 Huawei Technologies
February 22, 2021
Associated Channel over IPv6
draft-yang-rtgwg-ipv6-associated-channel-00
Abstract
In this document, an associated channel is introduced to provide a
control channel based on IPv6, carrying types of control and
management messages. By using the associated channel, messages can
be transmitted between the network nodes to provide functions like
path identification, OAM, protection switchover signaling, etc.,
targeting to provide high quality SLA guarantee to service.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 August 26, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yang, et al. Expires August 26, 2021 [Page 1]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Associated Channel . . . . . . . . . . . . . . . . . . . . . 3
3.1. Identification of Associated Channel . . . . . . . . . . 3
3.2. ACH TLV to Carry Message . . . . . . . . . . . . . . . . 3
3.3. Encapsulation of ACH TLV in IPv6 . . . . . . . . . . . . 4
3.3.1. Encapsulated in IPv6 Destination Options Header . . . 5
3.3.2. Encapsulated in IPv6 Hop-by-Hop Options Header . . . 5
3.3.3. Encapsulated in IPv6 Segment Routing Header . . . . . 6
3.3.4. Encapsulated in Payload . . . . . . . . . . . . . . . 6
3.4. Processing of ACH TLV . . . . . . . . . . . . . . . . . . 7
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Path Identification . . . . . . . . . . . . . . . . . . . 7
4.2. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Assist to Protection Switchover . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
IPv6 is becoming widely accepted to provide the connectivity in many
new emerging scenarios, including Cloud Network convergence, Cloud-
Cloud interconnection, 5G vertical industries, Internet of Things, as
well as the legacy networks migrating towards SR over IPv6. However,
IP packet is locally lookup, and forwarded hop by hop without aware
of the forwarding path. Path segment over SRv6
[I-D.ietf-spring-srv6-path-segment] provides a good solution to
identify an SR path over IPv6, but can only be applicable in source
routing paradigm.
Yang, et al. Expires August 26, 2021 [Page 2]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 2021
To identify an IPv6 forwarding path, further to better control and
manage the path, this document introduces an associated channel based
on IPv6, intenting to create a control channel for the control and
management usages. By using the associated channel, messages can be
transmitted between the network nodes to provide functions like path
identification, OAM, protection switchover signaling, etc., targeting
to provide high quality SLA guarantee to service.
This document also defines a TLV format for the associated channel
and how it can be encapsulated in IPv6 packet, and the potential
applicability in IPv6 networks. Applications of associated channel
in IPv6 shall be specified in different documents and thus are out of
scope of this document.
2. Terminology
OAM: Operations, Administration, and Maintenance
SLA: Service Level Agreement
ACH: Associated CHannel
3. Associated Channel
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 parts of information, including the
identification of associated channel and the carried message.
3.1. Identification of Associated Channel
The identification of associated channel indicates the path where the
packets of associated channel are transmitted on. This
identification also indicates the same path of the service forwarding
path which the associated channel is associated to.
3.2. ACH TLV to Carry Message
An Associated CHannel (ACH) TLV is designed to carry the message of
an associated channel. ACH TLV has the following format:
Yang, et al. Expires August 26, 2021 [Page 3]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD1 | length | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Associated Channel ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 ACH TLV Format
Type: 8 bits, indicates it is an associated channel (ACH) TLV, and
request a value assigned by IANA. The uniform type of TLV
generalizes the applicability of ACH 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 as a part of Value
field. It indicates the specific type of messages carried in
associated channel. Note that a new ACH TLV Channel Type Registry
would be requested to IANA. In the 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 part of Value field. It specifies the messages
indicated by Channel Type and carried in associated channel. Note
that the Value field of ACH TLV MAY contain sub-TLVs to provide
additional context information to ACH TLV.
3.3. Encapsulation of ACH TLV in IPv6
In the context of IPv6, ACH TLV can be encapsulated in different
types of IPv6 extension header or even IPv6 payload. Note that, no
matter which way ACH TLV is applied, there is no semantic change to
IPv6 extension headers. Moreover, ACH TLV can be carried either with
user data in an in-situ way, or in a independent synthetic packet.
Yang, et al. Expires August 26, 2021 [Page 4]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 2021
3.3.1. Encapsulated in IPv6 Destination Options Header
ACH TLV can be encapsulated in IPv6 Destination Options Header as the
TLV-encoded options. Figure 2 gives an example of an ACH 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 | Type=ACH | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Type | Associated Channel ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value (depends on the specific protocol) ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 ACH TLV in IPv6 Destination Options Header
According to the note 1 and note 3 described in section 4.1
of[RFC8200], ACH TLV encapsulated in IPv6 Destination Options Header
can provide two semantics of 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.
3.3.2. Encapsulated in IPv6 Hop-by-Hop Options Header
ACH 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.
Similarly, the ACH TLV in IPv6 Hop-by-Hop Options Header shares the
same encapsulation shown in Figure 2.
When it is encapsulated in IPv6 Hop-by-Hop Options Header, it
provides an associated channel at every node along the forwarding
path.
Yang, et al. Expires August 26, 2021 [Page 5]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 2021
3.3.3. Encapsulated in IPv6 Segment Routing Header
ACH TLV can be encapsulated in IPv6 Segment Routing Header, as SRH
optional TLV. Figure 3 gives an example of an ACH TLV encapsulated
in IPv6 Segment Routing 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 | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Segment List[0] (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Segment List[n] (128 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=ACH | Length | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Associated Channel ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value (depends on the specific protocol) ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Other Optional Type Length Value objects (variable) ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 ACH TLV in IPv6 Segment Routing Header
When ACH TLV is encapsulated in IPv6 Segment Routing Header, it
provides an associated channel at every SRv6 endpoints along the
path.
3.3.4. Encapsulated in Payload
ACH TLV can also be encapsulated in the payload of an IPv6 packet.
The term of 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 is associated to. For example, synthetic packet
can encapsulate the same segment list as the one used in IPv6 SRH of
service data.
Yang, et al. Expires August 26, 2021 [Page 6]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 2021
3.4. Processing of ACH TLV
Take the ACH TLV encapsulated in Segment Routing Header as an
example. At headend, ACH TLV is encapsulated with control and
management messages in Segment Routing Header. When midpoint or
tail-end receives an SRv6 packet with ACH TLV, it recognizes the ACH
TLV, check the Channel Type field to interpret the protocol, and
continue with processing of messages. The processing of message is
not limited, for example READ or/and WRITE. It should depend on the
specification of protocols used in the associated channel.
4. Applicability
4.1. Path Identification
In a native IPv6 network, packets is 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.
4.2. OAM
OAM includes the 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 ACH 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 ACH TLV
to provide a set of OAM functions. By using ACH TLV to carry OAM
messages in associated channel, different OAM functions can be easily
integrated. The OAM functions can be performed in either end-to-end
or hop-by-hop mode. For example, signal degrade happens on the
intermediate node could be discovered and further indicated in
associated channel to monitor the path status.
4.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. ACH TLV can be used to transmit the protection state
control messages on an IPv6 forwarding path to provide the function
of bidirectional protection switchover.
Yang, et al. Expires August 26, 2021 [Page 7]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 2021
5. 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 ACH TLV.
o This document request IANA to create a new IANA-managed registry
of ACH Channel Type to identify the usage of associated channel.
6. Security Considerations
TBD
7. Acknowledgements
TBD
8. References
8.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>.
8.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.
[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>.
[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>.
Yang, et al. Expires August 26, 2021 [Page 8]
Internet-Draft draft--yang-rtgwg-ipv6-associated-channel February 2021
Authors' Addresses
Fan Yang
Huawei Technologies
Beijing
China
Email: shirley.yangfan@huawei.com
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 August 26, 2021 [Page 9]