[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                        D. von Hugo
Internet-Draft                           Telekom Innovation Laboratories
Intended status: Informational                               B. Sarikaya
Expires: May 17, 2017                                             Huawei
                                                       November 13, 2016


  Review on issues in discussion of next generation converged networks
                     (5G) from an IP point of view
                   draft-vonhugo-5gangip-ip-issues-01

Abstract

   This document presents considerations related to open and upcoming
   issues with upcoming new communication systems denoted as 5G aiming
   to set a basis for documenting problem space, use-cases, and
   potential solutions related to next-generation network
   infrastructure.  The draft reviews currently investigated topics,
   including both inputs from IETF and from other SDOs as well as
   research activities.  Further the outcome of recent discussions at
   side sessions during IETF meetings are recaptured to help identifying
   a starting point for future thoughts.

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 May 17, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://trustee.ietf.org/license-info) in effect on the date of



von Hugo & Sarikaya       Expires May 17, 2017                  [Page 1]


Internet-Draft                5G IP Issues                 November 2016


   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.  Problem Space and Typical Use Cases . . . . . . . . . . . . .   4
     2.1.  Ubiquitous Broadband Access Use Case  . . . . . . . . . .   4
     2.2.  Massive Deployment of Machines Use Case . . . . . . . . .   4
     2.3.  Critical Communications Use Case  . . . . . . . . . . . .   4
   3.  Requirements to Future Communication Systems  . . . . . . . .   4
   4.  Current Activities and Areas of Work within IETF/IRTF . . . .   5
   5.  Future Internet Architecture  . . . . . . . . . . . . . . . .   6
   6.  Edge Network with no Tunneling  . . . . . . . . . . . . . . .   8
   7.  Logical Network Isolation (Slicing) Concepts  . . . . . . . .   9
   8.  Location Identification Separation and Naming . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     13.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document focuses on IP architecture and protocol aspects related
   to upcoming new communication system infrastructure.  This envisaged
   5G system is foreseen to be available from 2020 onwards to provide a
   converged Information and Communication Technology (ICT) ecosystem.
   The offered broad spectrum of fixed and mobile services will be
   characterised mainly by improved flexibility and efficient usage of
   available resources to support services' demands with partially
   contradicting requirements.  A new highly re-configurable
   architecture in both heterogeneous access and a converged core
   network shall allow for key features as

   o  Stable selectable low latency

   o  Granted reliability and availability according to user and service
      demands





von Hugo & Sarikaya       Expires May 17, 2017                  [Page 2]


Internet-Draft                5G IP Issues                 November 2016


   o  Potential (adaptive) mobility support (i.e. on demand): in case of
      change in device or service location or as countermeasure to
      partial failures /outage

   o  Low cost (i.e. affordable and related to service characteristics)
      with respect to both investment and operational expenses:
      efficiency in terms of resource consumption and effort

   o  Adaptive support of service quality in terms of (raw network)
      performance and individual user experience (requiring end-to-end
      monitoring and feedback)

   o  Selectable inbuilt security: different measures to be chosen from
      a tool box

   o  Improved resource efficiency (e.g. in terms of energy consumption,
      processing power, data storage, and radio spectrum usage)

   o  High flexibility for new services (and service features)
      introduction and deployment

   o  Much better scalability in terms of amount of supported end
      devices and transferred data rates and volume

   o  Higher bandwidth, data rate and throughput shall be achieved with
      new radio technologies (multiple antennas) and usage of multiple
      potentially heterogeneous technologies in concurrence
      (multiaccess), bandwidth/ broadband access values exceeding 1Gbps.

   A network to serve diverse demands ranging between very strict and
   quite relaxed requirements asks for dynamic feature selection per
   network functionality and thus will be much more software centric.
   Only an architecture with modular control plane functions will enable
   service tailored selection or adaptation of network characteristics
   in terms of functionalities.

   Also the expected high flexibility and resource efficiency demands
   for exploitation of SDN and NFV together with computation and storage
   space provision in central or distributed cloud environments.

   In addition a new architecture with modular control plane functions
   is required to enable service tailored selection or adaptation of
   network characteristics in terms of functionalities.

   Decoupling and abstraction of access and core domains to allow for
   heterogeneity enabling higher flexibility and resource usage
   efficiency is a request to 5G systems.




von Hugo & Sarikaya       Expires May 17, 2017                  [Page 3]


Internet-Draft                5G IP Issues                 November 2016


2.  Problem Space and Typical Use Cases

   The design of the new 5G system faces challenging requirements which
   are derived from potential prospective services to be provisioned via
   the 5G ecosystem.  To illustrate the broad range of diverse demands
   out of the plentitude of use cases as identified e.g. in [NGMN] a set
   of three exemplary use case families is presented below following
   [METIS].

   Generally all such services cannot and have not to be provided within
   one specifically configured logical network.  Flexibility to allow
   different adaptations of the same physical infrastructure to fulfill
   one tenants or verticals (service providers) requests is essential
   for an appropriate 5G system concept.

2.1.  Ubiquitous Broadband Access Use Case

   These group of use cases covers fixed, portable, and mobile
   applications between user equipment and servers in the network which
   may be characterized by large bandwidth requirements, support of
   moving devices, typical multimedia services between humans and
   between humans and content in the network to only name a few.

2.2.  Massive Deployment of Machines Use Case

   The MTC or IoT use cases cover generally a large amount and dense
   deployment of devices (sensors, metering) as smart grid or of
   Industry 4.0 type, but also vehicular communication.

2.3.  Critical Communications Use Case

   Here a strict latency and reliability limit has to be considered
   since services are time-critical or need high delivery probability.

3.  Requirements to Future Communication Systems

   Derived from the use case scenarios a list of requirements for 5G has
   been established by several organisations as e.g.  NGMN or 3GPP
   denoting as key issues or key design principles or key drivers, for
   details see e.g. 3GPP [TR23.799].  Also ITU has identified key
   capabilities of IMT-2020, i.e. the International Mobile
   Telecommunications (IMT) system for 2020 and beyond, which can be
   found in [M.2083].

   Beside quantitatively measurable Expected enhancement of performance
   parameters as

   o  User experienced data rate: 100 vs. 10 Mbit/s



von Hugo & Sarikaya       Expires May 17, 2017                  [Page 4]


Internet-Draft                5G IP Issues                 November 2016


   o  Spectrum efficiency 3 times that of IMT Advanced

   o  Mobility support for up to 500 km/h instead of 350 (only)

   o  Latency (of 1 vs. 10 ms), Latency down to 1ms could be foreseen
      for 5G

   o  Connection density of 1 Million vs. 100000 devices/km )

   o  Network energy efficiency of 100 times improved

   o  Area traffic capacity of 10 vs. 0.1 Mbit/s/m2

   o  Peak data rate of 20 instead of below 1 Gbit/s

   Other key improvements which are not always direct quantitatively
   measurable cover so-called soft features are also essential for 5G:

   o  Network scalability and flexibility

   o  Logical network separation (slicing)

   o  Consistent customer experience

   o  Service and network trust, reliability and security

   o  Operational efficiency

   o  Openness for innovation

