idnits 2.17.00 (12 Aug 2021) /tmp/idnits64647/draft-ietf-dmm-5g-uplane-analysis-04.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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == 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 (November 2, 2020) is 558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GTP-U-1' is mentioned on line 685, but not defined == Missing Reference: 'GTP-U-2' is mentioned on line 687, but not defined == Missing Reference: 'GTP-U-3' is mentioned on line 689, but not defined == Missing Reference: 'Uplink' is mentioned on line 305, but not defined == Missing Reference: 'Downlink' is mentioned on line 325, but not defined == Missing Reference: 'GTP-U-4' is mentioned on line 692, but not defined == Missing Reference: 'GTP-U-5' is mentioned on line 695, but not defined == Missing Reference: 'GTP-U-6' is mentioned on line 698, but not defined == Missing Reference: 'GTP-U-7' is mentioned on line 701, but not defined == Missing Reference: 'GTP-U-8' is mentioned on line 705, but not defined == Missing Reference: 'GTP-U-9' is mentioned on line 708, but not defined == Missing Reference: 'GTP-U-10' is mentioned on line 710, but not defined == Missing Reference: 'GTP-U-11' is mentioned on line 712, but not defined == Missing Reference: 'GTP-U-12' is mentioned on line 714, but not defined == Missing Reference: 'GTP-U-13' is mentioned on line 717, but not defined == Missing Reference: 'GTP-U-14' is mentioned on line 719, but not defined == Missing Reference: 'F-SEID' is mentioned on line 928, but not defined == Missing Reference: 'PDR-ID' is mentioned on line 932, but not defined == Missing Reference: 'FAR-ID' is mentioned on line 938, but not defined == Missing Reference: 'QER-ID' is mentioned on line 951, but not defined == Missing Reference: 'URR-ID' is mentioned on line 961, but not defined == Missing Reference: 'BAR-ID' is mentioned on line 968, but not defined == Missing Reference: 'Traffic-Endpoint-ID' is mentioned on line 971, but not defined == Unused Reference: 'RFC6935' is defined on line 1757, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 26 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: May 6, 2021 KDDI Research 6 S. Matsushima 7 SoftBank 8 D. Voyer 9 Bell Canada 10 November 2, 2020 12 User Plane Protocol and Architectural Analysis on 3GPP 5G System 13 draft-ietf-dmm-5g-uplane-analysis-04 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 May 6, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . 4 61 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 62 3. GTP-U Specification and Observation . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 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.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19 73 4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21 74 4.2. Architectural Requirements for User Plane Protocols . 22 75 4.2.1. Fundamental Functionalities . . . . . . . . . . . . . 23 76 4.2.2. Supporting 5G Services . . . . . . . . . . . . . . . 26 77 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 32 78 5.1. Supporting PDU Session Type Variations . . . . . . . . . 32 79 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 33 80 5.3. Supporting Transport Variations . . . . . . . . . . . . . 33 81 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 34 82 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 35 83 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 35 84 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 35 85 5.8. Reliable Communication support . . . . . . . . . . . . . 36 86 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 37 87 7. Security Consideration . . . . . . . . . . . . . . . . . . . 37 88 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 37 89 9. Informative References . . . . . . . . . . . . . . . . . . . 38 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 92 1. Introduction 94 This document analyzes the mobile user plane protocol and the 95 architecture specified by 3GPP 5G documents. The background of the 96 work is that 3GPP requests through a liaison statement that the IETF 97 to provide any information for the User Plane Protocol Study work in 98 3GPP [CP-180116-3GPP]. Justification and the objectives of the study 99 can be found from [CP-173160-3GPP]. 101 We understand that the current user plane protocol, GTP-U 102 [TS.29.281-3GPP], has been well developed in 3GPP, and deployed very 103 widely as the successor of legacy network technologies, such as TDM 104 circuit, or ATM virtual circuit. That GTP-U success seems based on 105 IP overlay technique that is dramatically scaled compare to the 106 previous ones because it successfully isolates mobile session states 107 from the user plane transport network. 109 Even after that big success, it is definitely worth that 3GPP has 110 decided to revisit user plane which seems to response to IPv6 111 deployment growth and [IAB-Statement] that encourages the industry to 112 develop strategies for IPv6-only operation. It can be seen from the 113 justification section in [CP-173160-3GPP]. 115 The study description mentions that the study would be based on 116 Release 16 requirement while only Release 15 specifications has been 117 available now. However we believe that to provide adequate 118 information for 3GPP, we need to clearly understand what the current 119 user plane protocol is in Release 15, and architectural requirements 120 for the user plane. 122 As the liaison statement indicates 3GPP specifications related to 123 user plane, those documents should be a good start point to clarify 124 their specifications and to extract protocol and architectural 125 requirements from them. 127 1.1. Current Status of Mobile User Plane for 5G 129 3GPP RAN and CT4 decided to use GTP-U as the 5G user plane 130 encapsulation protocol over N3 and N9 that respectively described 131 in[TS.38.300-3GPP] and [TR.29.891-3GPP]. N3 is an interface between 132 RAN and UPF and N9 is an interface between different UPFs 133 [TS.23.501-3GPP]. 135 In [TR.29.891-3GPP], it captured user plane requirements and 136 concluded that GTP-U is adopted for the user plane protocol. It 137 seems that GTP-U was only option to be chose and it focused on how to 138 carry 5G specific QoS information between UPF and access networks. 139 That is described in section 5.2 and 11.2 of [TR.29.891-3GPP]. 140 Another aspects of user plane requirements couldn't be found. 142 1.2. Our Way of Analysis Work 144 First, we analyze [TS.29.281-3GPP] for clarifying it as the current 145 user plane protocol in the 5G system. [TR.29.891-3GPP] describes how 146 GTP-U is selected as the user plane protocol for 5G in 3GPP. 147 Clarified characteristics of the protocol are described in Section 3. 149 Then, to clarify what are required to the user plane protocol in 150 architecture level, we analyze [TS.23.501-3GPP] as the 5G system 151 architecture specification. [TS.23.502-3GPP] is the specification of 152 system procedures that helps us to understand how the system works in 153 the architecture. [TS.23.503-3GPP] is also helpful to find the role 154 of user plane in the architecture that influences user plane 155 protocol. Extracted architectural requirements are described in 156 Section 4. 158 Based on the results of above, we identify some aspects where there 159 might be gap between the current user plane protocol and the 160 architectural requirements on which [TR.29.891-3GPP] does not 161 discuss. That aspects are discussed Section 5. That's what we 162 intend to be as a part of the reply to 3GPP. CT4 WG in 3GPP can 163 utilize it as an input to evaluate the candidate protocols for user 164 plane to the 5G system including the current protocol. 166 2. Terms and Abbreviations 168 This section describes terms of functions and interfaces relevant to 169 user plane protocol which we extract from the 3GPP specifications 170 since this document focuses on user plane. 172 In those specifications, there are so many unique terms and 173 abbreviations in the 3GPP context which IETF community seems not 174 familiar with. We will try to bring those terms with brief 175 explanations to make sure common understanding for them. 177 GTP: GPRS Tunneling Protocol 179 GTP-U: User Plane part of GTP 181 Noted that GTP version 1 (GTPv1-U) is the user-plane protocol 182 specification which is defined in [TS.29.281-3GPP]. Unless there 183 is no specific annotation, we refer GTP-U to GTPv1-U in this 184 document. 186 PDU: Protocol Data Unit of end-to-end user protocol packet. 188 Noted that the PDU in 3GPP includes IP header in case that PDU 189 session type is IPv4 or IPv6. In contrast, in IETF it is supposed 190 that PDU is the payload of IP packet so that it doesn't include 191 IP/TCP/UDP header in end-to-end. 193 T-PDU: Transport PDU. 195 G-PDU: GTP encapsulated user Plane Data Unit. 197 GTP-U has above two notions on PDU. T-PDU is a PDU that GTP-U 198 header encapsulates. G-PDU is a PDU that includes GTP-U header. 199 A G-PDU may include a T-PDU. G-PDU can be sent without T-PDU, but 200 just with extension headers or TLV elements. It can be used for 201 OAM related operations. 203 PDU session: Association between the UE and a Data Network that 204 provides a PDU connectivity service. 206 Data Network (DN): The network of operator services, Internet access 207 or 3rd party services. 209 User Plane (UP): Encapsulating user end-to-end PDU. 211 In fact, we can't find exact text that defines UP in the 212 architecture specification. However when we see the figure 213 8.3.1-1 in [TS.23.501-3GPP], we specify UP as the layer right 214 under PDU that directly encapsulates PDU. Underneath layers of UP 215 are UP transport, such as IP/UDP, L2 and L1. 217 However 3GPP is consistent to use the term user plane when they 218 indicate that layer. In IETF, we can see the terms data plane, or 219 forwarding plane as variations which often makes us tend to be 220 confused in terminology. 222 QFI: QoS Flow Identifier 224 UPF: User Plane Function 226 SMF: Session Management Function 228 SMF is a control plane function which provides session management 229 service that handling PDU sessions in the control plane. SMF 230 allocates tunnels corresponding to the PDU sessions and configure 231 the tunnel to the UPF. 233 PFCP: Packet Forwarding Control Protocol 235 PFCP is used on N4 interface between SMF and UPF to configure the 236 rules of packet detection, forwarding action, QoS enforcement, 237 usage report and buffering for each PDU session. 239 PDR: Packet Detection Rule 241 FAR: Fowarding Action Rule 243 RAN: Radio Access Network 245 Noted that UP protocol provides a RAN to connect UPF. But the UP 246 protocol is not appeared on the air in the RAN. 248 3. GTP-U Specification and Observation 250 In this section we analyze the GTP-U specification and summarize 251 clarified characteristic of GTP-U to see if GTP-U meets the 252 requirements of 5G architecture for user plane in later section. 254 3.1. GTP-U Tunnel 256 GTP-U is a tunneling protocol between given a pair of GTP-U tunnel 257 endpoint nodes and encapsulates T-PDU from/to UE on top of IP/UDP. A 258 Tunnel Endpoint Identifier (TEID) value allocated on each end point 259 indicates which tunnel a particular T-PDU belongs to. 261 The receiving endpoint individually allocate a TEID and the sender 262 tunnel endpoint node encapsulates the IP packet from/to UE with the 263 TEID which is present in GTP-U header on top of IPv4 or IPv6, and 264 UDP. That is described in section 4.2.1 of [TS.29.281-3GPP]. 266 [GTP-U-1]: GTP-U is an unidirectional Point-to-Point tunneling 267 protocol. 269 Figure 1 shows an example of GTP-U protocol stack for uplink (UL) and 270 downlink (DL) traffic flow. Two GTP-U tunnels are required to form 271 one bi-directional tunnel. 273 UL: From RAN to UPF1 (TEID=1), and from UPF1 to UPF2 (TEID=2) 275 DL: From UPF2 to UPF1 (TEID=3), and from UPF1 to RAN (TEID=4) 277 In 5GS, GTP-U tunnel is established at following interfaces to 278 provide PDU Session between UE and 5GC. 280 N3: Between RAN and UPF 282 N9: Between different UPFs 284 GTP-U allows one tunnel endpoint node to send out a G-PDU to be 285 received by multiple tunnel endpoints by utilizing IP multicast 286 capability of underlay IP networks. That is described in section 287 4.2.6 of [TS.29.281-3GPP]. It looks GTP-U has Point-to-Multipoint 288 (P2MP) tunneling capability. The P2MP tunneling is used for MBMS 289 (Multimedia Broadcast Multicast Service) through GTP-U tunnel. 291 [GTP-U-2]: GTP-U supports Point-to-Multipoint tunneling. 293 UDP is utilized for GTP-U encapsulation and UDP destination port is 294 2152 which is assigned by IANA. Allocation of UDP source port 295 depends on sender tunnel endpoint node and GTP-U supports dynamic 296 allocation of UDP source port for load balancing objective. The 297 specification of this dynamic allocation is described in section 298 4.4.2.0 of [TS.29.281-3GPP], however specific procedure, e.g., 299 5-tuple hashing, is not described in the document and depends on the 300 implementation of GTP-U tunnel endpoint node. 302 [GTP-U-3]: GTP-U supports load balancing by using dynamic UDP source 303 port allocation. 305 [Uplink] 306 .- .-+--------+ - - - - +--------+ - - - - +--------+ 307 | | |Payload | |Payload | |Payload | 308 | PDU < +--------+ +--------+ +--------+ 309 |(3GPP)| |Inner IP| |Inner IP| |Inner IP| 310 | '-+--------+ - - - - +--------+ - - - - +--------+ 311 | | GTP-U | | GTP-U | | L2 | 312 | |(TEID=1)| |(TEID=2)| +--------+ 313 GTP< +--------+ +--------+ | L1 | 314 Pkt | | UDP | | UDP | +--------+ 315 | +--------+ +--------+ 316 | |Outer IP| |Outer IP| 317 | +--------+ +--------+ 318 | | L2 | | L2 | 319 | +--------+ +--------+ 320 | | L1 | | L1 | 321 '- +--------+ - - - - +--------+ 323 ================ Traffic Direction =======================> 325 [Downlink] 326 .- .-+--------+ - - - - +--------+ - - - - +--------+ 327 | | |Payload | |Payload | |Payload | 328 | PDU < +--------+ +--------+ +--------+ 329 |(3GPP)| |Inner IP| |Inner IP| |Inner IP| 330 | '-+--------+ - - - - +--------+ - - - - +--------+ 331 | | GTP-U | | GTP-U | | L2 | 332 | |(TEID=4)| |(TEID=3)| +--------+ 333 GTP< +--------+ +--------+ | L1 | 334 Pkt | | UDP | | UDP | +--------+ 335 | +--------+ +--------+ 336 | |Outer IP| |Outer IP| 337 | +--------+ +--------+ 338 | | L2 | | L2 | 339 | +--------+ +--------+ 340 | | L1 | | L1 | 341 '- +--------+ - - - - +--------+ 343 <=============== Traffic Direction ======================== 345 +-----+ N3 +------+ N9 +------+ N6 346 -----+ RAN +-----------+ UPF1 +------------+ UPF2 +---------- 347 +-----+ +------+ +------+ 349 Figure 1: Protocol Stack by GTPv1-U for Uplink and Downlink Traffic 350 Flow 352 IPv6 flow label [RFC6437] is also candidate method for load balancing 353 especially for IP-in-IPv6 tunnel [RFC6438] like GTP-U. GTP-U also 354 supports dynamic allocation of IPv6 flow label for load balancing 355 objective. The specification of this dynamic allocation is described 356 in section 4.4.2.0 of [TS.29.281-3GPP], however specific procedure, 357 e.g., 5-tuple hashing, is not described in the document and depends 358 on the implementation of GTP-U tunnel endpoint node. 360 [GTP-U-4]: GTP-U supports load balancing by using dynamic IPv6 flow 361 label allocation. 363 GTP-U supports both IPv4 and IPv6 as the underlying network layer 364 protocol. From Release 16, GTP-U updates their reference to IPv6 365 specification from [RFC2460] to [RFC8200] which allows UDP zero 366 checksum for the protocols that use UDP as a tunnel encapsulation, 367 such as GTP-U. As a result of the update, GTP-U over IPv6 also 368 supports the UDP zero checksum if the sender and receiver tunnel 369 endpoint node support the UDP zero checksum, which is described in 370 section 4.4.2.0 of [TS.29.281-3GPP]. 372 [GTP-U-5]: GTP-U supports UDP zero checksum. 374 "Unnecessary fragmentation should be avoided" is recommended and to 375 avoid the fragmentation operator should configure MTU size at UE 376 [TS.29.281-3GPP]. However, there's no reference and specification of 377 Path MTU Discovery for IPv6 transport. If encapsulated IPv6 packet 378 is too big on a network link between tunnel endpoint nodes, UE may 379 not receive ICMPv6 Packet Too Big message and causes Path MTU 380 Discovery black hole. 382 [GTP-U-6]: GTP-U does not support to response ICMP PTB for Path MTU 383 Discovery. 385 Section 9.3 of [TS.23.060-3GPP] specifies advertisement of inner IPv6 386 link MTU size for UE by IPv6 RA message [RFC4861]. However, this 387 document doesn't specify a procedure to measure MTU size in mobile 388 network system and mobile network operator need to calculate MTU size 389 for UE like Annex C of [TS.23.060-3GPP]. If link MTU of a router in 390 a transport network is accidentally modified, UE cannot detect the 391 event and send packet with initial MTU size, which may cause service 392 disruption due to MTU exceed in the router link. 394 3.2. GTP-U Header Format 396 Figure 2 shows general and mandatory GTP-U header and Figure 3 shows 397 extension GTP-U header. 399 [GTP-U-7]: GTP-U supports sequence number option in the header, but 400 it is not recommended to be used by almost GTP-U 401 entities. 403 GTP-U header has Sequence Number field to reorder incoming packets 404 based on the sequence number. If Sequence Number Flag is set to '1' 405 it indicates that Sequence Number Filed exists in GTP-U header and 406 examined at receiving tunnel endpoint node to reorder incoming 407 packets. However, the sequence number flag is set to '1' only for 408 RAT HO procedure and sequence number flag should be set to '0' in 409 normal case. Therefore, in normal case receiver tunnel endpoint node 410 doesn't examine sequence number and can't reorder GTP-U packets based 411 on the sequence number. This specification is described in section 412 5.1 of [TS.29.281-3GPP]. In 3GPP, sequential delivery is required 413 only during handover procedure and is used by only RAN entities. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Ver |P|R|E|S|N| Message Type | Length | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Tunnel Endpoint Identifier | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Sequence Number | N-PDU Number | Next-Ext-Hdr | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 2: GTP-U Header 427 o Ver: Version field (Set to '1') 429 o P: Protocol Type (Set to '1') 431 o R: Reserved bit (Set to '0') 433 o E: Extension Header Flag (Set to '1' if extension header exists) 435 o S: Sequence Number Flag (Set to '1' if sequence number exists) 437 o N: N-PDU Number Flag (Set to '1' if N-PDU number exists) 439 o Message Type: Indicates the type of GTP-U message 441 o Length: Indicates the length in octets of the payload 443 o Tunnel Endpoint Identifier (TEID) 445 o Sequence Number: Indicates increasing sequence number for T-PDUs 446 is transmitted via GTP-U tunnels 448 o N-PDU Number: It is used only for inter SGSN, 2G-3G handover case, 449 etc. 451 o Next-Ext-Hdr: Indicates following extension header type 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Ext-Hdr Length| | 457 +-+-+-+-+-+-+-+-+ | 458 | Extension Header Content | 459 . . 460 . +-+-+-+-+-+-+-+-+ 461 | | Next-Ext-Hdr | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 3: Extension GTP-U Header 466 o Ext-Hdr Length: Represents the length of the Extension header in 467 units of 4 octets 469 o Extension Header Content: Contains 3GPP related information 471 o Next-Ext-Hdr: Indicates following extension header type 473 The extension GTP-U header is a variable-length and extendable header 474 and contains 3GPP specific information. Following list summarizes 475 every extension header which is used for user plane protocol. These 476 extension headers are defined in [TS.29.281-3GPP]. In this list 477 Next-Ext-Hdr is represented in binary. 479 o No more extension headers (Next-Ext-Hdr = 00000000) 481 o Service Class Indicator (Next-Ext-Hdr = 00100000) 483 o UDP Port (Next-Ext-Hdr = 01000000) 485 o RAN Container (Next-Ext-Hdr = 10000001) 487 o Long PDCP PDU Number (Next-Ext-Hdr = 10000010) 489 o Xw RAN Container (Next-Ext-Hdr = 10000011) 491 o NR RAN Container (Next-Ext-Hdr = 10000100) 493 o PDU Session Container (Next-Ext-Hdr = 10000101) 495 o PDCP PDU Number (Next-Ext-Hdr = 11000000) 497 [GTP-U-8]: GTP-U supports carrying QoS Identifiers transparently for 498 Access Networks in an extension header. 500 GTP-U is designed to carry 3GPP specific information with extension 501 headers. 3GPP creates PDU Session Container extension header for 502 NGRAN of 5G to carry QFI. It is described in section 5.2.2.7 of 503 [TS.29.281-3GPP]. 505 [GTP-U-9]: GTP-U supports DSCP marking based on the QFI. 507 DSCP marking on outer IPv4 or IPv6 shall be set by sender tunnel 508 endpoint node based on the QFI. This specification is described in 509 section 4.4.1 of [TS.29.281-3GPP]. 511 [GTP-U-10]: GTP-U does not specify extension header order. 513 In general, multiple GTP-U extension headers are able to contained in 514 one GTP-U packet and the order of those extension headers is not 515 specified by [TS.29.281-3GPP]. Thereby the receiving endpoint can't 516 predict exact position where the target extension headers are. This 517 could impact on header lookup performance on the node. 519 As for PDU Session Container extension header, there is a note in 520 [TS.29.281-3GPP] as "For a G-PDU with several Extension Headers, the 521 PDU Session Container should be the first Extension Header". This 522 note was added at the version 15.3.0 of [TS.29.281-3GPP] which is 523 published on June 2018 in order to accelerate the processing of GTP-U 524 packet at UPF and RAN. It is only one rule regarding the extension 525 header order. 527 [GTP-U-11]: GTP-U does not support to indicate next protocol type. 529 When Next-Ext-Hdr is set to 0x00 it indicates that no more extension 530 headers follow. As GTP is designed to indicate protocol types for 531 T-PDU by control-plane signaling, GTP-U doesn't have Next-Protocol- 532 Header field to indicate the T-PDU type in the header. 534 3.3. Control Plane Protocol for GTP-U 536 Control plane protocol for GTP-U signals TEID between tunnel endpoint 537 nodes. GTPv2-C [TS.29.274-3GPP] is the original control plane 538 protocol tied with GTP-U in previous generation architectures before 539 CUPS (Control and User Plane Separation). 541 3GPP decided to use extended PFCP (Packet Forwarding Control 542 Protocol) [TS.29.244-3GPP] for N4 interface [TR.29.891-3GPP] to 543 signal tunnel states from SMF to UPF. 545 3.4. GTP-U message 547 GTP-U supports in-band messaging to signal OAM. Currently GTP-U 548 supports following messages [TS.29.281-3GPP]. 550 o Echo Request 552 o Echo Response 554 o Supported Extension Headers Notification 556 o Error Indication 558 o End Marker 560 [GTP-U-12]: GTP-U supports active OAM as a path management message 561 "Echo Request/Response". 563 A GTP-U tunnel endpoint node sends a Echo Request message to another 564 nodes for keep-alive and received node sends a Echo Response message 565 to sender node as acknowledgment. Echo Request message and Echo 566 Response message are described in section 7.2.1 and section 7.2.2 of 567 [TS.29.281-3GPP] respectively. [TR.29.891-3GPP] recommends not to 568 send Echo Request message more often than 60s on each path. 570 Supported Extension Headers Notification message indicates a list of 571 supported that tunnel endpoint node can support. This message is 572 sent only in case a tunnel endpoint node receives GTP-U packet with 573 unsupported extension header. 575 [GTP-U-13]: GTP-U supports tunnel management messages "Error 576 Indication". 578 GTP-U has Error Indication message to notify that the receiving 579 endpoint discard packets of which no session exist to the sending 580 endpoint. Error Indication message is described in section 7.3.1 of 581 [TS.29.281-3GPP]. 583 [GTP-U-14]: GTP-U supports tunnel management messages "End Marker". 585 GTP-U has End Marker message to indicate the end of the payload 586 stream that needs to be sent on a GTP-U tunnel. End Marker message 587 is described in section 7.3.2 of [TS.29.281-3GPP]. 589 3.5. Packet Format 591 Figure 4 shows a packet format example of GTP-U over IPv6 that 592 carries an extension header for QFI and an IPv6 PDU. All values in 593 the example are illustration purpose only. The encoding of PDU 594 Session Container for QFI refers to [TS.38.415-3GPP]. 596 Outer IPv6 Header's DSCP value(EF) in Figure 4 is marked at sender 597 tunnel endpoint node based on QFI value which is contained in GTP-U 598 Extension Header (PDU Session Container). 600 0 1 2 3 601 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 602 Outer IPv6 Header 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 |Version| DSCP=EF | Flow Label | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | 609 + + 610 | | 611 + Source IPv6 Address + 612 | 2001:db8:1:1::1 | 613 + + 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | | 617 + + 618 | | 619 + Destination IPv6 Address + 620 | 2001:db8:1:2::1 | 621 + + 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Outer UDP Header 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Source Port = xxxx | Dest Port = 2152 | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | UDP Length | UDP Checksum (Non-zero) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 GTP-U header 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | 0x1 |1|0|1|0|0| 0xff | Length | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | TEID = 1654 | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Sequence Number = 0 |N-PDU Number=0 |NextExtHdr=0x85| 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 GTP-U Extension Header (PDU Session Container) 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | ExtHdrLen=2 |Type=0 |0|0| |0|0| QFI | PPI | Spare | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Padding |NextExtHdr=0x0 | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Inner IPv6 Header 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |Version| DSCP=0 | Flow Label | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Payload Length | NexttHdr | Hop Limit | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 + + 656 | | 657 + Source IPv6 Address + 658 | 2001:db8:2:1::1 | 659 + + 660 | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | 663 + + 664 | | 665 + Destination IPv6 Address + 666 | 2001:db8:3:1::1 | 667 + + 668 | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Payload 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | | 674 | | 675 . TCP/UDP/etc., Data . 676 . . 677 | | 678 | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 4: GTP-U Protocol Stack Example 683 3.6. Observations Summary 685 [GTP-U-1]: An unidirectional Point-to-Point tunneling protocol. 687 [GTP-U-2]: Supports Point-to-Multipoint tunneling. 689 [GTP-U-3]: Supports load balancing by using dynamic UDP port 690 allocation. 692 [GTP-U-4]: Does not support IPv6 flow label for load balancing in 693 case of IPv6 transport. 695 [GTP-U-5]: UDP zero checksum is not available in case of IPv6 696 transport. 698 [GTP-U-6]: Does not support to response ICMP PTB for Path MTU 699 Discovery. 701 [GTP-U-7]: Supports sequence number option and sequence number flag 702 in the header, but it is not recommended to be used by 703 almost GTP-U entities. 705 [GTP-U-8]: Supports carrying QoS Identifiers transparently for 706 Access Networks in extension headers. 708 [GTP-U-9]: Supports DSCP marking based on the QFI. 710 [GTP-U-10]: Does not specify the rule for the extension header order. 712 [GTP-U-11]: Does not support an indication of next-header type. 714 [GTP-U-12]: Supports active OAM as a path management message "Echo 715 Request/Response". 717 [GTP-U-13]: Supports tunnel management messages "Error Indication". 719 [GTP-U-14]: Supports tunnel management messages "End Marker". 721 4. 5GS Architectural Requirements for User Plane Protocols 723 4.1. Overview of 5G System Architecture 725 The 5G system is designed for applying to diverse devices and 726 services due to factors such as the diffusion of IoT devices, and the 727 UP protocol is required to have capabilities for satisfying their 728 requirements. 730 As a principle of the 5G system, User Plane (UP) functions are 731 separated from the Control Plane (CP) functions for allowing 732 independent scalability, evolution and flexible deployments. 734 Network slicing is also one of the fundamental concepts of the 5G 735 system, and it provides logical network separation. In terms of user 736 plane, multiple network slices can be comprised of UPFs on top of 737 same physical network resources. Allocated resources and structures 738 may be differentiated among the slices by which the required features 739 or capabilities. 741 The 3GPP 5G architecture [TS.23.501-3GPP] defines slice types which 742 are eMBB, URLLC and MIoT from Rel-15. In addition to that, V2X slice 743 type is defined from Rel-16. 745 The architecture overview is shown in Figure 5. The details of 746 functions are described in [TS.23.501-3GPP]. A UPF handles UP paths 747 on N3, N9 and N6 interface, and the setup is controlled by SMF via N4 748 interface. A UP path will be manipulated based on application 749 requirements for the PDU session corresponding to the path. An SMF 750 is also capable to receive information regarding routing path with 751 API from AF via NEF, PCF, and SMF. 753 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 754 |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | 755 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 756 Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf 757 ---+--------+--+-----+--+--------+--+-----+--------+- 758 Nausf| Namf| Nsmf| 759 +--+--+ +--+--+ +--+-------+ 760 |AUSR | | AMF | | SMF | 761 +-----+ ++-+--+ +--+-----+-+ 762 / | | \ 763 Control Plane N1/ |N2 |N4 \N4 764 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 765 User Plane / | | \ 766 +--++ +--+--+ N3 +--+--+ N9 +-+---+ N6 +-----+ 767 |UE +--+(R)AN+-----+ UPF +-----+ UPF +----+ DN | 768 +---+ +-----+ +--+--+ +-----+ +-----+ 769 |N6 770 +--+--+ 771 | DN | 772 +-----+ 774 Figure 5: 5GS Architecture and Service-based Interfaces 776 This document mainly focuses on requirements for N9 interface as 777 relevant to UP protocol of 5G system. 779 4.1.1. UPF Functionalities 781 UPF has a role to handle UP traffic, and provides functionalities to 782 look up user data traffic and enforce the appropriate policies to it. 784 The followings are defined as UPF functionalities defined in the 785 section 6.2.3 of [TS.23.501-3GPP] 787 o Anchor point for Intra-/Inter-RAT mobility (when applicable). 789 o External PDU Session point of interconnect to Data Network. 791 o Packet routing and forwarding (e.g. support of Uplink classifier 792 to route traffic flows to an instance of a data network, support 793 of Branching point to support multi-homed PDU Session). 795 o Packet inspection (e.g. Application detection based on service 796 data flow template and the optional PFDs received from the SMF in 797 addition). 799 o User Plane part of policy rule enforcement, e.g. Gating, 800 Redirection, Traffic steering). 802 o Lawful intercept (UP collection). 804 o Traffic usage reporting. 806 o QoS handling for user plane, e.g. UL/DL rate enforcement, 807 Reflective QoS marking in DL. 809 o Uplink Traffic verification (SDF to QoS Flow mapping). 811 o Transport level packet marking in the uplink and downlink. 813 o Downlink packet buffering and downlink data notification 814 triggering. 816 o Sending and forwarding of one or more "end marker" to the source 817 NG-RAN node. 819 o ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the 820 Ethernet PDUs. 822 o Packet duplication in downlink direction and elimination in uplink 823 direction in UP protocol layer. 825 o TSN Translator functionality to hold and forward user plane 826 packets for de-jittering when 5G System is integrated as a bridge 827 with the TSN network. 829 4.1.2. UP Traffic Detection 831 The traffic detection is described in the section 5.8.2.4 of 832 [TS.23.501-3GPP]. In 3GPP UP packet forwarding model, UPF detects UP 833 traffic flow which belong to a N4 session configured by SMF. 835 The protocol of N4 interface, PFCP, brings a set of traffic detection 836 information from SMF to UPF as Packet Detection Information (PDI) in 837 a PDR to establish/modify the N4 PFCP session. It is defined in 838 section 7.5.2.2 of [TS.29.244-3GPP]. 840 Combination of the following information is used for the traffic 841 detection: 843 o For IPv4 or IPv6 PDU Session type 845 * CN tunnel info (Tunnel ID and the endpoint IP address of 5G 846 Core) 848 * Network instance 850 * QFI 852 * IP Packet Filter Set 854 * Application Identifier: The Application ID is an index to a set 855 of application detection rules configured in UPF 857 o For Ethernet PDU Session type 859 * CN tunnel info(Tunnel ID and the endpoint IP address of 5G 860 Core) 862 * Network instance 864 * QFI 866 * Ethernet Packet Filter Set 868 It is noted that Network Instance is encoded as Octet String in PFCP, 869 and is NOT appeared in UP packet over the wire. It is expected like 870 an attribute of the receiving IP interface of the UPF. It supports 871 UPF to be able to connect to different IP domains of N3, N9 or N6, 872 which run each independent policy in routing and addressing. The UPF 873 detects traffic flow with Network Instance which the receiving 874 interface attributed to. 876 The IP Packet Filter Set and Ethernet Packet Filter Set defined in 877 clause 5.7.6 of [TS.23.501-3GPP] are following: 879 o IP Packet Filter Set: 881 * Source/destination IP address or IPv6 prefix 883 * Source/destination port number 885 * Protocol ID of the protocol above IP/Next header type 887 * Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask. 889 * Flow Label (IPv6) 891 * Security parameter index 893 * Packet filter direction 895 o Ethernet Packet Filter Set: 897 * Source/destination MAC address 899 * Ethertype as defined in IEEE 802.3 901 * Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) VID 902 fields as defined in IEEE 802.1Q 904 * Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/DEI 905 fields as defined in IEEE 802.1Q 907 * IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 908 payload 910 * Packet filter direction 912 4.1.3. User Plane Configuration 914 User Plane configuration on a UPF is managed by an SMF through PFCP 915 [TS.29.244-3GPP]. The SMF establishes PFCP sessions on the UPF per 916 PDU session basis. The UPF maintains each configured PFCP session 917 states during the sessions exist. 919 A PFCP session consists of the rules of packet detection, forwarding 920 action, QoS enforcement, usage reporting and buffering action. 921 Figure 6 depicts overview of the PFCP session state structure. 923 The listed information in Section 4.1.2 indicates packet detection 924 information of packet detection rule for that the rest of related 925 rules within the PFCP session to be derived. All rules are per 926 session unique and no rules are shared with other sessions. 928 PFCP-Session* [F-SEID] 929 +- F-SEID(Full Qualified Session Endpoint ID) uint64 930 +- PDU-Session-Type [IPv4|IPv6|IPv4v6|Ether|Unstrct] 931 +- DNN(Data Network Name) 932 +- PDR(Packet Detection Rule)* [PDR-ID] 933 | +- PDR-ID uint16 934 | +- PDI (Packet Detection Information) 935 | | +- Traffic-Endpoint-ID? -> Traffic-Endpoint-ID reference 936 | | +- .... 937 | +- FAR/URR/QER-ID -> FAR/URR/QER-ID references 938 +- FAR(Forwarding Action Rule)* [FAR-ID] 939 | +- FAR-ID uint32 940 | +- Forwarding-Parameters 941 | | +- Network-Instance? Octet String 942 | | +- Outer-Header-Creation 943 | | | +- Outer-Hdr-Creation-Desc [GTPoUDP/IPv4|IPv6, etc.,] 944 | | | +- TEID, outer IP-Address for N3/N9 945 | | | +- C/S-TAG, UDP Port-number for N6 946 | | +- Forwarding-Policy-ID? Octet String 947 | | +- .... 948 | +- Duplicating-Parameters 949 | | +- .... 950 | +- BAR-ID? -> BAR-ID reference 951 +- QER(QoS Enforcement Rule)* [QER-ID] 952 | +- QER-ID uint32 953 | +- MBR(Maximum Bit Rate) 954 | | +- UL/DL-MBR? bitrate_in_kbps (0..10000000) 955 | +- GBR(Guaranteed Bit Rate) 956 | | +- UL/DL-GBR? bitrate_in_kbps (0..10000000) 957 | +- QoS-flow-identifier? QFI value(6-bits) 958 | +- Reflective-QoS? boolean 959 | +- Paging-Policy-Indicator? PPI value(3-bits) 960 | +- .... 961 +- URR(Usage Reporting Rule)* [URR-ID] 962 | +- URR-ID uint32 963 | +- Measurement-Method, Period, Reporting-Triggers? 964 | +- Volume/Event/Time Threshold, Quota? 965 | +- Quota-Holding-Time? 966 | +- FAR-ID for Quota action? -> FAR-ID reference 967 | +- .... 968 +- BAR(Buffering Action Rule)* [BAR-ID] 969 | +- BAR-ID uint8 970 | +- Suggested-Buffering-Packets-Count 971 +- Traffic-Endpoint* [Traffic-Endpoint-ID] 972 +- Traffic-Endpoint-ID uint8 973 +- TEID, Tunnle IP Address, UE Address...? 975 Figure 6: User Plane Configuration Model 977 4.2. Architectural Requirements for User Plane Protocols 979 This section lists the requirements for the UP protocol on the 5G 980 system. The requirements are picked up from [TS.23.501-3GPP]. In 981 addition, some of service requirements described in [TS.22.261-3GPP] 982 are referred to clarify the originations of architectural 983 requirements. 985 According to [TS.23.501-3GPP], the specifications potentially have 986 assumptions that the UP protocol is a tunnel representing a single 987 TEID between a pair of UPFs and it is corresponding to a single PDU 988 session. In short, the UP protocol is a tunnel and it is assumed to 989 be managed under per PDU session handling. Also, it should be a 990 stateful tunnel in the UPFs along with the PDU session. 992 4.2.1. Fundamental Functionalities 994 The fundamental requirements for UP protocols are described below: 996 ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU 998 The 5G system defines four types of PDU session as IPv4, IPv6, 999 Ethernet, and Unstructured. Therefore, UP protocol must support to 1000 convey all of these PDU session types. This is described in 1001 [TS.23.501-3GPP]. 1003 Note: In TS 23.501 v15.2.0, IPv4v6 is added as a PDU session type. 1005 ARCH-Req-2: Supporting IP connectivity for N3, N6, and N9 interfaces 1007 The 5G system requires IP connectivity for N3, N6, and N9 interfaces. 1008 The IP connectivity is assumed that it comprises of IP routing and 1009 L1/L2 transport networks which are outside of 3GPP specifications. 1011 It is desirable that the IP connectivity built on IPv6 networks when 1012 it comes to address space for end-to-end user plane coverage. But it 1013 is expected to take certain time. During the IPv6 networks are not 1014 deployed for all the coverage, UP protocol should support RANs and 1015 DNs running on IPv4 transport connect to UPF running on IPv6 1016 transport. 1018 Furthermore, on N6 interface, point-to-point tunneling based on UDP/ 1019 IPv6 may be used to deliver unstructured PDU type data. Then, the 1020 content information of the PDU may be mapped into UDP port number, 1021 and the UDP port numbers is pre-configured in the UPF and DN. This 1022 is described in the section 9.2 of [TS.29.561-3GPP]. 1024 ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a 1025 single PDU session 1027 The 5G system allows to deploy multiple UPFs as anchors for a single 1028 PDU session, and supports multihoming of a single PDU session for 1029 such anchor UPFs. 1031 Multihoming is provided with Branching Point (BP). BP provides 1032 forwarding of UL traffic towards the different PDU Session Anchors 1033 based on the source IPv6 prefixes and merge of DL traffic to the UE. 1034 IPv6 multihoming only means multiple source IPv6 prefixes are used 1035 for a PDU session. It is identical to one classified as scenario 1 1036 in [RFC7157]. 1038 Up link classifier (UL CL) is to forward uplink packets to multiple 1039 anchor UPFs based on the destination IP of the T-PDU regardless of 1040 the source IP address. Noted that single source IP address/prefix 1041 PDU session is not defined as multihoming PDU session in 5GCS even 1042 though a PDU session has multiple anchor UPFs. 1044 On UL side, P2P tunnels are established per destination anchor UPFs 1045 basis from one UL CL UPF to the anchor UPFs for the PDU session. 1047 On DL side, one single multipoint-to-point (MP2P) tunnel exists from 1048 the source anchor UPFs to the destination BP UPF for the PDU session. 1049 It means that the paths from the anchor UPFs are merged into just one 1050 tunnel state at the destination BP UPF. 1052 Multiple P2P paths on DL could also be used for multihoming. However 1053 it should be the multiple PDU sessions multihoming case where the 1054 destination gNB or UPF needs to maintain multiple tunnel states under 1055 the one PDU session to one UP tunnel architectural principle. It 1056 causes increase of load on tunnel states management in UPF due to 1057 increment of the anchor UPF for the PDU session. 1059 However, P2P tunneling could increase explosively the number of 1060 states in UPF as the anchor UPF/DN incremented to the PDU session. 1061 Thereby single PDU session multihoming with MP2P path should be a 1062 better option for multihoming in terms of reducing total number of 1063 tunnel states. 1065 SSC mode 3 for session continuity in hand-over case uses a single PDU 1066 multihoming with BP to make sure make-before-break. It is described 1067 in the section 5.6.4 and 5.6.9 of [TS.23.501-3GPP]. 1069 Multihoming is also assumed to be used for edge computing scenario. 1070 Edge computing enables some services to be hosted close to the UE's 1071 access point of attachment, and achieves an efficient service 1072 delivery through the reduced end-to-end latency and load on the 1073 transport network. In edge computing, local user's traffic is routed 1074 or steered to application in the local DN by UPF. This refers the 1075 section 5.13 of [TS.23.501-3GPP]. 1077 ARCH-Req-4: Supporting flexible UPF selection for PDU 1079 The appropriate UPFs are selected for a PDU session based on 1080 parameters and information such as UPF's dynamic load or UE location 1081 information. Examples of parameters and information are described in 1082 the section 6.3.3 of [TS.23.501-3GPP]. 1084 This means that it is possible to make routing on user plane more 1085 efficient in the 5GS. For example, in case that UPFs are distributed 1086 geographically, decision of the destination UPF based on locations of 1087 end hosts (e.g., UE or NF in DN) enables to forward PDUs with a route 1088 connecting between UPFs nearby the hosts directly. This would be 1089 useful UE-to-UE or UE-to-local_DN communication, and such usage is 1090 described in the section 6.5 of [TS.22.261-3GPP]. 1092 The 5GS allows operators to select parameters used for UPF selection. 1093 (In other words, any specific schemes on UPF selection are not 1094 defined in the current 3GPP documents.) 1096 ARCH-Req-5: No limitation for number of UPFs in a data path 1098 The number of UPF in the data path is not constrained by 3GPP 1099 specifications. This specification is described in the section 8.3.1 1100 of [TS.23.501-3GPP]. 1102 Putting multiple UPFs, which provides specific function, in a data 1103 path enables flexible function deployment to make sure load 1104 distribution optimizations, etc. 1106 Meanwhile, each UPF in a data path shall be controlled by an SMF via 1107 N4 interface. Thus putting an excess of UPF for data paths might 1108 cause increase of load of an SMF. Pragmatically, the number of UPF 1109 put in a data path is one or two (e.g., for MEC or roaming cases), 1110 and, at most, it would be three (e.g., for case where UE moves during 1111 a session). 1113 It is expected that multiple UPFs with per session tunnel handling 1114 for a PDU session becomes complicated task more and more for a SMF by 1115 increasing number of UPFs. 1117 ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated 1118 with QFI into a PDU Session 1120 Against to the previous generation, 5G enables UPF to multiplex QoS 1121 Flows, equivalent with IP-CAN bearers in the previous generation, 1122 into one single PDU session. That means that a single tunnel 1123 includes multiple QFIs contrast to just one QoS Flow (a bearer) to 1124 one tunnel before 5G. 1126 In even the 5GS, each flow is forwarded based on the appropriate QoS 1127 rules. QoS rules are configured by SMF as QoS profiles to UP 1128 components and these components perform QoS controls to PDUs based on 1129 rules. In downlink, a UPF pushes QFI into an extension header, and 1130 transmits the PDU to RAN or another UPF. Then, such UPF may perform 1131 transport level QoS packet marking (e.g., DSCP marking in the outer 1132 header). In uplink, each UE obtains the QoS rule from SMF, and 1133 transmit PDUs with QFI containing the QoS rules to the RAN. The 1134 following RAN and UPFs perform enforcement of QoS control and 1135 charging based on the QFI. 1137 This specification is described in 5.7.1 of [TS.23.501-3GPP]. 1139 ARCH-Req-7: Supporting network slicing 1141 The 5GS fundamentally supports network slicing for provision the 1142 appropriate end-to-end communication to various services. In the 1143 relevant documents (e.g., [TS.23.501-3GPP], [TS.28.530-3GPP]), a 1144 network slice is defined as virtual network and it is structured with 1145 5GS NF instances, such as SMF, UPF including IP transport 1146 connectivity between RANs and DNS. Each network slice is independent 1147 and its user plane (including network functions and links) should be 1148 noninteractive against the others. 1150 The 5G architecture specification has been updated with that Network 1151 Instance is defined as the glue of network slice between 5G slice and 1152 corresponding IP transport slice in addition to the original role of 1153 separating IP domains, which is described in Section 4.1.2. 1155 It has been appeared from version 15.2.0 of [TS.23.501-3GPP] in 1156 section 5.6.12. 1158 UP underlay transport networks and UPFs may be shared by 5G slices, 1159 as described in section 4 of [TS.28.530-3GPP]. The data model 1160 defined in [TS.29.510-3GPP] allows that a Network Instance, a UPF and 1161 its interfaces can belong to multiple slices as same as other type of 1162 NFs. UP endpoint IP prefix/address of an interface can also be 1163 shared with multiple interfaces on the UPF as the model doesn't make 1164 them slice unique. 1166 The slice lifecycle managements is described in the relevant 1167 documents: [TS.28.531-3GPP], [TS.28.532-3GPP], and [TS.28.533-3GPP]. 1169 ARCH-Req-8: End Marker support 1171 The construction of End Marker packets specified in [TS.23.501-3GPP] 1172 may either be done in the CP/UP functions for indicating the end of 1173 the payload stream on a given UP tunnel. PDU packets arrive after an 1174 End Marker message on the tunnel may be silently discarded. For 1175 example, End Maker is used for handover procedures, and it can 1176 prevent reordering of arriving packets due to switch of anchor UPFs. 1178 4.2.2. Supporting 5G Services 1180 In the release 16 [TS.23.501-3GPP], some specifications have been 1181 added to support 5G specific services and communications. This 1182 section describes overviews of the specifications relevant to use 1183 plane functionalities. 1185 ARCHI-Req-9: URLLC Support 1187 The 5GS supports Ultra-Reliable Low Latency Communication (URLLC) for 1188 mission critical applications. The User Plane features are described 1189 below. 1191 o Redundant UP transmission for URLLC 1193 The 5G is expected to support services which are latency sensitive 1194 and require high reliability. Communication to realize such services 1195 is called Ultra-Reliable and Low-Latency Communication or URLLC. In 1196 URLLC, redundancy of QoS flows is required for providing highly 1197 reliable communication. For instance, a set of UP NFs (e.g., UPF or 1198 gNB) and interfaces between UE and DN are redundant, and packets are 1199 replicated and forwarded via each route. UEs and DN support dual 1200 connectivity and drop duplicated received packets. The scheme of 1201 packet dropping at UE is out of responsibility of 3GPP. The overview 1202 is shown in Figure 7. 1204 ---+-----------+----------+--- 1205 Namf| Nsmf| Nsmf| 1206 +--+--+ +--+--+ +--+--+ 1207 | AMF | | SMF1| | SMF3| 1208 +-+---+ +--+--+ +-+---+ 1209 / / / 1210 N2/ N4/ N4/ 1211 / / / 1212 +----++ N3 +--+---+ / N6 +----+ 1213 |M-RAN+--------+ UPF1 +--------------+ | 1214 ++-+--+ +-+--+-+ / | | 1215 / | | | / | | 1216 +----+ / | +--+ / | | 1217 | UE +< |Xn N9 / | DN | 1218 +----+ \ | / | | 1219 \ | / | | 1220 ++-+--+ N3 +----+-+ N6 | | 1221 |S-RAN+--------+ UPF2 +--------------+ | 1222 +-----+ +-+--+-+ +----+ 1223 | | 1224 +--+ 1225 N9 1226 *Legends 1227 M-RAN: Master RAN 1228 S-RAN: Secondary RAN 1230 Figure 7: Redundant UP paths using dual connectivity 1232 Otherwise, in case that RAN nodes and UPFs have enough reliability 1233 and they are not redundant by dual devices, reliable connectivity of 1234 QoS flows is provided by dual N3 tunnels between RAN and UPFs. Such 1235 tunnels are treated as individual ones, but they have the same 1236 sequence number. UP NFs identifies the duplication of PDU packets 1237 based on sequence number content in the UP tunnel headers. For 1238 uplink packets, a RAN node replicates each packet from a UE. An 1239 anchor UPF receives the duplicated packets, and drops ones which 1240 reach later in each duplicated packet pare. On the other hand, for 1241 downlink packets, a UPF replicates packets received from DN, and a 1242 RAN node drops the duplicated packets as well. The overviews of the 1243 ways are shown in Figure 8. 1245 ----+-----------+-----------+--- 1246 Namf| Nsmf| Npcf| 1247 +--+--+ +--+--+ +--+--+ 1248 | AMF | | SMF | | PCF | 1249 +-+---+ +--+--+ +-----+ 1250 / | 1251 N2/ N4| 1252 / N3 Tunnel1 | 1253 +----+ +--+--+__________+--+--+ N6 +----+ 1254 | UE +----+ RAN |__________| UPF |-----+ DN | 1255 +----+ +-----+ +-----+ +----+ 1256 N3 Tunnel2 1258 Figure 8: Redundant UP transmission with two N3 tunnels 1260 In addition, there is a case that two intermediate UPFs (I-UPFs) 1261 between anchor UPF and RAN are used to support the redundant 1262 transmission based on two N3 and N9 tunnels between single anchor UPF 1263 and RAN node. The RAN node and anchor UPF support the packet 1264 replication and dropping of duplicated packets as described above. 1265 As described above, anchor UPF and RAN node detect packet duplication 1266 with sequence number of UP tunnels, and thus I-UPFs would forward the 1267 packets with the same sequence number on N3 and N9 tunnels. The 1268 overview is shown in Figure 9. 1270 ----+-------------+--------------+--- 1271 Namf| Nsmf| Npcf| 1272 +--+--+ +---+---+ +--+--+ 1273 | AMF | | SMF + | PCF | 1274 +--+--+ +-+-+-+-+ +-----+ 1275 / | | | 1276 N2 / N4| | +----------------+ 1277 / | | | 1278 / N3 Tunnel1 +-+-+---+ N9 Tunnel1 | 1279 / +-----+I-UPF1 +----+ | 1280 +----+ +--+--+______| +-------+ |______+--+--+ N6 +----+ 1281 | UE +---+ RAN |______ | ______| UPF +-----+ DN | 1282 +----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+ 1283 +-----+I-UPF2 +----+ 1284 N3 Tunnel2 +-------+ N9 Tunnel2 1286 Figure 9: Redundant UP transmission with two I-UPF and N3/N9 tunnels 1288 o Supporting QoS Monitoring for URLLC 1290 QoS monitoring is also required for URLLC. It means that the user 1291 plane should be able to measure packet delay between anchor UPF and 1292 UE. The measurement would be in various granularities, in the basis 1293 of per QoS Flow per UE, or per UP path for example. 1295 To help the measurement at anchor UPF and RAN, UP protocol requires 1296 to have capability to convey necessary information to do that; such 1297 as time information at sending or reception of a measurement packet. 1298 That information should exist in per F-TEID and QFI basis which 1299 indicates QoS Flow of the packet. UP protocol should also be able to 1300 indicate which packets include the corresponding information for each 1301 measurement. 1303 The QoS monitoring requirement has been appeared in section 5.33.3 of 1304 [TS.23.501-3GPP] from Rel-16, version 16.2.0. 1306 ARCHI-Req-10: Time Sensitive Communication Support 1308 The 5GS supports Time Sensitive Communications (TSC) for realtime 1309 applications, and it can be integrated transparently as a bridge in 1310 an IEEE 802.1 TSN network. For TSN time synchronization, the E2E 5GS 1311 can be considered as a "time-aware system (ref [IEEE-Std-802.1AS])". 1312 The TSN Translators (TTs) at the edges of the 5GS need to support the 1313 [IEEE-Std-802.1AS] operations. For instance, UE, gNB, NW-TT 1314 (Network-side TSN Translator) and DS-TTs (Device-side TSN 1315 Translators) are synchronized with the Grandmaster (GM) located in 1316 the 5GS. In addition, the TTs fulfill some functions related to 1317 [IEEE-Std-802.1AS] (e.g., gPTP support, timestamping, rateRatio, 1318 etc.). An overview of the 5G and TSN GM clock distribution model via 1319 the 5GS is shown in Figure 10. 1321 <-TSN-D-> <---- 5G Time Domain ----> <-TSN-D-> 1323 +-----+ +------+ 1324 |5G GM| |TSN GM| 1325 +-----+ +------+ 1326 |M |M 1327 | +---+-----+ VS 1328 +----+ VS ,--------. | |NW-TT| ,-----. 1329 |End | +-----+ +--+ Uu +---+ / PTP \ | +-----+ / TSN \ 1330 |Sta.|<==|DS-TT|<-|UE|<----|gNB|--|Compatible|-->|UPF |<==|Working| 1331 +----+S M+-----+ +--+S M+---+M \ 5G TN / S+---------+S M\ Domain/ 1332 `--------' `-----' 1334 Legend 1335 TSN-D : Non-3GPP TSN Domain 1336 TN : Transport Network 1337 End Sta.: End Station 1338 <-- : 5GS timing direction 1339 <== : TSN timing direction 1340 M : Master 1341 S : Slave 1343 Figure 10: An overview of the 5G and TSN GM clock distribution model 1345 In this model, two independent synchronizations are processing, and 1346 gNB only needs to be synchronized to the 5G GM clock. To enable TSN 1347 domain synchronization, the 5GS calculates and adds the measured 1348 residence time between the DS-TT and NW-TT into the Correction Field 1349 (CF) of the synchronization packet of the TSN working domain. The 1350 details are described in section 5.27 in [TS.23.501-3GPP]. 1352 From this feature, UP functions and protocol are needed to support 1353 TSN specified in [IEEE-Std-802.1AS] . 1355 ARCHI-Req-11: Cellular IoT Support 1357 For supporting Cellular IoT (CIoT) (ref. [TS.22.261-3GPP]), 1358 optimizations of functionalities of the 5GS is needed. CIoT is in 1359 earlier 3GPP release also referred to as Machine Type Communication 1360 (MTC). Some of CIoT functionalities relevant to user plane are 1361 described in this section. The details of CIoT support is described 1362 in section 5.31 in [TS.23.501-3GPP]. 1364 o Non-IP Data Delivery (NIDD) 1366 The 5GS may support Non-IP Data Delivery (NIDD) to handle Mobile 1367 Originated (MO) and Mobile Terminated (MT) communication for 1368 unstructured data. Thus, User Plane Protocol should be conveyable 1369 such unstructured data units. 1371 o Reliable Data Service (RDS) 1373 Reliable Data Service (RDS) may be used for a PDU session of 1374 unstructured type. The service provides a mechanism for the NEF or 1375 UPF to determine if the data was successfully delivered to the UE and 1376 for the UE to determine if the data was successfully delivered to the 1377 NEF or UPF. 1379 When the service is enabled, a protocol that uses a packet header to 1380 identify the requested acknowledgement from peered end-point may be 1381 used between end-points of the PDU session. In addition, port 1382 numbers in the header are used to identify the applications on the 1383 originator and receiver. The UE, NEF and the UPF may support 1384 reservation of the source and destination port numbers for their use 1385 and subsequent release of the reserved port numbers. 1387 Therefore, UP protocol is required to have fields for containing 1388 information to determine normality of unstructured PDU sessions and 1389 used applications. 1391 o High Latency Communication 1393 Functions for High Latency Communication may be used to handle mobile 1394 terminated (MT) communication with UEs being unreachable while using 1395 power saving functions. "High latency" refers to the initial 1396 response time before normal exchange of packets is established. High 1397 latency communication is supported by extended buffering of downlink 1398 data in the UPF, SMF or NEF when a UE is using power saving functions 1399 in CM-IDL state and the UE is not reachable. 1401 o Small Data Rate Control 1403 The SMF may apply Small Data Rate Control for PDU sessions based on, 1404 for example, operator policy, DNN, S-NSSAI, RAT type etc. The rate 1405 control may indicate following parameters in each of uplink and 1406 downlink. 1408 - an integer number of packets per time unit 1410 - an integer number of additional allowed exception report packets 1411 per time unit once the rate control limit has been reached 1412 The UE shall comply with this uplink rate control instruction. If 1413 the UE exceeds the uplink number of packet per time, the UE may still 1414 send uplink exception report if allowed and the number exception 1415 reports per time unit has not been exceeded. 1417 For the UPF and NEF, Small Data Rate Control is based on a maximum 1418 allowed rate per direction. The UPF or NEF may enforce the uplink 1419 rate by discarding or delaying packets that exceed the maximum 1420 allowed rate. The UPF or NEF shall enforce the downlink rate by 1421 discarding or delaying packets that exceed the downlink part of the 1422 maximum allowed rate. 1424 o User Plane CIoT 5GS Optimisation 1426 User Plane CIoT 5GS Optimization enables transfer of user plane data 1427 from CM-IDLE without the need for using the Service Request procedure 1428 by negotiation between UE and AMF in advance. In case that there are 1429 many devices being CM-IDLE state for long time, it would be better 1430 that User Plane Protocol i s session less. 1432 5. Evaluation Aspects 1434 This section provides UP protocol evaluation aspects that are mainly 1435 we derived from the architectural requirements described in 1436 Section 4. Those aspects are not prioritized by the order here. 1437 Expected deployment scenarios explain the evaluations purpose in the 1438 corresponding aspects. 1440 As we were noticed that the gaps between GTP-U specifications and 5G 1441 architectural requirements through the analysis, those each gap are 1442 briefly described in the evaluation aspect associated to it. 1444 Since it is obvious that 5G system should be able to interwork with 1445 existing previous generation based systems, any aspects from 1446 coexisting and interworking point of view are not particularly 1447 articulated here. It may be described in a next version. 1449 5.1. Supporting PDU Session Type Variations 1451 Given that UP protocol is required to support all PDU session types: 1452 IPv4, IPv6, Ethernet, and Unstructured. However, it is expected that 1453 some deployment cases allow candidate protocol to adopt only one or 1454 few PDU session type(s) for simplicity of operations. As we can 1455 expect that IPv4 connectivity services will be available through 1456 IPv6-only PDU session that enabled by bunch of IPv6 transition 1457 solutions already available in the field. 1459 For this, the expected evaluation points from this aspect should be 1460 whether there is substitutional means to cover other PDU session 1461 types. And how much it makes simple the system than deploying 1462 original PDU session types. 1464 5.2. Nature of Data Path 1466 As it is described in Section 4.2, the single PDU session multi- 1467 homing case requires multipoint-to-point (MP2P) data path. It should 1468 be much scalable than multi-homing with multiple PDU sessions because 1469 number of required path states in the UPFs are reduced as closed to 1470 egress endpoint. Against that point-to-point (P2P) protocol requires 1471 same number of states in each UPF throughout the path, and it could 1472 increase explosively the load on management of tunnel states. 1474 From this point of view, the expected evaluation points from this 1475 aspect is whether the nature of candidate UP protocols are to utilize 1476 MP2P data path. Supporting MP2P data path by GTP-U could be a gap 1477 since GTP-U is a point-to-point tunneling protocol as it is described 1478 in Section 3. 1480 Noted that 3GPP CT WG4 pointed out GTP-U was already required to 1481 allow one single tunnel endpoint to receive packets from multiple 1482 source endpoints ([C4-185491-3GPP]). It was an architectural 1483 requirement of 3GPP system from a previous generation. It means that 1484 MP2P data path requirement for UP protocol has been existed before 1485 the 5G system. 1487 5.3. Supporting Transport Variations 1489 The 5G system will be expected that the new radio spectrums in high 1490 frequency bands require operators to deploy their base stations much 1491 dense for much wider areas compare to previous generation footprints. 1492 To make sure that density and coverage, all available types of 1493 transport in the field must be employed between RAN to UPF, or UPF to 1494 UPF. 1496 It is also expected that MTU size of each transport could be varied. 1497 Because one could be own fiber which the operator configure the MTU 1498 size as they like while others are third-party provided L2/L3 VPN 1499 lines which MTU size can't be controlled by the operators. 1501 The MTU between RAN and UPF can be discovered by offline means and 1502 the operator takes into account the MTU that is transferable on the 1503 radio interface and based on this the operator configures the right 1504 MTU to be used. That is then signaled to the UE either via PCO (for 1505 IPv4 case) or the IPv6 RA message (for IPv6 case). 1507 In addition, for cases that third-parties provide VPN lines, it would 1508 be recommended MTU size discovery for each data path and dynamic MTU 1509 size adjustment mechanisms, while GTP-U does not support those 1510 mechanisms. 1512 As the study item in 3GPP mentioned, IPv6 is preferable address 1513 family not only for UEs, but also for the UP transport, in terms of 1514 size of available address space to support dense and wide footprint 1515 of base stations. However it increases header size from 20bytes to 1516 40bytes compare to IPv4. It could be a problem if the MTU size is 1517 uncontrollable, or only limited MTU size available to carry committed 1518 PDU size on the user plane. 1520 The expected evaluation points from this aspect should be that the 1521 candidate protocols are able to dynamically adjust path MTU size with 1522 appropriate MTU size discovery mechanism. It also should be that how 1523 the candidate protocols leverage IPv6 to deal with header size 1524 increasing. 1526 5.4. Data Path Management 1528 As Section 4.2 described, the 5G systems allows user plane that 1529 flexible UPF selection, multiple anchor UPFs, and no limit on how 1530 many UPFs chained for the data path of the PDU session. UPF 1531 deployments in the field will thereby be distributed to be able to 1532 optimize the data path based on various logics and service scenarios. 1534 That powerful user plane capability could make data path management 1535 through the control plane, or operation support systems (OSS) be 1536 complicated and difficult. Perhaps it could be the case where the UP 1537 protocol nature is P2P and it only supports per session base data 1538 path handling. Therefore it would be better that UP protocol could 1539 support to aggregate several PDU sessions into a tunnel or shall be a 1540 session-less tunnel. 1542 Because it increases data path states by number of sessions, and 1543 number of endpoints of UPFs that makes data path handling much hectic 1544 and the control plane tend to be overloaded by not only usual 1545 attach/detach/hand-over operations, but also existing session 1546 manipulation triggered by UPF and transport nodes/paths restoration, 1547 etc., 1549 The expected evaluation points from this aspect should be that how 1550 much the candidate protocols can reduce data path management loads 1551 both on the control plane NFs and UPFs compare to the per session 1552 based handling for P2P paths. It could possibly include N3 and N6 in 1553 addition to N9 while it supports flexible user plane data path 1554 optimizations for some example scenarios. 1556 5.5. QoS Control 1558 The QoS model is based on QoS flows to which QFI indicates in the 5G 1559 system that allows multiple QoS flows are aggregated into a single 1560 PDU session. So that it is given that the UP protocol should convey 1561 QFIs for a PDU session and the UPF needs to lookup them. It makes 1562 sure that reflects QoS policy in the 5G system to corresponding 1563 forwarding policy in the user plane IP transports. 1565 The expected evaluation points from this aspect should be whether the 1566 candidate protocols can provide stable ID space for QFI which 1567 shouldn't be a big deal since QFI just requires 6-bits space. 1569 As we pointed out in Section 3.2, the lookup process could impact UPF 1570 performance if the QFI container position in the header is 1571 unpredictable. It could happen many times along the path because the 1572 each UPFs should do it again and again in case that various different 1573 QoS policies are deployed in the networks under the UP as we 1574 discussed in Section 5.3. 1576 As [TS.29.281-3GPP] updated in version 15.3.0, it is recommended that 1577 the first extension header is the PDU session container in which QFI 1578 is present. 1580 5.6. Traffic Detection and Flow Handling 1582 As described in Section 4.1.1, UPF need to detect traffic flow 1583 specified by SMF within a PDU session, and enforce some processes to 1584 the PDU based on the pre-configured policy rule. 1586 As similar with QoS flow lookup described in Section 5.5, UPFs along 1587 the path are repeatedly detecting an specified traffic flow in inner 1588 PDU. It could increase redundant flow detection load on every UPFs 1589 that could be avoided if the upstream UPF put some identifier which 1590 abstracts the detected flow into the packets. It enables following 1591 UPFs just find the ID to detect the indicated flow from the packet. 1593 The expected evaluation points from this aspect should be whether the 1594 candidate protocols can provide means to reduce that redundant flow 1595 detection that could be enough bits space on stable ID space to put 1596 abstracted detected flow identifier. 1598 5.7. Supporting Network Slicing Diversity 1600 Network Instance has been defined as the glue of network slice 1601 between 5G and IP transport in addition to IP domain separation, as 1602 described in Section 4.1.2. It is expected that SMF is able to 1603 configure UPF to send UP packet to corresponding transport slice by 1604 indicating Network Instance in FAR so that UPF can determine outgoing 1605 interface for the UP packet. 1607 It is assumed that IP transport networks are Network Instance 1608 agnostic, i.e., transport slices are independently instantiated and 1609 not bound to specific IP address space in the 5GC, for preventing 1610 increase of routing table size. 1612 As a transport slice may be shared with multiple IP domains, Network 1613 Instance could be instantiated for all combination of IP domains and 1614 transport slice. To indicate those combination in UP packet over the 1615 wire, the 5G architecture expects VPN solutions as described in 1616 section 5.6.12 of [TS.23.501-3GPP]. 1618 Binding Network Instance with corresponding VPN would be varied per 1619 VPN solutions and FAR is not able to do. Hence it is out of scope of 1620 3GPP and it may be covered by IETF, or other SDOs. 1622 Apart from binding, if it is the case where MPLS based VPNs, such as 1623 [RFC4364] and [RFC4664] are expected as the existing VPN solution 1624 which bound to Network Instance, there are some avaiable deployment 1625 options, such as 1). PE router integrates UPF, 2). CE router 1626 integrates UPF, 3). UPF connects to the VPN behind the CE router. 1628 Option 1 could work since all legacy MPLS or Segment Routing 1629 [RFC8402] based solution are available for both VPN and transport 1630 slicing at the UPF integrated PE router. However it is hard to 1631 expect it in multi-vendor deployment case, where the PE routers 1632 providing vendor is different from the vendor who provides UPFs, for 1633 example. 1635 Option 2 and 3 are expected as IP domain separation, but it is hard 1636 to see that it is able to indicate transport slice in addition to the 1637 IP domain. Other L2 and tunneling solutions should be same with 1638 those options. 1640 The expected evaluation points from this aspect should be whether the 1641 candidate protocols can contain forwarding information associated to 1642 the assigned IP domain and transport slice for all possible 1643 deployment cases. 1645 5.8. Reliable Communication support 1647 As Section 4.2 described, more than two UP paths are required for a 1648 QoS flow of a PDU session between the anchor UPF and gNB. Those UP 1649 paths are to convey redundant duplicated packets. 1651 To support reliable communication with above requirements, UPF and 1652 gNB must replicate the sending UP packets and eliminate the received 1653 duplicated UP packets. Not to mention that UP protocol should be 1654 able to make sure that the paths are not in fate sharing, the UP 1655 packet must have sequence number to indicate duplicate packets per 1656 QoS flow basis. 1658 The expected evaluation points from this aspect should be whether the 1659 candidate protocols can indicate packet sequence and diversed paths 1660 in the context of QoS flow, not in UP tunnel context. The packet 1661 sequence information should be transparent through I-UPF(s) exist in 1662 the middle of the path even in case that the UP tunnels are 1663 terminated at the I-UPF(s). 1665 6. Conclusion 1667 We analyzed the 3GPP specifications of the 5G architecture in terms 1668 of user plane and the current protocol adopted to the user plane. 1669 After the analysis work, we believe that the results described in 1670 this document shows that we reach at certain level of understanding 1671 on the 5G systems and ready to provide our inputs to 3GPP. 1673 We clarified GTP-U through the analysis and listed observed 1674 characteristics in Section 3.6. We also clarified the architectural 1675 requirements for UP protocol described in Section 4.2. 1677 Our conclusion here is that it is hopefull if the evaluation aspects 1678 described in Section 5 help for the study progress. It is worth to 1679 study possible candidate UP protocols for the 5G system including 1680 current one based from the aspects. 1682 7. Security Consideration 1684 TBD 1686 8. Acknowledgement 1688 The authors would like to thank Tom Herbert, Takashi Ito, John Leddy, 1689 Pablo Camarillo, Daisuke Yokota, Satoshi Watanabe, Koji Tsubouchi and 1690 Miya Kohno for their detailed reviews, comments, and contributions. 1692 A special thank you goes to Arashmid Akhavain for his technical 1693 review and feedback. 1695 Lastly, the authors would like to thank 3GPP CT WG4 folks for their 1696 review and feedback. 1698 9. Informative References 1700 [C4-185491-3GPP] 1701 3rd Generation Partnership Project (3GPP), "LS OUT on User 1702 Plane Analysis", July 2018, 1703 . 1706 [CP-173160-3GPP] 1707 3rd Generation Partnership Project (3GPP), "New Study Item 1708 on User Plane Protocol in 5GC", December 2017, 1709 . 1712 [CP-180116-3GPP] 1713 3rd Generation Partnership Project (3GPP), "LS on user 1714 plane protocol study", March 2018, 1715 . 1718 [IAB-Statement] 1719 Internet Architecture Board (IAB), "IAB Statement on 1720 IPv6", November 2016, 1721 . 1723 [IEEE-Std-802.1AS] 1724 Institute of Electrical and Electronics Engineers (IEEE), 1725 "Timing and Synchronization for Time-Sensitive 1726 Applications in Bridged Local Area Networks", March 2011, 1727 . 1729 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1730 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1731 December 1998, . 1733 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1734 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1735 2006, . 1737 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1738 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1739 DOI 10.17487/RFC4664, September 2006, 1740 . 1742 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1743 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1744 DOI 10.17487/RFC4861, September 2007, 1745 . 1747 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1748 "IPv6 Flow Label Specification", RFC 6437, 1749 DOI 10.17487/RFC6437, November 2011, 1750 . 1752 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1753 for Equal Cost Multipath Routing and Link Aggregation in 1754 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1755 . 1757 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1758 UDP Checksums for Tunneled Packets", RFC 6935, 1759 DOI 10.17487/RFC6935, April 2013, 1760 . 1762 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 1763 and D. Wing, "IPv6 Multihoming without Network Address 1764 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 1765 . 1767 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1768 (IPv6) Specification", STD 86, RFC 8200, 1769 DOI 10.17487/RFC8200, July 2017, 1770 . 1772 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1773 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1774 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1775 July 2018, . 1777 [TR.29.891-3GPP] 1778 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 1779 (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December 1780 2017, . 1783 [TS.22.261-3GPP] 1784 3rd Generation Partnership Project (3GPP), "3GPP TS 22.261 1785 (V15.7.0): Service requirements for 5G system stage 1", 1786 December 2018, . 1789 [TS.23.060-3GPP] 1790 3rd Generation Partnership Project (3GPP), "3GPP TS 23.060 1791 (V15.3.0): General Packet Radio Service (GPRS); Service 1792 description; Stage 2", June 2018, 1793 . 1796 [TS.23.501-3GPP] 1797 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 1798 (V16.2.0): System Architecture for 5G System; Stage 2", 1799 September 2019, . 1802 [TS.23.502-3GPP] 1803 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 1804 (V15.4.0): Procedures for 5G System; Stage 2", December 1805 2018, . 1808 [TS.23.503-3GPP] 1809 3rd Generation Partnership Project (3GPP), "3GPP TS 23.503 1810 (V15.4.0): Policy and Charging Control System for 5G 1811 Framework; Stage 2", December 2018, 1812 . 1815 [TS.28.530-3GPP] 1816 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1817 (V15.1.0): Management and orchestration of networks and 1818 network slicing; Concepts, use cases and requirements 1819 (work in progress)", December 2018, 1820 . 1823 [TS.28.531-3GPP] 1824 3rd Generation Partnership Project (3GPP), "3GPP TS 28.531 1825 (V15.1.0): Management and orchestration of networks and 1826 network slicing; Provisioning; Stage 1 (Release 15)", 1827 December 2018, . 1830 [TS.28.532-3GPP] 1831 3rd Generation Partnership Project (3GPP), "3GPP TS 28.532 1832 (V15.1.0): Management and orchestration of networks and 1833 network slicing; Provisioning; Stage 2 and stage 3 1834 (Release 15)", Decempber 2018, 1835 . 1838 [TS.28.533-3GPP] 1839 3rd Generation Partnership Project (3GPP), "3GPP TS 28.533 1840 (V15.1.0): Management and orchestration of networks and 1841 network slicing; Management and orchestration architecture 1842 (Release 15)", December 2018, 1843 . 1846 [TS.29.244-3GPP] 1847 3rd Generation Partnership Project (3GPP), "3GPP TS 29.244 1848 (V15.1.0): Interface between the Control Plane and the 1849 User Plane Nodes; Stage 3", December 2018, 1850 . 1853 [TS.29.274-3GPP] 1854 3rd Generation Partnership Project (3GPP), "3GPP TS 29.274 1855 (V15.4.0): 3GPP Evolved Packet System (EPS); Evolved 1856 General Packet Radio Service (GPRS) Tunneling Protocol for 1857 Control plane (GTPv2-C); Stage 3", June 2018, 1858 . 1861 [TS.29.281-3GPP] 1862 3rd Generation Partnership Project (3GPP), "3GPP TS 29.281 1863 (V16.1.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", 1864 September 2020, . 1867 [TS.29.510-3GPP] 1868 3rd Generation Partnership Project (3GPP), "3GPP TS 29.510 1869 (V15.2.0): 5G System; Network Function Repository 1870 Services; Stage 3", December 2018, 1871 . 1874 [TS.29.561-3GPP] 1875 3rd Generation Partnership Project (3GPP), "3GPP TS 29.561 1876 (V15.1.0): 5G System; Interworking between 5G Network and 1877 external Data Networks; Stage 3", September 2018, 1878 . 1881 [TS.38.300-3GPP] 1882 3rd Generation Partnership Project (3GPP), "3GPP TS 38.300 1883 (v15.4.0): NR and NG-RAN Overall Description; Stage 2", 1884 December 2018, . 1887 [TS.38.401-3GPP] 1888 3rd Generation Partnership Project (3GPP), "3GPP TS 38.401 1889 (v15.4.0): NG-RAN; Architecture Description", December 1890 2018, . 1893 [TS.38.415-3GPP] 1894 3rd Generation Partnership Project (3GPP), "3GPP TS 38.415 1895 (v16.2.0): NG-RAN; PDU Session User Plane protocol", 1896 October 2020, . 1899 Authors' Addresses 1901 Shunsuke Homma 1902 NTT 1904 Email: homma.shunsuke@lab.ntt.co.jp 1906 Takuya Miyasaka 1907 KDDI Research 1909 Email: ta-miyasaka@kddi-research.jp 1911 Satoru Matsushima 1912 SoftBank 1914 Email: satoru.matsushima@g.softbank.co.jp 1916 Daniel Voyer 1917 Bell Canada 1919 Email: daniel.voyer@bell.ca