--- 1/draft-ietf-dmm-5g-uplane-analysis-02.txt 2019-11-03 22:13:23.887709271 -0800 +++ 2/draft-ietf-dmm-5g-uplane-analysis-03.txt 2019-11-03 22:13:23.967711298 -0800 @@ -1,58 +1,58 @@ DMM Working Group S. Homma Internet-Draft NTT Intended status: Informational T. Miyasaka -Expires: January 9, 2020 KDDI Research +Expires: May 7, 2020 KDDI Research S. Matsushima SoftBank D. Voyer Bell Canada - July 8, 2019 + November 4, 2019 User Plane Protocol and Architectural Analysis on 3GPP 5G System - draft-ietf-dmm-5g-uplane-analysis-02 + draft-ietf-dmm-5g-uplane-analysis-03 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 https://datatracker.ietf.org/drafts/current/. + Drafts is at http://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 January 9, 2020. + This Internet-Draft will expire on May 7, 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 - (https://trustee.ietf.org/license-info) in effect on the date of + (http://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 @@ -65,34 +65,34 @@ 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 . . . . . . . . . . . . . . . . 19 4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21 4.2. Architectural Requirements for User Plane Protocols . 22 - 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 28 + 5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 29 5.1. Supporting PDU Session Type Variations . . . . . . . . . 29 - 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 29 + 5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 30 5.3. Supporting Transport Variations . . . . . . . . . . . . . 30 - 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 30 - 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 31 + 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 32 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 32 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 32 5.8. Reliable Communication support . . . . . . . . . . . . . 33 - 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Security Consideration . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34 - 9. Informative References . . . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 + 9. Informative References . . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 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]. @@ -1164,21 +1164,21 @@ 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 + ARCHI-Req-9: Supporting Redundant UP transmission for 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 @@ -1261,26 +1261,43 @@ / 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 + ARCHI-Req-10: Supporting QoS Monitoring for URLLC + + QoS monitoring is also required for URLLC. It means that the user + plane should be able to measure packet delay between anchor UPF and + UE. The measurement would be in various granularities, in the basis + of per QoS Flow per UE, or per UP path for example. + + To help the measurement at anchor UPF and RAN, UP protocol requires + to have capability to convey necessary information to do that; such + as time information at sending or reception of a measurement packet. + That information should exist in per F-TEID and QFI basis which + indicates QoS Flow of the packet. UP protocol should also be able to + indicate which packets include the corresponding information for each + measurement. + + The QoS monitoring requirement has been appeared in section 5.33.3 of + [TS.23.501-3GPP] from Rel-16, version 16.2.0. + 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 @@ -1550,65 +1567,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 - (V16.1.0): System Architecture for 5G System; Stage 2", - June 2019, . + (V16.2.0): System Architecture for 5G System; Stage 2", + September 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