4.  Current Activities and Areas of Work within IETF/IRTF

   Although a vertical topic as 5G is seen not as IETF topic ( providing
   standardized building blocks for specific engineering challenges
   "horizontals."  IETF does not define or adapt "vertical" frameworks
   like "Smart Cities," "Internet of Things," or "5G networks."  It is
   implicitly assumed that the participants will apply the building
   blocks within the verticals
   [I-D.arkko-ietf-trends-and-observations].), the topic creates issues
   on multiple horizontal levels as is reflected within drafts and
   discussions in WGs such as LISP (Locator/Identifier Separation
   Protocol), NVO3 (Network Virtualization Overlays).  Furthermore IRTF
   RGs with focus on 5G topics are NFV(Network Function Virtualization),
   SDN (Software Defined Networking), and ICN (Information Centric
   Networking).






von Hugo & Sarikaya       Expires May 17, 2017                  [Page 5]


Internet-Draft                5G IP Issues                 November 2016


   The current activities there contribute to one or more of the
   following issues addressed in more detail during the preceding side
   meetings of the 5GangIP mailing list archive.

5.  Future Internet Architecture

   Currently the efforts are in its beginning stages of defining,
   designing or optimizing protocols for a more efficient internet to
   provide mobility, scale, security and ease of deployment required for
   a connected society beyond the year 2020.  But the industry seems to
   be divided by what should qualify as a true 5G.  One approach to 5G
   is:

   5G radio + 4G Core (with improvements)

   This approach takes 4G/LTE core, i.e. the current core network as 5G
   core.  However, what is in demand should be

   5G radio + 5G Core

   As a truly 5G, the real distinguisher lies in designing a new core to
   meet the 5G requirements.  The new core may also allow for connection
   via enhanced 4G radio for reasons of operational continuity.

   The current IP is connectivity-centric.  Additional features such as
   mobility and security are added as optional patches and fix-ups.
   Moreover, protocols have been designed in a segmented way instead of
   an architectural way.

   Future Internet Architecture attempts to look at the current user/
   data plane protocol stack that is in use in both fixed and mobile
   networks and redesign it.  One issue the future internet architecture
   addresses is the number of layers below the IP layer.

   If we consider the current LTE radio protocol stack, we can easily
   find that there are 6-plus layers, with PDCP, RLC, MAC and PHY being
   the ones below IP layer.  Each layer adds some bytes to the header,
   some layers have their own checksums, i.e. more overhead.  However,
   in cellular Internet of Things, (IoT) a packet may have only 1 byte
   payload.  In this case, we would not call it efficient, the
   efficiency rate is less than 1%, with the efficiency rate defined as
   (payload length)/(packet size).

   Future internet architecture deals with data plane protocol stack
   reduction issues like:

   Which layers could be reduced?




