--- 1/draft-ietf-dmm-5g-uplane-analysis-01.txt 2019-07-08 06:13:37.545418058 -0700 +++ 2/draft-ietf-dmm-5g-uplane-analysis-02.txt 2019-07-08 06:13:37.641420476 -0700 @@ -1,96 +1,98 @@ DMM Working Group S. Homma Internet-Draft NTT Intended status: Informational T. Miyasaka -Expires: September 12, 2019 KDDI Research +Expires: January 9, 2020 KDDI Research S. Matsushima SoftBank D. Voyer Bell Canada - March 11, 2019 + July 8, 2019 User Plane Protocol and Architectural Analysis on 3GPP 5G System - draft-ietf-dmm-5g-uplane-analysis-01 + draft-ietf-dmm-5g-uplane-analysis-02 Abstract This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 12, 2019. + This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3 - 1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 3 + 1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 4 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 3. GTP-U Specification and Observation . . . . . . . . . . . . . 6 3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6 3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 10 3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12 3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14 3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16 4. 5GS Architectural Requirements for User Plane Protocols . . . 16 4.1. Overview of 5G System Architecture . . . . . . . . . . . 16 4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18 - 4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 18 - 4.2. Architectural Requirements for User Plane Protocols . 20 - 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 24 - 5.1. Supporting PDU Session Type Variations . . . . . . . . . 25 - 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 25 - 5.3. Supporting Transport Variations . . . . . . . . . . . . . 25 - 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 26 - 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 27 - 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 27 - 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 28 - 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 7. Security Consideration . . . . . . . . . . . . . . . . . . . 29 - 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 - 9. Informative References . . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 + 4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19 + 4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21 + 4.2. Architectural Requirements for User Plane Protocols . 22 + 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 28 + 5.1. Supporting PDU Session Type Variations . . . . . . . . . 29 + 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 29 + 5.3. Supporting Transport Variations . . . . . . . . . . . . . 30 + 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 30 + 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 32 + 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 32 + 5.8. Reliable Communication support . . . . . . . . . . . . . 33 + 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Consideration . . . . . . . . . . . . . . . . . . . 34 + 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34 + 9. Informative References . . . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction This document analyzes the mobile user plane protocol and the architecture specified by 3GPP 5G documents. The background of the work is that 3GPP requests through a liaison statement that the IETF to provide any information for the User Plane Protocol Study work in 3GPP [CP-180116-3GPP]. Justification and the objectives of the study can be found from [CP-173160-3GPP]. @@ -726,20 +729,24 @@ separated from the Control Plane (CP) functions for allowing independent scalability, evolution and flexible deployments. Network slicing is also one of the fundamental concepts of the 5G system, and it provides logical network separation. In terms of user plane, multiple network slices can be comprised of UPFs on top of same physical network resources. Allocated resources and structures may be differentiated among the slices by which the required features or capabilities. + The 3GPP 5G architecture [TS.23.501-3GPP] defines slice types which + are eMBB, URLLC and MIoT from Rel-15. In addition to that, V2X slice + type is defined from Rel-16. + The architecture overview is shown in Figure 5. The details of functions are described in [TS.23.501-3GPP]. A UPF handles UP paths on N3, N9 and N6 interface, and the setup is controlled by SMF via N4 interface. A UP path will be manipulated based on application requirements for the PDU session corresponding to the path. An SMF is also capable to receive information regarding routing path with API from AF via NEF, PCF, and SMF. +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ |NSSF | | NEF | | NRF | | PCF | | UDM | | AF | @@ -803,20 +810,27 @@ o Downlink packet buffering and downlink data notification triggering. o Sending and forwarding of one or more "end marker" to the source NG-RAN node. o ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the Ethernet PDUs. + o Packet duplication in downlink direction and elimination in uplink + direction in UP protocol layer. + + o TSN Translator functionality to hold and forward user plane + packets for de-jittering when 5G System is integrated as a bridge + with the TSN network. + 4.1.2. UP Traffic Detection The traffic detection is described in the section 5.8.2.4 of [TS.23.501-3GPP]. In 3GPP UP packet forwarding model, UPF detects UP traffic flow which belong to a N4 session configured by SMF. The protocol of N4 interface, PFCP, brings a set of traffic detection information from SMF to UPF as Packet Detection Information (PDI) in a PDR to establish/modify the N4 PFCP session. It is defined in section 7.5.2.2 of [TS.29.244-3GPP]. @@ -885,20 +900,85 @@ fields as defined in IEEE 802.1Q * Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/DEI fields as defined in IEEE 802.1Q * IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 payload * Packet filter direction +4.1.3. User Plane Configuration + + User Plane configuration on a UPF is managed by an SMF through PFCP + [TS.29.244-3GPP]. The SMF establishes PFCP sessions on the UPF per + PDU session basis. The UPF maintains each configured PFCP session + states during the sessions exist. + + A PFCP session consists of the rules of packet detection, forwarding + action, QoS enforcement, usage reporting and buffering action. + Figure 6 depicts overview of the PFCP session state structure. + + The listed information in Section 4.1.2 indicates packet detection + information of packet detection rule for that the rest of related + rules within the PFCP session to be derived. All rules are per + session unique and no rules are shared with other sessions. + + PFCP-Session* [F-SEID] + +- F-SEID(Full Qualified Session Endpoint ID) uint64 + +- PDU-Session-Type [IPv4|IPv6|IPv4v6|Ether|Unstrct] + +- DNN(Data Network Name) + +- PDR(Packet Detection Rule)* [PDR-ID] + | +- PDR-ID uint16 + | +- PDI (Packet Detection Information) + | | +- Traffic-Endpoint-ID? -> Traffic-Endpoint-ID reference + | | +- .... + | +- FAR/URR/QER-ID -> FAR/URR/QER-ID references + +- FAR(Forwarding Action Rule)* [FAR-ID] + | +- FAR-ID uint32 + | +- Forwarding-Parameters + | | +- Network-Instance? Octet String + | | +- Outer-Header-Creation + | | | +- Outer-Hdr-Creation-Desc [GTPoUDP/IPv4|IPv6, etc.,] + | | | +- TEID, outer IP-Address for N3/N9 + | | | +- C/S-TAG, UDP Port-number for N6 + | | +- Forwarding-Policy-ID? Octet String + | | +- .... + | +- Duplicating-Parameters + | | +- .... + | +- BAR-ID? -> BAR-ID reference + +- QER(QoS Enforcement Rule)* [QER-ID] + | +- QER-ID uint32 + | +- MBR(Maximum Bit Rate) + | | +- UL/DL-MBR? bitrate_in_kbps (0..10000000) + | +- GBR(Guaranteed Bit Rate) + | | +- UL/DL-GBR? bitrate_in_kbps (0..10000000) + | +- QoS-flow-identifier? QFI value(6-bits) + | +- Reflective-QoS? boolean + | +- Paging-Policy-Indicator? PPI value(3-bits) + | +- .... + +- URR(Usage Reporting Rule)* [URR-ID] + | +- URR-ID uint32 + | +- Measurement-Method, Period, Reporting-Triggers? + | +- Volume/Event/Time Threshold, Quota? + | +- Quota-Holding-Time? + | +- FAR-ID for Quota action? -> FAR-ID reference + | +- .... + +- BAR(Buffering Action Rule)* [BAR-ID] + | +- BAR-ID uint8 + | +- Suggested-Buffering-Packets-Count + +- Traffic-Endpoint* [Traffic-Endpoint-ID] + +- Traffic-Endpoint-ID uint8 + +- TEID, Tunnle IP Address, UE Address...? + + Figure 6: User Plane Configuration Model + 4.2. Architectural Requirements for User Plane Protocols This section lists the requirements for the UP protocol on the 5G system. The requirements are picked up from [TS.23.501-3GPP]. In addition, some of service requirements described in [TS.22.261-3GPP] are referred to clarify the originations of architectural requirements. According to [TS.23.501-3GPP], the specifications potentially have assumptions that the UP protocol is a tunnel representing a single @@ -939,39 +1020,37 @@ ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a single PDU session The 5G system allows to deploy multiple UPFs as anchors for a single PDU session, and supports multihoming of a single PDU session for such anchor UPFs. Multihoming is provided with Branching Point (BP). BP provides forwarding of UL traffic towards the different PDU Session Anchors based on the source IPv6 prefixes and merge of DL traffic to the UE. - UL CL provides destination based multihoming for load balancing. + IPv6 multihoming only means multiple source IPv6 prefixes are used + for a PDU session. It is identical to one classified as scenario 1 + in [RFC7157]. - Noted that, in 3GPP definition, IPv6 multihoming indicates only cases - where "multiple" source IPv6 prefixes are used, and it is different - from IETF definition. Actually, in the 5GS, Up link classifier (UL - CL) is capable to provide forwarding to multiple anchor for a PDU - session with a single source IPv6 prefix, but it is distinguished - from IPv6 multihoming. + Up link classifier (UL CL) is to forward uplink packets to multiple + anchor UPFs based on the destination IP of the T-PDU regardless of + the source IP address. Noted that single source IP address/prefix + PDU session is not defined as multihoming PDU session in 5GCS even + though a PDU session has multiple anchor UPFs. - On UL side, multihoming of a single PDU session is achieved by a - point-to-point (P2P) tunnel per anchor UPF. It means that multiple - P2P paths are established from one source gNB or UPF to the multiple - destination anchor UPFs for the PDU session. + On UL side, P2P tunnels are established per destination anchor UPFs + basis from one UL CL UPF to the anchor UPFs for the PDU session. - On DL side, one single multipoint-to-point (MP2P) path exists from - the anchor UPFs to the destination gNB or UPF for the PDU session in - this multihoming case. It means that the paths from the anchor UPFs - are merged into just one tunnel state at the source gNB or UPF for - the PDU session. + On DL side, one single multipoint-to-point (MP2P) tunnel exists from + the source anchor UPFs to the destination BP UPF for the PDU session. + It means that the paths from the anchor UPFs are merged into just one + tunnel state at the destination BP UPF. Multiple P2P paths on DL could also be used for multihoming. However it should be the multiple PDU sessions multihoming case where the destination gNB or UPF needs to maintain multiple tunnel states under the one PDU session to one UP tunnel architectural principle. It causes increase of load on tunnel states management in UPF due to increment of the anchor UPF for the PDU session. However, P2P tunneling could increase explosively the number of states in UPF as the anchor UPF/DN incremented to the PDU session. @@ -1084,25 +1164,123 @@ ARCH-Req-8: End Marker support The construction of End Marker packets specified in [TS.23.501-3GPP] may either be done in the CP/UP functions for indicating the end of the payload stream on a given UP tunnel. PDU packets arrive after an End Marker message on the tunnel may be silently discarded. For example, End Maker is used for handover procedures, and it can prevent reordering of arriving packets due to switch of anchor UPFs. + ARCHI-Req-9: Supporting URLLC + + The 5G is expected to support services which are latency sensitive + and require high reliability. Communication to realize such services + is called Ultra-Reliable and Low-Latency Communication or URLLC. In + URLLC, redundancy of QoS flows is required for providing highly + reliable communication. For instance, a set of UP NFs (e.g., UPF or + gNB) and interfaces between UE and DN are redundant, and packets are + replicated and forwarded via each route. UEs and DN support dual + connectivity and drop duplicated received packets. The scheme of + packet dropping at UE is out of responsibility of 3GPP. The overview + is shown in Figure 7. + + ---+-----------+----------+--- + Namf| Nsmf| Nsmf| + +--+--+ +--+--+ +--+--+ + | AMF | | SMF1| | SMF3| + +-+---+ +--+--+ +-+---+ + / / / + N2/ N4/ N4/ + / / / + +----++ N3 +--+---+ / N6 +----+ + |M-RAN+--------+ UPF1 +--------------+ | + ++-+--+ +-+--+-+ / | | + / | | | / | | + +----+ / | +--+ / | | + | UE +< |Xn N9 / | DN | + +----+ \ | / | | + \ | / | | + ++-+--+ N3 +----+-+ N6 | | + |S-RAN+--------+ UPF2 +--------------+ | + +-----+ +-+--+-+ +----+ + | | + +--+ + N9 + *Legends + M-RAN: Master RAN + S-RAN: Secondary RAN + + Figure 7: Redundant UP paths using dual connectivity + + Otherwise, in case that RAN nodes and UPFs have enough reliability + and they are not redundant by dual devices, reliable connectivity of + QoS flows is provided by dual N3 tunnels between RAN and UPFs. Such + tunnels are treated as individual ones, but they have the same + sequence number. UP NFs identifies the duplication of PDU packets + based on sequence number content in the UP tunnel headers. For + uplink packets, a RAN node replicates each packet from a UE. An + anchor UPF receives the duplicated packets, and drops ones which + reach later in each duplicated packet pare. On the other hand, for + downlink packets, a UPF replicates packets received from DN, and a + RAN node drops the duplicated packets as well. The overviews of the + ways are shown in Figure 8. + + ----+-----------+-----------+--- + Namf| Nsmf| Npcf| + +--+--+ +--+--+ +--+--+ + | AMF | | SMF | | PCF | + +-+---+ +--+--+ +-----+ + / | + N2/ N4| + / N3 Tunnel1 | + +----+ +--+--+__________+--+--+ N6 +----+ + | UE +----+ RAN |__________| UPF |-----+ DN | + +----+ +-----+ +-----+ +----+ + N3 Tunnel2 + + Figure 8: Redundant UP transmission with two N3 tunnels + + In addition, there is a case that two intermediate UPFs (I-UPFs) + between anchor UPF and RAN are used to support the redundant + transmission based on two N3 and N9 tunnels between single anchor UPF + and RAN node. The RAN node and anchor UPF support the packet + replication and dropping of duplicated packets as described above. + As described above, anchor UPF and RAN node detect packet duplication + with sequence number of UP tunnels, and thus I-UPFs would forward the + packets with the same sequence number on N3 and N9 tunnels. The + overview is shown in Figure 9. + + ----+-------------+--------------+--- + Namf| Nsmf| Npcf| + +--+--+ +---+---+ +--+--+ + | AMF | | SMF + | PCF | + +--+--+ +-+-+-+-+ +-----+ + / | | | + N2 / N4| | +----------------+ + / | | | + / N3 Tunnel1 +-+-+---+ N9 Tunnel1 | + / +-----+I-UPF1 +----+ | + +----+ +--+--+______| +-------+ |______+--+--+ N6 +----+ + | UE +---+ RAN |______ | ______| UPF +-----+ DN | + +----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+ + +-----+I-UPF2 +----+ + N3 Tunnel2 +-------+ N9 Tunnel2 + + Figure 9: Redundant UP transmission with two I-UPF and N3/N9 tunnels + 5. Evaluation Aspects This section provides UP protocol evaluation aspects that are mainly we derived from the architectural requirements described in Section 4. Those aspects are not prioritized by the order here. + Expected deployment scenarios explain the evaluations purpose in the corresponding aspects. As we were noticed that the gaps between GTP-U specifications and 5G architectural requirements through the analysis, those each gap are briefly described in the evaluation aspect associated to it. Since it is obvious that 5G system should be able to interwork with existing previous generation based systems, any aspects from coexisting and interworking point of view are not particularly @@ -1298,20 +1475,40 @@ Option 2 and 3 are expected as IP domain separation, but it is hard to see that it is able to indicate transport slice in addition to the IP domain. Other L2 and tunneling solutions should be same with those options. The expected evaluation points from this aspect should be whether the candidate protocols can contain forwarding information associated to the assigned IP domain and transport slice for all possible deployment cases. +5.8. Reliable Communication support + + As Section 4.2 described, more than two UP paths are required for a + QoS flow of a PDU session between the anchor UPF and gNB. Those UP + paths are to convey redundant duplicated packets. + + To support reliable communication with above requirements, UPF and + gNB must replicate the sending UP packets and eliminate the received + duplicated UP packets. Not to mention that UP protocol should be + able to make sure that the paths are not in fate sharing, the UP + packet must have sequence number to indicate duplicate packets per + QoS flow basis. + + The expected evaluation points from this aspect should be whether the + candidate protocols can indicate packet sequence and diversed paths + in the context of QoS flow, not in UP tunnel context. The packet + sequence information should be transparent through I-UPF(s) exist in + the middle of the path even in case that the UP tunnels are + terminated at the I-UPF(s). + 6. Conclusion We analyzed the 3GPP specifications of the 5G architecture in terms of user plane and the current protocol adopted to the user plane. After the analysis work, we believe that the results described in this document shows that we reach at certain level of understanding on the 5G systems and ready to provide our inputs to 3GPP. We clarified GTP-U through the analysis and listed observed characteristics in Section 3.6. We also clarified the architectural @@ -1353,60 +1550,65 @@ Docs/CP-173160.zip>. [CP-180116-3GPP] 3rd Generation Partnership Project (3GPP), "LS on user plane protocol study", March 2018, . [IAB-Statement] Internet Architecture Board (IAB), "IAB Statement on - IPv6", November 2016, . + IPv6", November 2016, + . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, - DOI 10.17487/RFC4664, September 2006, . + DOI 10.17487/RFC4664, September 2006, + . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, - DOI 10.17487/RFC4861, September 2007, . + DOI 10.17487/RFC4861, September 2007, + . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, - DOI 10.17487/RFC6437, November 2011, . + DOI 10.17487/RFC6437, November 2011, + . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, - DOI 10.17487/RFC6935, April 2013, . + DOI 10.17487/RFC6935, April 2013, + . + + [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., + and D. Wing, "IPv6 Multihoming without Network Address + Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, + . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, - DOI 10.17487/RFC8200, July 2017, . + DOI 10.17487/RFC8200, July 2017, + . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [TR.29.891-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December 2017, . [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 - (V15.4.0): System Architecture for 5G System; Stage 2", - December 2018, . + (V16.1.0): System Architecture for 5G System; Stage 2", + June 2019, . [TS.23.502-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 (V15.4.0): Procedures for 5G System; Stage 2", December 2018, . [TS.23.503-3GPP] 3rd Generation Partnership Project (3GPP), "3GPP TS 23.503 (V15.4.0): Policy and Charging Control System for 5G