idnits 2.17.1 draft-murakami-dmm-user-plane-message-encoding-05.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 5, 2022) is 777 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'B0' is mentioned on line 243, but not defined == Missing Reference: 'B1' is mentioned on line 245, but not defined == Missing Reference: 'B2' is mentioned on line 247, but not defined == Missing Reference: 'B3' is mentioned on line 249, but not defined == Unused Reference: 'RFC2460' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-18 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Murakami, Ed. 3 Internet-Draft Arrcus, Inc 4 Intended status: Informational S. Matsushima 5 Expires: September 6, 2022 SoftBank 6 K. Ebisawa 7 Toyota Motor Corporation 8 P. Camarillo 9 R. Shekhar 10 Cisco Systems, Inc. 11 March 5, 2022 13 User Plane Message Encoding 14 draft-murakami-dmm-user-plane-message-encoding-05 16 Abstract 18 This document defines the encoding of User Plane messages into 19 Segment Routing Header (SRH). The SRH carries the User Plane 20 messages over SRv6 Network. 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 6, 2022. 39 Copyright Notice 41 Copyright (c) 2022 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 59 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. User Plane Message encoding into SRH . . . . . . . . . . . . 3 61 5.1. GTP-U Header format . . . . . . . . . . . . . . . . . . . 4 62 5.2. Args.Mob.Upmsg . . . . . . . . . . . . . . . . . . . . . 4 63 5.3. Encoding of Tags Field . . . . . . . . . . . . . . . . . 5 64 5.4. User Plane message Information Element Support . . . . . 6 65 5.5. SID flavor consideration . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 3GPP defines User Plane function (UPF) and the protocol messages that 77 it supports. The User Plane messages support in-band signalling for 78 path and tunnel management. Currently, User Plane messages are 79 defined in TS 29.281 [TS29281]. 81 When applying SRv6 (Segment Routing IPv6) to the user plane of mobile 82 networks, based on draft-ietf-dmm-srv6-mobile-uplane 83 [I-D.ietf-dmm-srv6-mobile-uplane]. User Plane messages must be 84 carried over SRv6 network. This document defines which User Plane 85 message must be encoded to SRv6 and also defines how to encode the 86 User Plane messages into SRH. 88 In addition, SRH is mandatory at the ultimate segment upon carrying 89 the User Plane messages because User Plane message is encoded into 90 SRH. Hence, this document considers how to deal with the encoding of 91 User Plane messages into SRH when PSP is applied that SRH is popped 92 out at the penultimate segment. 94 2. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 3. Conventions and Terminology 102 SRv6: Segment Routing IPv6. 104 GTP-U: GPRS Tunneling Protocol User Plane. 106 UPF: User Plane Function. 108 SRH: IPv6 Segment Routing Header. 110 PSP: Penultimate Segment POP of the SRH. 112 USP: Ultimate Segment Pop of the SRH. 114 4. Motivation 116 3GPP User Plane needs to support the user plane messages associated 117 with a GTP-U tunnel defined in [TS29281]. In the case of SRv6 User 118 Plane [I-D.ietf-dmm-srv6-mobile-uplane], those messages are also 119 required when the user plane interworks with GTP-U. 121 IPv6 Segment Routing Header (SRH) [RFC8754] is used for SRv6 User 122 Plane. SRH is able to associate additional information to the 123 segments. The Tag field of SRH is capable to indicate different 124 properties within a SID. SRH TLV is capable to provide meta-data to 125 the endpoint node. 127 The above capability of SRH motivates us to map the user plane 128 messages into it because of the same encapsulation with the packets 129 of carrying client packets. It introduces no additional headers or 130 extension headers to be chained in the packet just for carrying the 131 user plane messages. 133 5. User Plane Message encoding into SRH 135 This section defines how to encode the User Plane messages into SRH 136 in order to carry the User Plane messages over SRv6 network. 138 5.1. GTP-U Header format 140 3GPP defines GTP-U Header format as shown below. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Ver |P|R|E|S|N| Message Type | Length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Tunnel Endpoint Identifier | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Sequence Number | N-PDU Number | Next-Ext-Hdr | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: GTP-U Header format 154 User Plane message type is encoded in Message Type field of GTP-U 155 Header. The following User Plane messages must be carried over SRv6 156 network at least. The value of each User Plane message type is 157 defined as shown below. 159 Echo Request: 1 161 Echo Reply: 2 163 Error Indication: 26 165 End Marker: 254 167 5.2. Args.Mob.Upmsg 169 draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane] 170 defines the format of Args.Mob.Session argument which is used in SRv6 171 SID Mobility Functions in order to carry the PDU Session identifier. 172 The format of Args.Mobs.Session is defined as shown below. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | QFI |R|U| PDU Session ID | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |PDU Sess(cont')| 180 +-+-+-+-+-+-+-+-+ 182 Figure 2: Args.Mob.Session format 184 In case of Echo Request, Echo Reply and Error Indication, Sequence 185 Number in GTP-U header needs to be carried. Similar to draft-ietf- 186 dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane], the new 187 arguments to carry Sequqnce number for Echo Request, Echo Reply and 188 Error Indication message needs to be defined. For this, the 189 following Args.Mobs.Upmsg should be defined newly to carry Sequence 190 number. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | QFI |R|U| Sequence Number | Pad | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Pad(cont') | 198 +-+-+-+-+-+-+-+-+ 200 Figure 3: Args.Mob.Upmsg format for Echo Request, Echo Reply and 201 Error Indication 203 QFI bit, R bit, U bit and 16-bit Sequence Number is encoded in 204 Args.Mobs.Upmsg. The remaining bits followed by Sequence Number must 205 be padded in 0. 207 In case of End Marker, TEID shall be used as PDU Session ID same as 208 draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane]. 209 Hence, for End Marker, Args.Mobs.Session should be used to carry TEID 210 as PDU Session ID. 212 5.3. Encoding of Tags Field 214 The Segment Routing Header is defined in IPv6 Segment Routing Header 215 (SRH) [RFC8754]. This draft defines 16 bits Tag field but does not 216 define the format or use of this Tag field in the Segment Routing 217 Header. 219 The User Plane message type encoding is defined in TS 29.281 220 [TS29281]. Based on this definition, the User Plane message type 221 must be encoded into the Tag field in the Segment Routing Header in 222 order to indicate the type of the user plane messages for at least 223 Echo Request, Echo Reply, Error Indication or End Marker. 225 Only UPF must process the Tag field where the user plane message is 226 encoded. In addition, when the user plane message is encoded in the 227 Tag field, the UPF should not encode any segments in the Segment 228 Routing Header whose function modifies the Tag field value. Any 229 other transport router implementing SRv6 must ignore the Tag field 230 upon processing the Segment Routing Header. 232 The user plane messages must be encoded into the Tag filed as shown 233 below. 235 0 1 236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 237 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 238 | Reserved |B3|B2|B1|B0| 239 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 241 Figure 4: Tag Field Encoding 243 Bit 0 [B0]: End Marker 245 Bit 1 [B1]: Error Indication 247 Bit 2 [B2]: Echo Request 249 Bit 3 [B3]: Echo Reply 251 End Marker, Echo Request and Echo reply messages do not require any 252 additional information elements. However, Error Indication message 253 requires the additional information elements like Tunnel Endpoint 254 Identifier Data IE, GSN Address, etc. These additional information 255 elements can be encoded into the SRH TLV that is defined in the next 256 section. 258 5.4. User Plane message Information Element Support 260 End Maker, Echo Request and Echo Reply messages do not require any 261 additional information elements. However, Error Indication message 262 requires additional 3GPP IEs (Information Element). These additional 263 information elements must be carried over SRv6 network as well. 264 However SRv6 SID has limited space only. Hence it cannot carry a lot 265 of information elements. 267 In order to carry more information elements, SRH TLV shall be 268 leveraged. SRH TLV is defined in IPv6 Segment Routing Header (SRH) 269 [RFC8754] in order to carry the meta-data for the segment processing. 270 In order to carry additional User Plane messages like 3GPP IEs, the 271 new type named as "User Plane Container" must be defined as the new 272 SRH TLV. The "User Plane Container" can carry additional User Plane 273 messages which includes multiple 3GPP IEs with 1 sub-TLV. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | User Plane message sub-TLV | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 // User Plane message sub-TLV // 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 User Plane Container TLV 285 Type: to be assigned by IANA 287 Length: Length of User Plane message sub-TLV 289 User Plane message sub-TLV: User Plane message sub-TLV defined 290 below 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | Value // 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 User Plane message sub-TLV 300 Type: Type of User Plane message sub-TLV 302 3GPP IE sub-TLV: 0x01 304 Length: Length of Value 306 Value: User Plane Message data 308 3GPP IE sub-TLV: multiple 3GG IEs 310 5.5. SID flavor consideration 312 This section considers SID flavor of where the SRH is popped out at 313 either the penultimate or the ultimate segment. 315 In order to carry User Plane message over SRv6 network, SRH must be 316 sustained over entire SRv6 network because User Plane message type 317 and required information elements are encoded into SRH. If the 318 penultimate segment is popping out SRH, i.e., PSP, User Plane message 319 can not be carried in entire SRv6 network. 321 In order to avoid this problem, USP is recommended in SRv6 Mobile 322 network. In this case, SRH is never popped out and User Plane 323 message can be sustained over entire SRv6 network. 325 However, if PSP needs to be enabled in SRv6 network, it is also a 326 possible solution to encap another SRH which carries User Plane 327 message along with the outer IPv6 or SRH. 329 6. Security Considerations 331 This document does not raise any additional security issues. This 332 document just define the mechanisms for mapping between user plane 333 message (GTP-U message) and SRH in SRv6. Basically, since this 334 document is using SRH defined in [RFC8754] to carry user plane 335 message, same security consideration stated in [RFC8754] shall be 336 applied. 338 7. IANA Consideration 340 The type value of SRH TLV for User Plane Container must be assigned 341 by IANA. 343 8. Acknowledgements 345 9. References 347 9.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 355 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 356 December 1998, . 358 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 359 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 360 2006, . 362 9.2. Informative References 364 [I-D.ietf-dmm-srv6-mobile-uplane] 365 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 366 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 367 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-18 368 (work in progress), February 2022. 370 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 371 and E. Lear, "Address Allocation for Private Internets", 372 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 373 . 375 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 376 (IPv6) Addressing Architecture", RFC 3513, 377 DOI 10.17487/RFC3513, April 2003, 378 . 380 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 381 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 382 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 383 . 385 [TS29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling 386 Protocol User Plane (GTPv1-U)", 2019, 387 . 390 Authors' Addresses 392 Tetsuya Murakami (editor) 393 Arrcus, Inc 394 2077 Gateway Place, Suite 400 395 San Jose 396 USA 398 Email: tetsuya@arrcus.com 400 Satoru Matsushima 401 SoftBank 402 1-9-1 Higashi-Shinbashi, Munato-ku 403 Tokyo 404 Japan 406 Email: satoru.matsushima@g.softbank.co.jp 407 Kentaro Ebisawa 408 Toyota Motor Corporation 409 Tokyo 410 Japan 412 Email: ebisawa@toyota-tokyo.tech 414 Pablo Camarillo 415 Cisco Systems, Inc. 416 Spain 418 Email: pcamaril@cisco.com 420 Ravi Shekhar 421 Cisco Systems, Inc. 422 USA 424 Email: ravishek@cisco.com