idnits 2.17.1 draft-murakami-dmm-user-plane-message-encoding-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 (November 4, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'B0' is mentioned on line 196, but not defined == Missing Reference: 'B1' is mentioned on line 198, but not defined == Missing Reference: 'B2' is mentioned on line 200, but not defined == Missing Reference: 'B3' is mentioned on line 202, but not defined == Unused Reference: 'RFC2460' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 319, 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-06 -- 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: May 7, 2020 SoftBank 6 K. Ebisawa 7 Toyota Motor Corporation 8 P. Garvia 9 R. Shekhar 10 Cisco Systems, Inc. 11 November 4, 2019 13 User Plane Message Encoding 14 draft-murakami-dmm-user-plane-message-encoding-00 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 May 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . 3 62 5.2. Encoding of Tags Field . . . . . . . . . . . . . . . . . 4 63 5.3. User Plane message Information Element Support . . . . . 5 64 5.4. Consideration of PSP case . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 3GPP defines User Plane messages. The User Plane messages support 76 in-band signaling for path and tunnel management. Currently, User 77 Plane messages are defined in TS 29.281 [TS29281]. 79 When applying SRv6 (Segment Routing IPv6) to the user plane of mobile 80 networks based on draft-ietf-dmm-srv6-mobile-uplane 81 [I-D.ietf-dmm-srv6-mobile-uplane], User Plane messages must be 82 carried over SRv6 network. This document defines which User Plane 83 message must be encoded to SRv6 and also defines how to encode the 84 User Plane messages into SRH. 86 In addition, SRH is mandatory at the ultimate segment upon carrying 87 the User Plane messages because User Plane message is encoded into 88 SRH. Hence, this document considers how to deal with the encoding of 89 User Plane messages into SRH when PSP is applied that SRH is popped 90 out at the penultimate segment. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Conventions and Terminology 100 SRv6: Segment Routing IPv6. 102 GTP-U: GPRS Tunneling Protocol User Plane. 104 UPF: User Plane Function. 106 SRH: IPv6 Segment Routing Header. 108 PSP: Penultimate Segment POP of the SRH. 110 USP: Ultimate Segment Pop of the SRH. 112 4. Motivation 114 3GPP User Plane needs to support the user plane messages associated 115 with a GTP-U tunnel defined in [TS29281]. In the case of SRv6 User 116 Plane [I-D.ietf-dmm-srv6-mobile-uplane], those messages are also 117 required when the user plane interworks with GTP-U. 119 Segment Routing Header (SRH) [I-D.ietf-6man-segment-routing-header] 120 is used for SRv6 User Plane. SRH is able to associate additional 121 information to the segments. The Tag field of SRH is capable to 122 indicate different properties within a SID. SRH TLV is capable to 123 provide meta-data to the endpoint node. 125 The above capability of SRH motivates us to map the user plane 126 messages into it because of the same encapsulation with the packets 127 of carrying client packets. It introduces no additional headers or 128 extension headers to be chained in the packet just for carrying the 129 user plane messages. 131 5. User Plane Message encoding into SRH 133 This section defines how to encode the User Plane messages into SRH 134 in order to carry the User Plane messages over SRv6 network. 136 5.1. GTP-U Header format 138 3GPP defines GTP-U Header format as shown below. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Ver |P|R|E|S|N| Message Type | Length | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Tunnel Endpoint Identifier | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Sequence Number | N-PDU Number | Next-Ext-Hdr | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 1: GTP-U Header format 152 User Plane message type is encoded in Message Type field of GTP-U 153 Header. The following User Plane messages must be carried over SRv6 154 network at least. The value of each User Plane message type is 155 defined as shown below. 157 Echo Request: 1 159 Echo Reply: 2 161 Error Indication: 26 163 End Marker: 254 165 5.2. Encoding of Tags Field 167 The Segment Routing Header is defined in draft-ietf-6man-segment- 168 routing-header [I-D.ietf-6man-segment-routing-header]. This draft 169 defines 16 bits Tag field but does not define the format or use of 170 this Tag field in the Segment Routing Header. 172 The User Plane message type encoding is defined in TS 29.281 173 [TS29281]. Based on this definition, the User Plane message type 174 must be encoded into the Tag field in the Segment Routing Header in 175 order to indicate the type of the user plane messages for at least 176 Echo Request, Echo Reply, Error Indication or End Marker. 178 Only UPF must process the Tag field where the user plane message is 179 encoded. In addition, when the user plane message is encoded in the 180 Tag field, the UPF should not encode any segments in the Segment 181 Routing Header whose function modifies the Tag field value. Any 182 other transport router implementing SRv6 must ignore the Tag field 183 upon processing the Segment Routing Header. 185 The user plane messages must be encoded into the Tag filed as shown 186 below. 188 0 1 189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 190 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 191 | Reserved |B3|B2|B1|B0| 192 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 194 Figure 2: Tag Field Encoding 196 Bit 0 [B0]: End Marker 198 Bit 1 [B1]: Error Indication 200 Bit 2 [B2]: Echo Request 202 Bit 3 [B3]: Echo Reply 204 End Marker, Echo Request and Echo reply messages do not require any 205 additional information elements. However, Error Indication message 206 requires the additional information elements like Tunnel Endpoint 207 Identifier Data IE, GSN Address, etc. These additional information 208 elements can be encoded into the SRH TLV that is defined in the next 209 section. 211 5.3. User Plane message Information Element Support 213 End Maker, Echo Request and Echo Reply messages do not require any 214 additional information elements. However, Error Indication message 215 requires additional 3GPP IEs (Information Element). These additional 216 information elements must be carried over SRv6 network as well. 217 However SRv6 SID has limited space only. Hence it cannot carry a lot 218 of information elements. 220 In order to carry more information elements, SRH TLV shall be 221 leveraged. SRH TLV is defined in draft-ietf-6man-segment-routing- 222 header [I-D.ietf-6man-segment-routing-header] in order to carry the 223 meta-data for the segment processing. In order to carry 3GPP IEs, 224 the new type named as "5GS Container" must be defined as the new SRH 225 TLV. The "5GS Container" can carry multiple 3GPP IEs with 1 TLV. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Length | 3GPP IE TLVs | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 // 3GPP IE TLVs // 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 5GS Container TLV 237 Type: to be assigned by IANA 239 Length: Length of 3GPP IE TLVs 241 3GPP IE TLVs: Multiple 3GPP IE TLV defined below 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Value // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 3GPP IE TLV 251 Type: 3GPP IE Type defined by 3GPP 253 Length: Length of Value 255 Value: 3GPP IE value 257 5.4. Consideration of PSP case 259 This section considers PSP case where the SRH is popped out at the 260 penultimate segment. 262 In order to carry User Plane message over SRv6 network, SRH must be 263 sustained over entire SRv6 network because User Plane message type 264 and required information elements are encoded into SRH. If the 265 penultimate segment is popping out SRH, i.e., PSP, User Plane message 266 can not be carried in entire SRv6 network. 268 In order to avoid this problem, USP must be used in SRv6 network. In 269 this case, SRH is never popped out and User Plane message can be 270 sustained over entire SRv6 network. However, if PSP needs to be 271 enabled in SRv6 network, it is also a possible solution to encap 272 another SRH which carries User Plane message along with the outer 273 IPv6 or SRH. 275 6. Security Considerations 277 7. IANA Consideration 279 The type value of SRH TLV for 5GS Container must be assigned by IANA. 281 8. Acknowledgements 283 9. References 285 9.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 293 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 294 December 1998, . 296 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 297 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 298 2006, . 300 9.2. Informative References 302 [I-D.ietf-6man-segment-routing-header] 303 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 304 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 305 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 306 progress), October 2019. 308 [I-D.ietf-dmm-srv6-mobile-uplane] 309 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 310 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 311 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-06 312 (work in progress), September 2019. 314 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 315 and E. Lear, "Address Allocation for Private Internets", 316 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 317 . 319 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 320 (IPv6) Addressing Architecture", RFC 3513, 321 DOI 10.17487/RFC3513, April 2003, 322 . 324 [TS29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling 325 Protocol User Plane (GTPv1-U)", 2019, 326 . 329 Authors' Addresses 331 Tetsuya Murakami (editor) 332 Arrcus, Inc 333 2077 Gateway Place, Suite 400 334 San Jose 335 USA 337 Email: tetsuya@arrcus.com 339 Satoru Matsushima 340 SoftBank 341 1-9-1 Higashi-Shinbashi, Munato-ku 342 Tokyo 343 Japan 345 Email: satoru.matsushima@g.softbank.co.jp 347 Kentaro Ebisawa 348 Toyota Motor Corporation 349 Tokyo 350 Japan 352 Email: ebisawa@toyota-tokyo.tech 354 Pablo Camarillo Garvia 355 Cisco Systems, Inc. 356 Spain 358 Email: pcamaril@cisco.com 360 Ravi Shekhar 361 Cisco Systems, Inc. 362 USA 364 Email: ravishek@cisco.com