Internet DRAFT - draft-hspab-5gangip-atticps
draft-hspab-5gangip-atticps
Network Working Group D. von Hugo
Internet-Draft Deutsche Telekom AG
Intended status: Standards Track B. Sarikaya
Expires: August 1, 2018
January 28, 2018
IP Issues and Associated Gaps in Fifth Generation Wireless Networks
draft-hspab-5gangip-atticps-00.txt
Abstract
This document attempts to make the case for new work that need to be
developed to be used among various virtualized functions and the end
user which may be moving. First a set of use cases on tunneling,
charging, mobility anchors are developed and then the steps of
proposed new work is described next.
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/.
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 August 1, 2018.
Copyright Notice
Copyright (c) 2018 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
von Hugo, et al. Expires August 1, 2018 [Page 1]
Internet-Draft nextgenprot January 2018
(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
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2
3. Issues in Fifth Generation Wireless Networks . . . . . . . . 2
4. Identifier Locator Separation Systems . . . . . . . . . . . . 4
5. Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Virtualized network functions enable operators to remove single
points of failure and distribute network state in a more efficient
way. These functions are divided into control plane and data plane
functions. Control plane and data plane protocols are used when
these functions interact with each other over well defined interfaces
between the functions.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Issues in Fifth Generation Wireless Networks
Means for enabling to set up and manage connectivity among end user
terminals or between an end user terminal and an application function
in the network are provided by systems for mobile communication such
as cellular access and core networks as defined by 3GPP (e.g., LTE
and EPC for 4G). Architecture and protocols in such systems have
been developped previously in a rather independent manner from
evolution of IP protocols as done in IETF although many protocols are
used for e.g. authentication, address assignment, and provision of
applications to the end user terminal.
von Hugo, et al. Expires August 1, 2018 [Page 2]
Internet-Draft nextgenprot January 2018
With expected change in the future regarding services and service
demands as well as in the dynamicity of network features to be
supported, the traditional approaches may turn out to be not flexible
enough to efficiently and effectively provide the services. Some
issues as also partly mentioned elsewhere are described in the
following.
[ETSI NGP] describes requirements for how to better provide mobile
Internet access addressing as key points:
Efficiency: Smaller Headers, Scalable protocol structures
Security: Native, Scalable, Association and Stakeholder based
Addressing: Location, Network Address separation and ID separation
Transmission: Flexible, Efficient, Context Aware and Profile based
Mobility: Native, Scalable, Context Aware
Documentation missing on GTP-U
User plane GTP protocol called GTP-U has been selected to be used on
interfaces N3 and N9. GTP is UDP based tunneling protocol used to
carry general packet radio service (GPRS) within wireless core
network.
GTP-U header contains 12 octets 4 octets of it are used to carry
Tunnel Endpoint Identifier or TEID. TEID indicates which tunnel this
packet belongs and TEID values are negotiated on the control plane.
We can say that GTP-U is a means that multiplexes and de-multiplexes
packets between a given pair of tunnel endpoints.
GTP which is heavily used in 4G networks and now to be used in 5G
networks is not known in IETF. There is no documentation on GTP.
Also there are concerns that GTP is used more to carry IPv4 packets
and operators possibly due to lack of expertise are not using it for
IPv6.
Tunneling blues
As explained above delivery of user or UE packets is based on
tunneling. That means to every IPv6 packet at least 52 octets of
overhead is added. Also since over the air delivery is not involved
possibly no header compression is involved.
Tunneling is suitable for point-to-point communication and introduces
complexities to point-to-multipoint communication, i.e. IP multicast.
von Hugo, et al. Expires August 1, 2018 [Page 3]
Internet-Draft nextgenprot January 2018
Another issue with tunneling is it introduces gateways in the core
network such as packet data network gateway or PGW. Gateways are
prominent places for single-point failure for security attacks like
DOS or DDOS.
Charging etc.
It seems like a major reason for the use of tunneling is charging.
Tunneling user packets to certain gateways certainly enables very
effectively to account for and subsequently charge user traffic.
Other features to be supported by tunneling are policy and security
enforcement, providing a point for traffic monitoring and legal
interception etc.
Mobility anchors
Some gateways are used as mobility anchors as enabled by tunneling.
In 4G LTE networks PGW is a fixed mobility anchor which means that UE
packets are always anchored from the PGW that serves that specific
UE.
In 5G networks the use of mobility anchor continues but it is not a
fixed anchor. Based on user mobility, the anchor, i.e. UPF assigned
to the UE may be changed and another UPF takes over.
Dynamic anchoring used in 5G is expected to enable much faster
communication. Ideally no anchoring is better and dynamic anchoring
ranks next.
The issue with anchoring is continued use of gateways or anchor
points and exposure to single-point failure. Also roaming policies
of the operator are enforced at the mobility anchors. So the
operators are almost encouraged to setup such anchors and it is not
clear how much the user benefits from it.
4. Identifier Locator Separation Systems
Identifier locator separation systems like ILNP, LISP and ILA may
present themselves as an effective solution to packet delivery data
plane protocol without tunneling. They can also handle mobility as
well as correspondent node mobility updates with already standardized
control plane extensions, e.g. ILNP.
It should be noted that open source systems have recently started to
pay attention to the identifier locator addressing systems. Fast
Data open source initiative is a good example [FD.io]. FD.io has
recently included identifier locator addressing as one of the network
services in its Vector Packet Processor (VPP) features as of version
17.1.
von Hugo, et al. Expires August 1, 2018 [Page 4]
Internet-Draft nextgenprot January 2018
We will attempt to cover the issues with using Id-Loc systems in 5G.
Identifier space
Most systems use 64-bit identifiers because of the commonly used
64-bit division of 128 bit IPv6 address. However it can be argued
that it is difficult to derive globally unique identifiers only using
64 bits. So it is better to use longer identifiers, e.g. 80 bits or
longer.
Charging of User Data
Packet delivery without tunneling removes the need for gateways and
anchor points but also raises the issue of user data charging. How
to achieve user data charging without tunneling to a specific
charging gateway becomes an issue. We should mention that unlimited
user data plans are becoming more and more popular and this helps
solve the problem.
Privacy Issues
The use of identifiers unique for each user brings privacy issues.
If the identifier is stolen then your traffic can be unlawfully
tracked, there could be serious implications of it.
Privacy of identifiers is especially an issue for a UE communication
with a server like Google, Facebook, LinkedIn, etc.
Privacy issue can be mitigated only if Id-Loc system has proxy mode
of operation. In proxy mode, user traffic is intercepted by a proxy.
Proxy node which could be placed at the subnet router or site border
router. The router tunnels the traffic to the server. In the
process UE identifier becomes hidden and this hopefully removes
privacy issues.
5G specific identifiers can also used to deal with privacy issues.
IMSI is known to be 64 bit and unique for each UE. IMSI should not
be exposed to any entities. It is like 64-identifier. Instead
identifiers like 5G-GUTI can be used.
5. Work Plan
Work plan will include development of the following documents:
GTP documentation. GTP-U will be documented emphasizing IETF
relevant aspects. GTP-U lends itself to better explain the issues in
the fifth generation wireless networks.
von Hugo, et al. Expires August 1, 2018 [Page 5]
Internet-Draft nextgenprot January 2018
Deployment/application of ILA/ILNP to fifth generation wireless
network architecture.
The aim will be to show the flexibility and delay minimization that
can be achieved only if ILA/ILNP can be used in the data plane,
because every packet from/to a UE in fifth generation wireless
networks needs to traverse the virtual network function called UPF
which is the IP anchor point and this will create unnecessary delay.
Slicing will considered. The feature may enable faster deployment
since slices can be instantiated with ILA/ILNP support. Performance
in case of UE mobility can be compared in slices with and without
identifier locator addressing support.
6. IANA Considerations
TBD.
7. Security Considerations
TBD.
8. Acknowledgements
The authors would like to express their thanks for contributing and
interesting discussions to Alex Petrescu, Arashmid Akhavain, Saleem
Bhatti, and Tom Herbert.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[ETSI NGP] ETSI White Paper No. 17, "Next Generation Protocols -
Market Drivers and Key Scenarios", May 2016
[FD.io] White paper "FD.io - Vector Packet Processing", July 2017,
available at https://fd.io/wp-content/uploads/sites/34/
2017/07/FDioVPPwhitepaperJuly2017.pdf
von Hugo, et al. Expires August 1, 2018 [Page 6]
Internet-Draft nextgenprot January 2018
Authors' Addresses
Dirk von Hugo
Deutsche Telekom AG
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Email: Dirk.von-Hugo@telekom.de
Behcet Sarikaya
Email: sarikaya@ieee.org
von Hugo, et al. Expires August 1, 2018 [Page 7]
