Internet DRAFT - draft-xyx-5gip-ps

draft-xyx-5gip-ps







Network Working Group                                        D. von Hugo
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                               B. Sarikaya
Expires: November 23, 2017                                        Huawei
                                                              T. Herbert
                                                              Quantonium
                                                               K. Satish
                                                                   Nokia
                                                               R. Schott
                                                        Deutsche Telekom
                                                                  S. Seo
                                                           Korea Telekom
                                                            May 22, 2017


             5G IP Access and Session Management Protocols
                          draft-xyx-5gip-ps-01

Abstract

   This document builds upon 5G IP issues work and - based on a
   simplified 5G system architecture - attempts to make the case for a
   possible set of new protocols that need to be developed to be used
   among various virtualized functions in a 5G network.

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/.

   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 November 23, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





von Hugo, et al.        Expires November 23, 2017               [Page 1]

Internet-Draft          5G IP Problem Statements                May 2017


   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
   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Converged Access-Agnostic Core Network  . . . . . . . . . . .   3
   4.  Access  Management Protocols  . . . . . . . . . . . . . . . .   7
   5.  Mobility Management Protocols . . . . . . . . . . . . . . . .   8
   6.  Session Management Protocols  . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Current networking infrastructure is moving towards a converged
   common core network serving wireline and wireless access networks to
   which the end users are connected.  Such a network if realized in
   terms of 5G project being undertaken worldwide is expected to meet
   the stringent requirements discussed in
   [I-D.vonhugo-5gangip-ip-issues].

   In this document we elaborate upon 5G system architecture which is
   composed of modularised adaptable network functions of control plane
   and data plane and their interconnections.  Much of this
   functionality is expected to be implemented as virtualized functions
   running in central and/or distributed computation environment (cloud)
   as well as traditional physical entities in parallel.

   We discuss IP level protocols that need to be developed.  The
   discussion is based on and builds upon existing documents on mobility
   management and access management.  Identifier Locator Addressing
   (ILA) protocol is designed as a data plane protocol for task
   communication and migration in L3 based data center networks



von Hugo, et al.        Expires November 23, 2017               [Page 2]

Internet-Draft          5G IP Problem Statements                May 2017


   [I-D.herbert-nvo3-ila].  ILA can also be used in user mobility.  This
   aspect of ILA is investigated in [I-D.mueller-ila-mobility]  by
   attempting to apply it directly to 4G 3GPP Evolved Packet System
   (EPS).

   Regarding access management, a framework allowing clients and
   networks in a multi-network scenario to negotiate combination of
   uplink and downlink paths taking into account client's application
   needs and network conditions has been developed in
   [I-D.kanugovi-intarea-mams-protocol].  A control plane protocol for
   configuring the user plane in a multi access management framework
   that can be used to flexibly select the combination of uplink and
   downlink access and core network paths is described in
   [I-D.zhu-intarea-mams-control-protocol].  A data plane protocol for
   multiplexing end to end connections is described in
   [I-D.zhu-intarea-mams-user-protocol] using trailer approach, i.e. the
   IP header of a Multi-Access (MX) PDU is extended by a newly defined
   MX trailer containing data to indicate control procedures and
   identities to support that multiple connections can be integrated
   building up a single end-to-end connectivity.

2.  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 [RFC2119].

3.  Converged Access-Agnostic Core Network

   Key principles and concepts in 5G system architecture include
   separation of User Plane (UP) functions from the Control Plane (CP)
   functions, allowing independent scalability, evolution, and a
   flexible deployment at e.g. centralised location or distributed
   (remote) locations; the concept relies on a new definition of the
   network functions, e.g. to enable flexible and efficient provision of
   logically separated network slices.  Network slicing with slice
   instantiations that may include components served by fixed networks
   is another innovation in 3GPP 5G system architecture as well as the
   definition of a common core network which is access agnostic.
   Wherever applicable, procedures (i.e. the set of interactions between
   network functions) are defined as services, so that their re-use is
   possible.  Each Network function (NF) can interact with the other NF
   directly if required.  The architecture does not preclude the use of
   an intermediate function to help route control plane messages.  On
   the other hand, the architecture shall be flexible enough to allow
   for hassle-free introduction of newly specified network services if
   required by a specific network slice for a prospective new use case.




