idnits 2.17.1 draft-hmm-dmm-5g-uplane-analysis-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GTP-U-1' is mentioned on line 673, but not defined == Missing Reference: 'GTP-U-2' is mentioned on line 675, but not defined == Missing Reference: 'GTP-U-3' is mentioned on line 677, but not defined == Missing Reference: 'Uplink' is mentioned on line 293, but not defined == Missing Reference: 'Downlink' is mentioned on line 313, but not defined == Missing Reference: 'GTP-U-4' is mentioned on line 680, but not defined == Missing Reference: 'GTP-U-5' is mentioned on line 683, but not defined == Missing Reference: 'GTP-U-6' is mentioned on line 686, but not defined == Missing Reference: 'GTP-U-7' is mentioned on line 689, but not defined == Missing Reference: 'GTP-U-8' is mentioned on line 693, but not defined == Missing Reference: 'GTP-U-9' is mentioned on line 696, but not defined == Missing Reference: 'GTP-U-10' is mentioned on line 698, but not defined == Missing Reference: 'GTP-U-11' is mentioned on line 700, but not defined == Missing Reference: 'GTP-U-12' is mentioned on line 702, but not defined == Missing Reference: 'GTP-U-13' is mentioned on line 705, but not defined == Missing Reference: 'GTP-U-14' is mentioned on line 707, but not defined -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group S. Homma 3 Internet-Draft NTT 4 Intended status: Informational T. Miyasaka 5 Expires: April 25, 2019 KDDI Research 6 S. Matsushima 7 SoftBank 8 D. Voyer 9 Bell Canada 10 October 22, 2018 12 User Plane Protocol and Architectural Analysis on 3GPP 5G System 13 draft-hmm-dmm-5g-uplane-analysis-02 15 Abstract 17 This document analyzes the mobile user plane protocol and the 18 architecture specified in 3GPP 5G documents. The analysis work is to 19 clarify those specifications, extract protocol and architectural 20 requirements and derive evaluation aspects for user plane protocols 21 on IETF side. This work is corresponding to the User Plane Protocol 22 Study work on 3GPP side. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3 60 1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 3 61 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 62 3. GTP-U Specification and Observation . . . . . . . . . . . . . 5 63 3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 10 65 3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12 66 3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13 67 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14 68 3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16 69 4. 5GS Architectural Requirements for User Plane Protocols . . . 16 70 4.1. Overview of 5G System Architecture . . . . . . . . . . . 16 71 4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18 72 4.2. Architectural Requirements for User Plane Protocols . 19 73 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 22 74 5.1. Supporting PDU Session Type Variations . . . . . . . . . 23 75 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 23 76 5.3. Supporting Transport Variations . . . . . . . . . . . . . 24 77 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 24 78 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 25 79 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 26 80 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 26 81 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 7. Security Consideration . . . . . . . . . . . . . . . . . . . 27 83 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 84 9. Informative References . . . . . . . . . . . . . . . . . . . 28 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 87 1. Introduction 89 This document analyzes the mobile user plane protocol and the 90 architecture specified by 3GPP 5G documents. The background of the 91 work is that 3GPP requests through a liaison statement that the IETF 92 to provide any information for the User Plane Protocol Study work in 93 3GPP [CP-180116-3GPP]. Justification and the objectives of the study 94 can be found from [CP-173160-3GPP]. 96 We understand that the current user plane protocol, GTP-U 97 [TS.29.281-3GPP], has been well developed in 3GPP, and deployed very 98 widely as the successor of legacy network technologies, such as TDM 99 circuit, or ATM virtual circuit. That GTP-U success seems based on 100 IP overlay technique that is dramatically scaled compare to the 101 previous ones because it successfully isolates mobile session states 102 from the user plane transport network. 104 Even after that big success, it is definitely worth that 3GPP has 105 decided to revisit user plane which seems to response to IPv6 106 deployment growth and [IAB-Statement] that encourages the industry to 107 develop strategies for IPv6-only operation. It can be seen from the 108 justification section in [CP-173160-3GPP]. 110 The study description mentions that the study would be based on 111 Release 16 requirement while only Release 15 specifications has been 112 available now. However we believe that to provide adequate 113 information for 3GPP, we need to clearly understand what the current 114 user plane protocol is in Release 15, and architectural requirements 115 for the user plane. 117 As the liaison statement indicates 3GPP specifications related to 118 user plane, those documents should be a good start point to clarify 119 their specifications and to extract protocol and architectural 120 requirements from them. 122 1.1. Current Status of Mobile User Plane for 5G 124 3GPP RAN and CT4 decided to use GTP-U as the 5G user plane 125 encapsulation protocol over N3 and N9 that respectively described 126 in[TS.38.300-3GPP] and [TR.29.891-3GPP]. N3 is an interface between 127 RAN and UPF and N9 is an interface between different UPFs 128 [TS.23.501-3GPP]. 130 In [TR.29.891-3GPP], it captured user plane requirements and 131 concluded that GTP-U is adopted for the user plane protocol. It 132 seems that GTP-U was only option to be chose and it focused on how to 133 carry 5G specific QoS information between UPF and access networks. 134 That is described in section 5.2 and 11.2 of [TR.29.891-3GPP]. 135 Another aspects of user plane requirements couldn't be found. 137 1.2. Our Way of Analysis Work 139 First, we analyze [TS.29.281-3GPP] for clarifying it as the current 140 user plane protocol in the 5G system. [TR.29.891-3GPP] describes how 141 GTP-U is selected as the user plane protocol for 5G in 3GPP. 142 Clarified characteristics of the protocol are described in Section 3. 144 Then, to clarify what are required to the user plane protocol in 145 architecture level, we analyze [TS.23.501-3GPP] as the 5G system 146 architecture specification. [TS.23.502-3GPP] is the specification of 147 system procedures that helps us to understand how the system works in 148 the architecture. [TS.23.503-3GPP] is also helpful to find the role 149 of user plane in the architecture that influences user plane 150 protocol. Extracted architectural requirements are described in 151 Section 4. 153 Based on the results of above, we identify some aspects where there 154 might be gap between the current user plane protocol and the 155 architectural requirements on which [TR.29.891-3GPP] does not 156 discuss. That aspects are discussed Section 5. That's what we 157 intend to be as a part of the reply to 3GPP. CT4 WG in 3GPP can 158 utilize it as an input to evaluate the candidate protocols for user 159 plane to the 5G system including the current protocol. 161 [I-D.bogineni-dmm-optimized-mobile-user-plane] will provide the 162 candidate protocols on IETF side to the 3GPP study. 164 2. Terms and Abbreviations 166 This section describes terms of functions and interfaces relevant to 167 user plane protocol which we extract from the 3GPP specifications 168 since this document focuses on user plane. 170 In those specifications, there are so many unique terms and 171 abbreviations in the 3GPP context which IETF community seems not 172 familiar with. We will try to bring those terms with brief 173 explanations to make sure common understanding for them. 175 GTP: GPRS Tunneling Protocol 177 GTP-U: User Plane part of GTP 179 Noted that GTP version 1 (GTPv1-U) is the user-plane protocol 180 specification which is defined in [TS.29.281-3GPP]. Unless there 181 is no specific annotation, we refer GTP-U to GTPv1-U in this 182 document. 184 PDU: Protocol Data Unit of end-to-end user protocol packet. 186 Noted that the PDU in 3GPP includes IP header in case that PDU 187 session type is IPv4 or IPv6. In contrast, in IETF it is supposed 188 that PDU is the payload of IP packet so that it doesn't include 189 IP/TCP/UDP header in end-to-end. 191 T-PDU: Transport PDU. 193 G-PDU: GTP encapsulated user Plane Data Unit. 195 GTP-U has above two notions on PDU. T-PDU is a PDU that GTP-U 196 header encapsulates. G-PDU is a PDU that includes GTP-U header. 197 A G-PDU may include a T-PDU. G-PDU can be sent without T-PDU, but 198 just with extension headers or TLV elements. It can be used for 199 OAM related operations. 201 PDU session: Association between the UE and a Data Network that 202 provides a PDU connectivity service. 204 Data Network (DN): The network of operator services, Internet access 205 or 3rd party services. 207 User Plane (UP): Encapsulating user end-to-end PDU. 209 In fact, we can't find exact text that defines UP in the 210 architecture specification. However when we see the figure 211 8.3.1-1 in [TS.23.501-3GPP], we specify UP as the layer right 212 under PDU that directly encapsulates PDU. Underneath layers of UP 213 are UP transport, such as IP/UDP, L2 and L1. 215 However 3GPP is consistent to use the term user plane when they 216 indicate that layer. In IETF, we can see the terms data plane, or 217 forwarding plane as variations which often makes us tend to be 218 confused in terminology. 220 QFI: QoS Flow Identifier 222 UPF: User Plane Function 224 SMF: Session Management Function 226 SMF is a control plane function which provides session management 227 service that handling PDU sessions in the control plane. SMF 228 allocates tunnels corresponding to the PDU sessions and configure 229 the tunnel to the UPF. 231 RAN: Radio Access Network 233 Noted that UP protocol provides a RAN to connect UPF. But the UP 234 protocol is not appeared on the air in the RAN. 236 3. GTP-U Specification and Observation 238 In this section we analyze the GTP-U specification and summarize 239 clarified characteristic of GTP-U to see if GTP-U meets the 240 requirements of 5G architecture for user plane in later section. 242 3.1. GTP-U Tunnel 244 GTP-U is a tunneling protocol between given a pair of GTP-U tunnel 245 endpoint nodes and encapsulates T-PDU from/to UE on top of IP/UDP. A 246 Tunnel Endpoint Identifier (TEID) value allocated on each end point 247 indicates which tunnel a particular T-PDU belongs to. 249 The receiving endpoint individually allocate a TEID and the sender 250 tunnel endpoint node encapsulates the IP packet from/to UE with the 251 TEID which is present in GTP-U header on top of IPv4 or IPv6, and 252 UDP. That is described in section 4.2.1 of [TS.29.281-3GPP]. 254 [GTP-U-1]: GTP-U is an unidirectional Point-to-Point tunneling 255 protocol. 257 Figure 1 shows an example of GTP-U protocol stack for uplink (UL) and 258 downlink (DL) traffic flow. Two GTP-U tunnels are required to form 259 one bi-directional tunnel. 261 UL: From RAN to UPF1 (TEID=1), and from UPF1 to UPF2 (TEID=2) 263 DL: From UPF2 to UPF1 (TEID=3), and from UPF1 to RAN (TEID=4) 265 In 5GS, GTP-U tunnel is established at following interfaces to 266 provide PDU Session between UE and 5GC. 268 N3: Between RAN and UPF 270 N9: Between different UPFs 272 GTP-U allows one tunnel endpoint node to send out a G-PDU to be 273 received by multiple tunnel endpoints by utilizing IP multicast 274 capability of underlay IP networks. That is described in section 275 4.2.6 of [TS.29.281-3GPP]. It looks GTP-U has Point-to-Multipoint 276 (P2MP) tunneling capability. The P2MP tunneling is used for MBMS 277 (Multimedia Broadcast Multicast Service) through GTP-U tunnel. 279 [GTP-U-2]: GTP-U supports Point-to-Multipoint tunneling. 281 UDP is utilized for GTP-U encapsulation and UDP destination port is 282 2152 which is assigned by IANA. Allocation of UDP source port 283 depends on sender tunnel endpoint node and GTP-U supports dynamic 284 allocation of UDP source port for load balancing objective. The 285 specification of this dynamic allocation is described in section 286 4.4.2.0 of [TS.29.281-3GPP], however specific procedure, e.g., 287 5-tuple hashing, is not described in the document and depends on the 288 implementation of GTP-U tunnel endpoint node. 290 [GTP-U-3]: GTP-U supports load balancing by using dynamic UDP source 291 port allocation. 293 [Uplink] 294 .- .-+--------+ - - - - +--------+ - - - - +--------+ 295 | | |Payload | |Payload | |Payload | 296 | PDU < +--------+ +--------+ +--------+ 297 |(3GPP)| |Inner IP| |Inner IP| |Inner IP| 298 | '-+--------+ - - - - +--------+ - - - - +--------+ 299 | | GTP-U | | GTP-U | | L2 | 300 | |(TEID=1)| |(TEID=2)| +--------+ 301 GTP< +--------+ +--------+ | L1 | 302 Pkt | | UDP | | UDP | +--------+ 303 | +--------+ +--------+ 304 | |Outer IP| |Outer IP| 305 | +--------+ +--------+ 306 | | L2 | | L2 | 307 | +--------+ +--------+ 308 | | L1 | | L1 | 309 '- +--------+ - - - - +--------+ 311 ================ Traffic Direction =======================> 313 [Downlink] 314 .- .-+--------+ - - - - +--------+ - - - - +--------+ 315 | | |Payload | |Payload | |Payload | 316 | PDU < +--------+ +--------+ +--------+ 317 |(3GPP)| |Inner IP| |Inner IP| |Inner IP| 318 | '-+--------+ - - - - +--------+ - - - - +--------+ 319 | | GTP-U | | GTP-U | | L2 | 320 | |(TEID=4)| |(TEID=3)| +--------+ 321 GTP< +--------+ +--------+ | L1 | 322 Pkt | | UDP | | UDP | +--------+ 323 | +--------+ +--------+ 324 | |Outer IP| |Outer IP| 325 | +--------+ +--------+ 326 | | L2 | | L2 | 327 | +--------+ +--------+ 328 | | L1 | | L1 | 329 '- +--------+ - - - - +--------+ 331 <=============== Traffic Direction ======================== 333 +-----+ N3 +------+ N9 +------+ N6 334 -----+ RAN +-----------+ UPF1 +------------+ UPF2 +---------- 335 +-----+ +------+ +------+ 337 Figure 1: Protocol Stack by GTPv1-U for Uplink and Downlink Traffic 338 Flow 340 IPv6 flow label [RFC6437] is also candidate method for load balancing 341 especially for IP-in-IPv6 tunnel [RFC6438] like GTP-U. However, how 342 to use IPv6 flow label of GTP-U is not described in [TS.29.281-3GPP]. 343 Though this method is limited to a case of IPv6 encapsulated GTP-U 344 tunnel, it is worth to study usage of IPv6 flow label in 3GPP. 346 [GTP-U-4]: GTP-U does not support IPv6 flow label for load balancing 347 in case of IPv6 transport. 349 GTP-U supports both IPv4 and IPv6 as underlying transport layer 350 protocol. As for IPv6, GTP-U specification refers [RFC2460], which 351 is described in section 4.2.3 of [TS.29.281-3GPP]. As [RFC2460] does 352 not allow the tunnel protocols on top of UDP to set the checksum 353 value to zero, the GTP-U specification inherits it while the IPv4 354 transport for GTP-U case allows UDP zero checksum. It is noted that 355 the IPv6 specification in IETF has been updated to [RFC8200] which 356 allows UDP zero checksum for the tunnel. [RFC6935] describes 357 benefits of zero checksum for tunnel protocol over UDP. If GTP-U 358 support UFP zero checksum in future version, possible 359 interoperability issue between previous generations which does not 360 support zero checksum may raise. 362 [GTP-U-5]: UDP zero checksum is not available in case of IPv6 363 transport. 365 "Unnecessary fragmentation should be avoided" is recommended and to 366 avoid the fragmentation operator should configure MTU size at UE 367 [TS.29.281-3GPP]. However, there's no reference and specification of 368 Path MTU Discovery for IPv6 transport. If encapsulated IPv6 packet 369 is too big on a network link between tunnel endpoint nodes, UE may 370 not receive ICMPv6 Packet Too Big message and causes Path MTU 371 Discovery black hole. 373 [GTP-U-6]: GTP-U does not support to response ICMP PTB for Path MTU 374 Discovery. 376 Section 9.3 of [TS.23.060-3GPP] specifies advertisement of inner IPv6 377 link MTU size for UE by IPv6 RA message [RFC4861]. However, this 378 document doesn't specify a procedure to measure MTU size in mobile 379 network system and mobile network operator need to calculate MTU size 380 for UE like Annex C of [TS.23.060-3GPP]. If link MTU of a router in 381 a transport network is accidentally modified, UE cannot detect the 382 event and send packet with initial MTU size, which may cause service 383 disruption due to MTU exceed in the router link. 385 3.2. GTP-U Header Format 387 Figure 2 shows general and mandatory GTP-U header and Figure 3 shows 388 extension GTP-U header. 390 [GTP-U-7]: GTP-U supports sequence number option in the header, but 391 it is not recommended to be used by almost GTP-U 392 entities. 394 GTP-U header has Sequence Number field to reorder incoming packets 395 based on the sequence number. If Sequence Number Flag is set to '1' 396 it indicates that Sequence Number Filed exists in GTP-U header and 397 examined at receiving tunnel endpoint node to reorder incoming 398 packets. However, the sequence number flag is set to '1' only for 399 RAT HO procedure and sequence number flag should be set to '0' in 400 normal case. Therefore, in normal case receiver tunnel endpoint node 401 doesn't examine sequence number and can't reorder GTP-U packets based 402 on the sequence number. This specification is described in section 403 5.1 of [TS.29.281-3GPP]. In 3GPP, sequential delivery is required 404 only during handover procedure and is used by only RAN entities. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Ver |P|R|E|S|N| Message Type | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Tunnel Endpoint Identifier | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Sequence Number | N-PDU Number | Next-Ext-Hdr | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 2: GTP-U Header 418 o Ver: Version field (Set to '1') 420 o P: Protocol Type (Set to '1') 422 o R: Reserved bit (Set to '0') 424 o E: Extension Header Flag (Set to '1' if extension header exists) 426 o S: Sequence Number Flag (Set to '1' if sequence number exists) 428 o N: N-PDU Number Flag (Set to '1' if N-PDU number exists) 430 o Message Type: Indicates the type of GTP-U message 432 o Length: Indicates the length in octets of the payload 433 o Tunnel Endpoint Identifier (TEID) 435 o Sequence Number: Indicates increasing sequence number for T-PDUs 436 is transmitted via GTP-U tunnels 438 o N-PDU Number: It is used only for inter SGSN, 2G-3G handover case, 439 etc. 441 o Next-Ext-Hdr: Indicates following extension header type 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Ext-Hdr Length| | 447 +-+-+-+-+-+-+-+-+ | 448 | Extension Header Content | 449 . . 450 . +-+-+-+-+-+-+-+-+ 451 | | Next-Ext-Hdr | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 3: Extension GTP-U Header 456 o Ext-Hdr Length: Represents the length of the Extension header in 457 units of 4 octets 459 o Extension Header Content: Contains 3GPP related information 461 o Next-Ext-Hdr: Indicates following extension header type 463 The extension GTP-U header is a variable-length and extendable header 464 and contains 3GPP specific information. Following list summarizes 465 every extension header which is used for user plane protocol. These 466 extension headers are defined in [TS.29.281-3GPP]. In this list 467 Next-Ext-Hdr is represented in binary. 469 o No more extension headers (Next-Ext-Hdr = 00000000) 471 o Service Class Indicator (Next-Ext-Hdr = 00100000) 473 o UDP Port (Next-Ext-Hdr = 01000000) 475 o RAN Container (Next-Ext-Hdr = 10000001) 477 o Long PDCP PDU Number (Next-Ext-Hdr = 10000010) 479 o Xw RAN Container (Next-Ext-Hdr = 10000011) 480 o NR RAN Container (Next-Ext-Hdr = 10000100) 482 o PDU Session Container (Next-Ext-Hdr = 10000101) 484 o PDCP PDU Number (Next-Ext-Hdr = 11000000) 486 [GTP-U-8]: GTP-U supports carrying QoS Identifiers transparently for 487 Access Networks in an extension header. 489 GTP-U is designed to carry 3GPP specific information with extension 490 headers. 3GPP creates PDU Session Container extension header for 491 NGRAN of 5G to carry QFI. It is described in section 5.2.2.7 of 492 [TS.29.281-3GPP]. 494 [GTP-U-9]: GTP-U supports DSCP marking based on the QFI. 496 DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel 497 endpoint node based on the QFI. This specification is described in 498 section 4.4.1 of [TS.29.281-3GPP]. 500 [GTP-U-10]: GTP-U does not specify extension header order. 502 In general, multiple GTP-U extension headers are able to contained in 503 one GTP-U packet and the order of those extension headers is not 504 specified by [TS.29.281-3GPP]. Thereby the receiving endpoint can't 505 predict exact position where the target extension headers are. This 506 could impact on header lookup performance on the node. 508 As for PDU Session Container extension header, there is a note in 509 [TS.29.281-3GPP] as "For a G-PDU with several Extension Headers, the 510 PDU Session Container should be the first Extension Header". This 511 note was added at the version 15.3.0 of [TS.29.281-3GPP] which is 512 published on June 2018 in order to accelerate the processing of GTP-U 513 packet at UPF and RAN. It is only one rule regarding the extension 514 header order. 516 [GTP-U-11]: GTP-U does not support to indicate next protocol type. 518 When Next-Ext-Hdr is set to 0x00 it indicates that no more extension 519 headers follow. As GTP is designed to indicate protocol types for 520 T-PDU by control-plane signaling, GTP-U doesn't have Next-Protocol- 521 Header field to indicate the T-PDU type in the header. 523 3.3. Control Plane Protocol for GTP-U 525 Control plane protocol for GTP-U signals TEID between tunnel endpoint 526 nodes. GTPv2-C [TS.29.274-3GPP] is the original control plane 527 protocol tied with GTP-U in previous generation architectures before 528 CUPS (Control and User Plane Separation). 530 3GPP decided to use extended PFCP (Packet Forwarding Control 531 Protocol) [TS.29.244-3GPP] for N4 interface [TR.29.891-3GPP] to 532 signal tunnel states from SMF to UPF. 534 3.4. GTP-U message 536 GTP-U supports in-band messaging to signal OAM. Currently GTP-U 537 supports following messages [TS.29.281-3GPP]. 539 o Echo Request 541 o Echo Response 543 o Supported Extension Headers Notification 545 o Error Indication 547 o End Marker 549 [GTP-U-12]: GTP-U supports active OAM as a path management message 550 "Echo Request/Response". 552 A GTP-U tunnel endpoint node sends a Echo Request message to another 553 nodes for keep-alive and received node sends a Echo Response message 554 to sender node as acknowledgment. Echo Request message and Echo 555 Response message are described in section 7.2.1 and section 7.2.2 of 556 [TS.29.281-3GPP] respectively. [TR.29.891-3GPP] recommends not to 557 send Echo Request message more often than 60s on each path. 559 Supported Extension Headers Notification message indicates a list of 560 supported that tunnel endpoint node can support. This message is 561 sent only in case a tunnel endpoint node receives GTP-U packet with 562 unsupported extension header. 564 [GTP-U-13]: GTP-U supports tunnel management messages "Error 565 Indication". 567 GTP-U has Error Indication message to notify that the receiving 568 endpoint discard packets of which no session exist to the sending 569 endpoint. Error Indication message is described in section 7.3.1 of 570 [TS.29.281-3GPP]. 572 [GTP-U-14]: GTP-U supports tunnel management messages "End Marker". 574 GTP-U has End Marker message to indicate the end of the payload 575 stream that needs to be sent on a GTP-U tunnel. End Marker message 576 is described in section 7.3.2 of [TS.29.281-3GPP]. 578 3.5. Packet Format 580 Figure 4 shows a packet format example of GTP-U over IPv6 that 581 carries an extension header for QFI and an IPv6 PDU. All values in 582 the example are illustration purpose only. The encoding of PDU 583 Session Container for QFI refers to [TS.38.415-3GPP]. 585 Outer IPv6 Header's DSCP value(EF) in Figure 4 is marked at sender 586 tunnel endpoint node based on QFI value which is contained in GTP-U 587 Extension Header (PDU Session Container). 589 0 1 2 3 590 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 591 Outer IPv6 Header 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |Version| DSCP=EF | Flow Label | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 598 + + 599 | | 600 + Source IPv6 Address + 601 | 2001:db8:1:1::1 | 602 + + 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 + + 607 | | 608 + Destination IPv6 Address + 609 | 2001:db8:1:2::1 | 610 + + 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Outer UDP Header 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Source Port = xxxx | Dest Port = 2152 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | UDP Length | UDP Checksum (Non-zero) | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 GTP-U header 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | 0x1 |1|0|1|0|0| 0xff | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | TEID = 1654 | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Sequence Number = 0 |N-PDU Number=0 |NextExtHdr=0x85| 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 GTP-U Extension Header (PDU Session Container) 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | ExtHdrLen=2 |Type=0 | Spare |0|0| QFI | PPI | Spare | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Padding |NextExtHdr=0x0 | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Inner IPv6 Header 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |Version| DSCP=0 | Flow Label | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Payload Length | NexttHdr | Hop Limit | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 + + 645 | | 646 + Source IPv6 Address + 647 | 2001:db8:2:1::1 | 648 + + 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | 652 + + 653 | | 654 + Destination IPv6 Address + 655 | 2001:db8:3:1::1 | 656 + + 657 | | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Payload 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | 663 | | 664 . TCP/UDP/etc., Data . 665 . . 666 | | 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 Figure 4: GTP-U Protocol Stack Example 671 3.6. Observations Summary 673 [GTP-U-1]: An unidirectional Point-to-Point tunneling protocol. 675 [GTP-U-2]: Supports Point-to-Multipoint tunneling. 677 [GTP-U-3]: Supports load balancing by using dynamic UDP port 678 allocation. 680 [GTP-U-4]: Does not support IPv6 flow label for load balancing in 681 case of IPv6 transport. 683 [GTP-U-5]: UDP zero checksum is not available in case of IPv6 684 transport. 686 [GTP-U-6]: Does not support to response ICMP PTB for Path MTU 687 Discovery. 689 [GTP-U-7]: Supports sequence number option and sequence number flag 690 in the header, but it is not recommended to be used by 691 almost GTP-U entities. 693 [GTP-U-8]: Supports carrying QoS Identifiers transparently for 694 Access Networks in extension headers. 696 [GTP-U-9]: Supports DSCP marking based on the QFI. 698 [GTP-U-10]: Does not specify the rule for the extension header order. 700 [GTP-U-11]: Does not support an indication of next-header type. 702 [GTP-U-12]: Supports active OAM as a path management message "Echo 703 Request/Response". 705 [GTP-U-13]: Supports tunnel management messages "Error Indication". 707 [GTP-U-14]: Supports tunnel management messages "End Marker". 709 4. 5GS Architectural Requirements for User Plane Protocols 711 4.1. Overview of 5G System Architecture 713 The 5G system is designed for applying to diverse devices and 714 services due to factors such as the diffusion of IoT devices, and the 715 UP protocol is required to have capabilities for satisfying their 716 requirements. 718 As a principle of the 5G system, User Plane (UP) functions are 719 separated from the Control Plane (CP) functions for allowing 720 independent scalability, evolution and flexible deployments. 722 Network slicing is also one of the fundamental concepts of the 5G 723 system, and it provides logical network separation. In terms of user 724 plane, multiple network slices can be comprised of UPFs on top of 725 same physical network resources. Allocated resources and structures 726 may be differentiated among the slices by which the required features 727 or capabilities. 729 The architecture overview is shown in Figure 5. The details of 730 functions are described in [TS.23.501-3GPP]. User plane path and 731 applied functions for a tunnel will be manipulated based on 732 application requirements that the PDU session corresponding to the 733 tunnel. These tunnels are available to be handled by other 734 authorized functions through the control plane. 736 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 737 |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 738 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 739 Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf 740 ---+--------+--+-----+--+--------+--+-----+--------+- 741 Nausf| Namf| Nsmf| 742 +--+--+ +--+--+ +--+-------+ 743 |AUSR | | AMF | | SMF | 744 +-----+ ++-+--+ +--+-----+-+ 745 / | | \ 746 Control Plane N1/ |N2 |N4 \N4 747 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 748 User Plane / | | \ 749 +--++ +--+--+ N3 +--+--+ N9 +-+---+ N6 +-----+ 750 |UE +--+(R)AN+-----+ UPF +-----+ UPF +----+ DN | 751 +---+ +-----+ +--+--+ +-----+ +-----+ 752 |N6 753 +--+--+ 754 | DN | 755 +-----+ 757 Figure 5: 5GS Architecture and Service-based Interfaces 759 This document mainly focuses on requirements for N9 interface as 760 relevant to UP protocol of 5G system. 762 4.1.1. UPF Functionalities 764 UPF has a role to handle UP traffic, and provides functionalities to 765 look up user data traffic and enforce the appropriate policies to it. 767 The followings are defined as UPF functionalities for traffic 768 handling: 770 o User Plane part of policy rule enforcement, e.g. Gating, 771 Redirection, Traffic steering) 773 o QoS handling for user plane, e.g. UL/DL rate enforcement, 774 Reflective QoS marking in DL 776 o Transport level packet marking in the uplink and downlink 778 Other functionalities are described in the section 6.2.3 of 779 [TS.23.501-3GPP] 781 UPF shall detect user plane traffic flow depending on information 782 indicated by SMF. User data traffic is detected with combination of 783 the following information: 785 o For IPv4 or IPv6 PDU Session type 787 * PDU Session 789 * QFI 791 * Application Identifier: The Application ID is an index to a set 792 of application detection rules configured in UPF 794 o For Ethernet PDU Session type 796 * PDU Session 798 * QFI 800 * Ethernet Packet Filter Set: 802 + Source/destination MAC address 804 + Ethertype as defined in IEEE 802.3 806 + Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) VID 807 fields as defined in IEEE 802.1Q 809 + Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/ 810 DEI fields as defined in IEEE 802.1Q 812 + IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 813 payload 815 + Packet filter direction 817 Such information for traffic detection (Traffic Detection 818 Information) is described in the section 5.8.2.4 of [TS.23.501-3GPP]. 820 4.2. Architectural Requirements for User Plane Protocols 822 This section lists the requirements for the UP protocol on the 5G 823 system. The requirements are picked up from [TS.23.501-3GPP]. In 824 addition, some of service requirements described in [TS.22.261-3GPP] 825 are referred to clarify the originations of architectural 826 requirements. 828 According to [TS.23.501-3GPP], the specifications potentially have 829 assumptions that the UP protocol is a tunnel representing a single 830 TEID between a pair of UPFs and it is corresponding to a single PDU 831 session. In short, the UP protocol is a tunnel and it is assumed to 832 be managed under per PDU session handling. Also, it should be a 833 stateful tunnel in the UPFs along with the PDU session. 835 The requirements for UP protocols are described below: 837 ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU 839 The 5G system defines four types of PDU session as IPv4, IPv6, 840 Ethernet, and Unstructured. Therefore, UP protocol must support to 841 convey all of these PDU session types. This is described in 842 [TS.23.501-3GPP]. 844 Note: In TS 23.501 v15.2.0, IPv4v6 is added as a PDU session type. 846 ARCH-Req-2: Supporting IP connectivity for N3, N6, and N9 interfaces 848 The 5G system requires IP connectivity for N3, N6, and N9 interfaces. 849 The IP connectivity is assumed that it comprises of IP routing and 850 L1/L2 transport networks which are outside of 3GPP specifications. 852 It is desirable that the IP connectivity built on IPv6 networks when 853 it comes to address space for end-to-end user plane coverage. But it 854 is expected to take certain time. During the IPv6 networks are not 855 deployed for all the coverage, UP protocol should support RANs and 856 DNs running on IPv4 transport connect to UPF running on IPv6 857 transport. 859 Furthermore, on N6 interface, point-to-point tunneling based on UDP/ 860 IPv6 may be used to deliver unstructured PDU type data. Then, the 861 content information of the PDU may be mapped into UDP port number, 862 and the UDP port numbers is pre-configured in the UPF and DN. This 863 is described in the section 9.2 of [TS.29.561-3GPP]. 865 ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a 866 single PDU session 868 The 5G system allows to deploy multiple UPFs as anchors for a single 869 PDU session, and supports multihoming of a single PDU session for 870 such anchor UPFs. 872 Multihoming is provided with Branching Point (BP) or Uplink 873 Classifier (UL CL) which are functionalities of UPF. BP provides 874 forwarding of UL traffic towards the different PDU Session Anchors 875 based on the source IPv6 prefixes and merge of DL traffic to the UE. 876 UL CL provides destination based multihoming for load balancing. 878 On UL side, multihoming of a single PDU session is achieved by a 879 point-to-point (P2P) tunnel per anchor UPF. It means that multiple 880 P2P paths are established from one source gNB or UPF to the multiple 881 destination anchor UPFs for the PDU session. 883 On DL side, one single multipoint-to-point (MP2P) path exists from 884 the anchor UPFs to the source gNB or UPF for the PDU session in this 885 multihoming case. It means that the paths from the anchor UPFs are 886 merged into just one tunnel state at the source gNB or UPF for the 887 PDU session. 889 Multiple P2P paths on DL could also be used for multihoming. However 890 it should be the multiple PDU sessions multihoming case where the 891 destination gNB or UPF needs to maintain multiple tunnel states under 892 the one PDU session to one UP tunnel architectural principle. 894 However, P2P tunneling could increase explosively the number of 895 states in UPF as the anchor UPF/DN incremented to the PDU session. 896 Thereby single PDU session multihoming with MP2P path should be a 897 better option for multihoming in terms of reducing total number of 898 tunnel states. 900 SSC mode 3 for session continuity in hand-over case uses a single PDU 901 multihoming with BP to make sure make-before-break. It is described 902 in the section 5.6.4 and 5.6.9 of [TS.23.501-3GPP]. 904 Multihoming is also assumed to be used for edge computing scenario. 905 Edge computing enables some services to be hosted close to the UE's 906 access point of attachment, and achieves an efficient service 907 delivery through the reduced end-to-end latency and load on the 908 transport network. In edge computing, local user's traffic is routed 909 or steered to application in the local DN by UPF. This refers the 910 section 5.13 of [TS.23.501-3GPP]. 912 ARCH-Req-4: Supporting flexible UPF selection for PDU 914 The appropriate UPFs are selected for a PDU session based on 915 parameters and information such as UPF's dynamic load or UE location 916 information. Examples of parameters and information are described in 917 the section 6.3.3 of [TS.23.501-3GPP]. 919 This means that its possible to make routing on user plane more 920 efficient in the 5GS. For example, in case that UPFs are distributed 921 geographically, decision of the destination UPF based on locations of 922 end hosts (e.g., UE or NF in DN) enables to forward PDUs with a route 923 connecting between UPFs nearby the hosts directly. 925 The 5GS allows operators to select parameters used for UPF selection. 926 (In other words, any specific schems on UPF selection are not defined 927 in the current 3GPP documents.) 929 ARCH-Req-5: No limitation for number of UPFs in a data path 931 The number of UPF in the data path is not constrained by 3GPP 932 specifications. This specification is described in the section 8.3.1 933 of [TS.23.501-3GPP]. 935 Putting multiple UPFs, which provides specific function, in a data 936 path enables flexible function deployment to make sure load 937 distribution optimizations, etc. 939 In addition, deployment of multiple UPFs as anchors closed to UEs' 940 site and connecting them without extra anchor points enable to make 941 data path more efficient. This usage is described in the section 6.5 942 of [TS.22.261-3GPP]. 944 Meanwhile, each UPF in a data path shall be controlled by an SMF via 945 N4 interface. Thus putting an excess of UPF for data paths might 946 cause increase of load of an SMF. Pragmatically, the number of UPF 947 put in a data path is one or two (e.g., for MEC or roaming cases), 948 and, at most, it would be three (e.g., for case where UE moves during 949 a session). 951 It is expected that multiple UPFs with per session tunnel handling 952 for a PDU session becomes complicated task more and more for a SMF by 953 increasing number of UPFs, and UP protocol shall support to aggregate 954 several PDU sessions into a tunnel or shall be a session-less tunnel. 956 ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated 957 with QFI into a PDU Session 959 Against to the previous generation, 5G enables UPF to multiplex QoS 960 Flows, equivalent with IP-CAN bearers in the previous generation, 961 into one single PDU session. That means that a single tunnel 962 includes multiple QFIs contrast to just one QoS Flow (a bearer) to 963 one tunnel before 5G. 965 In even the 5GS, each flow is forwarded based on the appropriate QoS 966 rules. QoS rules are configured by SMF as QoS profiles to UP 967 compoents and these components perform QoS controls to PDUs based on 968 rules. In downlink, a UPF pushes QFI into an extension header, and 969 transmits the PDU to RAN or another UPF. Then, such UPF may perform 970 transport level QoS packet marking (e.g., DSCP marking in the outer 971 header). In uplink, each UE obtains the QoS rule from SMF, and 972 transmit PDUs with QFI containing the QoS rules to the RAN. The 973 following RAN and UPFs perform enforcement of QoS control and 974 charging based on the QFI. 976 This specification is described in 5.7.1 of [TS.23.501-3GPP]. 978 ARCH-Req-7: Supporting network slicing 980 The 5GS fundamentally supports network slicing for provision the 981 appropriate end-to-end communication to various services. In the 982 relevant documents (e.g., [TS.23.501-3GPP], [TS.28.531-3GPP]), a 983 network slice is defined as virtual network and it is structured with 984 SMF, RANs, UPFs and DNs. Each network slice is independent and its 985 user plane (including network functions and links) should be 986 noninteractive against the others. 988 Note that 3GPP focuses on only mobility management and specifications 989 to synchronize with other networks including transport networks is 990 not clearly defined. 992 5. Evaluation Aspects 994 This section provides UP protocol evaluation aspects that are mainly 995 we derived from the architectural requirements described in 996 Section 4. Those aspects are not prioritized by the order here. 997 Expected deployment scenarios explain the evaluations purpose in the 998 corresponding aspects. 1000 As we were noticed that the gaps between GTP-U specifications and 5G 1001 architectural requirements through the analysis, those each gap are 1002 briefly described in the evaluation aspect associated to it. 1004 Since it is obvious that 5G system should be able to interwork with 1005 existing previous generation based systems, any aspects from 1006 coexisting and interworking point of view are not particularly 1007 articulated here. It may be described in a next version. 1009 5.1. Supporting PDU Session Type Variations 1011 Given that UP protocol is required to support all PDU session types: 1012 IPv4, IPv6, Ethernet, and Unstructured. However, it is expected that 1013 some deployment cases allow candidate protocol to adopt only one or 1014 few PDU session type(s) for simplicity of operations. As we can 1015 expect that IPv4 connectivity services will be available through 1016 IPv6-only PDU session that enabled by bunch of IPv6 transition 1017 solutions already available in the field. 1019 For this, the expected evaluation points from this aspect should be 1020 whether there is substitutional means to cover other PDU session 1021 types. And how much it makes simple the system than deploying 1022 original PDU session types. 1024 5.2. Nature of Data Path 1026 As it is described in Section 4.2, the single PDU session multi- 1027 homing case requires multipoint-to-point (MP2P) data path. It should 1028 be much scalable than multi-homing with multiple PDU sessions because 1029 number of required path states in the UPFs are reduced as closed to 1030 egress endpoint. Against that point-to-point (P2P) protocol requires 1031 same number of states in each UPF throughout the path. 1033 From this point of view, the expected evaluation points from this 1034 aspect is whether the nature of candidate UP protocols are to utilize 1035 MP2P data path. Supporting MP2P data path by GTP-U could be a gap 1036 since GTP-U is a point-to-point tunneling protocol as it is described 1037 in Section 3. 1039 Noted that 3GPP CT WG4 pointed out GTP-U was already required to 1040 allow one single tunnel endpoint to receive packets from multiple 1041 source endpoints ([C4-185491-3GPP]). It was an architectural 1042 requirement of 3GPP system from a previous generation. It means that 1043 MP2P data path requirement for UP protocol has been existed before 1044 the 5G system. 1046 5.3. Supporting Transport Variations 1048 The 5G system will be expected that the new radio spectrums in high 1049 frequency bands require operators to deploy their base stations much 1050 dense for much wider areas compare to previous generation footprints. 1051 To make sure that density and coverage, all available types of 1052 transport in the field must be employed between RAN to UPF, or UPF to 1053 UPF. 1055 It is also expected that MTU size of each transport could be varied. 1056 Because one could be own fiber which the operator configure the MTU 1057 size as they like while others are third-party provided L2/L3 VPN 1058 lines which MTU size can't be controlled by the operators. 1060 The MTU between RAN and UPF can be discovered by offline means and 1061 the operator takes into account the MTU that is transferable on the 1062 radio interface and based on this the operator configures the right 1063 MTU to be used. That is then signaled to the UE either via PCO (for 1064 IPv4 case) or the IPv6 RA message (for IPv6 case). 1066 In addition, for cases that third-parties provide VPN lines, it would 1067 be recommended MTU size discovery for each data path and dynamic MTU 1068 size adjustment mechanisms, while GTP-U does not support those 1069 mechanisms. 1071 As the study item in 3GPP mentioned, IPv6 is preferable address 1072 family not only for UEs, but also for the UP transport, in terms of 1073 size of available address space to support dense and wide footprint 1074 of base stations. However it increases header size from 20bytes to 1075 40bytes compare to IPv4. It could be a problem if the MTU size is 1076 uncontrollable, or only limited MTU size available to carry committed 1077 PDU size on the user plane. 1079 The expected evaluation points from this aspect should be that the 1080 candidate protocols are able to dynamically adjust path MTU size with 1081 appropriate MTU size discovery mechanism. It also should be that how 1082 the candidate protocols leverage IPv6 to deal with header size 1083 increasing. 1085 5.4. Data Path Management 1087 As Section 4.2 described, the 5G systems allows user plane that 1088 flexible UPF selection, multiple anchor UPFs, and no limit on how 1089 many UPFs chained for the data path of the PDU session. UPF 1090 deployments in the field will thereby be distributed to be able to 1091 optimize the data path based on various logics and service scenarios. 1093 That powerful user plane capability could affect data path management 1094 complicated and difficult to be managed through the control plane, or 1095 operation support systems (OSS). Perhaps it could be the case where 1096 the UP protocol nature is P2P and it only supports per session base 1097 data path handling. 1099 Because it increases data path states by number of sessions, and 1100 number of endpoints of UPFs that makes data path handling much hectic 1101 and the control plane tend to be overloaded by not only usual 1102 attach/detach/hand-over operations, but also existing session 1103 manipulation triggered by UPF and transport nodes/paths restoration, 1104 etc., 1106 The expected evaluation points from this aspect should be that how 1107 much the candidate protocols can reduce data path management loads 1108 both on the control plane NFs and UPFs compare to the per session 1109 based handling for P2P paths. It could possibly include N3 and N6 in 1110 addition to N9 while it supports flexible user plane data path 1111 optimizations for some example scenarios. 1113 5.5. QoS Control 1115 The QoS model is based on QoS flows to which QFI indicates in the 5G 1116 system that allows multiple QoS flows are aggregated into a single 1117 PDU session. So that it is given that the UP protocol should convey 1118 QFIs for a PDU session and the UPF needs to lookup them. It makes 1119 sure that reflects QoS policy in the 5G system to corresponding 1120 forwarding policy in the user plane IP transports. 1122 The expected evaluation points from this aspect should be whether the 1123 candidate protocols can provide stable ID space for QFI which 1124 shouldn't be a big deal since QFI just requires 6-bits space. 1126 As we pointed out in Section 3.2, the lookup process could impact UPF 1127 performance if the QFI container position in the header is 1128 unpredictable. It could happen many times along the path because the 1129 each UPFs should do it again and again in case that various different 1130 QoS policies are deployed in the networks under the UP as we 1131 discussed in Section 5.3. 1133 As [TS.29.281-3GPP] updated in version 15.3.0, it is recommended that 1134 the first extension header is the PDU session container in which QFI 1135 is present. 1137 5.6. Traffic Detection and Flow Handling 1139 As described in Section 4.1.1, UPF need to detect traffic flow 1140 specified by SMF within a PDU session, and enforce some processes to 1141 the PDU based on the pre-configured policy rule. 1143 As similar with QoS flow lookup described in Section 5.5, UPFs along 1144 the path are repeatedly detecting an specified traffic flow in inner 1145 PDU. It could increase redundant flow detection load on every UPFs 1146 that could be avoided if the upstream UPF put some identifier which 1147 abstracts the detected flow into the packets. It enables following 1148 UPFs just find the ID to detect the indicated flow from the packet. 1150 The expected evaluation points from this aspect should be whether the 1151 candidate protocols can provide means to reduce that redundant flow 1152 detection that could be enough bits space on stable ID space to put 1153 abstracted detected flow identifier. 1155 5.7. Supporting Network Slicing Diversity 1157 To embody network slicing, it is expected that various means should 1158 be available in case by case, or operator by operator, for their 5G 1159 systems while it follows the fundamental slicing concept, as 1160 described in Section 4.1. 1162 As [TS.28.530-3GPP] described in section 4, UP underlay transport 1163 networks and UPFs are shared by network slices. The data model 1164 defined in [TS.29.510-3GPP] allows that a Network Instance, a UPF and 1165 its interfaces can belong to multiple slices as same as other type of 1166 NFs. UP endpoint IP prefix/address of an interface can also be 1167 shared with multiple interfaces on the UPF as the model doesn't make 1168 them slice unique. 1170 The assumed slice operation in 5G architecture is that UPFs connect 1171 to each other through direct (virtual) link as Section 4.1 describes 1172 that UPFs compose a network slice on an UP. So IP routing and 1173 transport system underneath the UP are not visible from the 5G 1174 system. However some means need to indicate a slice on the shared 1175 underlying networks of the UP over the wire. 1177 That's just one way for network slicing, but it would help to reduce 1178 the operational burden. Even it depends on each operator's policy, 1179 sharing network instances, UPFs, and the interfaces among slices 1180 makes operators relax and not to be much hustled on slice lifecycle 1181 management., such as create, update, and delete operations for 1182 slices. 1184 By the way, the 3GPP specifications for slice lifecycle managements 1185 is described in the relevant documents: [TS.28.531-3GPP], 1186 [TS.28.532-3GPP], and [TS.28.533-3GPP]. 1188 It could also make sense in case that each network slice requires 1189 different forwarding policies in the middle of the path. Some 1190 identifier in the packets for a slice could be a glue between UP path 1191 and its underlying transport networks. For example, if a slice 1192 requires certain level of latency with dedicated route, traffic 1193 engineering (TE) embodies appropriate forwarding policy through the 1194 underlay transport network. 1196 The expected evaluation points from this aspect should be whether the 1197 candidate protocols can support to indicate a network slice in the UP 1198 packets that could be enough bits space on stable ID space to put 1199 slice identifier for the slice, or the forwarding policy within the 1200 slice. Since 5G control plane is not designed to handle transport 1201 resources, such as VLAN, MPLS Label, Tunnel ID except GTP-U, less 1202 impact to the control plane protocol and the APIs should be much 1203 preferable. 1205 6. Conclusion 1207 We analyzed the 3GPP specifications of the 5G architecture in terms 1208 of user plane and the current protocol adopted to the user plane. 1209 After the analysis work, we believe that the results described in 1210 this document shows that we reach at certain level of understanding 1211 on the 5G systems and ready to provide our inputs to 3GPP. 1213 We clarified GTP-U through the analysis and listed observed 1214 characteristics in Section 3.6. We also clarified the architectural 1215 requirements for UP protocol described in Section 4.2. 1217 As we identified some potential gaps between the current UP protocol 1218 and the architectural requirements even for Release 15, it is worth 1219 to study possible candidate UP protocols for the 5G system including 1220 current one. Our conclusion here is that we suggest the UP protocol 1221 study work in 3GPP takes into account the evaluation aspects 1222 described in Section 5. 1224 7. Security Consideration 1226 TBD 1228 8. Acknowledgement 1230 The authors would like to thank Tom Herbert, Takashi Ito, John Leddy, 1231 Pablo Camarillo, Daisuke Yokota, Satoshi Watanabe, Koji Tsubouchi and 1232 Miya Kohno for their detailed reviews, comments, and contributions. 1234 A special thank you goes to Arashmid Akhavain for his technical 1235 review and feedback. 1237 Lastly, the authors would like to thank 3GPP CT WG4 folks for their 1238 review and feedback. 1240 9. Informative References 1242 [C4-185491-3GPP] 1243 3rd Generation Partnership Project (3GPP), "LS OUT on User 1244 Plane Analysis", July 2018, 1245 . 1248 [CP-173160-3GPP] 1249 3rd Generation Partnership Project (3GPP), "New Study Item 1250 on User Plane Protocol in 5GC", December 2017, 1251 . 1254 [CP-180116-3GPP] 1255 3rd Generation Partnership Project (3GPP), "LS on user 1256 plane protocol study", March 2018, 1257 . 1260 [I-D.bogineni-dmm-optimized-mobile-user-plane] 1261 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 1262 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 1263 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 1264 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 1265 optimized-mobile-user-plane-01 (work in progress), June 1266 2018. 1268 [IAB-Statement] 1269 Internet Architecture Board (IAB), "IAB Statement on 1270 IPv6", November 2016, 1271 . 1273 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1274 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1275 December 1998, . 1277 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1278 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1279 DOI 10.17487/RFC4861, September 2007, 1280 . 1282 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1283 "IPv6 Flow Label Specification", RFC 6437, 1284 DOI 10.17487/RFC6437, November 2011, 1285 . 1287 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1288 for Equal Cost Multipath Routing and Link Aggregation in 1289 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1290 . 1292 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1293 UDP Checksums for Tunneled Packets", RFC 6935, 1294 DOI 10.17487/RFC6935, April 2013, 1295 . 1297 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1298 (IPv6) Specification", STD 86, RFC 8200, 1299 DOI 10.17487/RFC8200, July 2017, 1300 . 1302 [TR.29.891-3GPP] 1303 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 1304 (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December 1305 2017, . 1308 [TS.22.261-3GPP] 1309 3rd Generation Partnership Project (3GPP), "3GPP TS 22.261 1310 (V15.4.0): Service requirements for 5G system stage 1", 1311 March 2018, . 1314 [TS.23.060-3GPP] 1315 3rd Generation Partnership Project (3GPP), "3GPP TS 23.060 1316 (V15.3.0): General Packet Radio Service (GPRS); Service 1317 description; Stage 2", June 2018, 1318 . 1321 [TS.23.501-3GPP] 1322 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 1323 (V15.3.0): System Architecture for 5G System; Stage 2", 1324 September 2018, . 1327 [TS.23.502-3GPP] 1328 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 1329 (V15.1.0): Procedures for 5G System; Stage 2", March 2018, 1330 . 1333 [TS.23.503-3GPP] 1334 3rd Generation Partnership Project (3GPP), "3GPP TS 23.503 1335 (V15.1.0): Policy and Charging Control System for 5G 1336 Framework; Stage 2", March 2018, . 1339 [TS.28.530-3GPP] 1340 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1341 (V1.0.0): Management and orchestration of networks and 1342 network slicing; Concepts, use cases and requirements 1343 (work in progress)", June 2018, 1344 . 1347 [TS.28.531-3GPP] 1348 3rd Generation Partnership Project (3GPP), "3GPP TS 28.531 1349 (V1.0.0): Management and orchestration of networks and 1350 network slicing; Provisioning; Stage 1 (Release 15)", June 1351 2018, . 1354 [TS.28.532-3GPP] 1355 3rd Generation Partnership Project (3GPP), "3GPP TS 28.532 1356 (V0.3.0): Management and orchestration of networks and 1357 network slicing; Provisioning; Stage 2 and stage 3 1358 (Release 15)", June 2018, . 1361 [TS.28.533-3GPP] 1362 3rd Generation Partnership Project (3GPP), "3GPP TS 28.533 1363 (V0.3.0): Management and orchestration of networks and 1364 network slicing; Management and orchestration architecture 1365 (Release 15)", June 2018, . 1368 [TS.29.244-3GPP] 1369 3rd Generation Partnership Project (3GPP), "3GPP TS 29.244 1370 (V15.1.0): Interface between the Control Plane and the 1371 User Plane Nodes; Stage 3", March 2018, 1372 . 1375 [TS.29.274-3GPP] 1376 3rd Generation Partnership Project (3GPP), "3GPP TS 29.274 1377 (V15.4.0): 3GPP Evolved Packet System (EPS); Evolved 1378 General Packet Radio Service (GPRS) Tunneling Protocol for 1379 Control plane (GTPv2-C); Stage 3", June 2018, 1380 . 1383 [TS.29.281-3GPP] 1384 3rd Generation Partnership Project (3GPP), "3GPP TS 29.281 1385 (V15.4.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", 1386 September 2018, . 1389 [TS.29.510-3GPP] 1390 3rd Generation Partnership Project (3GPP), "3GPP TS 29.510 1391 (V15.0.0): 5G System; Network Function Repository 1392 Services; Stage 3", June 2018, . 1395 [TS.29.561-3GPP] 1396 3rd Generation Partnership Project (3GPP), "3GPP TS 29.561 1397 (V15.0.0): 5G System; Interworking between 5G Network and 1398 external Data Networks; Stage 3", June 2018, 1399 . 1402 [TS.38.300-3GPP] 1403 3rd Generation Partnership Project (3GPP), "3GPP TS 38.300 1404 (v15.1.0): NR and NG-RAN Overall Description; Stage 2", 1405 March 2018, . 1408 [TS.38.401-3GPP] 1409 3rd Generation Partnership Project (3GPP), "3GPP TS 38.401 1410 (v15.1.0): NG-RAN; Architecture Description", March 2018, 1411 . 1414 [TS.38.415-3GPP] 1415 3rd Generation Partnership Project (3GPP), "3GPP TS 38.415 1416 (v15.1.0): NG-RAN; PDU Session User Plane protocol", 1417 September 2018, . 1420 Authors' Addresses 1422 Shunsuke Homma 1423 NTT 1425 Email: homma.shunsuke@lab.ntt.co.jp 1427 Takuya Miyasaka 1428 KDDI Research 1430 Email: ta-miyasaka@kddi-research.jp 1432 Satoru Matsushima 1433 SoftBank 1435 Email: satoru.matsushima@g.softbank.co.jp 1437 Daniel Voyer 1438 Bell Canada 1440 Email: daniel.voyer@bell.ca