idnits 2.17.1 draft-yang-rtgwg-ipv6-associated-channel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 238 == Missing Reference: 'ITU-T G.8013' is mentioned on line 304, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group F. Yang 3 Internet-Draft M. Chen 4 Intended status: Standards Track T. Zhou 5 Expires: August 26, 2021 Huawei Technologies 6 February 22, 2021 8 Associated Channel over IPv6 9 draft-yang-rtgwg-ipv6-associated-channel-00 11 Abstract 13 In this document, an associated channel is introduced to provide a 14 control channel based on IPv6, carrying types of control and 15 management messages. By using the associated channel, messages can 16 be transmitted between the network nodes to provide functions like 17 path identification, OAM, protection switchover signaling, etc., 18 targeting to provide high quality SLA guarantee to service. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 26, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Associated Channel . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Identification of Associated Channel . . . . . . . . . . 3 64 3.2. ACH TLV to Carry Message . . . . . . . . . . . . . . . . 3 65 3.3. Encapsulation of ACH TLV in IPv6 . . . . . . . . . . . . 4 66 3.3.1. Encapsulated in IPv6 Destination Options Header . . . 5 67 3.3.2. Encapsulated in IPv6 Hop-by-Hop Options Header . . . 5 68 3.3.3. Encapsulated in IPv6 Segment Routing Header . . . . . 6 69 3.3.4. Encapsulated in Payload . . . . . . . . . . . . . . . 6 70 3.4. Processing of ACH TLV . . . . . . . . . . . . . . . . . . 7 71 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Path Identification . . . . . . . . . . . . . . . . . . . 7 73 4.2. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.3. Assist to Protection Switchover . . . . . . . . . . . . . 7 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 IPv6 is becoming widely accepted to provide the connectivity in many 86 new emerging scenarios, including Cloud Network convergence, Cloud- 87 Cloud interconnection, 5G vertical industries, Internet of Things, as 88 well as the legacy networks migrating towards SR over IPv6. However, 89 IP packet is locally lookup, and forwarded hop by hop without aware 90 of the forwarding path. Path segment over SRv6 91 [I-D.ietf-spring-srv6-path-segment] provides a good solution to 92 identify an SR path over IPv6, but can only be applicable in source 93 routing paradigm. 95 To identify an IPv6 forwarding path, further to better control and 96 manage the path, this document introduces an associated channel based 97 on IPv6, intenting to create a control channel for the control and 98 management usages. By using the associated channel, messages can be 99 transmitted between the network nodes to provide functions like path 100 identification, OAM, protection switchover signaling, etc., targeting 101 to provide high quality SLA guarantee to service. 103 This document also defines a TLV format for the associated channel 104 and how it can be encapsulated in IPv6 packet, and the potential 105 applicability in IPv6 networks. Applications of associated channel 106 in IPv6 shall be specified in different documents and thus are out of 107 scope of this document. 109 2. Terminology 111 OAM: Operations, Administration, and Maintenance 113 SLA: Service Level Agreement 115 ACH: Associated CHannel 117 3. Associated Channel 119 An associated channel provides a control channel that carries at 120 least one or more types of control and management messages. The type 121 of message is not limited to any specific usage. The associated 122 channel is specified by two parts of information, including the 123 identification of associated channel and the carried message. 125 3.1. Identification of Associated Channel 127 The identification of associated channel indicates the path where the 128 packets of associated channel are transmitted on. This 129 identification also indicates the same path of the service forwarding 130 path which the associated channel is associated to. 132 3.2. ACH TLV to Carry Message 134 An Associated CHannel (ACH) TLV is designed to carry the message of 135 an associated channel. ACH TLV has the following format: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type=TBD1 | length | Channel Type | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 // Associated Channel ID // 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | ~ 145 ~ Value ~ 146 ~ | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1 ACH TLV Format 151 Type: 8 bits, indicates it is an associated channel (ACH) TLV, and 152 request a value assigned by IANA. The uniform type of TLV 153 generalizes the applicability of ACH TLV to support various types of 154 messages. 156 Length: 8 bits, defines the length of Value field in bytes. 158 Channel Type: is a 16-bit-length fixed portion as a part of Value 159 field. It indicates the specific type of messages carried in 160 associated channel. Note that a new ACH TLV Channel Type Registry 161 would be requested to IANA. In the later documents which specify 162 application protocols of associated channel, MUST also specify the 163 applicable Channel Type field value assigned by IANA. 165 Associated Channel ID: indicates the identification of associated 166 channel. The length is TBD. 168 Value: is a variable part of Value field. It specifies the messages 169 indicated by Channel Type and carried in associated channel. Note 170 that the Value field of ACH TLV MAY contain sub-TLVs to provide 171 additional context information to ACH TLV. 173 3.3. Encapsulation of ACH TLV in IPv6 175 In the context of IPv6, ACH TLV can be encapsulated in different 176 types of IPv6 extension header or even IPv6 payload. Note that, no 177 matter which way ACH TLV is applied, there is no semantic change to 178 IPv6 extension headers. Moreover, ACH TLV can be carried either with 179 user data in an in-situ way, or in a independent synthetic packet. 181 3.3.1. Encapsulated in IPv6 Destination Options Header 183 ACH TLV can be encapsulated in IPv6 Destination Options Header as the 184 TLV-encoded options. Figure 2 gives an example of an ACH TLV 185 encapsulated in IPv6 Destination Options Header. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Next Header | Hdr Ext Len | Type=ACH | Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Channel Type | Associated Channel ID // 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | ~ 195 ~ Value (depends on the specific protocol) ~ 196 ~ | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2 ACH TLV in IPv6 Destination Options Header 201 According to the note 1 and note 3 described in section 4.1 202 of[RFC8200], ACH TLV encapsulated in IPv6 Destination Options Header 203 can provide two semantics of associated channel. When only IPv6 204 Destination Options Header exists or IPv6 Destination Options Header 205 exists after the Routing Header, an end to end associated channel is 206 provided to transmit the messages between two endpoints. When both 207 IPv6 Destination Options Header and Routing Header exist, and IPv6 208 Destination Options Header exists before the Routing Header, an 209 associated channel is provided at network nodes of the first 210 destination that appears in the IPv6 Destination Address field plus 211 subsequent destinations listed in the Routing header. 213 3.3.2. Encapsulated in IPv6 Hop-by-Hop Options Header 215 ACH TLV can be encapsulated in IPv6 Hop-by-Hop Options Header as the 216 TLV-encoded options. Same option type numbering space is used for 217 both Hop-by-Hop Options header and Destination Options header. 218 Similarly, the ACH TLV in IPv6 Hop-by-Hop Options Header shares the 219 same encapsulation shown in Figure 2. 221 When it is encapsulated in IPv6 Hop-by-Hop Options Header, it 222 provides an associated channel at every node along the forwarding 223 path. 225 3.3.3. Encapsulated in IPv6 Segment Routing Header 227 ACH TLV can be encapsulated in IPv6 Segment Routing Header, as SRH 228 optional TLV. Figure 3 gives an example of an ACH TLV encapsulated 229 in IPv6 Segment Routing Header. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Last Entry | Flags | Tag | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 ~ Segment List[0] (128 bits) ~ 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 ~ ... ~ 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 ~ Segment List[n] (128 bits) ~ 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type=ACH | Length | Channel Type | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 // Associated Channel ID // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | ~ 249 ~ Value (depends on the specific protocol) ~ 250 ~ | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | ~ 253 ~ Other Optional Type Length Value objects (variable) ~ 254 ~ | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 3 ACH TLV in IPv6 Segment Routing Header 259 When ACH TLV is encapsulated in IPv6 Segment Routing Header, it 260 provides an associated channel at every SRv6 endpoints along the 261 path. 263 3.3.4. Encapsulated in Payload 265 ACH TLV can also be encapsulated in the payload of an IPv6 packet. 266 The term of payload here means the octets after the IPv6 header and 267 extension headers. A synthetic packet is created with the payload of 268 messages. and transmitted in an associated channel. The synthetic 269 packet can use the same routing information with service data whose 270 associated channel is associated to. For example, synthetic packet 271 can encapsulate the same segment list as the one used in IPv6 SRH of 272 service data. 274 3.4. Processing of ACH TLV 276 Take the ACH TLV encapsulated in Segment Routing Header as an 277 example. At headend, ACH TLV is encapsulated with control and 278 management messages in Segment Routing Header. When midpoint or 279 tail-end receives an SRv6 packet with ACH TLV, it recognizes the ACH 280 TLV, check the Channel Type field to interpret the protocol, and 281 continue with processing of messages. The processing of message is 282 not limited, for example READ or/and WRITE. It should depend on the 283 specification of protocols used in the associated channel. 285 4. Applicability 287 4.1. Path Identification 289 In a native IPv6 network, packets is transmitted hop by hop, there is 290 no way to identify an IPv6 forwarding path. The path needs to be 291 identified when OAM or protection switchover is applied to the path. 293 4.2. OAM 295 OAM includes the a group of functions such as connectivity 296 verification, fault indication and detection, and performance 297 measurement of loss and delay etc. For example, BFD defines a 298 generic control packet format that can be encapsulated in different 299 data planes to provide low-overhead and short-duration failure 300 detection function. The format can also be encapsulated in ACH TLV 301 as the option TLV of Destination Options Header, to provide the same 302 connectivity verification and fault detect functions without 303 introducing upper layer protocols. Another example is to encapsulate 304 PDU formats of Ethernet OAM [ITU-T G.8013] in Value field of ACH TLV 305 to provide a set of OAM functions. By using ACH TLV to carry OAM 306 messages in associated channel, different OAM functions can be easily 307 integrated. The OAM functions can be performed in either end-to-end 308 or hop-by-hop mode. For example, signal degrade happens on the 309 intermediate node could be discovered and further indicated in 310 associated channel to monitor the path status. 312 4.3. Assist to Protection Switchover 314 Linear protection [RFC6378] provides a very flexible protection 315 mechanism in a mesh network because it can operate between any pair 316 of endpoints. ACH TLV can be used to transmit the protection state 317 control messages on an IPv6 forwarding path to provide the function 318 of bidirectional protection switchover. 320 5. IANA Considerations 322 o This document requests IANA to assign a codepoint of Destination 323 Options and Hop-by-Hop Options. 325 o This document requests IANA to assign a codepoint of Segment 326 Routing Header TLVs to indicate ACH TLV. 328 o This document request IANA to create a new IANA-managed registry 329 of ACH Channel Type to identify the usage of associated channel. 331 6. Security Considerations 333 TBD 335 7. Acknowledgements 337 TBD 339 8. References 341 8.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 8.2. Informative References 350 [I-D.ietf-spring-srv6-path-segment] 351 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 352 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 353 ietf-spring-srv6-path-segment-00 (work in progress), 354 November 2020. 356 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 357 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 358 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 359 October 2011, . 361 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 362 (IPv6) Specification", STD 86, RFC 8200, 363 DOI 10.17487/RFC8200, July 2017, 364 . 366 Authors' Addresses 368 Fan Yang 369 Huawei Technologies 370 Beijing 371 China 373 Email: shirley.yangfan@huawei.com 375 Mach(Guoyi) Chen 376 Huawei Technologies 377 Beijing 378 China 380 Email: mach.chen@huawei.com 382 Tianran Zhou 383 Huawei Technologies 384 Beijing 385 China 387 Email: zhoutianran@huawei.com