von Hugo & Sarikaya       Expires May 17, 2017                  [Page 6]


Internet-Draft                5G IP Issues                 November 2016


   How can we deal with multiple checksums, since it is very expensive
   to compute checksums, remembering we only have 1ms latency budget?

   Should we design a new type of protocol that does not reuse the
   existing ones to make the network more efficient?  Such a clean slate
   approach would expose a high degree of disruption.

   What would happen if we take away GTP, LTE's tunneling protocol?  For
   more discussion on this see Section 6.

   Future internet architecture proposes a unified layering for both
   fixed and mobile networks.  In the IP layer, we have Identifier
   Oriented Networking or IP protocol.  Below this, we have the next
   generation medium access control protocol providing a unified medium
   access to 5G radio, 802.11 or Wi-Fi and Ethernet type of fixed access
   technologies.  The lowest layer is the next generation physical layer
   protocol unifying all physical accesses to 5G-era.

   In the control plane, there are even much more we need to consider.
   For example, the current internet is operated by routing protocols
   and their extensions.  These protocols are usually driven by Command
   Line Interfaces (CLIs) on the first hand, e.g. for protocols like
   OSPF [RFC5340] will work as instructed by the commands in CLI.

   However, in 5G, there will be many moving things, perhaps with low-
   power so that at one instant they are up and at the next instant they
   are down.  The traditional operation model won't work any more, since
   we can't easily configure them and we don't want their mobility and
   status change affecting the routing tables, Routing Information Base
   (RIB) frequently.

   In this case, mobility issue will arise.  A cell phone moves, but its
   identifier (ID) does not change.  Can LISP-mobile [I-D.meyer-lisp-mn]
   based on LISP [RFC6830] be used for this use case, i.e. also handle
   e.g.  session continuity in case of multi-connectivity?  Which
   further extensions and modifications might be needed to re-scope the
   approach to apply for the required mobility?  ID plays a central role
   in mobility.  Can we design a new protocol, say ID-Oriented
   Networking Protocol?  In future, more and more mobile things are
   connected to the internet which may not yet have proper identifiers
   available compared to cell phones (see e.g.
   [I-D.ietf-dmm-4283mnids]): things like connected cars, connected
   drones, etc.

   For more discussion on this see Section 8.