von Hugo, et al.        Expires November 23, 2017               [Page 3]

Internet-Draft          5G IP Problem Statements                May 2017


   Currently network infrastructure is being transformed into two-layer
   data center or cloud as Core Network (CN) and the Access Network (AN)
   which mainly accommodates 5G radio access network on the wireless
   side and central office on the wireline network closer to the user.
   This new architecture enables us to flexibly deploy 5G Virtual
   Network Functions (VNFs) based on the service scenarios.  The
   division of work in this case is to deploy 5G control plane VNFs and
   5G data plane VNFs with related applications in both the central core
   cloud and distributed local edge clouds.

   Especially for new ultra low latency services offering vehicular
   communications a placement of both user data plane functions (e.g.
   caches or anchors) and corresponding control plane tasks (e.g.
   activating and monitoring them) near the points of attachment (e.g.
   road side radio antennas) may be required.

   These Network Function names as defined in current version of draft
   3GPP specifications are given here exemplarily and shall serve for
   illustrative purposes only.  The final version of the architecture is
   still under discussion.

   5G system architecture is based on a complete system operation
   including policy control, authentication, quality of service (QoS),
   subscriber profiles and charging which are not of interest to us in
   this document.  Based on this abstraction we can simplify the
   architecture with the elimination of the corresponding network
   functions and their interconnections.  The resulting simplified
   system architecture is shown in Figure 1.  The rectangles are the
   network functions and the lines are their interconnections.  Network
   Function names are given on the right hand side.

                      +---+     +---+
              ________|AMF|-----|SMF|
            /         +---+     +---+
           /         /           /
          /         /           /                   Access and Mobility
         /        /            /                       Function (AMF)
        /        /            /                     Session Management
      /         /            /                          Function (SMF)
    /         /             /                       Data Network, e.g.
  /         /             /                            Internet (DN)
+--+     +-----+        +---+        /---\          User Equipment(UE)
|UE|-----|(R)AN|--------|UPF|------ |  DN | (Radio)Access Network ((R)AN)
+--+     +-----+        +---+        \---/     User Plane Function (UPF)

                Figure 1: Simplified 5G System Architecture





von Hugo, et al.        Expires November 23, 2017               [Page 4]

Internet-Draft          5G IP Problem Statements                May 2017


   Access and Mobility Management Function (AMF) is in charge of
   registration management, connection management, reachability
   management, mobility management.  It does access authentication and
   access authorization.

   Session Management Function (SMF) is in charge of session
   establishment, modify and release, including tunnel maintenance
   between UPF and the access network (AN) node (if applicable).  UE IP
   address allocation and management (incl. optional authorization),
   selection and control of the user plane (UP), i.e. data plane
   function.  SMF configures traffic steering at UPF to route traffic to
   proper destination (i.e. the corresponding Data Network, DN);
   initiator of AN specific SM information, sent via AMF to AN; support
   for interaction with external DN for transport of signalling for PDU
   session authorization/authentication by external DN.

   User Plane Function (UPF) is anchor point for mobility; external PDU
   session point of interconnect to Data Network; Packet routing and
   forwarding; Packet inspection and User plane part of Policy rule
   enforcement; uplink classifier to support routing traffic flows to a
   data network; branching point to support multi-homed PDU session;
   transport level packet marking in the uplink and downlink; downlink
   packet buffering and downlink data notification triggering.

   The reference points in the original 5G system architecture
   [TR23.501], [TR23.502] usually carry a specific protocol such as GTP
   (GTP-C for control plane, e.g. over N2 or GTP-U for data plane, e.g.
   over N3) or Non-Access Stratum (NAS) of 3GPP.  Access and Mobility
   Management Function (AMF) is the Network Function (NF) that
   terminates N1 and N2.  User Plane Function (UPF) is the NF that
   terminates N3.  N1 which is the reference point between UE and AMF
   represents interactions going over (R)AN but these interactions are
   transparently relayed by (R)AN.  That is the difference between N1
   and N2 which is the reference point between (R)AN and AMF.

   According to 5G architecture, 5G UE is expected to use Non-Access
   Stratum (as opposed to Access-Stratum (AS) which is used between
   access network and UE) signaling for establishment of communication
   sessions and for maintaining continuous communications with the user
   equipment as it moves in 5G core network even when UE is connected to
   5G core network via a non-3GPP access network, e.g. over Wi-Fi,
   oftentimes simultaneously to the wireless radio access network (RAN).
   Some of the procedures for the 5G system being defined in [TR23.502]
   are to be used in establishing an IP link, like Non-Access Stratum
   signaling.  Such link layer aspects of 5G System Architecture are out
   of scope.





