idnits 2.17.1 draft-hmm-dmm-5g-uplane-analysis-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 : ---------------------------------------------------------------------------- ** 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 (August 10, 2018) is 2086 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GTP-U-1' is mentioned on line 664, but not defined == Missing Reference: 'GTP-U-2' is mentioned on line 666, but not defined == Missing Reference: 'GTP-U-3' is mentioned on line 668, but not defined == Missing Reference: 'Uplink' is mentioned on line 286, but not defined == Missing Reference: 'Downlink' is mentioned on line 306, but not defined == Missing Reference: 'GTP-U-4' is mentioned on line 671, but not defined == Missing Reference: 'GTP-U-5' is mentioned on line 674, but not defined == Missing Reference: 'GTP-U-6' is mentioned on line 677, but not defined == Missing Reference: 'GTP-U-7' is mentioned on line 680, but not defined == Missing Reference: 'GTP-U-8' is mentioned on line 684, but not defined == Missing Reference: 'GTP-U-9' is mentioned on line 687, but not defined == Missing Reference: 'GTP-U-10' is mentioned on line 689, but not defined == Missing Reference: 'GTP-U-11' is mentioned on line 691, but not defined == Missing Reference: 'GTP-U-12' is mentioned on line 693, but not defined == Missing Reference: 'GTP-U-13' is mentioned on line 696, but not defined == Missing Reference: 'GTP-U-14' is mentioned on line 698, 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: February 11, 2019 KDDI Research 6 S. Matsushima 7 SoftBank 8 D. Voyer 9 Bell Canada 10 August 10, 2018 12 User Plane Protocol and Architectural Analysis on 3GPP 5G System 13 draft-hmm-dmm-5g-uplane-analysis-01 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 February 11, 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 . . . . . . . . . . . . . . . . . . . 9 65 3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12 66 3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 12 67 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 13 68 3.6. Observations Summary . . . . . . . . . . . . . . . . . . 15 69 4. 5GS Architectural Requirements for User Plane Protocols . . . 15 70 4.1. Overview of 5G System Architecture . . . . . . . . . . . 15 71 4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 17 72 4.2. Architectural Requirements for User Plane Protocols . 18 73 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 20 74 5.1. Supporting PDU Session Type Variations . . . . . . . . . 21 75 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 21 76 5.3. Supporting Transport Variations . . . . . . . . . . . . . 22 77 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 22 78 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 23 79 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 24 80 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 24 81 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 7. Security Consideration . . . . . . . . . . . . . . . . . . . 25 83 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 84 9. Informative References . . . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 GTP-U allows one tunnel endpoint node to send out a G-PDU to be 266 received by multiple tunnel endpoints by utilizing IP multicast 267 capability of underlay IP networks. That is described in section 268 4.2.6 of [TS.29.281-3GPP]. It looks GTP-U has Point-to-Multipoint 269 (P2MP) tunneling capability. The P2MP tunneling is used for MBMS 270 (Multimedia Broadcast Multicast Service) through GTP-U tunnel. 272 [GTP-U-2]: GTP-U supports Point-to-Multipoint tunneling. 274 UDP is utilized for GTP-U encapsulation and UDP destination port is 275 2152 which is assigned by IANA. Allocation of UDP source port 276 depends on sender tunnel endpoint node and GTP-U supports dynamic 277 allocation of UDP source port for load balancing objective. The 278 specification of this dynamic allocation is described in section 279 4.4.2.0 of [TS.29.281-3GPP], however specific procedure, e.g., 280 5-tuple hashing, is not described in the document and depends on the 281 implementation of GTP-U tunnel endpoint node. 283 [GTP-U-3]: GTP-U supports load balancing by using dynamic UDP source 284 port allocation. 286 [Uplink] 287 .- .-+--------+ - - - - +--------+ - - - - +--------+ 288 | | |Payload | |Payload | |Payload | 289 | PDU < +--------+ +--------+ +--------+ 290 |(3GPP)| |Inner IP| |Inner IP| |Inner IP| 291 | '-+--------+ - - - - +--------+ - - - - +--------+ 292 | | GTP-U | | GTP-U | 293 | |(TEID=1)| |(TEID=2)| 294 GTP< +--------+ +--------+ 295 Pkt | | UDP | | UDP | 296 | +--------+ +--------+ 297 | |Outer IP| |Outer IP| 298 | +--------+ +--------+ 299 | | L2 | | L2 | 300 | +--------+ +--------+ 301 | | L1 | | L1 | 302 '- +--------+ - - - - +--------+ 304 ================ Traffic Direction =======================> 306 [Downlink] 307 .- .-+--------+ - - - - +--------+ - - - - +--------+ 308 | | |Payload | |Payload | |Payload | 309 | PDU < +--------+ +--------+ +--------+ 310 |(3GPP)| |Inner IP| |Inner IP| |Inner IP| 311 | '-+--------+ - - - - +--------+ - - - - +--------+ 312 | | GTP-U | | GTP-U | 313 | |(TEID=4)| |(TEID=3)| 314 GTP< +--------+ +--------+ 315 Pkt | | UDP | | UDP | 316 | +--------+ +--------+ 317 | |Outer IP| |Outer IP| 318 | +--------+ +--------+ 319 | | L2 | | L2 | 320 | +--------+ +--------+ 321 | | L1 | | L1 | 322 '- +--------+ - - - - +--------+ 324 <=============== Traffic Direction ======================== 326 +-----+ N3 +------+ N9 +------+ N6 327 -----+ RAN +-----------+ UPF1 +------------+ UPF2 +---------- 328 +-----+ +------+ +------+ 330 Figure 1: Protocol Stack by GTPv1-U for Uplink and Downlink Traffic 331 Flow 333 IPv6 flow label [RFC6437] is also candidate method for load balancing 334 especially for IP-in-IPv6 tunnel [RFC6438] like GTP-U. However, how 335 to use IPv6 flow label of GTP-U is not described in [TS.29.281-3GPP]. 336 Though this method is limited to a case of IPv6 encapsulated GTP-U 337 tunnel, it is worth to study usage of IPv6 flow label in 3GPP. 339 [GTP-U-4]: GTP-U does not support IPv6 flow label for load balancing 340 in case of IPv6 transport. 342 GTP-U supports both IPv4 and IPv6 as underlying transport layer 343 protocol. As for IPv6, GTP-U specification refers [RFC2460], which 344 is described in section 4.2.3 of [TS.29.281-3GPP]. As [RFC2460] does 345 not allow the tunnel protocols on top of UDP to set the checksum 346 value to zero, the GTP-U specification inherits it while the IPv4 347 transport for GTP-U case allows UDP zero checksum. It is noted that 348 the IPv6 specification in IETF has been updated to [RFC8200] which 349 allows UDP zero checksum for the tunnel. [RFC6935] describes 350 benefits of zero checksum for tunnel protocol over UDP. If GTP-U 351 support UFP zero checksum in future version, possible 352 interoperability issue between previous generations which does not 353 support zero checksum may raise. 355 [GTP-U-5]: UDP zero checksum is not available in case of IPv6 356 transport. 358 "Unnecessary fragmentation should be avoided" is recommended and to 359 avoid the fragmentation operator should configure MTU size at UE 360 [TS.29.281-3GPP]. However, there's no reference and specification of 361 Path MTU Discovery for IPv6 transport. If encapsulated IPv6 packet 362 is too big on a network link between tunnel endpoint nodes, UE may 363 not receive ICMPv6 Packet Too Big message and causes Path MTU 364 Discovery black hole. 366 [GTP-U-6]: GTP-U does not support to response ICMP PTB for Path MTU 367 Discovery. 369 Section 9.3 of [TS.23.060-3GPP] specifies advertisement of inner IPv6 370 link MTU size for UE by IPv6 RA message [RFC4861]. However, this 371 document doesn't specify a procedure to measure MTU size in mobile 372 network system and mobile network operator need to calculate MTU size 373 for UE like Annex C of [TS.23.060-3GPP]. If link MTU of a router in 374 a transport network is accidentally modified, UE cannot detect the 375 event and send packet with initial MTU size, which may cause service 376 disruption due to MTU exceed in the router link. 378 3.2. GTP-U Header Format 380 Figure 2 shows general and mandatory GTP-U header and Figure 3 shows 381 extension GTP-U header. 383 [GTP-U-7]: GTP-U supports sequence number option in the header, but 384 it is not recommended to be used by almost GTP-U 385 entities. 387 GTP-U header has Sequence Number field to reorder incoming packets 388 based on the sequence number. If Sequence Number Flag is set to '1' 389 it indicates that Sequence Number Filed exists in GTP-U header and 390 examined at receiving tunnel endpoint node to reorder incoming 391 packets. However, the sequence number flag is set to '1' only for 392 RAT HO procedure and sequence number flag should be set to '0' in 393 normal case. Therefore, in normal case receiver tunnel endpoint node 394 doesn't examine sequence number and can't reorder GTP-U packets based 395 on the sequence number. This specification is described in section 396 5.1 of [TS.29.281-3GPP]. In 3GPP, sequential delivery is required 397 only during handover procedure and is used by only RAN entities. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Ver |P|R|E|S|N| Message Type| Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Tunnel Endpoint Identifier | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Sequence Number | N-PDU Number | Next-Ext-Hdr | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 2: GTP-U Header 411 o Ver: Version field (Set to '1') 413 o P: Protocol Type (Set to '1') 415 o R: Reserved bit (Set to '0') 417 o E: Extension Header Flag (Set to '1' if extension header exists) 419 o S: Sequence Number Flag (Set to '1' if sequence number exists) 421 o N: N-PDU Number Flag (Set to '1' if N-PDU number exists) 423 o Message Type: Indicates the type of GTP-U message 425 o Length: Indicates the length in octets of the payload 426 o Tunnel Endpoint Identifier (TEID) 428 o Sequence Number: Indicates increasing sequence number for T-PDUs 429 is transmitted via GTP-U tunnels 431 o N-PDU Number: It is used only for inter SGSN, 2G-3G handover case, 432 etc. 434 o Next-Ext-Hdr: Indicates following extension header type 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Ext-Hdr Length| | 440 +-+-+-+-+-+-+-+-+ | 441 | Extension Header Content | 442 . . 443 . +-+-+-+-+-+-+-+-+ 444 | | Next-Ext-Hdr | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 3: Extension GTP-U Header 449 o Ext-Hdr Length: Represents the length of the Extension header in 450 units of 4 octets 452 o Extension Header Content: Contains 3GPP related information 454 o Next-Ext-Hdr: Indicates following extension header type 456 The extension GTP-U header is a variable-length and extendable header 457 and contains 3GPP specific information. Following list summarizes 458 every extension header which is used for user plane protocol. These 459 extension headers are defined in [TS.29.281-3GPP]. In this list 460 Next-Ext-Hdr is represented in binary. 462 o No more extension headers (Next-Ext-Hdr = 00000000) 464 o Service Class Indicator (Next-Ext-Hdr = 00100000) 466 o UDP Port (Next-Ext-Hdr = 01000000) 468 o RAN Container (Next-Ext-Hdr = 10000001) 470 o Long PDCP PDU Number (Next-Ext-Hdr = 10000010) 472 o Xw RAN Container (Next-Ext-Hdr = 10000011) 473 o NR RAN Container (Next-Ext-Hdr = 10000100) 475 o PDU Session Container (Next-Ext-Hdr = 10000101) 477 o PDCP PDU Number (Next-Ext-Hdr = 11000000) 479 [GTP-U-8]: GTP-U supports carrying QoS Identifiers transparently for 480 Access Networks in an extension header. 482 GTP-U is designed to carry 3GPP specific information with extension 483 headers. 3GPP creates PDU Session Container extension header for 484 NGRAN of 5G to carry QFI. It is described in section 5.2.2.7 of 485 [TS.29.281-3GPP]. 487 [GTP-U-9]: GTP-U supports DSCP marking based on the QFI. 489 DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel 490 endpoint node based on the QFI. This specification is described in 491 section 4.4.1 of [TS.29.281-3GPP]. However in [TS.29.281-3GPP] "DSCP 492 marking based on QCI" is specified but "DSCP marking based on QFI" 493 has not been noted. To support QFI of 5G QoS framework, it seems to 494 need to update [TS.29.281-3GPP]. 496 [GTP-U-10]: GTP-U does not specify extension header order. 498 In general, multiple GTP-U extension headers are able to contained in 499 one GTP-U packet and the order of those extension headers is not 500 specified by [TS.29.281-3GPP]. Thereby the receiving endpoint can't 501 predict exact position where the target extension headers are. This 502 could impact on header lookup performance on the node. 504 As for PDU Session Container extension header, there is a note in 505 [TS.29.281-3GPP] as "For a G-PDU with several Extension Headers, the 506 PDU Session Container should be the first Extension Header". This 507 note was added at the version 15.3.0 of [TS.29.281-3GPP] which is 508 published on June 2018 in order to accelerate the processing of GTP-U 509 packet at UPF and RAN. It is only one rule regarding the extension 510 header order. 512 [GTP-U-11]: GTP-U does not support to indicate next protocol type. 514 When Next-Ext-Hdr is set to 0x00 it indicates that no more extension 515 headers follow. As GTP is designed to indicate protocol types for 516 T-PDU by control-plane signaling, GTP-U doesn't have Next-Protocol- 517 Header field to indicate the T-PDU type in the header. 519 3.3. Control Plane Protocol for GTP-U 521 Control plane protocol for GTP-U signals TEID between tunnel endpoint 522 nodes. GTPv2-C [TS.29.274-3GPP] is the original control plane 523 protocol tied with GTP-U in previous generation architectures before 524 CUPS (Control and User Plane Separation). 526 3GPP decided to use extended PFCP (Packet Forwarding Control 527 Protocol) [TS.29.244-3GPP] for N4 interface [TR.29.891-3GPP] to 528 signal tunnel states from SMF to UPF. 530 3.4. GTP-U message 532 GTP-U supports in-band messaging to signal OAM. Currently GTP-U 533 supports following messages [TS.29.281-3GPP]. 535 o Echo Request 537 o Echo Response 539 o Supported Extension Headers Notification 541 o Error Indication 543 o End Marker 545 [GTP-U-12]: GTP-U supports active OAM as a path management message 546 "Echo Request/Response". 548 A GTP-U tunnel endpoint node sends a Echo Request message to another 549 nodes for keep-alive and received node sends a Echo Response message 550 to sender node as acknowledgment. Echo Request message and Echo 551 Response message are described in section 7.2.1 and section 7.2.2 of 552 [TS.29.281-3GPP] respectively. [TR.29.891-3GPP] recommends not to 553 send Echo Request message more often than 60s on each path. 555 Supported Extension Headers Notification message indicates a list of 556 supported that tunnel endpoint node can support. This message is 557 sent only in case a tunnel endpoint node receives GTP-U packet with 558 unsupported extension header. 560 [GTP-U-13]: GTP-U supports tunnel management messages "Error 561 Indication". 563 GTP-U has Error Indication message to notify that the receiving 564 endpoint discard packets of which no session exist to the sending 565 endpoint. Error Indication message is described in section 7.3.1 of 566 [TS.29.281-3GPP]. 568 [GTP-U-14]: GTP-U supports tunnel management messages "End Marker". 570 GTP-U has End Marker message to indicate the end of the payload 571 stream that needs to be sent on a GTP-U tunnel. End Marker message 572 is described in section 7.3.2 of [TS.29.281-3GPP]. 574 3.5. Packet Format 576 Figure 4 shows a packet format example of GTP-U over IPv6 that 577 carries an extension header for QFI and an IPv6 PDU. All values in 578 the example are illustration purpose only. The encoding of PDU 579 Session Container for QFI refers to [TS.38.415-3GPP]. 581 0 1 2 3 582 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 583 Outer IPv6 Header 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 |Version| DSCP=EF | Flow Label | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | | 590 + + 591 | | 592 + Source IPv6 Address + 593 | 2001:db8:1:1::1 | 594 + + 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 598 + + 599 | | 600 + Destination IPv6 Address + 601 | 2001:db8:1:2::1 | 602 + + 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Outer UDP Header 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Source Port = xxxx | Dest Port = 2152 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | UDP Length | UDP Checksum (Non-zero) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 GTP-U header 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | 0x1 |1|0|1|0|0| 0xff | Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | TEID = 1654 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Sequence Number = 0 |N-PDU Number=0 |NextExtHdr=0x85| 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 GTP-U Extension Header (PDU Session Container) 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | ExtHdrLen=1 |Type=0 | Spare |0| QFI |NextExtHdr=0x0 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Inner IPv6 Header 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 |Version| DSCP=0 | Flow Label | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Payload Length | NexttHdr | Hop Limit | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | | 634 + + 635 | | 636 + Source IPv6 Address + 637 | 2001:db8:2:1::1 | 638 + + 639 | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | | 642 + + 643 | | 644 + Destination IPv6 Address + 645 | 2001:db8:3:1::1 | 646 + + 647 | | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Payload 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | | 653 | | 654 . TCP/UDP/etc., Data . 655 . . 656 | | 657 | | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 4: GTP-U Protocol Stack Example 662 3.6. Observations Summary 664 [GTP-U-1]: An unidirectional Point-to-Point tunneling protocol. 666 [GTP-U-2]: Supports Point-to-Multipoint tunneling. 668 [GTP-U-3]: Supports load balancing by using dynamic UDP port 669 allocation. 671 [GTP-U-4]: Does not support IPv6 flow label for load balancing in 672 case of IPv6 transport. 674 [GTP-U-5]: UDP zero checksum is not available in case of IPv6 675 transport. 677 [GTP-U-6]: Does not support to response ICMP PTB for Path MTU 678 Discovery. 680 [GTP-U-7]: Supports sequence number option and sequence number flag 681 in the header, but it is not recommended to be used by 682 almost GTP-U entities. 684 [GTP-U-8]: Supports carrying QoS Identifiers transparently for 685 Access Networks in extension headers. 687 [GTP-U-9]: Supports DSCP marking based on the QFI. 689 [GTP-U-10]: Does not specify the rule for the extension header order. 691 [GTP-U-11]: Does not support an indication of next-header type. 693 [GTP-U-12]: Supports active OAM as a path management message "Echo 694 Request/Response". 696 [GTP-U-13]: Supports tunnel management messages "Error Indication". 698 [GTP-U-14]: Supports tunnel management messages "End Marker". 700 4. 5GS Architectural Requirements for User Plane Protocols 702 4.1. Overview of 5G System Architecture 704 The 5G system is designed for applying to diverse devices and 705 services due to factors such as the diffusion of IoT devices, and the 706 UP protocol is required to have capabilities for satisfying their 707 requirements. 709 As a principle of the 5G system, User Plane (UP) functions are 710 separated from the Control Plane (CP) functions for allowing 711 independent scalability, evolution and flexible deployments. 713 Network slicing is also one of the fundamental concepts of the 5G 714 system, and it provides logical network separation. In terms of user 715 plane, multiple network slices can be comprised of UPFs on top of 716 same physical network resources. Allocated resources and structures 717 may be differentiated among the slices by which the required features 718 or capabilities. 720 The architecture overview is shown in Figure 5. The details of 721 functions are described in [TS.23.501-3GPP]. User plane path and 722 applied functions for a tunnel will be manipulated based on 723 application requirements that the PDU session corresponding to the 724 tunnel. These tunnels are available to be handled by other 725 authorized functions through the control plane. 727 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 728 |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 729 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 730 Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf 731 ---+--------+--+-----+--+--------+--+-----+--------+- 732 Nausf| Namf| Nsmf| 733 +--+--+ +--+--+ +--+-------+ 734 |AUSR | | AMF | | SMF | 735 +-----+ ++-+--+ +--+-----+-+ 736 / | | \ 737 Control Plane N1/ |N2 |N4 \N4 738 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 739 User Plane / | | \ 740 +--++ +--+--+ N3 +--+--+ N9 +-+---+ N6 +-----+ 741 |UE +--+(R)AN+-----+ UPF +-----+ UPF +----+ DN | 742 +---+ +-----+ +--+--+ +-----+ +-----+ 743 |N6 744 +--+--+ 745 | DN | 746 +-----+ 748 Figure 5: 5GS Architecture and Service-based Interfaces 750 This document mainly focuses on requirements for N9 interface as 751 relevant to UP protocol of 5G system. 753 4.1.1. UPF Functionalities 755 UPF has a role to handle UP traffic, and provides functionalities to 756 look up user data traffic and enforce the appropriate policies to it. 758 The followings are defined as UPF functionalities for traffic 759 handling: 761 o User Plane part of policy rule enforcement, e.g. Gating, 762 Redirection, Traffic steering) 764 o QoS handling for user plane, e.g. UL/DL rate enforcement, 765 Reflective QoS marking in DL 767 o Transport level packet marking in the uplink and downlink 769 Other functionalities are described in the section 6.2.3 of 770 [TS.23.501-3GPP] 772 UPF shall detect user plane traffic flow depending on information 773 indicated by SMF. User data traffic is detected with combination of 774 the following information: 776 o For IPv4 or IPv6 PDU Session type 778 * PDU Session 780 * QFI 782 * Application Identifier: The Application ID is an index to a set 783 of application detection rules configured in UPF 785 o For Ethernet PDU Session type 787 * PDU Session 789 * QFI 791 * Ethernet Packet Filter Set: 793 + Source/destination MAC address 795 + Ethertype as defined in IEEE 802.3 797 + Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) VID 798 fields as defined in IEEE 802.1Q 800 + Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/ 801 DEI fields as defined in IEEE 802.1Q 803 + IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 804 payload 806 + Packet filter direction 808 Such information for traffic detection (Traffic Detection 809 Information) is described in the section 5.8.2.4 of [TS.23.501-3GPP]. 811 4.2. Architectural Requirements for User Plane Protocols 813 This section lists the requirements for the UP protocol on the 5G 814 system. The requirements are picked up from [TS.23.501-3GPP]. In 815 addition, some of service requirements described in [TS.22.261-3GPP] 816 are referred to clarify the originations of architectural 817 requirements. 819 According to [TS.23.501-3GPP], the specifications potentially have 820 assumptions that the UP protocol is a tunnel representing a single 821 TEID between a pair of UPFs and it is corresponding to a single PDU 822 session. In short, the UP protocol is a tunnel and it is assumed to 823 be managed under per PDU session handling. Also, it should be a 824 stateful tunnel in the UPFs along with the PDU session. 826 The requirements for UP protocols are described below: 828 ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU 830 The 5G system defines four types of PDU session as IPv4, IPv6, 831 Ethernet, and Unstructured. Therefore, UP protocol must support to 832 convey all of these PDU session types. This is described in 833 [TS.23.501-3GPP]. 835 Note: In TS 23.501 v15.2.0, IPv4v6 is added as a PDU session type. 837 ARCH-Req-2: Supporting IP connectivity for N3, N6, and N9 interfaces 839 The 5G system requires IP connectivity for N3, N6, and N9 interfaces. 840 The IP connectivity is assumed that it comprises of IP routing and 841 L1/L2 transport networks which are outside of 3GPP specifications. 843 On N6 interface, point-to-point tunneling based on UDP/IPv6 may be 844 used to deliver unstructured PDU type data. Then, the content 845 information of the PDU may be mapped into UDP port number, and the 846 UDP port numbers is pre-configured in the UPF and DN. This is 847 described in the section 9.2 of [TS.29.561-3GPP]. 849 ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a 850 single PDU session 852 The 5G system allows to deploy multiple UPFs as anchors for a single 853 PDU session, and supports multihoming of a single PDU session for 854 such anchor UPFs. 856 Multihoming is provided with Branching Point (BP) or Uplink 857 Classifier (UL CL) which are functionalities of UPF. BP provides 858 forwarding of UL traffic towards the different PDU Session Anchors 859 based on the source IPv6 prefixes and merge of DL traffic to the UE. 860 UL CL provides destination based multihoming for load balancing. 862 On UL side, multihoming of a single PDU session is achieved by a 863 point-to-point (P2P) tunnel per anchor UPF. It means that multiple 864 P2P paths are established from one source gNB or UPF to the multiple 865 destination anchor UPFs for the PDU session. 867 On DL side, one single multipoint-to-point (MP2P) path exists from 868 the anchor UPFs to the source gNB or UPF for the PDU session in this 869 multihoming case. It means that the paths from the anchor UPFs are 870 merged into just one tunnel state at the source gNB or UPF for the 871 PDU session. 873 Multiple P2P paths on DL could also be used for multihoming. However 874 it should be the multiple PDU sessions multihoming case where the 875 destination gNB or UPF needs to maintain multiple tunnel states under 876 the one PDU session to one UP tunnel architectural principle. 878 However, P2P tunneling could increase explosively the number of 879 states in UPF as the anchor UPF/DN incremented to the PDU session. 880 Thereby single PDU session multihoming with MP2P path should be a 881 better option for multihoming in terms of reducing total number of 882 tunnel states. 884 SSC mode 3 for session continuity in hand-over case uses a single PDU 885 multihoming with BP to make sure make-before-break. It is described 886 in the section 5.6.4 and 5.6.9 of [TS.23.501-3GPP]. 888 Multihoming is also assumed to be used for edge computing scenario. 889 Edge computing enables some services to be hosted close to the UE's 890 access point of attachment, and achieves an efficient service 891 delivery through the reduced end-to-end latency and load on the 892 transport network. In edge computing, local user's traffic is routed 893 or steered to application in the local DN by UPF. This refers the 894 section 5.13 of [TS.23.501-3GPP]. 896 ARCH-Req-4: Supporting flexible UPF selection for PDU 897 The appropriate UPFs are selected for a PDU session based on 898 parameters and information such as UPF's dynamic load or UE location 899 information. Examples of parameters and information are described in 900 the section 6.3.3 of [TS.23.501-3GPP]. 902 ARCH-Req-5: No limitation for number of UPFs in a data path 904 The number of UPF in the data path is not constrained by 3GPP 905 specifications. This specification is described in the section 8.3.1 906 of [TS.23.501-3GPP]. 908 Putting multiple UPFs, which provides specific function, in a data 909 path enables flexible function deployment to make sure load 910 distribution optimizations, etc. 912 In addition, deployment of multiple UPFs as anchors closed to UEs' 913 site and connecting them without extra anchor points enable to make 914 data path more efficient. This usage is described in the section 6.5 915 of [TS.22.261-3GPP]. 917 Meanwhile, each UPF in a data path shall be controlled by an SMF via 918 N4 interface. Thus putting an excess of UPF for data paths might 919 cause increase of load of an SMF. Pragmatically, the number of UPF 920 put in a data path is one or two (e.g., for MEC or roaming cases), 921 and, at most, it would be three (e.g., for case where UE moves during 922 a session). 924 It is expected that multiple UPFs with per session tunnel handling 925 for a PDU session becomes complicated task more and more for a SMF by 926 increasing number of UPFs, and UP protocol shall support to aggregate 927 several PDU sessions into a tunnel or shall be a session-less tunnel. 929 ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated 930 with QFI into a PDU Session 932 Against to the previous generation, 5G enables UPF to multiplex QoS 933 Flows, equivalent with IP-CAN bearers in the previous generation, 934 into one single PDU session. That means that a single tunnel 935 includes multiple QFIs contrast to just one QoS Flow (a bearer) to 936 one tunnel before 5G. This specification is described in 5.7.1 of 937 [TS.23.501-3GPP]. 939 5. Evaluation Aspects 941 This section provides UP protocol evaluation aspects that are mainly 942 we derived from the architectural requirements described in 943 Section 4. Those aspects are not prioritized by the order here. 945 Expected deployment scenarios explain the evaluations purpose in the 946 corresponding aspects. 948 As we were noticed that the gaps between GTP-U specifications and 5G 949 architectural requirements through the analysis, those each gap are 950 briefly described in the evaluation aspect associated to it. 952 Since it is obvious that 5G system should be able to interwork with 953 existing previous generation based systems, any aspects from 954 coexisting and interworking point of view are not particularly 955 articulated here. It may be described in a next version. 957 5.1. Supporting PDU Session Type Variations 959 Given that UP protocol is required to support all PDU session types: 960 IPv4, IPv6, Ethernet, and Unstructured. However, it is expected that 961 some deployment cases allow candidate protocol to adopt only one or 962 few PDU session type(s) for simplicity of operations. As we can 963 expect that IPv4 connectivity services will be available through 964 IPv6-only PDU session that enabled by bunch of IPv6 transition 965 solutions already available in the field. 967 For this, the expected evaluation points from this aspect should be 968 whether there is substitutional means to cover other PDU session 969 types. And how much it makes simple the system than deploying 970 original PDU session types. 972 5.2. Nature of Data Path 974 As it is described in Section 4.2, the single PDU session multi- 975 homing case requires multipoint-to-point (MP2P) data path. It should 976 be much scalable than multi-homing with multiple PDU sessions because 977 number of required path states in the UPFs are reduced as closed to 978 egress endpoint. Against that point-to-point (P2P) protocol requires 979 same number of states in each UPF throughout the path. 981 From this point of view, the expected evaluation points from this 982 aspect is whether the nature of candidate UP protocols are to utilize 983 MP2P data path. Supporting MP2P data path by GTP-U could be a gap 984 since GTP-U is a point-to-point tunneling protocol as it is described 985 in Section 3. 987 Noted that 3GPP CT WG4 pointed out GTP-U was already required to 988 allow one single tunnel endpoint to receive packets from multiple 989 source endpoints ([C4-185491-3GPP]). It was an architectural 990 requirement of 3GPP system from a previous generation. It means that 991 MP2P data path requirement for UP protocol has been existed before 992 the 5G system. 994 5.3. Supporting Transport Variations 996 The 5G system will be expected that the new radio spectrums in high 997 frequency bands require operators to deploy their base stations much 998 dense for much wider areas compare to previous generation footprints. 999 To make sure that density and coverage, all available types of 1000 transport in the field must be employed between RAN to UPF, or UPF to 1001 UPF. 1003 It is also expected that MTU size of each transport could be varied. 1004 Because one could be own fiber which the operator configure the MTU 1005 size as they like while others are third-party provided L2/L3 VPN 1006 lines which MTU size can't be controlled by the operators. 1008 The MTU between RAN and UPF can be discovered by offline means and 1009 the operator takes into account the MTU that is transferable on the 1010 radio interface and based on this the operator configures the right 1011 MTU to be used. That is then signaled to the UE either via PCO (for 1012 IPv4 case) or the IPv6 RA message (for IPv6 case). 1014 In addition, for cases that third-parties provide VPN lines, it would 1015 be recommended MTU size discovery for each data path and dynamic MTU 1016 size adjustment mechanisms, while GTP-U does not support those 1017 mechanisms. 1019 As the study item in 3GPP mentioned, IPv6 is preferable address 1020 family not only for UEs, but also for the UP transport, in terms of 1021 size of available address space to support dense and wide footprint 1022 of base stations. However it increases header size from 20bytes to 1023 40bytes compare to IPv4. It could be a problem if the MTU size is 1024 uncontrollable, or only limited MTU size available to carry committed 1025 PDU size on the user plane. 1027 The expected evaluation points from this aspect should be that the 1028 candidate protocols are able to dynamically adjust path MTU size with 1029 appropriate MTU size discovery mechanism. It also should be that how 1030 the candidate protocols leverage IPv6 to deal with header size 1031 increasing. 1033 5.4. Data Path Management 1035 As Section 4.2 described, the 5G systems allows user plane that 1036 flexible UPF selection, multiple anchor UPFs, and no limit on how 1037 many UPFs chained for the data path of the PDU session. UPF 1038 deployments in the field will thereby be distributed to be able to 1039 optimize the data path based on various logics and service scenarios. 1041 That powerful user plane capability could affect data path management 1042 complicated and difficult to be managed through the control plane, or 1043 operation support systems (OSS). Perhaps it could be the case where 1044 the UP protocol nature is P2P and it only supports per session base 1045 data path handling. 1047 Because it increases data path states by number of sessions, and 1048 number of endpoints of UPFs that makes data path handling much hectic 1049 and the control plane tend to be overloaded by not only usual 1050 attach/detach/hand-over operations, but also existing session 1051 manipulation triggered by UPF and transport nodes/paths restoration, 1052 etc., 1054 The expected evaluation points from this aspect should be that how 1055 much the candidate protocols can reduce data path management loads 1056 both on the control plane NFs and UPFs compare to the per session 1057 based handling for P2P paths. It could possibly include N3 and N6 in 1058 addition to N9 while it supports flexible user plane data path 1059 optimizations for some example scenarios. 1061 5.5. QoS Control 1063 The QoS model is based on QoS flows to which QFI indicates in the 5G 1064 system that allows multiple QoS flows are aggregated into a single 1065 PDU session. So that it is given that the UP protocol should convey 1066 QFIs for a PDU session and the UPF needs to lookup them. It makes 1067 sure that reflects QoS policy in the 5G system to corresponding 1068 forwarding policy in the user plane IP transports. 1070 The expected evaluation points from this aspect should be whether the 1071 candidate protocols can provide stable ID space for QFI which 1072 shouldn't be a big deal since QFI just requires 6-bits space. 1074 As we pointed out in Section 3.2, the lookup process could impact UPF 1075 performance if the QFI container position in the header is 1076 unpredictable. It could happen many times along the path because the 1077 each UPFs should do it again and again in case that various different 1078 QoS policies are deployed in the networks under the UP as we 1079 discussed in Section 5.3. 1081 As [TS.29.281-3GPP] updated in version 15.3.0, it is recommended that 1082 the first extension header is the PDU session container in which QFI 1083 is present. 1085 5.6. Traffic Detection and Flow Handling 1087 As described in Section 4.1.1, UPF need to detect traffic flow 1088 specified by SMF within a PDU session, and enforce some processes to 1089 the PDU based on the pre-configured policy rule. 1091 As similar with QoS flow lookup described in Section 5.5, UPFs along 1092 the path are repeatedly detecting an specified traffic flow in inner 1093 PDU. It could increase redundant flow detection load on every UPFs 1094 that could be avoided if the upstream UPF put some identifier which 1095 abstracts the detected flow into the packets. It enables following 1096 UPFs just find the ID to detect the indicated flow from the packet. 1098 The expected evaluation points from this aspect should be whether the 1099 candidate protocols can provide means to reduce that redundant flow 1100 detection that could be enough bits space on stable ID space to put 1101 abstracted detected flow identifier. 1103 5.7. Supporting Network Slicing Diversity 1105 To embody network slicing, it is expected that various means should 1106 be available in case by case, or operator by operator, for their 5G 1107 systems while it follows the fundamental slicing concept, as 1108 described in Section 4.1. 1110 As [TS.28.530-3GPP] described in section 4, UP underlay transport 1111 networks and UPFs are shared by network slices. The data model 1112 defined in [TS.29.510-3GPP] allows that a Network Instance, a UPF and 1113 its interfaces can belong to multiple slices as same as other type of 1114 NFs. UP endpoint IP prefix/address of an interface can also be 1115 shared with multiple interfaces on the UPF as the model doesn't make 1116 them slice unique. 1118 The assumed slice operation in 5G architecture is that UPFs connect 1119 to each other through direct (virtual) link as Section 4.1 describes 1120 that UPFs compose a network slice on an UP. So IP routing and 1121 transport system underneath the UP are not visible from the 5G 1122 system. However some means need to indicate a slice on the shared 1123 underlying networks of the UP over the wire. 1125 That's just one way for network slicing, but it would help to reduce 1126 the operational burden. Even it depends on each operator's policy, 1127 sharing network instances, UPFs, and the interfaces among slices 1128 makes operators relax and not to be much hustled on slice lifecycle 1129 management., such as create, update, and delete operations for 1130 slices. 1132 By the way, the 3GPP specifications for slice lifecycle managements 1133 is described in the relevant documents: [TS.28.531-3GPP], 1134 [TS.28.532-3GPP], and [TS.28.533-3GPP]. 1136 It could also make sense in case that each network slice requires 1137 different forwarding policies in the middle of the path. Some 1138 identifier in the packets for a slice could be a glue between UP path 1139 and its underlying transport networks. For example, if a slice 1140 requires certain level of latency with dedicated route, traffic 1141 engineering (TE) embodies appropriate forwarding policy through the 1142 underlay transport network. 1144 The expected evaluation points from this aspect should be whether the 1145 candidate protocols can support to indicate a network slice in the UP 1146 packets that could be enough bits space on stable ID space to put 1147 slice identifier for the slice, or the forwarding policy within the 1148 slice. Since 5G control plane is not designed to handle transport 1149 resources, such as VLAN, MPLS Label, Tunnel ID except GTP-U, less 1150 impact to the control plane protocol and the APIs should be much 1151 preferable. 1153 6. Conclusion 1155 We analyzed the 3GPP specifications of the 5G architecture in terms 1156 of user plane and the current protocol adopted to the user plane. 1157 After the analysis work, we believe that the results described in 1158 this document shows that we reach at certain level of understanding 1159 on the 5G systems and ready to provide our inputs to 3GPP. 1161 We clarified GTP-U through the analysis and listed observed 1162 characteristics in Section 3.6. We also clarified the architectural 1163 requirements for UP protocol described in Section 4.2. 1165 As we identified some potential gaps between the current UP protocol 1166 and the architectural requirements even for Release 15, it is worth 1167 to study possible candidate UP protocols for the 5G system including 1168 current one. Our conclusion here is that we suggest the UP protocol 1169 study work in 3GPP takes into account the evaluation aspects 1170 described in Section 5. 1172 7. Security Consideration 1174 TBD 1176 8. Acknowledgement 1178 The authors would like to thank Tom Herbert, Takashi Ito, John Leddy, 1179 Pablo Camarillo, Daisuke Yokota, Satoshi Watanabe, Koji Tsubouchi and 1180 Miya Kohno for their detailed reviews, comments, and contributions. 1182 A special thank you goes to Arashmid Akhavain for his technical 1183 review and feedback. 1185 Lastly, the authors would like to thank 3GPP CT WG4 folks for their 1186 review and feedback. 1188 9. Informative References 1190 [C4-185491-3GPP] 1191 3rd Generation Partnership Project (3GPP), "LS OUT on User 1192 Plane Analysis", July 2018, 1193 . 1196 [CP-173160-3GPP] 1197 3rd Generation Partnership Project (3GPP), "New Study Item 1198 on User Plane Protocol in 5GC", December 2017, 1199 . 1202 [CP-180116-3GPP] 1203 3rd Generation Partnership Project (3GPP), "LS on user 1204 plane protocol study", March 2018, 1205 . 1208 [I-D.bogineni-dmm-optimized-mobile-user-plane] 1209 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 1210 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 1211 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 1212 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 1213 optimized-mobile-user-plane-01 (work in progress), June 1214 2018. 1216 [IAB-Statement] 1217 Internet Architecture Board (IAB), "IAB Statement on 1218 IPv6", November 2016, 1219 . 1221 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1222 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1223 December 1998, . 1225 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1226 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1227 DOI 10.17487/RFC4861, September 2007, 1228 . 1230 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1231 "IPv6 Flow Label Specification", RFC 6437, 1232 DOI 10.17487/RFC6437, November 2011, 1233 . 1235 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1236 for Equal Cost Multipath Routing and Link Aggregation in 1237 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1238 . 1240 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1241 UDP Checksums for Tunneled Packets", RFC 6935, 1242 DOI 10.17487/RFC6935, April 2013, 1243 . 1245 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1246 (IPv6) Specification", STD 86, RFC 8200, 1247 DOI 10.17487/RFC8200, July 2017, 1248 . 1250 [TR.29.891-3GPP] 1251 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 1252 (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December 1253 2017, . 1256 [TS.22.261-3GPP] 1257 3rd Generation Partnership Project (3GPP), "3GPP TS 22.261 1258 (V15.4.0): Service requirements for 5G system stage 1", 1259 March 2018, . 1262 [TS.23.060-3GPP] 1263 3rd Generation Partnership Project (3GPP), "3GPP TS 23.060 1264 (V15.3.0): General Packet Radio Service (GPRS); Service 1265 description; Stage 2", June 2018, 1266 . 1269 [TS.23.501-3GPP] 1270 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 1271 (V15.1.0): System Architecture for 5G System; Stage 2", 1272 March 2018, . 1275 [TS.23.502-3GPP] 1276 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 1277 (V15.1.0): Procedures for 5G System; Stage 2", March 2018, 1278 . 1281 [TS.23.503-3GPP] 1282 3rd Generation Partnership Project (3GPP), "3GPP TS 23.503 1283 (V15.1.0): Policy and Charging Control System for 5G 1284 Framework; Stage 2", March 2018, . 1287 [TS.28.530-3GPP] 1288 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1289 (V1.0.0): Management and orchestration of networks and 1290 network slicing; Concepts, use cases and requirements 1291 (work in progress)", June 2018, 1292 . 1295 [TS.28.531-3GPP] 1296 3rd Generation Partnership Project (3GPP), "3GPP TS 28.531 1297 (V1.0.0): Management and orchestration of networks and 1298 network slicing; Provisioning; Stage 1 (Release 15)", June 1299 2018, . 1302 [TS.28.532-3GPP] 1303 3rd Generation Partnership Project (3GPP), "3GPP TS 28.532 1304 (V0.3.0): Management and orchestration of networks and 1305 network slicing; Provisioning; Stage 2 and stage 3 1306 (Release 15)", June 2018, . 1309 [TS.28.533-3GPP] 1310 3rd Generation Partnership Project (3GPP), "3GPP TS 28.533 1311 (V0.3.0): Management and orchestration of networks and 1312 network slicing; Management and orchestration architecture 1313 (Release 15)", June 2018, . 1316 [TS.29.244-3GPP] 1317 3rd Generation Partnership Project (3GPP), "3GPP TS 29.244 1318 (V15.1.0): Interface between the Control Plane and the 1319 User Plane Nodes; Stage 3", March 2018, 1320 . 1323 [TS.29.274-3GPP] 1324 3rd Generation Partnership Project (3GPP), "3GPP TS 29.274 1325 (V15.4.0): 3GPP Evolved Packet System (EPS); Evolved 1326 General Packet Radio Service (GPRS) Tunneling Protocol for 1327 Control plane (GTPv2-C); Stage 3", June 2018, 1328 . 1331 [TS.29.281-3GPP] 1332 3rd Generation Partnership Project (3GPP), "3GPP TS 29.281 1333 (V15.3.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", 1334 June 2018, . 1337 [TS.29.510-3GPP] 1338 3rd Generation Partnership Project (3GPP), "3GPP TS 29.510 1339 (V15.0.0): 5G System; Network Function Repository 1340 Services; Stage 3", June 2018, . 1343 [TS.29.561-3GPP] 1344 3rd Generation Partnership Project (3GPP), "3GPP TS 29.561 1345 (V15.0.0): 5G System; Interworking between 5G Network and 1346 external Data Networks; Stage 3", June 2018, 1347 . 1350 [TS.38.300-3GPP] 1351 3rd Generation Partnership Project (3GPP), "3GPP TS 38.300 1352 (v15.1.0): NR and NG-RAN Overall Description; Stage 2", 1353 March 2018, . 1356 [TS.38.401-3GPP] 1357 3rd Generation Partnership Project (3GPP), "3GPP TS 38.401 1358 (v15.1.0): NG-RAN; Architecture Description", March 2018, 1359 . 1362 [TS.38.415-3GPP] 1363 3rd Generation Partnership Project (3GPP), "3GPP TS 38.415 1364 (v1.0.0): NG-RAN; PDU Session User Plane protocol (work in 1365 progress)", June 2018, . 1368 Authors' Addresses 1370 Shunsuke Homma 1371 NTT 1373 Email: homma.shunsuke@lab.ntt.co.jp 1375 Takuya Miyasaka 1376 KDDI Research 1378 Email: ta-miyasaka@kddi-research.jp 1380 Satoru Matsushima 1381 SoftBank 1383 Email: satoru.matsushima@g.softbank.co.jp 1385 Daniel Voyer 1386 Bell Canada 1388 Email: daniel.voyer@bell.ca