idnits 2.17.1 draft-murakami-dmm-user-plane-message-encoding-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 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, 2020) is 1505 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'B0' is mentioned on line 242, but not defined == Missing Reference: 'B1' is mentioned on line 244, but not defined == Missing Reference: 'B2' is mentioned on line 246, but not defined == Missing Reference: 'B3' is mentioned on line 248, but not defined == Unused Reference: 'RFC2460' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 376, 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-07 -- 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, 2020 SoftBank 6 K. Ebisawa 7 Toyota Motor Corporation 8 P. Garvia 9 R. Shekhar 10 Cisco Systems, Inc. 11 March 5, 2020 13 User Plane Message Encoding 14 draft-murakami-dmm-user-plane-message-encoding-01 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, 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. 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 . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 3GPP defines User Plane messages. The User Plane messages support 77 in-band signaling for path and tunnel management. Currently, User 78 Plane messages are defined in TS 29.281 [TS29281]. 80 When applying SRv6 (Segment Routing IPv6) to the user plane of mobile 81 networks based on draft-ietf-dmm-srv6-mobile-uplane 82 [I-D.ietf-dmm-srv6-mobile-uplane], User Plane messages must be 83 carried over SRv6 network. This document defines which User Plane 84 message must be encoded to SRv6 and also defines how to encode the 85 User Plane messages into SRH. 87 In addition, SRH is mandatory at the ultimate segment upon carrying 88 the User Plane messages because User Plane message is encoded into 89 SRH. Hence, this document considers how to deal with the encoding of 90 User Plane messages into SRH when PSP is applied that SRH is popped 91 out at the penultimate segment. 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Conventions and Terminology 101 SRv6: Segment Routing IPv6. 103 GTP-U: GPRS Tunneling Protocol User Plane. 105 UPF: User Plane Function. 107 SRH: IPv6 Segment Routing Header. 109 PSP: Penultimate Segment POP of the SRH. 111 USP: Ultimate Segment Pop of the SRH. 113 4. Motivation 115 3GPP User Plane needs to support the user plane messages associated 116 with a GTP-U tunnel defined in [TS29281]. In the case of SRv6 User 117 Plane [I-D.ietf-dmm-srv6-mobile-uplane], those messages are also 118 required when the user plane interworks with GTP-U. 120 Segment Routing Header (SRH) [I-D.ietf-6man-segment-routing-header] 121 is used for SRv6 User Plane. SRH is able to associate additional 122 information to the segments. The Tag field of SRH is capable to 123 indicate different properties within a SID. SRH TLV is capable to 124 provide meta-data to the endpoint node. 126 The above capability of SRH motivates us to map the user plane 127 messages into it because of the same encapsulation with the packets 128 of carrying client packets. It introduces no additional headers or 129 extension headers to be chained in the packet just for carrying the 130 user plane messages. 132 5. User Plane Message encoding into SRH 134 This section defines how to encode the User Plane messages into SRH 135 in order to carry the User Plane messages over SRv6 network. 137 5.1. GTP-U Header format 139 3GPP defines GTP-U Header format as shown below. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Ver |P|R|E|S|N| Message Type | Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Tunnel Endpoint Identifier | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Sequence Number | N-PDU Number | Next-Ext-Hdr | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: GTP-U Header format 153 User Plane message type is encoded in Message Type field of GTP-U 154 Header. The following User Plane messages must be carried over SRv6 155 network at least. The value of each User Plane message type is 156 defined as shown below. 158 Echo Request: 1 160 Echo Reply: 2 162 Error Indication: 26 164 End Marker: 254 166 5.2. Args.Mob.Upmsg 168 draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane] 169 defines the format of Args.Mob.Session argument which is used in SRv6 170 SID Mobility Functions in order to carry the PDU Session identifier. 171 The format of Args.Mobs.Session is defined as shown below. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | QFI |R|U| PDU Session ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |PDU Sess(cont')| 179 +-+-+-+-+-+-+-+-+ 181 Figure 2: Args.Mob.Session format 183 In case of Echo Request, Echo Reply and Error Indication, Sequence 184 Number in GTP-U header needs to be carried. Similar to draft-ietf- 185 dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane], the new 186 arguments to carry Sequqnce number for Echo Request, Echo Reply and 187 Error Indication message needs to be defined. For this, the 188 following Args.Mobs.Upmsg should be defined newly to carry Sequence 189 number. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | QFI |R|U| Sequence Number | Pad | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Pad(cont') | 197 +-+-+-+-+-+-+-+-+ 199 Figure 3: Args.Mob.Upmsg format for Echo Request, Echo Reply and 200 Error Indication 202 QFI bit, R bit, U bit and 16-bit Sequence Number is encoded in 203 Args.Mobs.Upmsg. The remaining bits followed by Sequence Number must 204 be padded in 0. 206 In case of End Marker, TEID shall be used as PDU Session ID same as 207 draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane]. 208 Hence, for End Marker, Args.Mobs.Session should be used to carry TEID 209 as PDU Session ID. 211 5.3. Encoding of Tags Field 213 The Segment Routing Header is defined in draft-ietf-6man-segment- 214 routing-header [I-D.ietf-6man-segment-routing-header]. This draft 215 defines 16 bits Tag field but does not define the format or use of 216 this Tag field in the Segment Routing Header. 218 The User Plane message type encoding is defined in TS 29.281 219 [TS29281]. Based on this definition, the User Plane message type 220 must be encoded into the Tag field in the Segment Routing Header in 221 order to indicate the type of the user plane messages for at least 222 Echo Request, Echo Reply, Error Indication or End Marker. 224 Only UPF must process the Tag field where the user plane message is 225 encoded. In addition, when the user plane message is encoded in the 226 Tag field, the UPF should not encode any segments in the Segment 227 Routing Header whose function modifies the Tag field value. Any 228 other transport router implementing SRv6 must ignore the Tag field 229 upon processing the Segment Routing Header. 231 The user plane messages must be encoded into the Tag filed as shown 232 below. 234 0 1 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 236 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 237 | Reserved |B3|B2|B1|B0| 238 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 240 Figure 4: Tag Field Encoding 242 Bit 0 [B0]: End Marker 244 Bit 1 [B1]: Error Indication 246 Bit 2 [B2]: Echo Request 248 Bit 3 [B3]: Echo Reply 250 End Marker, Echo Request and Echo reply messages do not require any 251 additional information elements. However, Error Indication message 252 requires the additional information elements like Tunnel Endpoint 253 Identifier Data IE, GSN Address, etc. These additional information 254 elements can be encoded into the SRH TLV that is defined in the next 255 section. 257 5.4. User Plane message Information Element Support 259 End Maker, Echo Request and Echo Reply messages do not require any 260 additional information elements. However, Error Indication message 261 requires additional 3GPP IEs (Information Element). These additional 262 information elements must be carried over SRv6 network as well. 263 However SRv6 SID has limited space only. Hence it cannot carry a lot 264 of information elements. 266 In order to carry more information elements, SRH TLV shall be 267 leveraged. SRH TLV is defined in draft-ietf-6man-segment-routing- 268 header [I-D.ietf-6man-segment-routing-header] in order to carry the 269 meta-data for the segment processing. In order to carry additional 270 User Plane messages like 3GPP IEs, the new type named as "User Plane 271 Container" must be defined as the new SRH TLV. The "User Plane 272 Container" can carry additional User Plane messages which includes 273 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 TBD 333 7. IANA Consideration 335 The type value of SRH TLV for User Plane Container must be assigned 336 by IANA. 338 8. Acknowledgements 340 9. References 342 9.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, 347 . 349 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 350 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 351 December 1998, . 353 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 354 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 355 2006, . 357 9.2. Informative References 359 [I-D.ietf-6man-segment-routing-header] 360 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 361 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 362 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 363 progress), October 2019. 365 [I-D.ietf-dmm-srv6-mobile-uplane] 366 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 367 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 368 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-07 369 (work in progress), November 2019. 371 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 372 and E. Lear, "Address Allocation for Private Internets", 373 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 374 . 376 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 377 (IPv6) Addressing Architecture", RFC 3513, 378 DOI 10.17487/RFC3513, April 2003, 379 . 381 [TS29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling 382 Protocol User Plane (GTPv1-U)", 2019, 383 . 386 Authors' Addresses 388 Tetsuya Murakami (editor) 389 Arrcus, Inc 390 2077 Gateway Place, Suite 400 391 San Jose 392 USA 394 Email: tetsuya@arrcus.com 396 Satoru Matsushima 397 SoftBank 398 1-9-1 Higashi-Shinbashi, Munato-ku 399 Tokyo 400 Japan 402 Email: satoru.matsushima@g.softbank.co.jp 404 Kentaro Ebisawa 405 Toyota Motor Corporation 406 Tokyo 407 Japan 409 Email: ebisawa@toyota-tokyo.tech 410 Pablo Camarillo Garvia 411 Cisco Systems, Inc. 412 Spain 414 Email: pcamaril@cisco.com 416 Ravi Shekhar 417 Cisco Systems, Inc. 418 USA 420 Email: ravishek@cisco.com