von Hugo & Sarikaya       Expires May 17, 2017                  [Page 7]


Internet-Draft                5G IP Issues                 November 2016


6.  Edge Network with no Tunneling

   In fixed network, PPPoE protocol [RFC2516] is used between the
   residential gateway and broadband network gateway to transport the
   residential users IP packets to the fixed network gateway to the
   Internet.  PPPoE protocol requires 8 octets of header in every IP
   packet, thereby reducing the MTU size by 8 octets to usually 1492
   octets.  PPPoE protocol is carried in Ethernet frames with 18 octet
   headers where the destination address is the broadband network
   gateway address.

   Aiming at an IP protocol unaware/agnostic/overarching control plane
   logic multiple protocol approches can be deployed depending on actual
   service and slice demands, such as e.g. those based on low-overhead
   translation mechanisms and encapsulation-based ones on the other
   hand.  If a client-based mapping between Identifier and Locator is
   required (i.e. executed on a user terminal) translation would be the
   recommended approach.  For network-centric deployment a LISP-like
   mapping function on gateways or the session terminating servers and
   data centers can be deployed.  How such a control plane could look
   like on L2/L3 to support LISP has recently been described in
   [I-D.portoles-lisp-eid-mobility].

   In mobile network, IP packets are tunneled using GTP data plane
   protocol called GTP-U.  First eNodeB or the base station tunnels UE's
   IP packets to the Serving Gateway, in S1 GTP tunnel and then the
   serving gateway tunnels to the Packet Gateway, called S5 tunnel.
   Both of them are UDP tunnels which adds 8 octet header and GTP
   protocol header is 12 octets, so a total of 20 octets are used.  In
   addition also an IPSec header should be accounted for between eNodeB
   and SGW.

   On the other hand in an end-to-end path between UEs or towards the
   Application Function the network has either to keep a lot of status
   information (meta data) for finding and maintaining the optimum path
   - or apply encapsulation with specific headers between eNB and SGW/
   PGW - as tunneling.  As exemplarily shown above, however, tunneling
   adds a lot of overhead to the user IP packets and therefore
   inefficiencies arise including reducing the MTU size.

   If tunneling can be avoided, i.e. if edge networks can be designed
   with no tunneling, a corrollary of this would be no gateways would be
   needed, leading to edge networks with no tunneling or no gateway.
   The means to avoid gateways and tunneling a direct end-to-end routing
   has to be established in the edge network.

   With routing support edge networks can direct the user traffic to the
   correct destinations, rather than tunneling to the gateways.  In



von Hugo & Sarikaya       Expires May 17, 2017                  [Page 8]


Internet-Draft                5G IP Issues                 November 2016


   order to deal with user mobility, ID-oriented networking protocol
   would be needed.  So it needs to be evaluated if using ID-oriented
   networking protocol with routing will lead to more efficient delivery
   of user IP packets in the edge network compared with 4G edge network
   techniques of tunneling with gateways.

   As we deal with carrier-grade networks here also the aspects of AAA
   and charging have to be considered.  The main reason why tunneling is
   used in 4G edge networks and broadband network is to direct the user
   traffic so that the operator can charge the user properly.  Edge
   networks with no gateways should enable enough control to the
   operators so that charging on the user traffic is properly conducted.

   Optimum use of available resources may also require a common control
   framework including e.g.  user plane communication between devices
   directly or via relays / access nodes only.  How such an efficient,
   scalable, and performant solution in case of mobility has to be
   designed - preferably without much effort due to complex state
   handling - is one of the challenging questions.