von Hugo, et al.        Expires November 23, 2017               [Page 5]

Internet-Draft          5G IP Problem Statements                May 2017


   In the simplified 5G system architecture, our interest in this
   document is to use IETF protocols in the interconnection points shown
   in Figure 1.  The goals of the work will involve:

   o  Align with the identifier usage, e.g. 64-bit identifier for UE,
      e.g.  International Mobile Subscriber Identity (IMSI)

   o  Adopt the same network functions, e.g.  Access and mobility
      Management Function, Session Management Function (SMF), User Plane
      Function (UPF)

   o  Address multiple access issue in the access management and also
      session management

   o  Adopt the identifier locator addressing protocol which does not
      involve tunneling for mobility management

   o  Define address allocation function of the session management as
      part of the mobility management protocol

   o  Define session and service continuity as part of the session
      management

   o  5G IoT.  Addressing of large number of small IOT devices by way of
      globally unique prefixes would be a challenge unless they are
      considered local, possibly requiring some proxies and
      encapsulation

   One of the challenges in 5G FMC is how to provide seamless mobility
   when 5G UE while in a 5G radio access network later moves to an area
   of served by a Wi-Fi access point connected to a central office
   within the fixed network while both access networks are served by a
   converged common core.  Another challenge is to enable flexible and
   seamless management of the user sessions while accessing the network
   sometimes simultaneously over UE's multiple interfaces, e.g. 5G and
   Wi-Fi.

   In the next sections, we discuss access (Section 4) and mobility
   (Section 5) and session (Section 6) management protocols that need to
   be developed in order to satisfy the key features and requirements of
   the upcoming 5G networks described in
   [I-D.vonhugo-5gangip-ip-issues].  These protocols will be defined to
   be potentially used in the interconnections of the virtualized
   network functions shown in Figure 1.







von Hugo, et al.        Expires November 23, 2017               [Page 6]

Internet-Draft          5G IP Problem Statements                May 2017


4.  Access Management Protocols

   An investigation of multiple access management for a UE that
   simultaneously connects to multiple data networks is presented in
   [I-D.kanugovi-intarea-mams-protocol].

   [I-D.kanugovi-intarea-mams-protocol] sets forward the requirements
   such as enabling connectivity using different access networks.  The
   network path selection and user data distribution should work
   transparently.  Access path selection should be independent for
   Uplink and Downlink.  A common core network independent of the access
   networks should be accessed by the UE.  Network path selection should
   be adaptive to the link quality implications on service specific
   performance requirements.  Distribution and aggregation of user data
   across multiple network paths at the IP layer should be supported.
   Heterogeneous access networks, which may have different MTU sizes
   should be supported using concatenation and fragmentation.

   Based on these requirements, control and data plane functions for
   connection management can be determined.  Network Connection Manager
   (NCM) is the control plane function.  There is a data plane component
   for user data traffic forwarding called Network Multi-Access Data
   Proxy (MADP) which is part of the User Plane Function (UPF) in
   Figure 1.  It can be argued that we also need corresponding client
   side counter part of NCM, called CCM and MADP hosted on the UE.
   Network Multi-Access Data Proxy (MADP), i.e. hosted in AMF in the
   core network handles the user data traffic forwarding across multiple
   network paths, as well as other user-plane functionalities, e.g.
   encapsulation, fragmentation, concatenation, reordering,
   retransmission, etc.  N-MADP is the distribution node for uplink and
   downlink data with visibility of packets at the IP layer.

   Network Connection Manager (NCM) in the core network configures
   identification and distribution rules for different user data traffic
   type at the N-MADP.  The NCM configures the routing in the MADP based
   on signaling exchanged with the CCM in UE.  In the uplink, NCM
   specifies the core network path to be used by MADP to route uplink
   user data at the MADP.  In the downlink, NCM specifies the access
   links to be used for delivery of data to the client at the MADP.

   At the UE, MADP handles encapsulation, fragmentation, concatenation,
   reordering, retransmissions, etc.  C-MADP is configured by CCM based
   on signaling exchange with NCM and local policies at the UE.

   At the UE, CCM manages the multiple network connections.  CCM is
   responsible for exchange of MAMS signaling messages with the NCM for
   supporting functions like configuring uplink and downlink user
   network paths for transporting user data packets, link sounding and



