Network Working Group D. von Hugo Internet-Draft Telekom Innovation Laboratories Intended status: Informational B. Sarikaya Expires: March 18, 2017 Huawei September 14, 2016 Review on issues in discussion of next generation converged networks (5G) from an IP point of view draft-vonhugo-5gangip-ip-issues-00 Abstract This document discusses considerations related to open and upcoming issues with upcoming new communication systems denoted as 5G. 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 March 18, 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect von Hugo & Sarikaya Expires March 18, 2017 [Page 1] Internet-Draft 5G IP Issues September 2016 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 . . . . . . . . . . . . . . . 7 7. Logical Network Isolation (Slicing) Concepts . . . . . . . . 8 8. Location Identification Separation and Naming . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This document focuses on IP architecture and protocol aspects related to upcoming new communication system dubbed as 5G. Originally foreseen to be available from 2020 onwards such a converged ICT system for a 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 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 von Hugo & Sarikaya Expires March 18, 2017 [Page 2] Internet-Draft 5G IP Issues September 2016 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 March 18, 2017 [Page 3] Internet-Draft 5G IP Issues September 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 March 18, 2017 [Page 4] Internet-Draft 5G IP Issues September 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 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). 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. von Hugo & Sarikaya Expires March 18, 2017 [Page 5] Internet-Draft 5G IP Issues September 2016 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? How can we deal with multiple checksums, since it is very expensive to compute checksums, remembering we only have 1ms latency budget? von Hugo & Sarikaya Expires March 18, 2017 [Page 6] Internet-Draft 5G IP Issues September 2016 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) doesn't change. Can we re-think about ID related protocols such as LISP? Can we re-scope it to just 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: connected cars, connected drones, etc. For more discussion on this see Section 8. 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. von Hugo & Sarikaya Expires March 18, 2017 [Page 7] Internet-Draft 5G IP Issues September 2016 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 protocl 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. Tunneling in both fixed and mobile networks has the purpose of directing the user traffic to the correct gateway. 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 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. 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. von Hugo & Sarikaya Expires March 18, 2017 [Page 8] Internet-Draft 5G IP Issues September 2016 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 identification of name 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. 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 new mapping mechanisms at borders to the Internet. ILNP (and ILNP-based ILA) do neither tunneling and encapsulation nor require changes in higher layers (except the transport layer) re-using part of an (IPv6) Address as Identifier and Locator. LISP has two forms of split EID/RLOC collocated in same entity: EID mobile, RLOC static. 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]. ILNP does not require any changes on the routing system or LTE core network. 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]. von Hugo & Sarikaya Expires March 18, 2017 [Page 9] Internet-Draft 5G IP Issues September 2016 LISP, ILA and mobile ILA are candidate protocols for ID-oriented networking protocol. 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). 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. von Hugo & Sarikaya Expires March 18, 2017 [Page 10] Internet-Draft 5G IP Issues September 2016 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, . 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.herbert-nvo3-ila] Herbert, T., "Identifier-locator addressing for network virtualization", draft-herbert-nvo3-ila-02 (work in progress), March 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-00 (work in progress), July 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, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . von Hugo & Sarikaya Expires March 18, 2017 [Page 11] Internet-Draft 5G IP Issues September 2016 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [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, . [TR23.799] "3GPP TR23.799, Study on Architecture for Next Generation System (Release 14)", August 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 March 18, 2017 [Page 12]