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