von Hugo, et al.        Expires November 23, 2017               [Page 7]

Internet-Draft          5G IP Problem Statements                May 2017


   reporting to support adaptive network path selection by NCM.  In the
   downlink, for the user data received by UE, it configures IP layer
   forwarding for application data packets received over any of the
   accesses to reach the appropriate application module on the client.
   In the uplink, for the data transmitted by UE, it configures the
   routing table to determine the best access to be used for uplink data
   based on a combination of local policy and network policy delivered
   by the NCM.

   It should be noted that the access management approach still requires
   future work involving consideration of 5G System Architecture
   specifics and carrying out any changes needed correspondingly.

   IP level protocols need to be developed supporting connection
   management in a 5G IP network.  An example is the trailer based
   approach integrating multiple connections into a single end to end IP
   connection.  A multiplexing trailer is added to the end of IP payload
   to flexibly support concatenation and fragmentation.
   [I-D.zhu-intarea-mams-user-protocol] details an approach, however
   there could possibly be other similar approaches.

5.  Mobility Management Protocols

   Next, we discuss mobility management.  Anchor-less mobility in a 5G
   fixed mobile convergence network with a converged core network
   possibly based on identifier and locator separation should be the
   preferred approach as opposed to tunneling approaches with fixed
   anchors, e.g.  or with distributed anchors.

   The prospective approach is to overcome tunneling and encapsulation
   overhead explained in detail in [I-D.vonhugo-5gangip-ip-issues] by
   simplified routing in the edge network according to identifiers not
   bound to locations and thus allowing for relocation within underlying
   infrastructure.  Such an approach should also incorporate session
   management in support of session and service continuity in the 5G
   architecture with a common core enabling mobility in multiple access
   networks.

   Anchor points perform important duties such as policy, accounting
   etc. as well as mapping that cannot be ignored.  In anchor-less
   mobility, without anchor points, UE is the only common device in the
   path to perform these functions.  When anchors are removed then it
   becomes a challenge to provide functions like security and trust.
   One option is to use the UE as the only remaining single anchor point
   to perform its own accounting and policy and other functions.

   There are secure execution environments/processors in UE's these
   days, where all the finger print recognition, password encryption



von Hugo, et al.        Expires November 23, 2017               [Page 8]

Internet-Draft          5G IP Problem Statements                May 2017


   etc. is done and perhaps it is possible to extend these to run secure
   network functions on behalf of the slices.  However, a trusted
   federation between any UE and the corresponding/accessible network
   entities cannot be assumed without doubt in any case.  In view of
   this, virtualizing and distributing anchor point functions, e.g.
   mapping identifiers to the most recent locators, security
   associations (SA), etc. so they can run in the network at the points
   of attachment close to the UE will need to be investigated.

   Transport protocol level independence is a strong requirement in
   identifier locator separation based mobility protocols.  This means
   that UE can have a locator or address but it should not be used as
   connection end point.  The identifier which may not be routable
   should be used as the connection end point.  This enables no
   modifications at the transport layer in the host stack.

   Based on the requirements, Identifier Locator Addressing (ILA)
   protocol [I-D.herbert-nvo3-ila] qualifies to be used as the base
   protocol.  IPv6 operation in the current ILA need to be improved in
   order to be used by the end nodes such as the UEs.  Mobility
   procedures in the control plane need to be defined.  ILA design is
   influenced by UE prefix/address allocation and management which is
   part of Session Management function.  Therefore the two functions
   need to be designed in an integrated fashion.

   Given the prefix assignment techniques to the UEs in effect, the base
   protocol need to be modified and carrying the identifier as an
   extension header similar to the segment routing header may need to be
   considered. for communication with the legacy hosts such as the
   servers encapsulation mode need to be developed involving the base
   ILA encapsulated using the Generic UDP Encapsulation (GUE).

   Multihoming, UEs with more than one network interfaces should be
   supported including simultaneous usage of the interfaces to connect
   to multiple access networks.  ILNP [RFC6740] supports multihoming.
   ILA support could be similarly designed.