7.  Logical Network Isolation (Slicing) Concepts

   Within the framework of 5G a network slice is seen as an independent
   logical end-to-end network, defined by a set of specific network
   functions providing service-specific network characteristic
   (performance).  The basic Network Functions can be both physical and
   virtual in nature, and comprise C-plane and D-plane tasks (maybe
   supplemented by Management), and should be independently instantiated
   and operated.  Identified related work in IETF on aspects of single
   virtualized network control cover the ACTN (Abstraction and Control
   of Traffic Engineered Networks) activity in TEAS (Traffic Engineering
   Architecture and Signaling) WG.

   Corresponding discussion is also under way in IRTF NFVRG analysing
   gaps of current approaches with respect to virtual network instances'
   operation and inter-operation.

8.  Location Identification Separation and Naming

   With both physical and logical mobility of (an extremely high number
   of) entities and virtualization of network functions the traditional
   usage of IP addresses for denoting both IDentifier and Address or
   logical entity and location as source or destination of data packets
   becomes cumbersome.  New approaches to solve the issues are proposed
   in LISP WG in terms of [RFC6830] and ICN RG (see [RFC7476]) but also
   ILNP [RFC6740] and ILA [I-D.herbert-nvo3-ila] address this challenge.





von Hugo & Sarikaya       Expires May 17, 2017                  [Page 9]


Internet-Draft                5G IP Issues                 November 2016


   By separating a Routing LOCator (RLOC) from a unique Identity (EID)
   LISP keeps a single address to each session endpoint even in multi-
   homing but requires a dedicated mapping mechanism for compatibility
   with the (LISP-unaware) Internet.  ILNP (and ILNP-based ILA) avoid
   encapsulation and require no changes in higher layers (except the
   transport layer) re-using part of an (IPv6) Address as Identifier and
   Locator.  ILA does not require any changes in transport layer but it
   is IPv6 only.

   In LISP the EID/RLOC split can be collocated in the same entity: EID
   mobile, RLOC static or dynamic.  Predictive RLOCs
   [I-D.farinacci-lisp-predictive-rlocs] can be used if LISP entity
   knows where the user going so that the system can mitigate mobility
   impacts.  LISP can be used between the Serving and Packet data
   Gateways.  Best solution is to keep LISP close to the moving entity
   with the functions as close to the edge as possible.

   ILNP defines minimal changes on IPv4 and IPv6, it requires changes on
   the domain name system and the transport layer [RFC6740].  Both ILNP
   and ILNP-based ILA rely on the routing system or LTE core network to
   route to the translated address.

   LISP requires routing system changes, it is implemented on the
   routers, possibly on the edge routers.  That means LISP requires
   changes on LTE core network.  ILNP does not use encapsulation so it
   is light weight.  LISP is UDP encapsulated so in IPv6, LISP messages
   incur 52 bytes of overhead.

   ILNP nodes send Locator Update messages which are ICMPv4/v6 messages
   to its correspondent nodes when its Locator value changes during an
   active session.  Correspondent node could be a fixed node such as
   Google server which means ILNP has to be implemented by the fixed
   nodes as well.

   ILA is a major update to ILNP [I-D.herbert-nvo3-ila].  It is
   originally designed for network virtualization to be used in cloud
   networks.  ILA can encode a virtual network identifier (VNID) and
   virtual address as an ILNP identifier.  ILA can be adopted for
   mobility and it can be applied to LTE network, the result can be
   called mobile-ILA.  This effort is undergoing.  These aspects of ILA
   are described in [I-D.mueller-ila-mobility].  An open question here
   is to use a proper mapping system which is more efficiently scalable
   and responsive to frequent updates than DNS which originally was not
   designed for mobility [I-D.padma-ideas-problem-statement] .

   As already mentioned in Section 5 LISP aspects relevant for mobility
   support are described in [I-D.meyer-lisp-mn].




von Hugo & Sarikaya       Expires May 17, 2017                 [Page 10]


