draft-ietf-dmm-5g-uplane-analysis-02.txt   draft-ietf-dmm-5g-uplane-analysis-03.txt 
DMM Working Group S. Homma DMM Working Group S. Homma
Internet-Draft NTT Internet-Draft NTT
Intended status: Informational T. Miyasaka Intended status: Informational T. Miyasaka
Expires: January 9, 2020 KDDI Research Expires: May 7, 2020 KDDI Research
S. Matsushima S. Matsushima
SoftBank SoftBank
D. Voyer D. Voyer
Bell Canada Bell Canada
July 8, 2019 November 4, 2019
User Plane Protocol and Architectural Analysis on 3GPP 5G System 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 Abstract
This document analyzes the mobile user plane protocol and the This document analyzes the mobile user plane protocol and the
architecture specified in 3GPP 5G documents. The analysis work is to architecture specified in 3GPP 5G documents. The analysis work is to
clarify those specifications, extract protocol and architectural clarify those specifications, extract protocol and architectural
requirements and derive evaluation aspects for user plane protocols requirements and derive evaluation aspects for user plane protocols
on IETF side. This work is corresponding to the User Plane Protocol on IETF side. This work is corresponding to the User Plane Protocol
Study work on 3GPP side. Study work on 3GPP side.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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 publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12 3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12
3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13 3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16 3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16
4. 5GS Architectural Requirements for User Plane Protocols . . . 16 4. 5GS Architectural Requirements for User Plane Protocols . . . 16
4.1. Overview of 5G System Architecture . . . . . . . . . . . 16 4.1. Overview of 5G System Architecture . . . . . . . . . . . 16
4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18 4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18
4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19 4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19
4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21 4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21
4.2. Architectural Requirements for User Plane Protocols . 22 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.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.3. Supporting Transport Variations . . . . . . . . . . . . . 30
5.4. Data Path Management . . . . . . . . . . . . . . . . . . 30 5.4. Data Path Management . . . . . . . . . . . . . . . . . . 31
5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 31 5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 32
5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 32 5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 32
5.7. Supporting Network Slicing Diversity . . . . . . . . . . 32 5.7. Supporting Network Slicing Diversity . . . . . . . . . . 32
5.8. Reliable Communication support . . . . . . . . . . . . . 33 5.8. Reliable Communication support . . . . . . . . . . . . . 33
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 33 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Security Consideration . . . . . . . . . . . . . . . . . . . 34 7. Security Consideration . . . . . . . . . . . . . . . . . . . 34
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34
9. Informative References . . . . . . . . . . . . . . . . . . . 34 9. Informative References . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document analyzes the mobile user plane protocol and the This document analyzes the mobile user plane protocol and the
architecture specified by 3GPP 5G documents. The background of the architecture specified by 3GPP 5G documents. The background of the
work is that 3GPP requests through a liaison statement that the IETF work is that 3GPP requests through a liaison statement that the IETF
to provide any information for the User Plane Protocol Study work in to provide any information for the User Plane Protocol Study work in
3GPP [CP-180116-3GPP]. Justification and the objectives of the study 3GPP [CP-180116-3GPP]. Justification and the objectives of the study
can be found from [CP-173160-3GPP]. can be found from [CP-173160-3GPP].
skipping to change at page 26, line 46 skipping to change at page 26, line 46
ARCH-Req-8: End Marker support ARCH-Req-8: End Marker support
The construction of End Marker packets specified in [TS.23.501-3GPP] 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 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 the payload stream on a given UP tunnel. PDU packets arrive after an
End Marker message on the tunnel may be silently discarded. For End Marker message on the tunnel may be silently discarded. For
example, End Maker is used for handover procedures, and it can example, End Maker is used for handover procedures, and it can
prevent reordering of arriving packets due to switch of anchor UPFs. 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 The 5G is expected to support services which are latency sensitive
and require high reliability. Communication to realize such services and require high reliability. Communication to realize such services
is called Ultra-Reliable and Low-Latency Communication or URLLC. In is called Ultra-Reliable and Low-Latency Communication or URLLC. In
URLLC, redundancy of QoS flows is required for providing highly URLLC, redundancy of QoS flows is required for providing highly
reliable communication. For instance, a set of UP NFs (e.g., UPF or 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 gNB) and interfaces between UE and DN are redundant, and packets are
replicated and forwarded via each route. UEs and DN support dual replicated and forwarded via each route. UEs and DN support dual
connectivity and drop duplicated received packets. The scheme of connectivity and drop duplicated received packets. The scheme of
packet dropping at UE is out of responsibility of 3GPP. The overview packet dropping at UE is out of responsibility of 3GPP. The overview
skipping to change at page 28, line 48 skipping to change at page 28, line 48
/ N3 Tunnel1 +-+-+---+ N9 Tunnel1 | / N3 Tunnel1 +-+-+---+ N9 Tunnel1 |
/ +-----+I-UPF1 +----+ | / +-----+I-UPF1 +----+ |
+----+ +--+--+______| +-------+ |______+--+--+ N6 +----+ +----+ +--+--+______| +-------+ |______+--+--+ N6 +----+
| UE +---+ RAN |______ | ______| UPF +-----+ DN | | UE +---+ RAN |______ | ______| UPF +-----+ DN |
+----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+ +----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+
+-----+I-UPF2 +----+ +-----+I-UPF2 +----+
N3 Tunnel2 +-------+ N9 Tunnel2 N3 Tunnel2 +-------+ N9 Tunnel2
Figure 9: Redundant UP transmission with two I-UPF and N3/N9 tunnels 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 5. Evaluation Aspects
This section provides UP protocol evaluation aspects that are mainly This section provides UP protocol evaluation aspects that are mainly
we derived from the architectural requirements described in we derived from the architectural requirements described in
Section 4. Those aspects are not prioritized by the order here. Section 4. Those aspects are not prioritized by the order here.
Expected deployment scenarios explain the evaluations purpose in the Expected deployment scenarios explain the evaluations purpose in the
corresponding aspects. corresponding aspects.
As we were noticed that the gaps between GTP-U specifications and 5G As we were noticed that the gaps between GTP-U specifications and 5G
architectural requirements through the analysis, those each gap are architectural requirements through the analysis, those each gap are
briefly described in the evaluation aspect associated to it. briefly described in the evaluation aspect associated to it.
Since it is obvious that 5G system should be able to interwork with Since it is obvious that 5G system should be able to interwork with
existing previous generation based systems, any aspects from existing previous generation based systems, any aspects from
coexisting and interworking point of view are not particularly coexisting and interworking point of view are not particularly
skipping to change at page 34, line 48 skipping to change at page 35, line 27
Docs/CP-173160.zip>. Docs/CP-173160.zip>.
[CP-180116-3GPP] [CP-180116-3GPP]
3rd Generation Partnership Project (3GPP), "LS on user 3rd Generation Partnership Project (3GPP), "LS on user
plane protocol study", March 2018, plane protocol study", March 2018,
<http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/ <http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/
Docs/CP-180116.zip>. Docs/CP-180116.zip>.
[IAB-Statement] [IAB-Statement]
Internet Architecture Board (IAB), "IAB Statement on Internet Architecture Board (IAB), "IAB Statement on
IPv6", November 2016, IPv6", November 2016, <https://www.iab.org/2016/11/07/iab-
<https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>. statement-on-ipv6/>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4664>. editor.org/info/rfc4664>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4861>. editor.org/info/rfc4861>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6437>. editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6935>. editor.org/info/rfc6935>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<https://www.rfc-editor.org/info/rfc7157>. <https://www.rfc-editor.org/info/rfc7157>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8200>. editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[TR.29.891-3GPP] [TR.29.891-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TR 29.891 3rd Generation Partnership Project (3GPP), "3GPP TR 29.891
(V15.0.0): 5G System Phase 1, CT WG4 Aspects", December (V15.0.0): 5G System Phase 1, CT WG4 Aspects", December
2017, <http://www.3gpp.org/FTP/Specs/2017-12/ 2017, <http://www.3gpp.org/FTP/Specs/2017-12/
skipping to change at page 36, line 26 skipping to change at page 37, line 7
[TS.23.060-3GPP] [TS.23.060-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.060 3rd Generation Partnership Project (3GPP), "3GPP TS 23.060
(V15.3.0): General Packet Radio Service (GPRS); Service (V15.3.0): General Packet Radio Service (GPRS); Service
description; Stage 2", June 2018, description; Stage 2", June 2018,
<http://www.3gpp.org/ftp//Specs/ <http://www.3gpp.org/ftp//Specs/
archive/23_series/23.060/23060-f30.zip>. archive/23_series/23.060/23060-f30.zip>.
[TS.23.501-3GPP] [TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501
(V16.1.0): System Architecture for 5G System; Stage 2", (V16.2.0): System Architecture for 5G System; Stage 2",
June 2019, <http://www.3gpp.org/ftp//Specs/ September 2019, <http://www.3gpp.org/ftp//Specs/
archive/23_series/23.501/23501-g10.zip>. archive/23_series/23.501/23501-g20.zip>.
[TS.23.502-3GPP] [TS.23.502-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.502 3rd Generation Partnership Project (3GPP), "3GPP TS 23.502
(V15.4.0): Procedures for 5G System; Stage 2", December (V15.4.0): Procedures for 5G System; Stage 2", December
2018, <http://www.3gpp.org/FTP/Specs/2018-03/ 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
Rel-15/23_series/23502-f40.zip>. Rel-15/23_series/23502-f40.zip>.
[TS.23.503-3GPP] [TS.23.503-3GPP]
3rd Generation Partnership Project (3GPP), "3GPP TS 23.503 3rd Generation Partnership Project (3GPP), "3GPP TS 23.503
(V15.4.0): Policy and Charging Control System for 5G (V15.4.0): Policy and Charging Control System for 5G
 End of changes. 21 change blocks. 
30 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/