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]