Internet-Draft                5G IP Issues                 November 2016


   To summarize for IDentifier/Locator split three protocols are under
   discussion which provide improved data/user plane routing as
   candidates:

   o  ILA as a host-based solution that uses translation.

   o  ILNP as a host or router based solution that uses translation.

   o  LISP as a host or router based solution that uses encapsulation.

   Also a combination of ILA and LISP to serve both host- and network-
   based multi-homing across multiple domains can be thought of.

   These protocols may also serve as the basis of an ID-oriented
   networking protocol for 5G yet to be designed and standardized.

   As none of the mentioned existing proposals fully covers the 5G
   requirements consistently, in this document, the authors propose the
   following steps for investigations on further enhancements that have
   to be performed.

   Problem statement on the need for ID-oriented networking protocol,
   exploiting LISP, ILNP and ILA efforts.

   Requirements on a new ID-oriented network protocol in view of 5G
   requirements such as in Section 3, and issues such as in Section 6.

   A document on possible solution space investigations.

9.  IANA Considerations

   None.

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

11.  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 (details have to be added).




von Hugo & Sarikaya       Expires May 17, 2017                 [Page 11]


Internet-Draft                5G IP Issues                 November 2016


   Especially as Identifiers and mapping of locators to them are
   addressed the discussion on identifier and privacy should consider
   existing solutions such as 3GPP Globally Unique Temporary UE Identity
   (GUTI) which is a temporary identity obfuscating the permanent
   identity in the mobile network and specified in [TS23.003].

12.  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 and careful review by Dino Farinacci as well as
   contributions by Tom Herbert, Julius Mueller, Robert Moskowitz and
   others of the 5GangIP mailing list are gratefully acknowledged.

13.  References

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

13.2.  Informative References

   [I-D.arkko-ietf-trends-and-observations]
              Arkko, J., Atlas, A., Doria, A., Gondrom, T., Kolkman, O.,
              olshansky@isoc.org, o., Schliesser, B., Sparks, R., and R.
              White, "IETF Trends and Observations", draft-arkko-ietf-
              trends-and-observations-00 (work in progress), February
              2016.

   [I-D.farinacci-lisp-predictive-rlocs]
              Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
              RLOCs", draft-farinacci-lisp-predictive-rlocs-00 (work in
              progress), May 2016.

   [I-D.herbert-nvo3-ila]
              Herbert, T., "Identifier-locator addressing for IPv6",
              draft-herbert-nvo3-ila-03 (work in progress), October
              2016.







von Hugo & Sarikaya       Expires May 17, 2017                 [Page 12]


Internet-Draft                5G IP Issues                 November 2016


   [I-D.ietf-dmm-4283mnids]
              Perkins, C. and (. (Unknown), "MN Identifier Types for RFC
              4283 Mobile Node Identifier Option", draft-ietf-dmm-
              4283mnids-03 (work in progress), November 2016.

   [I-D.meyer-lisp-mn]
              Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
              Mobile Node", draft-meyer-lisp-mn-15 (work in progress),
              July 2016.

   [I-D.mueller-ila-mobility]
              Mueller, J. and T. Herbert, "Mobility Management for 5G
              Network Architectures Using Identifier-locator
              Addressing", draft-mueller-ila-mobility-01 (work in
              progress), October 2016.

   [I-D.padma-ideas-problem-statement]
              Pillay-Esnault, P., Farinacci, D., Meyer, D., Lake, D.,
              Herbert, T., Menth, M., Raychadhuri, D., and J. Mueller,
              "Problem Statement for Mapping Systems in Identity Enabled
              Networks", draft-padma-ideas-problem-statement-00 (work in
              progress), September 2016.

   [I-D.portoles-lisp-eid-mobility]
              Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
              F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
              Unified Control Plane", draft-portoles-lisp-eid-
              mobility-01 (work in progress), October 2016.

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

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
              February 1999, <http://www.rfc-editor.org/info/rfc2516>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <http://www.rfc-editor.org/info/rfc5340>.




von Hugo & Sarikaya       Expires May 17, 2017                 [Page 13]


Internet-Draft                5G IP Issues                 November 2016


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

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,
              <http://www.rfc-editor.org/info/rfc7476>.

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

   [TS23.003]
              "3GPP TS23.003, Numbering, addressing and identification
              (Release 14)", September 2016.

Authors' Addresses

   Dirk von Hugo
   Telekom Innovation Laboratories
   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










von Hugo & Sarikaya       Expires May 17, 2017                 [Page 14]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/