idnits 2.17.00 (12 Aug 2021) /tmp/idnits15346/draft-du-spring-connection-oriented-srv6-01.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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2, 2022) is 73 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) == Missing Reference: 'SL' is mentioned on line 136, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft P. Liu 4 Intended status: Standards Track China Mobile 5 Expires: September 3, 2022 March 2, 2022 7 Connection-oriented Path in SRv6 Network 8 draft-du-spring-connection-oriented-srv6-01 10 Abstract 12 This document proposes a method to support connection-oriented path 13 in the SRv6 network. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 3, 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Data Plane for Connection-oriented Path . . . . . . . . . . . 3 57 3. Control Plane for Connection-oriented Path . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 SRv6 Network Programming concept is introduced in [RFC8986] and 69 [I-D.filsfils-spring-srv6-net-pgm-illustration], which enables a data 70 plane based network programming mechanism that goes beyond mere 71 packet routing. 73 According to [RFC8986], an SRv6 SID is defined as the format of 74 LOC:FUNCT:ARG, where the LOC stands for a locator, the FUNCT stands 75 for a function, and the ARG is optional and stands for the arguments 76 of the function. The locator is usually used to route the packet to 77 the node who generates the SID. The basic functions of SRv6 are End 78 (related to a node) and End.X (related to a link/adjacency), and many 79 other functions are also defined, including some VPN related ones and 80 some binding SIDs. In addition, it is said that even a local VM or 81 container which can apply any complex processing on the packet can be 82 defined as a function. The functions may or may not include 83 arguments. 85 Based on SRv6, a node in the network can initiate a SID list for a flow, so that a packet of the flow would be routed 87 to the first node where the function1 related to SID1 would be 88 implemented, then be routed to the second node where function2 89 related to SID2 would be implemented, and trigger similar operations 90 according to SID3. 92 In fact, both MPLS and SRv6 are some kind of languages that support 93 network programming. By using a label to represent a VPN instance, 94 MPLS provides a good support to the VPN services in the network. 95 SRv6 now shows a more powerful capability in network programming. 96 Perhaps in future, a lot of new network characteristics would be 97 developed based on SRv6; meanwhile, some old network characteristics 98 may also be realized by using SRv6 to integrate network protocols, 99 and simplify the network. This document gives an example of the 100 later. 102 Traditional MPLS transport is not source routing based, but is label 103 switching based. In MPLS networks, we can establish a label 104 switching path for a specific flow. It looks like a connection- 105 oriented path. If using the current SRv6 mechanism, we need to 106 initiate a SID list that includes every node 107 along the path, which is inconvenience. This document proposes a new 108 SRv6 mechanism to support the connection-oriented path by defining 109 some new functions on the node. 111 The motivation to support connection-oriented path in SRv6 is that 112 sometimes a strict hop-by-hop TE path is needed in the network, such 113 as a DetNet path defined in RFC 8655 [RFC8655]. In one realization 114 of DetNet, each node along the path need allocate specific resources 115 to the critical traffic, and a fixed path must be used. In future, 116 the network may evolve to a pure SRv6 network without MPLS. In this 117 situation, SRv6 should support some old network characteristics, such 118 as the connection-oriented characteristic mentioned in this document. 120 2. Data Plane for Connection-oriented Path 122 Data plane for connection-oriented path in SRv6 is easy to design. 123 We just need to define a new End.XCopd function, which is similar to 124 END.X (binding to a cross-connected adjacency in Layer-3), but 125 includes a label argument. 127 When receiving a packet with an End.XCopd SID S as the DA, the node 128 will match the SID in "My SID Table" to ensure that S is generated by 129 itself, and also check whether the label is valid. If all checks are 130 ok, the node should be able to obtain the outgoing SID S2. The node 131 should replace the DA with the outgoing SID S2, and forward the 132 packet to the layer-3 adjacency bound to the SID S. 134 The penultimate node along the path will find that the connection- 135 oriented path is about to terminate, so that it will do normal End.X 136 operations, i.e., decrement SL, update the IPv6 DA with SRH[SL], and 137 forward the packet to the layer-3 adjacency bound to the SID. 139 _______ _______ _______ _______ _______ 140 | Node1 |----| Node2 |----| Node3 |----| Node4 |----| Node5 | 141 ------- ------- ------- ------- ------- 142 Node1: 143 Node2: 144 Node3: 145 Node4: 147 Figure 1: changes along the Connection-oriented Path 148 in the data plane 150 Figure 1 shows an example of label switching in SRv6. It is assumed 151 that each NodeX has a locator as AX. Node 1 sends a packet to Node 5 152 with an SRH header: and an 153 pair: . And it is assumed that 154 A1::End.XCopd:ARG1 can match a switching table entry: incoming SID 155 A1::End.XCopd:ARG1, outgoing SID A2::End.XCopd:ARG2, and an interface 156 binding to this End.XCopd:ARG1 function. Hence, after the process of 157 "label switching", the Node 1 sends out a packet with an SRH header: 158 and an pair: . 161 We assume that the Node 2 has a switching table entry: incoming SID 162 A2::End.XCopd:ARG2, outgoing SID A3::End.XCopd:ARG3, and an interface 163 binding to that End.XCopd:ARG2 function, so that the packet will be 164 sent to Node 3, and then Node 4. 166 We also assume that the Node 4 has a switching table entry: incoming 167 SID A4::End.XCopd:ARG4, outgoing SID A5::End.XCopd:0003, and an 168 interface binding to that End.XCopd function. When the label "0003" 169 appears, it means the node is the penultimate node. The Node 4 will 170 do normal End.X operations, and sends out a packet without an SRH 171 header, but with an pair: . 173 The way by which the label switching table is established on each 174 node is described in the following section. 176 3. Control Plane for Connection-oriented Path 178 A PCE-based/controller-based method can surely configure each node 179 along the path with a proper label switching table. However, this 180 document also provides another optional mechanism for the distributed 181 control plane. In fact, this method looks like what the RSVP-TE does 182 in the MPLS network defined in RFC 3209 [RFC3209]. In other words, 183 we can simulate some basic functions of RSVP-TE by using SRv6 network 184 programming. 186 We need to define a new End.Copc function, which can establish and 187 maintain the connection-oriented path. The End.Copc function also 188 includes a label argument. Some of the label space should be 189 reserved. In this document, we suppose that the label "0000" stands 190 for the path establishment procedure. If a node receives a packet 191 with an End.Copc function as the DA with a label value "0000", the 192 node will trigger the path establishment procedure just as what the 193 Path message does in RSVP-TE. If a node receives a packet with an 194 End.Copc function as the DA with a normal label value, the node will 195 use the downstream label to establish a label switching table entry 196 just as what the Resv message does in RSVP-TE. 198 However, in this way, the Head-End needs to notify each node along 199 the path by some means, and we do not have a notification mechanism 200 between different nodes in the data-plane network programming now. 201 This document suggests to enable a simple notification method for the 202 data-plane network programming if the information is not that 203 complicated. For example, we can send a "ping" message with a 204 specific TLV containing the necessary information. The advantage is 205 easy to inter operate. 207 _______ _______ _______ _______ _______ 208 | Node1 |----| Node2 |----| Node3 |----| Node4 |----| Node5 | 209 ------- ------- ------- ------- ------- 210 Node1: --->> 211 Node2: --->> 212 Node3: --->> 213 Node4: --->> 214 Node5: <<--- 215 Node4: <<--- 216 Node3: <<--- 217 Node2: <<--- 219 Figure 2: changes along the Connection-oriented Path 220 in the control plane 222 Figure 2 shows an example of label switching path establishment in 223 SRv6. Node 1 sends a "ping" packet with an pair: . A new TLV defined for "ping" would include each 225 End.Copc functions along the path. And it is assumed that 226 A1::End.Copc:0000 can match the "My SID Table", and the DA is 227 replaced by A2::End.Copc:0000 after the Node 1 has read the new TLV 228 in the payload. Similar operation takes place in Node2-4. 230 Node 5 will find it is the last SID after reading the new TLV in the 231 payload. It generates a label "0003", and sends back the packet. In 232 this time, the "ping" packet has an pair: . Node 4 can generate a label "0117", and establish a 234 swapping table entry: incoming SID A4::End.XCopd:0117, outgoing SID 235 A5::End.XCopd:0003, and an interface binding to the A4's End.XCopd 236 function. 238 Similarly, the Node 3 can generate a label "0445", and establish a 239 swapping table entry: incoming SID A3::End.XCopd:0445, outgoing SID 240 A4::End.XCopd:0117, and an interface binding to the A3's End.XCopd 241 function. 243 The Node 1 will find it is the first SID after reading the new TLV in 244 the payload, and optionally, it can also generate a label "1111", and 245 establish a swapping table entry: incoming SID A1::End.XCopd:1111, 246 outgoing SID A2::End.XCopd:0998, and an interface binding to the A1's 247 End.XCopd function. 249 The swapping table is used in this document for description 250 convenience. In fact, it should be several entries in the "My SID 251 Table". 253 4. IANA Considerations 255 TBD. 257 5. Security Considerations 259 TBD. 261 6. Acknowledgements 263 TBD. 265 7. References 267 7.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 275 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 276 (SRv6) Network Programming", RFC 8986, 277 DOI 10.17487/RFC8986, February 2021, 278 . 280 7.2. Informative References 282 [I-D.filsfils-spring-srv6-net-pgm-illustration] 283 Filsfils, C., Garvia, P. C., Li, Z., Matsushima, S., 284 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 285 J. Leddy, "Illustrations for SRv6 Network Programming", 286 draft-filsfils-spring-srv6-net-pgm-illustration-04 (work 287 in progress), March 2021. 289 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 290 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 291 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 292 . 294 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 295 "Deterministic Networking Architecture", RFC 8655, 296 DOI 10.17487/RFC8655, October 2019, 297 . 299 Authors' Addresses 301 Zongpeng Du 302 China Mobile 303 No.32 XuanWuMen West Street 304 Beijing 100053 305 China 307 Email: duzongpeng@foxmail.com 309 Peng Liu 310 China Mobile 311 No.32 XuanWuMen West Street 312 Beijing 100053 313 China 315 Email: liupengyjy@chinamobile.com