6.  Session Management Protocols

   Session management responsible for the setup of the connectivity for
   the UE as well as managing the user plane for that connectivity is
   identified as one of the key issues in 5G system architecture in
   [TR23.799].  Session management design issues include managing
   multiple access, multiple connectivity, multiple transport paths,
   e.g. to RAN and to non-3GPP access network (AN), sometimes
   simultaneously and how to efficiently transmit and receive infrequent
   small amounts of data and short data bursts, e.g. for Narrow Band
   Internet of Things (NB-IoT).



von Hugo, et al.        Expires November 23, 2017               [Page 9]

Internet-Draft          5G IP Problem Statements                May 2017


   The challenges of this kind of session management design include if
   such a design can be simplified so that NB-IoT type of very simple
   sessions can also be handled.  Regarding SMF and AMF, identifying the
   correlation between session management and mobility management,
   identifying the interactions between session management and the
   mobility framework required to enable the various mobility scenarios
   while minimizing any negative impact on the user experience
   investigating solutions to coordinate the relocation of user-plane
   flows with the relocation of applications (hosted close to the point
   of attachment of the UE) due to the mobility of users can be
   considered as the challenges of 5G architecture.

   Network layer or IP session normally has two components: source IP
   address and destination IP address.  In case identifier locator
   separation protocol is used IP session has four components, i.e.
   source locator, source identifier, destination locator and
   destination identifier.  With transport layer independence IP session
   should be composed of source identifier and destination identifier
   only.

   Session management deals with IP address management.  SMF performs IP
   address allocation.  Both IPv4 and IPv6 should be supported.  In an
   identifier locator separation system, IPv4 can be supported
   transparently by keeping the communication in IPv6 and converting the
   addresses at the end points.

   Session continuity in the case of UE mobility should be provided.  In
   an anchorless system, UE mobility incurs changes to the locators.
   Session management should maintain the established sessions when the
   UE moves.  This also involves informing the destinations of the
   locator change.  This is done in the control plane of the mobility
   management.

7.  IANA Considerations

   None.

8.  Security Considerations

   Security considerations related to the 5G systems are discussed in
   [NGMN].  Due to the request for intrinsic realization of security
   such aspects have to be considered by design for architecture and
   protocols.

   Especially as a joint usage of resources and network functions by
   different separate logical network slices (e.g. in terms of virtual
   network functions) seems to be inevitable in the framework of 5G the




von Hugo, et al.        Expires November 23, 2017              [Page 10]

Internet-Draft          5G IP Problem Statements                May 2017


   need for strong security measures in such an environment is a major
   challenge.

9.  Privacy Considerations

   Support of full privacy of the users (customers and tenants / end
   service providers) is a basic feature of the next generation trusted
   and reliable communications offering system.  Such a high degree of
   ensured privacy shall be reflected in the proposed architecture and
   protocol solutions.

   Especially as Identifiers and mapping of locators to them are
   addressed some privacy concerns arise.  Mobility solutions tend to
   expose unique identifiers.  A solution inside the mobile network
   exposes these identifiers to the network operator, which is not a big
   deal since the network operator already has information about the
   device's location.  In contrast, an IP level solution exposes both
   the identifiers and the locations at the IP layer.  That means that
   web sites, for example, can now track the device's successive
   locations by watching the IP address.  Solutions such as transporting
   the identifiers not as part of the IP header should be considered.

10.  Acknowledgements

   This work has been partially performed in the framework of the
   cooperation Config.  Contributions of the project partners are
   gratefully acknowledged.  The project consortium is not liable for
   any use that may be made of any of the information contained therein.

   Comments, constructive critisms from Christian Huitema, Cameron
   Bynes, Lorenzo Colitti, Saleem Bhatti, Mikael Abrahamsson, David
   Lake, Samita Chakrabarti, Jouni Korhonen, Zhu Jing are respectfully
   acknowledged.

11.  References

11.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,
              <http://www.rfc-editor.org/info/rfc2119>.

11.2.  Informative References







von Hugo, et al.        Expires November 23, 2017              [Page 11]

Internet-Draft          5G IP Problem Statements                May 2017


   [I-D.herbert-nvo3-ila]
              Herbert, T. and P. Lapukhov, "Identifier-locator
              addressing for IPv6", draft-herbert-nvo3-ila-04 (work in
              progress), March 2017.

   [I-D.kanugovi-intarea-mams-protocol]
              Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng,
              S., Mueller, J., and S. Seo, "Multiple Access Management
              Services", draft-kanugovi-intarea-mams-protocol-04 (work
              in progress), March 2017.

   [I-D.mueller-ila-mobility]
              Mueller, J. and T. Herbert, "Mobility Management Using
              Identifier Locator Addressing", draft-mueller-ila-
              mobility-03 (work in progress), February 2017.

   [I-D.vonhugo-5gangip-ip-issues]
              Hugo, D. and B. Sarikaya, "Review on issues in discussion
              of next generation converged networks (5G) from an IP
              point of view", draft-vonhugo-5gangip-ip-issues-03 (work
              in progress), March 2017.

   [I-D.zhu-intarea-mams-control-protocol]
              Kanugovi, S., Vasudevan, S., Zhu, J., Baboescu, F., Peng,
              S., and S. Seo, "Control Plane Protocols and Procedures
              for Multiple Access Management Services", draft-zhu-
              intarea-mams-control-protocol-01 (work in progress), March
              2017.

   [I-D.zhu-intarea-mams-user-protocol]
              Zhu, J. and S. Seo, "User-Plane Protocols for Multiple
              Access Management Service", draft-zhu-intarea-mams-user-
              protocol-01 (work in progress), March 2017.

   [M.2083]   ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and
              overall objectives of the future development of IMT for
              2020 and beyond", September 2015.

   [METIS]    Elayoubi, S. and et al., "5G Service Requirements and
              Operational Use Cases: Analysis and METIS II Vision",
              Proc. euCNC, 2016.

   [NGMN]     NGMN Alliance, "NGMN White Paper", February 2015.

   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740,
              DOI 10.17487/RFC6740, November 2012,
              <http://www.rfc-editor.org/info/rfc6740>.



von Hugo, et al.        Expires November 23, 2017              [Page 12]

Internet-Draft          5G IP Problem Statements                May 2017


   [TR23.501]
              "3GPP TR23.501, System Architecture for the 5G System
              (Release 15)", December 2017.

   [TR23.502]
              "3GPP TR23.502, Procedures for the 5G System (Release
              15)", December 2017.

   [TR23.799]
              "3GPP TR23.799, Study on Architecture for Next Generation
              System (Release 14)", December 2016.

Authors' Addresses

   Dirk von Hugo
   Deutsche Telekom
   Deutsche-Telekom-Allee 7
   D-64295 Darmstadt
   Germany

   Email: Dirk.von-Hugo@telekom.de


   Behcet Sarikaya
   Huawei
   5340 Legacy Dr.
   Plano, TX  75024

   Email: sarikaya@ieee.org


   Tom Herbert
   Quantonium

   Email: tom@herbertland.com


   K Satish
   Nokia

   Email: satish.k@nokia.com


   Roland Schott
   Deutsche Telekom

   Email: roland.schott@telekom.de




von Hugo, et al.        Expires November 23, 2017              [Page 13]

Internet-Draft          5G IP Problem Statements                May 2017


   SungHoon Seo
   Korea Telekom

   Email: sh.seo@kt.com















































von Hugo, et al.        Expires November 23, 2017              [Page 14]