ICN Research Group Prakash Suthar Internet-Draft Milan Stolic Intended status: Informational Anil Jangam, Ed. Expires: January 26, 2021 Cisco Systems Inc. Dirk Trossen Huawei Technologies Ravishankar Ravindran Sterlite Technologies July 25, 2020 Native Deployment of ICN in LTE, 4G Mobile Networks draft-irtf-icnrg-icn-lte-4g-08 Abstract LTE, 4G mobile networks use IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP transport used in the user plane is not optimized for data transport, which leads to inefficient data delivery. For instance, IP unicast routing from server to clients is used for the delivery of multimedia content to User Equipment (UE), with each user receiving a separate stream. From a bandwidth and routing perspective, this approach is inefficient. Multicast and broadcast technologies have recently emerged for mobile networks, but their deployments are very limited or at an experimental stage. ICN is a rapidly emerging technology, although much of the work is focused on fixed networks. The focus of this draft is on native deployment of ICN in cellular mobile networks by using ICN in a 3GPP protocol stack. ICN has inherent capabilities for multicast, anchorless mobility, and security, while being optimized for data delivery using local caching at the edge. The proposed approaches in this draft allow ICN to be enabled natively over the current LTE stack comprising PDCP/RLC/MAC/PHY, or in a dual stack mode (alongside IP). This document is a product of the Information-Centric Networking Research Group (ICNRG). 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/. Prakash Suthar, et al. Expires January 26, 2021 [Page 1] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 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 January 26, 2021. Copyright Notice Copyright (c) 2020 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 3 3. LTE, 4G Mobile Network . . . . . . . . . . . . . . . . . . . 7 3.1. Network Overview . . . . . . . . . . . . . . . . . . . . 7 3.2. QoS Challenges . . . . . . . . . . . . . . . . . . . . . 9 3.3. Data Transport Using IP . . . . . . . . . . . . . . . . . 10 3.4. Virtualizing Mobile Networks . . . . . . . . . . . . . . 10 4. Data Transport Using ICN . . . . . . . . . . . . . . . . . . 11 5. ICN Deployment in 4G and LTE Networks . . . . . . . . . . . . 13 5.1. General ICN Deployment Considerations . . . . . . . . . . 13 5.2. ICN Deployment Scenarios . . . . . . . . . . . . . . . . 14 5.3. ICN Deployment in LTE Control Plane . . . . . . . . . . . 17 5.4. ICN Deployment in LTE User Plane . . . . . . . . . . . . 19 5.4.1. Dual stack ICN deployments in UE . . . . . . . . . . 19 5.4.2. Native ICN Deployments in UE . . . . . . . . . . . . 23 5.5. ICN Deployment in eNodeB . . . . . . . . . . . . . . . . 24 5.6. ICN Deployment in Packet Core (SGW, PGW) Gateways . . . . 26 6. Security and Privacy Considerations . . . . . . . . . . . . . 27 6.1. Security Considerations . . . . . . . . . . . . . . . . . 28 6.2. Privacy Considerations . . . . . . . . . . . . . . . . . 29 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 Prakash Suthar, et al. Expires January 26, 2021 [Page 2] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 9.2. Informative References . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction LTE mobile technology is built as an all-IP network. It uses IP routing protocols (OSPF, ISIS, BGP, etc.) to establish network routes over which route data traffic. Stickiness of an IP address to a device is the key to get connected to a mobile network. The same IP address is maintained through the session until the device gets detached or moves to another network. Key protocols used in 4G and LTE networks are GPRS Tunneling protocol (GTP), DIAMETER, and other protocols that are built on top of IP. One of the biggest challenges with IP-based routing in LTE is that it is not optimized for data transport. As an alternative to IP routing, this draft presents instead the native implementation of Information Centric Networking (ICN) in 3GPP, offering an opportunity to leverage inherent ICN capabilities such as in-network caching, multicast, anchorless mobility management, and authentication. This draft proposes options for deploying ICN in mobile networks, and how those options affect mobile providers and end users. This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It has been reviewed extensively by the Research Group (RG) members active in the specific areas of work covered by the document. 2. 3GPP Terminology and Concepts 1. Access Point Name The Access Point Name (APN) is a Fully Qualified Domain Name (FQDN) and resolves to a set of gateways in an operator's network. APN identifies the packet data network (PDN) with which a mobile data user wants to communicate. In addition to identifying a PDN, an APN may also be used to define the type of service, QoS, and other logical entities inside GGSN, PGW. 2. Control Plane The control plane carries signaling traffic and is responsible for routing between eNodeB and MME, MME and HSS, MME and SGW, SGW and PGW, etc. Control plane signaling is required to authenticate and authorize UE and establish a mobility session with mobile gateways (SGW/PGW). Control plane functions also include system configuration and management. Prakash Suthar, et al. Expires January 26, 2021 [Page 3] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 3. Dual Address PDN/PDP Type The dual address Packet Data Network/Packet Data Protocol (PDN/ PDP) Type (IPv4v6) is used in 3GPP context, in many cases as a synonym for dual stack; i.e., a connection type capable of serving IPv4 and IPv6 simultaneously. 4. eNodeB The eNodeB is a base station entity that supports the Long-Term Evolution (LTE) air interface. 5. Evolved Packet Core The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet-optimized system. The EPC comprises some sub components of the EPS core such as Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), and Home Subscriber Server (HSS). 6. Evolved Packet System The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet-optimized system that supports multiple Radio Access Technologies (RATs). The EPS comprises the EPC together with the Evolved Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). 7. Evolved UTRAN The E-UTRAN is a communications network sometimes referred to as 4G, and consists of eNodeB (4G base stations). The E-UTRAN allows connectivity between the User Equipment and the core network. 8. GPRS Tunneling Protocol The GPRS Tunneling Protocol (GTP) [TS29.060] [TS29.274] [TS29.281] is a tunneling protocol defined by 3GPP. It is a network-based mobility protocol, working similar to Proxy Mobile IPv6 (PMIPv6). However, GTP also provides functionality beyond mobility, such as in-band signaling related to QoS and charging, among others. 9. Gateway GPRS Support Node Prakash Suthar, et al. Expires January 26, 2021 [Page 4] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 The Gateway GPRS Support Node (GGSN) is a gateway function in the GPRS and 3G network that provides connectivity to the Internet or other PDNs. The host attaches to a GGSN identified by an APN assigned to it by an operator. The GGSN also serves as the topological anchor for addresses/prefixes assigned to the User Equipment. 10. General Packet Radio Service The General Packet Radio Service (GPRS) is a packet-oriented mobile data service available to users of the 2G and 3G cellular communication systems--the GSM--specified by 3GPP. 11. Home Subscriber Server The Home Subscriber Server (HSS) is a database for a given subscriber and was introduced in 3GPP Release-5. It is the entity containing subscription-related information to support the network entities that handle calls/sessions. 12. Mobility Management Entity The Mobility Management Entity (MME) is a network element responsible for control plane functionalities, including authentication, authorization, bearer management, layer-2 mobility, and so on. The MME is essentially the control plane part of the SGSN in the GPRS. The user plane traffic bypasses the MME. 13. Public Land Mobile Network The Public Land Mobile Network (PLMN) is a network operated by a single administration. A PLMN (and, therefore, also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN. 14. Policy and Charging Control The Policy and Charging Control (PCC) framework is used for QoS policy and charging control. It has two main functions: flow- based charging (including online credit control), and policy control (for example, gating control, QoS control, and QoS signaling). It is optional to 3GPP EPS but needed if dynamic policy and charging control by means of PCC rules based on user and services are desired. 15. Packet Data Network Prakash Suthar, et al. Expires January 26, 2021 [Page 5] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 The Packet Data Network (PDN) is a packet-based network that either belongs to the operator or is an external network such as the Internet or a corporate intranet. The user eventually accesses services in one or more PDNs. The operator's packet core networks are separated from packet data networks either by GGSNs or PDN Gateways (PGWs). 16. Serving Gateway The Serving Gateway (SGW) is a gateway function in the EPS, which terminates the interface towards the E-UTRAN. The SGW is the Mobility Anchor point for layer-2 mobility (inter-eNodeB handovers). For each UE connected with the EPS, there is only one SGW at any given point in time. The SGW is essentially the user plane part of the GPRS's SGSN. 17. Packet Data Network Gateway The Packet Data Network Gateway (PGW) is a gateway function in the Evolved Packet System (EPS), which provides connectivity to the Internet or other PDNs. The host attaches to a PGW identified by an APN assigned to it by an operator. The PGW also serves as the topological anchor for addresses/prefixes assigned to the User Equipment. 18. Packet Data Protocol Context A Packet Data Protocol (PDP) context is the equivalent of a virtual connection between the User Equipment (UE) and a PDN using a specific gateway. 19. Packet Data Protocol Type A Packet Data Protocol Type (PDP Type) identifies the used/ allowed protocols within the PDP context. Examples are IPv4, IPv6, and IPv4v6 (dual-stack). 20. Serving GPRS Support Node The Serving GPRS Support Node (SGSN) is a network element located between the radio access network (RAN) and the gateway (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN and SGSN transports the packets between the UE and the gateway. 21. Terminal Equipment The Terminal Equipment (TE) is any device/host connected to the Mobile Terminal (MT) offering services to the user. A TE may Prakash Suthar, et al. Expires January 26, 2021 [Page 6] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 communicate to an MT, for example, over the Point-to-Point Protocol (PPP). 22. UE, MS, MN, and Mobile The terms User Equipment (UE), Mobile Station (MS), Mobile Node (MN), and mobile refer to the devices that are hosts with the ability to obtain Internet connectivity via a 3GPP network. An MS comprises the Terminal Equipment (TE) and a Mobile Terminal (MT). The terms UE, MS, MN, and mobile are used interchangeably within this document. 23. User Plane The user plane refers to data traffic and the required bearers for the data traffic. In practice, IP is the only data traffic protocol used in the user plane. 3. LTE, 4G Mobile Network 3.1. Network Overview With the introduction of LTE, mobile networks moved to all-IP transport for all elements such as eNodeB, MME, SGW/PGW, HSS, PCRF, routing and switching, etc. Although the LTE network is data- centric, it has support for legacy Circuit Switch features such as voice and SMS through transitional CS fallback and flexible IMS deployment [GRAYSON]. For each mobile device attached to the radio (eNodeB), there is a separate overlay tunnel (GPRS Tunneling Protocol, GTP) between eNodeB and Mobile gateways (i.e., SGW, PGW). When any UE is powered up, it attaches to a mobile network based on its configuration and subscription. After a successful attachment procedure, the UE registers with the mobile core network, and an IPv4 and/or IPv6 address is assigned. A default bearer is created for each UE, and it is assigned to default Access Point Name (APN). The GTP tunnel is used to carry user traffic between gateways and mobile devices, therefore mandating unicast delivery for any data transfer. It is also important to understand the overhead of GTP and IPSec protocols. All mobile backhaul traffic is encapsulated using a GTP tunnel, which has overhead of 8 bytes on top of IP and UDP [NGMN]. Additionally, if IPSec is used for security (which is often required if the Service Provider is using a shared backhaul), it adds overhead based on the IPSec tunneling model (tunnel or transport) as well as the encryption and authentication header algorithm used. If we consider as an example an Advanced Encryption Standard (AES) Prakash Suthar, et al. Expires January 26, 2021 [Page 7] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 encryption, the overhead can be significant [OLTEANU], particularly for smaller payloads. +-------+ Diameter +-------+ | HSS |------------| SPR | +-------+ +-------+ | | +------+ +------+ S4 | +-------+ | 3G |---| SGSN |----------------|------+ +------| PCRF | ^ |NodeB | | |---------+ +---+ | | +-------+ +-+ | +------+ +------+ S3 | | S6a | |Gxc | | | | +-------+ | | |Gx +-+ | +------------------| MME |------+ | | | UE v | S1MME +-------+ S11 | | | | +----+-+ +-------+ +-------+ |4G/LTE|------------------------------| SGW |-----| PGW | |eNodeB| S1U +-------+ +--| | +------+ | +-------+ +---------------------+ | | S1U GTP Tunnel traffic | +-------+ | | S2a GRE Tunnel traffic |S2A | ePDG |-------+ | S2b GRE Tunnel traffic | +-------+ S2B |SGi SGi IP traffic | | | +---------+ +---------+ +-----+ | Trusted | |Untrusted| | CDN | |non-3GPP | |non-3GPP | +-----+ +---------+ +---------+ | | +-+ +-+ | | | | +-+ +-+ UE UE Figure 1: LTE, 4G Mobile Network Overview If we consider the combined impact of GTP, IPSec and unicast traffic, the data delivery is not efficient. The IETF has developed various header compression algorithms to reduce the overhead associated with IP packets. Some techniques are robust header compression (ROHC) and enhanced compression of the real-time transport protocol (ECRTP) so that the impact of overhead created by GTP, IPsec, etc., is reduced to some extent [BROWER]. For commercial mobile networks, 3GPP has adopted different mechanisms for header compression to achieve efficiency in data delivery [TS25.323]; those solutions can be adapted to other data protocols, such as ICN, too [ICNLOWPAN] [TLVCOMP]. Prakash Suthar, et al. Expires January 26, 2021 [Page 8] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 3.2. QoS Challenges During the attachment procedure, a default bearer is created for each UE and it is assigned to the default Access Point Name (APN). The QoS values assigned during the initial attach are best-effort, with no guarantees. Additional dedicated bearer(s) with enhanced QoS parameters are established, depending on specific application needs. While all traffic within a certain bearer receives the same treatment, QoS parameters supporting these requirements can be very granular in different bearers. These values vary for the control, management and user traffic, and can be very different depending on application key parameters such as latency, jitter (important for voice and other real-time applications), packet loss, and queuing mechanism (strict priority, low-latency, fair, and so on). Implementation of QoS for mobile networks is done at two stages: at content prioritization/marking and transport marking, and congestion management. From the transport perspective, QoS is defined at layer 2 as class of service (CoS) and at layer 3 either as DiffServ code point (DSCP) or type of service (ToS). The mapping of DSCP to CoS takes place at layer 2/3 switching and routing elements. 3GPP has a specified a QoS Class Identifier (QCI), which represents different types of content and equivalent mappings to the DSCP at transport layer [TS23.401]. However, this requires manual configuration at different elements and is therefore prone to possible misconfigurations. In summary, QoS configuration in mobile networks for user plane traffic requires synchronization of parameters among different platforms. Normally, QoS in IP is implemented using DiffServ, which uses hop-by-hop QoS configuration at each router. Any inconsistency in IP QoS configuration at routers in the forwarding path can result in a poor subscriber experience (e.g., packet classified as high priority can go to a lower priority queue). By deploying ICN, we intend to enhance the subscriber experience using policy-based configuration, which can be associated with the named contents [ICNQoS] at the ICN forwarder. Further investigation is needed to understand how QoS in ICN can be implemented to meet the IP QoS requirements [RFC4594]. Research papers published so far explore the possibility of classifications based on name prefixes (thus addressing the problem of IP QoS not being information aware), or on popularity or placement (looking at a distance of a content from a requester). However, focus of these research efforts is on faster routing of Interest requests towards the content rather than content delivery. Prakash Suthar, et al. Expires January 26, 2021 [Page 9] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 3.3. Data Transport Using IP The data delivered to mobile devices is sent in unicast semantic inside the GTP tunnel from an eNodeB to a PDN gateway (PGW), as described in 3GPP specifications [TS23.401]. While the technology exists to address the issue of possible multicast delivery, there are many difficulties related to multicast protocol implementations on the RAN side of the network. Transport networks in the backhaul and core addressed the multicast delivery a long time ago and have implemented it in most cases in their multi-purpose integrated transport. But the RAN part of the network is still lagging behind due to complexities related to client mobility, handovers, and the fact that the potential gain to Service Providers may not justify the investment, which explains the prevalence of unicast delivery in mobile networks. Techniques to handle multicast (such as LTE-B or eMBMS) have been designed to handle pre-planned content delivery, such as live content, which contrasts user behavior today, largely based on content (or video) on demand model. To ease the burden on the bandwidth of the SGi interface, caching is introduced in a similar manner as with many Enterprises. In mobile networks, whenever possible, cached data is delivered. Caching servers are placed at a centralized location, typically in the Service Provider's Data Center, or in some cases lightly distributed in Packet Core locations with the PGW nodes close to the Internet and IP services access (SGi interface). This is a very inefficient concept because traffic must traverse the entire backhaul path for the data to be delivered to the end user. Other issues, such as out- of-order delivery, contribute to this complexity and inefficiency, which needs to be addressed at the application level. 3.4. Virtualizing Mobile Networks The Mobile packet core deployed in a major Service Provider network is either based on dedicated hardware or, in some cases, large capacity x86 platforms. With the adoption of Mobile Virtual Network Operators (MVNO), public safety networks, and enterprise mobility networks, elastic mobile core architecture are needed. By deploying the mobile packet core on a commercially off-the-shelf (COTS) platform, using a virtualized infrastructure (NFVI) framework and end-to-end orchestration, new deployments can be simplified to provide optimized TCO. While virtualization is growing, and many mobile providers use a hybrid architecture that consists of dedicated and virtualized infrastructures, the control and data planes are still the same. There is also work under way to separate the control and user plane for the network to scale better. Virtualized mobile networks and Prakash Suthar, et al. Expires January 26, 2021 [Page 10] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 network slicing with control and user plane separation provide a mechanism to evolve the GTP-based architecture towards an Openflow SDN-based signaling for LTE and proposed 5G core. Some early architecture work for 5G mobile technologies provides a mechanism for control and user plane separation and simplifies the mobility call flow by introducing Openflow-based signaling [ICN5G]. This has been considered by 3GPP [EPCCUPS] and is also described in [SDN5G]. 4. Data Transport Using ICN For mobile devices, the edge connectivity is between mobile terminal and a router or mobile edge computing (MEC) [MECSPEC] element. Edge computing has the capability of processing client requests and segregating control and user traffic at the edge of radio, rather than sending all requests to the mobile gateway. +----------+ | Content +----------------------------------------+ | Publisher| | +---+---+--+ | | | +--+ +--+ +--+ | | +--->|R1|------------>|R2|---------->|R4| | | +--+ +--+ +--+ | | | Cached | | v content | | +--+ at R3 | | +========|R3|---+ | | # +--+ | | | # | | | v v | | +-+ +-+ | +---------------| |-------------| |-------------+ +-+ +-+ Consumer-1 Consumer-2 UE UE ===> Content flow from cache ---> Content flow from publisher Figure 2: ICN Architecture Edge computing transforms radio access network into an intelligent service edge capable of delivering services directly from the edge of the network, while providing the best possible performance to the client. Edge computing can be an ideal candidate for implementing ICN forwarders in addition to its usual function of managing mobile Prakash Suthar, et al. Expires January 26, 2021 [Page 11] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 termination. In addition to edge computing, other transport elements, such as routers, can work as ICN forwarders. Data transport using ICN is different to IP-based transport by introducing uniquely named-data as a core design principle. Communication in ICN takes place between the content provider (producer) and the end user (consumer), as described in Figure 2. Every node in a physical path between a client and a content provider is called the ICN forwarder or router. It can route the request intelligently and cache content so it can be delivered locally for subsequent requests from any other client. For mobile networks, transport between a client and a content provider consists of radio network + mobile backhaul and IP core transport + Mobile Gateways + Internet + content data network (CDN). To understand the suitability of ICN for mobile networks, we will discuss the ICN framework by describing its protocols architecture and different types of messages to then consider how we can use this in mobile networks for delivering content more efficiently. ICN uses two types of packets called "interest packet" and "data packet" as described in Figure 3. +------------------------------------+ Interest | +------+ +------+ +------+ | +-----+ +-+ ---->| CS |---->| PIT |---->| FIB |--------->| CDN | | | | +------+ +------+ +------+ | +-----+ +-+ | | Add | Drop | | Forward UE <--------+ Intf v Nack v | Data | | +------------------------------------+ +------------------------------------+ +-+ | Forward +------+ | +-----+ | | <-------------------------------------| PIT |<---------| CDN | +-+ | | Cache +--+---+ | Data +-----+ UE | +--v---+ | | | | CS | v | | +------+ Discard | +------------------------------------+ Figure 3: ICN Interest, Data Packet and Forwarder In an LTE network, when a mobile device wants to receive certain content, it will send an Interest message to the closest eNodeB. Prakash Suthar, et al. Expires January 26, 2021 [Page 12] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 Interest packets follow the TLV format [RFC8609] and contain mandatory fields, such as name of the content and content matching restrictions (KeyIdRestr and ContentObjectHashRestr), expressed as a tuple [RFC8569]. The content matching tuple uniquely identifies the matching data packet for the given Interest packet. Another attribute called HopLimit is used to detect looping Interest messages. An ICN router will receive an Interest packet and lookup if a request for such content has arrived earlier from another client. If so, it may be served from the local cache; otherwise, the request is forwarded to the next-hop ICN router. Each ICN router maintains three data structures: Pending Interest Table (PIT), Forwarding Information Base (FIB), and Content Store (CS). The Interest packet travels hop-by-hop towards the content provider. Once the Interest packet reaches the content provider; it will return a Data packet containing information such as content name, signature, and the actual data. The data packet travels in reverse direction following the same path taken by the Interest packet, maintaining routing symmetry. Details about algorithms used in PIT, FIB, CS, and security trust models are described in various resources [CCN]; here, we have explained the concept and its applicability to the LTE network. 5. ICN Deployment in 4G and LTE Networks 5.1. General ICN Deployment Considerations In LTE/4G mobile networks, both user and control plane traffic have to be transported from the edge to the mobile packet core via IP transport. The evolution of the existing mobile packet core using Control and User Plane Separation (CUPS) [TS23.714] enables flexible network deployment and operation by distributed deployment and the independent scaling of control plane and user plane functions - while not affecting the functionality of existing nodes subject to this split. In the CUPS architecture, there is an opportunity to shorten the path for user plane traffic by deploying offload nodes closer to the edge [OFFLOAD]. With this major architecture change, a User Plane Function (UPF) node is placed close to the edge so traffic no longer needs to traverse the entire backhaul path to reach the EPC. In many cases, where feasible, the UPF can be collocated with the eNodeB, which is also a business decision based on user demand. Placing a Publisher close to the offload site, or at the offload site, provides for a significant improvement in user experience, especially with latency-sensitive applications. This capability allows for the Prakash Suthar, et al. Expires January 26, 2021 [Page 13] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 introduction of ICN and amplifies its advantages. This section analyzes the potential impact of ICN on control and user plane traffic for centralized and disaggregate CUPS-based mobile network architecture. 5.2. ICN Deployment Scenarios The deployment of ICN provides an opportunity to further optimize the existing data transport in LTE/4G mobile networks. The various deployment options that ICN and IP provide are somewhat analogous to the deployment scenarios when IPv6 was introduced to interoperate with IPv4 except, with ICN, the whole IP stack is being replaced. We have reviewed [RFC6459] and analyzed the impact of ICN on control plane signaling and user plane data delivery. In general, ICN can be deployed by natively replacing IP transport (IPv4 and IPv6) or as an overlay protocol. Figure 4 describes a modified protocol stack to support ICN deployment scenarios. +----------------+ +-----------------+ | ICN App (new) | |IP App (existing)| +---------+------+ +-------+---------+ | | +---------+----------------+---------+ | Transport Convergence Layer (new) | +------+---------------------+-------+ | | +------+------+ +------+-------+ |ICN function | | IP function | | (New) | | (Existing) | +------+------+ +------+-------+ | | (```). (```). ( ICN '`. ( IP '`. ( Cloud ) ( Cloud ) ` __..'+' ` __..'+' Figure 4: IP/ICN Convergence and Deployment Scenarios As shown in Figure 4, for applications running either in the UE or in the content provider system to use the new transport option, we propose a new transport convergence layer (TCL). This transport convergence layer helps determine the type of transport (such as ICN or IP), as well as the type of radio interface (LTE or WiFi or both) used to send and receive traffic based on preference (e.g., content location, content type, content publisher, congestion, cost, QoS). It helps configure and determine the type of connection as well as Prakash Suthar, et al. Expires January 26, 2021 [Page 14] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 the overlay mode (ICNoIP or IPoICN) between application and the protocol stack (IP or ICN) to be used. Combined with the existing IP function, the ICN function provides support for either native ICN and/or the dual stack (ICN/IP) transport functionality. See Section 5.4.1 for elaborate descriptions of these functional layers. The TCL can use several mechanisms for transport selection. It can use a per-application configuration through a management interface, possibly even a user-facing setting realized through a user interface, like those used today that select cellular over WiFi being used for selected applications. In another option, it might use a software API, which an adapted IP application could use to specify (such as an ICN transport) for obtaining its benefits. Another potential application of TCL is in implementation of network slicing, with a slice management capability locally or through an interface to an external slice manager via an API [GALIS]. This solution can enable network slicing for IP and ICN transport selection from the UE itself. The TCL could apply slice settings to direct certain traffic (or applications) over one slice and others over another slice, determined by some form of 'slicing policy'. Slicing policy can be obtained externally from the slice manager or configured locally on UE. From the perspective of applications either on the UE or at a content provider, the following options are possible for ICN deployment natively and/or with IP. 1. IP over IP In this scenario, the UE uses applications tightly integrated with the existing IP transport infrastructure. The TCL has no additional function because packets are forwarded directly using an IP protocol stack, which sends packets over the IP transport. 2. ICN over ICN Similar to case 1, ICN applications integrate tightly with the ICN transport infrastructure. The TCL has no additional responsibility because packets are forwarded directly using ICN protocol stack, which sends packets over the ICN transport. 3. ICN over IP (ICNoIP) In this scenario, the underlying IP transport infrastructure is not impacted (that is, ICN is implemented as an IP overlay Prakash Suthar, et al. Expires January 26, 2021 [Page 15] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 between user equipment (UE) and content provider). IP routing is used from Radio Access Network (eNodeB) to the mobile backhaul, the IP core, and the Mobile Gateway (SGW/PGW). The UE attaches to the Mobile Gateway (SGW/PGW) using an IP address. Also, the data transport between Mobile Gateway (SGW/PGW) and content publisher uses IP. The content provider can serve content either using IP or ICN, based on the UE request. An approach to implement ICN in mobile backhaul networks is described in [MBICN]. It implements a GTP-U extension header option to encapsulate ICN payload in a GTP tunnel. However, as this design runs ICN as an IP overlay, the mobile backhaul can be deployed using native IP. The proposal describes a mechanism where the GTP-U tunnel can be terminated by hair pinning the packet before it reaches SGW, if an ICN-enabled node is deployed in the mobile backhaul (that is, between eNodeB and SGW). This could be useful when an ICN data packet is stored in the ICN node (such as repositories, caches) in the tunnel path so that the ICN node can reply without going all the way through the mobile core. While a GTP-U extension header is used to carry UE specific ICN payload, they are not visible to the transport, including SGW. On the other hand, the PGW can use the UE-specific ICN header extension and ICN payload to set up an uplink transport towards a content provider in the Internet. In addition, the design assumes a proxy function at the edge, to perform ICN data retrieval on behalf of a non-ICN end device. 4. IP over ICN (IPoICN) [IPoICN] provides an architectural framework for deployment of IP as an overlay over ICN protocol. Implementing IP services over ICN provides an opportunity to leverage the benefits of ICN in the transport infrastructure while there is no impact on end devices (UE and access network) as they continue to use IP. IPoICN however, will require an inter-working function (IWF/ Border Gateway) to translate various transport primitives. The IWF function will provide a mechanism for protocol translation between IPoICN and native IP deployment for mobile network. After reviewing [IPoICN], we understand and interpret that ICN is implemented in the transport natively; however, IP is implemented in UE, eNodeB, and Mobile gateway (SGW/PGW), which is also called as a network attach point (NAP). For this, said NAP receives an incoming IP or HTTP packet (the latter through TCP connection termination) and publishes the packet under a suitable ICN name (i.e., the hash over the destination IP address for an IP packet or the hash over the FQDN of the HTTP request for an HTTP packet) to the ICN network. In Prakash Suthar, et al. Expires January 26, 2021 [Page 16] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 the HTTP case, the NAP maintains a pending request mapping table to map returning responses to the terminated TCP connection. 5. Hybrid ICN (hICN) An alternative approach to implement ICN over IP is provided in Hybrid ICN [HICN]. It describes a novel approach to integrate ICN into IPv6 without creating overlays with a new packet format as an encapsulation. hICN addresses the content by encoding a location-independent name in an IPv6 address. It uses two name components--name prefix and name suffix--that identify the source of data and the data segment within the scope of the name prefix, respectively. At application layer, hICN maps the name into an IPv6 prefix and, thus, uses IP as transport. As long as the name prefixes, which are routable IP prefixes, point towards a mobile GW (PGW or local breakout, such as CUPS), there are potentially no updates required to any of the mobile core gateways (for example, SGW/ PGW). The IPv6 backhaul routes the packets within the mobile core. hICN can run in the UE, in the eNodeB, in the mobile backhaul, or in the mobile core. Finally, as hICN itself uses IPv6, it cannot be considered as an alternative transport layer. 5.3. ICN Deployment in LTE Control Plane In this section, we analyze signaling messages that are required for different procedures, such as attach, handover, tracking area update, and so on. The goal of this analysis is to see if there are any benefits to replacing IP-based protocols with ICN for LTE signaling in the current architecture. It is important to understand the concept of point of attachment (POA). When UE connects to a network, it has the following POAs: 1. eNodeB managing location or physical POA 2. Authentication and Authorization (MME, HSS) managing identity or authentication POA 3. Mobile Gateways (SGW, PGW) managing logical or session management POA In the current architecture, IP transport is used for all messages associated with the control plane for mobility and session management. IP is embedded very deeply into these messages utilizing TLV syntax for carrying additional attributes such as a layer 3 transport. The physical POA in the eNodeB handles both mobility and session management for any UE attached to 4G, LTE network. The Prakash Suthar, et al. Expires January 26, 2021 [Page 17] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 number of mobility management messages between different nodes in an LTE network per signaling procedure is shown in Table 1. Normally, two types of UE devices attach to the LTE network: SIM based (need 3GPP mobility protocol for authentication) or non-SIM based (which connect to WiFi network). Both device types require authentication. For non-SIM based devices, AAA is used for authentication. We do not propose to change UE authentication or mobility management messaging for user data transport using ICN. A separate study would be required to analyze the impact of ICN on mobility management messages structures and flows. We are merely analyzing the viability of implementing ICN as a transport for control plane messages. It is important to note that, if MME and HSS do not support ICN transport, they still need to support UE capable of dual stack or native ICN. When UE initiates an attach request using the identity as ICN, MME must be able to parse that message and create a session. MME forwards UE authentication to HSS, so HSS must be able to authenticate an ICN-capable UE and authorize create session [TS23.401]. +---------------------------+-----+-----+-----+-----+------+ | LTE Signaling Procedures | MME | HSS | SGW | PGW | PCRF | +---------------------------+-----+-----+-----+-----+------+ | Attach | 10 | 2 | 3 | 2 | 1 | | Additional default bearer | 4 | 0 | 3 | 2 | 1 | | Dedicated bearer | 2 | 0 | 2 | 2 | 0 | | Idle-to-connect | 3 | 0 | 1 | 0 | 0 | | Connect-to-Idle | 3 | 0 | 1 | 0 | 0 | | X2 handover | 2 | 0 | 1 | 0 | 0 | | S1 handover | 8 | 0 | 3 | 0 | 0 | | Tracking area update | 2 | 2 | 0 | 0 | 0 | | Total | 34 | 2 | 14 | 6 | 3 | +---------------------------+-----+-----+-----+-----+------+ Table 1: Signaling Messages in LTE Gateways Anchorless mobility [ALM] provides a fully decentralized, control- plane agnostic solution to handle producer mobility in ICN. Mobility management at layer-3 level makes it access agnostic and transparent to the end device or the application. The solution discusses handling mobility without having to depend on core network functions (e.g. MME); however, a location update to the core network may still be required to support legal compliance requirements such as lawful intercept and emergency services. These aspects are open for further study. Prakash Suthar, et al. Expires January 26, 2021 [Page 18] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 One of the advantages of ICN is in the caching and reusing of the content, which does not apply to the transactional signaling exchange. After analyzing LTE signaling call flows [TS23.401] and messages inter-dependencies (see Table 1), our recommendation is that it is not beneficial to deploy ICN for control plane and mobility management functions. Among the features of ICN design, Interest aggregation and content caching are not applicable to control plane signaling messages. Control plane messages are originated and consumed by the applications and they cannot be shared. 5.4. ICN Deployment in LTE User Plane We will consider Figure 1 to discuss different mechanisms to deploy ICN in mobile networks. In Section 5.2, we discussed generic deployment scenarios of ICN. In this section, we discuss the specific use cases of native ICN deployment in LTE user plane. We consider the following options: 1. Dual stack ICN deployment in UE 2. Native ICN deployments in UE 3. ICN deployment in eNodeB 4. ICN deployment in mobile gateways (SGW/PGW) 5.4.1. Dual stack ICN deployments in UE The control and user plane communications in LTE, 4G mobile networks are specified in 3GPP documents [TS23.203] and [TS23.401]. It is important to understand that UE can be either consumer (receiving content) or publisher (pushing content for other clients). The protocol stack inside the mobile device (UE) is complex because it must support multiple radio connectivity access to eNodeB(s). Figure 5 provides a high-level description of a protocol stack, where IP is defined at two layers: (1) user plane communication and (2) UDP encapsulation. User plane communication takes place between Packet Data Convergence Protocol (PDCP) and Application layer, whereas UDP encapsulation is at GTP protocol stack. The protocol interactions and impact of supporting tunneling of ICN packet into IP or to support ICN natively are described in Figure 5 and Figure 6, respectively. Prakash Suthar, et al. Expires January 26, 2021 [Page 19] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 +--------+ +--------+ | App | | CDN | +--------+ +--------+ |Transp. | | | | |Transp. | |Converg.|.|..............|...............|............|.|Converge| +--------+ | | | +--------+ | +--------+ | |.|..............|...............|.| |.|.| | | ICN/IP | | | | | ICN/IP | | | ICN/IP| | | | | | | | | | | +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ | |.|.| | |.|.| | |.|.| | | | | | | PDCP | | |PDCP|GTP-U| | |GTP-U|GTP-U| | |GTP-U| | | | L2 | +--------+ | +----------+ | +-----------+ | +-----+ | | | | | RLC |.|.|RLC | UDP |.|.| UDP | UDP |.|.|UDP |L2|.|.| | +--------+ | +----------+ | +-----------+ | +-----+ | | | | | MAC |.|.| MAC| L2 |.|.| L2 | L2 |.|.| L2 | | | | | +--------+ | +----------+ | +-----------+ | +--------+ | +--------+ | L1 |.|.| L1 | L1 |.|.| L1 | L1 |.|.| L1 |L1|.|.| L1 | +--------+ | +----+-----+ | +-----+-----+ | +-----+--+ | +--------+ UE | BS(eNodeB) | SGW | PGW | Uu S1U S5/S8 SGi Figure 5: Dual Stack ICN Deployment in UE The protocols and software stack used inside LTE capable UE support both 3G and LTE software interworking and handover. the latest 3GPP Rel.13 onward specification describes the use of IP and non-IP protocols to establish logical/session connectivity. We intend to leverage the non-IP protocol-based mechanism to deploy ICN protocol stack in UE, as well as in eNodeB and mobile gateways (SGW, PGW). 1. An existing application layer can be modified to provide options for a new ICN-based application and existing IP-based applications. The UE can continue to support existing IP-based applications or host new applications developed to support native ICN as transport, ICNoIP, or IPoICN-based transport. The application layer has the option of selecting either ICN or IP transport, as well as radio interface, to send and receive data traffic. Our proposal is to provide an Application Programming Interface (API) to the application developers so they can choose either ICN or IP transport for exchanging the traffic with the network. As mentioned in Section 5.2, the transport convergence layer (TCL) function handles the interaction of applications with multiple transport options. Prakash Suthar, et al. Expires January 26, 2021 [Page 20] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 2. The transport convergence layer helps determine the type of transport (such as ICN, hICN, or IP) and type of radio interface (LTE or WiFi, or both) used to send and receive traffic. Application layer can make the decision to select a specific transport based on preference, such as content location, content type, content publisher, congestion, cost, QoS, and so on. There can be an Application Programming Interface (API) to exchange parameters required for transport selection. Southbound interactions of Transport Convergence Layer (TCL) will be either to IP or ICN at the network layer. When selecting the IPoICN mode, the TCL is responsible for receiving an incoming IP or HTTP packet and publishing the packet to the ICN network under a suitable ICN name (that is, the hash over the destination IP address for an IP packet, or the hash over the FQDN of the HTTP request for an HTTP packet). In the HTTP case, the TCL maintains a pending request mapping table to map returning responses to the originating HTTP request. The common API will provide a 'connection' abstraction for this HTTP mode of operation, returning the response over said connection abstraction, akin to the TCP socket interface, while implementing a reliable transport connection semantic over the ICN from the UE to the receiving UE or the PGW. If the HTTP protocol stack remains unchanged, therefore utilizing the TCP protocol for transfer, the TCL operates in local TCP termination mode, retrieving the HTTP packet through said local termination. Prakash Suthar, et al. Expires January 26, 2021 [Page 21] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 +----------------+ +-----------------+ | ICN App (new) | |IP App (existing)| +---------+------+ +-------+---------+ | | +---------+----------------+---------+ | Transport Convergence Layer (new) | +------+---------------------+-------+ | | +------+------+ +------+-------+ |ICN function | | IP function | | (New) | | (Existing) | +------+------+ +------+-------+ | | +------+---------------------+-------+ | PDCP (updated to support ICN) | +-----------------+------------------+ | +-----------------+------------------+ | RLC (Existing) | +-----------------+------------------+ | +-----------------+------------------+ | MAC Layer (Existing) | +-----------------+------------------+ | +-----------------+------------------+ | Physical L1 (Existing) | +------------------------------------+ Figure 6: Dual Stack ICN Protocol Interactions 3. The ICN function (forwarder) is introduced in parallel to the existing IP layer. The ICN forwarder contains functional capabilities to forward ICN packets, such as an Interest packet to eNodeB or a response "data packet" from eNodeB to the application. 4. For the dual-stack scenario, when UE is not supporting ICN as transport, we use an IP underlay to transport ICN packets. The ICN function will use the IP interface to send Interest and Data packets for fetching or sending data using ICN protocol function. This interface will use the ICN overlay over IP using any overlay tunneling mechanism. 5. To support ICN at network layer in UE, the PDCP layer must be aware of ICN capabilities and parameters. PDCP is located in the Radio Protocol Stack in the LTE Air interface, between IP Prakash Suthar, et al. Expires January 26, 2021 [Page 22] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 (Network layer) and Radio Link Control Layer (RLC). PDCP performs the following functions [TS36.323]: 1. Data transport by listening to upper layer, formatting and pushing down to Radio Link Layer (RLC) 2. Header compression and decompression using Robust Header Compression (ROHC) 3. Security protections such as ciphering, deciphering, and integrity protection 4. Radio layer messages associated with sequencing, packet drop detection and re-transmission, and so on. 6. No changes are required for lower layer such as RLC, MAC, and Physical (L1) because they are not IP aware. One key point to understand in this scenario is that ICN is deployed as an overlay on top of IP. 5.4.2. Native ICN Deployments in UE We propose to implement ICN natively in UE by modifying the PDCP layer in 3GPP protocols. Figure 7 provides a high-level protocol stack description where ICN is used at the following different layers: 1. User plane communication 2. Transport layer User plane communication takes place between PDCP and application layer, whereas ICN transport is a substitute of the GTP protocol. The removal of the GTP protocol stack is a significant change in the mobile architecture because GTP is used not just for routing but for mobility management functions, such as billing, mediation, and policy enforcement. If we implement ICN natively in the UE, the communication between UE and eNodeB will change. Also, this will avoid tunneling the user plane traffic from eNodeB to the mobile packet core (SGW, PGW) using a GTP tunnel. For native ICN deployment, an application will be configured to use ICN forwarder so there is no need for Transport Convergence. Also, to support ICN at the network layer in UE, we need to modify the existing PDCP layer to be aware of ICN capabilities and parameters. Prakash Suthar, et al. Expires January 26, 2021 [Page 23] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 The native implementation will also provide opportunities to develop new use cases leveraging ICN capabilities, such as seamless mobility, UE to UE content delivery using radio network without traversing the mobile gateways, and more. +--------+ +--------+ | App | | CDN | +--------+ +--------+ |Transp. | | | | | |Transp. | |Converge|.|..............|..............|..............|.|Converge| +--------+ | | | | +--------+ | |.|..............|..............|..............|.| | | ICN/IP | | | | | | | | | | | | | | | +--------+ | +----+-----+ | +----------+ | +----------+ | | ICN/IP | | |.|.| | | | | | | | | | | | | PDCP | | |PDCP| ICN |.|.| ICN |.|.| ICN |.|.| | +--------+ | +----+ | | | | | | | | | | | RLC |.|.|RLC | | | | | | | | | | | +--------+ | +----------+ | +----------+ | +----------+ | +--------+ | MAC |.|.| MAC| L2 |.|.| L2 |.|.| L2 |.|.| L2 | +--------+ | +----------+ | +----------+ | +----------+ | +--------+ | L1 |.|.| L1 | L1 |.|.| L1 |.|.| L1 |.|.| L1 | +--------+ | +----+-----+ | +----------+ | +----------+ | +--------+ UE | BS(eNodeB) | SGW | PGW | Uu S1u S5/S8 SGi Figure 7: Native ICN Deployment in UE 5.5. ICN Deployment in eNodeB The eNodeB is a physical point of attachment for the UE, where radio protocols are converted into IP transport protocol for dual stack/ overlay and native ICN, respectively (see Figure 6 and Figure 7). When a UE performs an attach procedure, it is assigned an identity either as IP or dual stack (IP and ICN), or ICN. UE can initiate data traffic using any of the following options: 1. Native IP (IPv4 or IPv6) 2. Native ICN 3. Dual stack IP (IPv4/IPv6) or ICN The UE encapsulates a user data transport request into PDCP layer and sends the information on the air interface to eNodeB, which in turn receives the information and, using PDCP [TS36.323], de-encapsulates Prakash Suthar, et al. Expires January 26, 2021 [Page 24] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 the air-interface messages and converts them to forward to core mobile gateways (SGW, PGW). As shown in Figure 8, to support ICN natively in eNodeB, it is proposed to provide transport convergence layer (TCL) capabilities in eNodeB (similar to as provided in UE), which provides the following functions: 1. It decides the forwarding strategy for a user data request coming from UE. The strategy can decide based on preference indicated by the application, such as congestion, cost, QoS, and so on. 2. eNodeB to provide open Application Programming Interface (API) to external management systems, to provide capability to eNodeB to program the forwarding strategies. +---------------+ | | UE request | | ICN +---------+ +---> | content using |--+--- transport -->| | | |ICN protocol | | | | | +---------------+ | | | | | | | | +---------------+ | | | +-+ | | UE request | | IP |To mobile| | |---+---> | content using |--+--- transport -->| GW | +-+ | | IP protocol | | |(SGW,PGW)| UE | +---------------+ | | | | | | | | +---------------+ | | | | | UE request | | Dual stack | | +---> | content using |--+--- IP+ICN -->| | |IP/ICN protocol| | transport +---------+ +---------------+ | eNodeB S1u Figure 8: Native ICN Deployment in eNodeB 3. eNodeB can be upgraded to support three different types of transport: IP, ICN, and dual stack IP+ICN towards mobile gateways, as depicted in Figure 8. It is also proposed to deploy IP and/or ICN forwarding capabilities into eNodeB, for efficient transfer of data between eNodeB and mobile gateways. Following are choices for forwarding a data request towards mobile gateways: 1. Assuming eNodeB is IP enabled and the UE requests an IP transfer, eNodeB forwards data over IP. Prakash Suthar, et al. Expires January 26, 2021 [Page 25] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 2. Assuming eNodeB is ICN enabled and the UE requests an ICN transfer, eNodeB forwards data over ICN. 3. Assuming eNodeB is IP enabled and the UE requests an ICN transfer, eNodeB overlays ICN on IP and forwards user plane traffic over IP. 4. Assuming eNodeB is ICN enabled and the UE requests an IP transfer, eNodeB overlays IP on ICN and forwards user plane traffic over ICN [IPoICN]. 5.6. ICN Deployment in Packet Core (SGW, PGW) Gateways Mobile gateways---also known as Evolved Packet Core (EPC)--include SGW, PGW, which perform session management for UE from the initial attach to disconnection. When UE is powered on, it performs NAS signaling and attaches to PGW after successful authentication. PGW is an anchoring point for UE and responsible for service creations, authorization, maintenance, and so on. The Entire functionality is managed using IP address(es) for UE. To implement ICN in EPC, the following functions are proposed: 1. Insert ICN attributes in session management layer as additional functionality with IP stack. Session management layer is used for performing attach procedures and assigning logical identity to user. After successful authentication by HSS, MME sends a create session request (CSR) to SGW and SGW to PGW. 2. When MME sends Create Session Request message (Step 12 in [TS23.401]) to SGW or PGW, it includes a Protocol Configuration Option Information Element (PCO IE) containing UE capabilities. We can use PCO IE to carry ICN-related capabilities information from UE to PGW. This information is received from UE during the initial attach request in MME. Details of available TLV, which can be used for ICN, are given in subsequent sections. UE can support either native IP, ICN+IP, or native ICN. IP is referred to as both IPv4 and IPv6 protocols. 3. For ICN+IP-capable UE, PGW assigns the UE both an IP address and ICN identity. UE selects either of the identities during the initial attach procedures and registers with the network for session management. For ICN-capable UE, it will provide only ICN attachment. For native IP-capable UE, there is no change. 4. To support ICN-capable attach procedures and use ICN for user plane traffic, PGW needs to have full ICN protocol stack functionalities. Typical ICN capabilities include functions such Prakash Suthar, et al. Expires January 26, 2021 [Page 26] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 as content store (CS), Pending Interest Table (PIT), Forwarding Information Base (FIB) capabilities, and so on. If UE requests ICN in PCO IE, then PGW registers UE with ICN names. For ICN forwarding, PGW caches content locally using CS functionality. 5. PCO IE described in [TS24.008] (see Figure 10.5.136 on page 598) and [TS24.008] (see Table 10.5.154 on page 599) provide details for different fields. 1. Octet 3 (configuration protocols define PDN types), which contains details about IPv4, IPv6, both or ICN. 2. Any combination of Octet 4 to Z can be used to provide additional information related to ICN capability. It is most important that PCO IE parameters are matched between UE and mobile gateways (SGW, PGW) so they can be interpreted properly and the UE can attach successfully. 6. Deployment of ICN functionalities in SGW and PGW should be matched with UE and eNodeB because they will exchange ICN protocols and parameters. 7. Mobile gateways SGW, PGW will also need ICN forwarding and caching capability. This is especially important if CUPS is implemented. User Plane Function (UPF), comprising the SGW and PGW user plane, will be located at the edge of the network and close to the end user. ICN-enabled gateway means that this UPF would serve as a forwarder and should be capable of caching, as is the case with any other ICN-enabled node. 8. The transport between PGW and CDN provider can be either IP or ICN. When UE is attached to PGW with ICN identity and communicates with an ICN-enabled CDN provider, it will use ICN primitives to fetch the data. On the other hand, for a UE attached with an ICN identity, if PGW must communicate with an IP enabled CDN provider, it will have to use an ICN-IP interworking gateway to perform conversion between ICN and IP primitives for data retrieval. In the case of CUPS implementation with an offload close to the edge, this interworking gateway can be collocated with the UPF at the offload site to maximize the path optimization. Further study is required to understand how this ICN-to-IP (and vice versa) interworking gateway would function. 6. Security and Privacy Considerations This section will cover some security and privacy considerations in user equipment (UE) and LTE network because of introduction of ICN. Prakash Suthar, et al. Expires January 26, 2021 [Page 27] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 6.1. Security Considerations To ensure only authenticated UEs are connected to the network, LTE mobile network implements various security mechanisms. From the perspective of ICN deployment in the user plane, it needs to take care of the following security aspects: 1. UE authentication and authorization 2. Radio or air interface security 3. Denial of service attacks on the mobile gateway, services either by the UE or by external entities in the Internet 4. Content poisoning either in transport or servers 5. Content cache pollution attacks 6. Secure naming, routing, and forwarding 7. Application security Security over the LTE air interface is provided through cryptographic techniques. When UE is powered up, it performs a key exchange between UE's USIM and HSS/Authentication Center using NAS messages, including ciphering and integrity protections between UE and MME. Details for secure UE authentication, key exchange, ciphering, and integrity protections messages are given in the 3GPP call flow [TS23.401]. With ICN we are modifying protocol stack for user plane and not control plane. The NAS signaling is exchanged between UE and mobile gateways e.g. MME, using control plane, therefore there is no adverse impact of ICN on UE. LTE uses IP transport in its mobile backhaul (between eNodeB and core network). In case of provider-owned backhaul, it may not be necessary to implement any security mechanisms because the entire IP transport is owned by service provider. Deployment of security gateways and encryption might be necessary when IP transport is provided by other provider as shared media or leased lines. The native IP transport continues to leverage security mechanism such as Internet key exchange (IKE) and the IP security protocol (IPsec). More details of mobile backhaul security are provided in 3GPP network security specifications [TS33.310] and [TS33.320]. When mobile backhaul is upgraded to support dual stack (IP+ICN) or native ICN, it is required to implement security techniques that are deployed in the mobile backhaul. When ICN forwarding is enabled on mobile transport routers, we need to deploy security practices based on [RFC7476] and [RFC7927]. Prakash Suthar, et al. Expires January 26, 2021 [Page 28] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 LTE mobile gateways (SGW, PGW) perform some of key functions such as content based online/offline billing and accounting, deep packet inspection (DPI), and lawful interception (LI). When ICN is deployed in user plane , we need to integrate ICN security for sessions between UE and gateway. If we encrypt user plane payload metadata then it might be difficult to perform routing based on contents and it may not work because we need decryption keys at every forwarder to route the content. The content itself can be encrypted between publisher and consumer to ensure privacy. Only the user with right decryption key shall be able to access the content. We need further research for ICN impact on LI, online/offline charging and accounting. 6.2. Privacy Considerations In any network, caching implies a trade-off between network efficiency and privacy. The activity of users is exposed to the scrutiny of cache owners with whom they may not have any relationship. By monitoring the cache transactions, an attacker could obtain significant information related to the objects accessed, topology and timing of the requests [RFC7945]. Privacy concerns are amplified by the introduction of new network functions such as Information lookup and Network storage, and different forms of communication [FOTIOU]. Privacy risks in ICN can be broadly divided in the following categories [TOURANI]: 1. Timing attack 2. Communication monitoring attack 3. Censorship and anonymity attack 4. Protocol attack 5. Naming-signature privacy Introduction of TCL effectively enables ICN at the application and/or transport layer, depending on the scenario described in section 5. Enabling ICN in LTE networks is expected to increase efficiency by taking advantage of ICN's inherent characteristics. While this approach would potentially leave some of the above-mentioned privacy concerns open, a mere presence of the TCL does not present increased risk and vulnerability. 1. IPoIP Section 5.2 would not be affected as TCL has no role in it and ICN does not apply Prakash Suthar, et al. Expires January 26, 2021 [Page 29] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 2. ICNoICN scenario Section 5.2 has increased risk of a privacy attack, and that risk is applicable to ICN protocol in general rather than specifically to the LTE implementation. Since this scenario describes communication over ICN transport, every forwarder in the path could be a potential risk for privacy attack 3. ICNoIP scenario Section 5.2 uses IP for transport, so the only additional ICN-related potential privacy risk areas are the endpoints (consumer and publisher) where, at the application layer, content is being served 4. IPoICN scenario Section 5.2 could have potentially increased risk due to possible vulnerability of the forwarders in the path of ICN transport As shown above, introduction of TCL as a vehicle to implement ICN in LTE does not present additional privacy risk beyond issues already identified as they apply to ICN in general. Further research in this area is needed. 7. Summary In this draft, we have discussed complexities of LTE network and key dependencies for deploying ICN in user plane data transport. Different deployment options described cover aspects such as inter- operability and multi-technology, which is a reality for any Service Provider. One can use LTE gateway software and ICN simulator and deploy ICN data transport in user plane as an overlay, dual stack (IP + ICN), hICN, or natively (by integrating ICN with CDN, eNodeB, SGW, PGW and transport network). Notice that, for deployment scenarios discussed above, additional study is required for lawful interception, billing/mediation, network slicing, and provisioning APIs. Edge Computing [CHENG] provides capabilities to deploy functionalities such as Content Delivery Network (CDN) caching and mobile user plane functions (UPF) [TS23.501]. Recent research for delivering real-time video content [MPVCICN] using ICN has also been proven to be efficient [NDNRTC] and can be used towards realizing the benefits of ICN deployment in eNodeB, edge computing, mobile gateways (SGW, PGW) and CDN. The key aspect for ICN is in its seamless integration in LTE and 5G networks with tangible benefits so we can optimize content delivery using a simple and scalable architecture. The authors will continue to explore how ICN forwarding in edge computing could be used for efficient data delivery from the mobile edge. Prakash Suthar, et al. Expires January 26, 2021 [Page 30] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 Based on our study of control plane signaling, it is not beneficial to deploy ICN with existing protocols unless further changes are introduced in the control protocol stack itself. As mentioned in [TS23.501], the 5G network architecture proposes a simplification of control plane messages and can be a candidate for the use of ICN. As a starting step towards ICN user plane deployment, it is proposed to incorporate protocol changes in UE, eNodeB, SGW/PGW for data transport. ICN has inherent capabilities for mobility and content caching, which can improve the efficiency of data transport for unicast and multicast delivery. The authors welcome contributions and suggestions, including those related to further validations of the principles by implementing prototype and/or proof of concept in the lab and in the production environment. 8. Acknowledgements We thank all contributors, reviewers, and the chairs for the valuable time in providing comments and feedback that helped improve this draft. We specially want to mention the following members of the IRTF Information-Centric Networking Research Group (ICNRG), listed in alphabetical order: Thomas Jagodits, Luca Muscariello, David R. Oran, Akbar Rahman, Martin J. Reed, and Thomas C. Schmidt. The IRSG review was provided by Colin Perkins. 9. References 9.1. Normative References [TS24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.008 3.20.0, December 2005, . [TS25.323] 3GPP, "Packet Data Convergence Protocol (PDCP) specification", 3GPP TS 25.323 3.10.0, September 2002, . [TS29.274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, June 2013, . Prakash Suthar, et al. Expires January 26, 2021 [Page 31] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 [TS29.281] 3GPP, "General Packet Radio System (GPRS) Tunneling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 2011, . [TS36.323] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification", 3GPP TS 36.323 10.2.0, January 2013, . 9.2. Informative References [ALM] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., Pau, G., and X. Zeng, "Anchor-Less Producer Mobility in ICN", Proceedings of the 2Nd ACM Conference on Information-Centric Networking, ACM-ICN'15, ACM DL, pp.189-190, September 2013, . [BROWER] Brower, E., Jeffress, L., Pezeshki, J., Jasani, R., and E. Ertekin, "Integrating Header Compression with IPsec", MILCOM 2006 - 2006 IEEE Military Communications conference IEEE Xplore DL, pp.1-6, October 2006, . [CCN] "Content Centric Networking", . [CHENG] Liang, C., Yu, R., and X. Zhang, "Information-centric network function virtualization over 5g mobile wireless networks", IEEE Network Journal vol. 29, number 3, pp. 68-74, June 2015, . [EPCCUPS] Schmitt, P., Landais, B., and F. Yong Yang, "Control and User Plane Separation of EPC nodes (CUPS)", 3GPP The Mobile Broadband Standard, July 2017, . [FOTIOU] Fotiou, N. and G. Polyzos, "ICN privacy and name based security", ACM-ICN '14: Proceedings of the 1st ACM Conference on Information-Centric Networking ACM Digitial Library, pp. 5-6, September 2014, . Prakash Suthar, et al. Expires January 26, 2021 [Page 32] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 [GALIS] Galis, A., Makhijani, K., Yu, D., and B. Liu, "Autonomic Slice Networking", draft-galis-anima-autonomic-slice- networking-05 (work in progress), September 2018. [GRAYSON] Grayson, M., Shatzkamer, M., and S. Wainner, "Cisco Press book "IP Design for Mobile Networks"", Cisco Press Networking Technology series, June 2009, . [HICN] Muscariello, L., Carofiglio, G., Auge, J., and M. Papalini, "Hybrid Information-Centric Networking", draft- muscariello-intarea-hicn-04 (work in progress), May 2020. [ICN5G] Ravindran, R., suthar, P., Trossen, D., and G. White, "Enabling ICN in 3GPP's 5G NextGen Core Architecture", draft-ravi-icnrg-5gc-icn-03 (work in progress), July 2020. [ICNLOWPAN] Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C., Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN Networks (ICN LoWPAN)", draft-irtf-icnrg-icnlowpan-08 (work in progress), May 2020. [ICNQoS] Al-Naday, M., Bontozoglou, A., Vassilakis, G., and M. Reed, "Quality of Service in an Information-Centric Network", 2014 IEEE Global Communications Conference IEEE Xplore DL, pp. 1861-1866, December 2014, . [IPoICN] Trossen, D., Read, M., Riihijarvi, J., Georgiades, M., Fotiou, N., and G. Xylomenos, "IP over ICN - The better IP?", 2015 European Conference on Networks and Communications (EuCNC) IEEE Xplore DL, pp. 413-417, June 2015, . [MBICN] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, "Scalable mobile backhauling via information-centric networking", The 21st IEEE International Workshop on Local and Metropolitan Area Networks, Beijing, pp. 1-6, April 2015, . [MECSPEC] "Mobile Edge Computing (MEC); Framework and Reference Architecture", ETSI European Telecommunication Standards Institute (ETSI) MEC specification, March 2016, . Prakash Suthar, et al. Expires January 26, 2021 [Page 33] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 [MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and G. Wang, "Realtime multi-party video conferencing service over information centric network", IEEE International Conference on Multimedia and Expo Workshops (ICMEW) Turin, Italy, pp. 1-6, June 2015, . [NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T., Ohnishi, R., and E. Muramoto, "Real-time Streaming Data Delivery over Named Data Networking,", IEICE Transactions on Communications vol. E99.B, pp. 974-991, May 2016, . [NGMN] Robson, J., "Backhaul Provisioning for LTE-Advanced and Small Cells", Next Generation Mobile Networks, LTE- Advanced Transport Provisioning, V0.0.14, October 2015, . [OFFLOAD] Rebecchi, F., Dias de Amorim, M., Conan, V., Passarella, A., Bruno, R., and M. Conti, "Data Offloading Techniques in Cellular Networks: A Survey", IEEE Communications Surveys and Tutorials, IEEE Xplore DL, vol:17, issue:2, pp.580-603, November 2014, . [OLTEANU] Olteanu, A. and P. Xiao, "Fragmentation and AES Encryption Overhead in Very High-speed Wireless LANs", Proceedings of the 2009 IEEE International Conference on Communications ICC'09, ACM DL, pp.575-579, June 2009, . [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, . [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, . Prakash Suthar, et al. Expires January 26, 2021 [Page 34] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 [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, . [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, . [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, . [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, . [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, . [SDN5G] Page, J. and J. Dricot, "Software-defined networking for low-latency 5G core network", 2016 International Conference on Military Communications and Information Systems (ICMCIS) IEEE Xplore DL, pp. 1-7, May 2016, . [TLVCOMP] Mosko, M., "Header Compression for TLV-based Packets", ICNRG Buenos Aires IETF 95, April 2016, . [TOURANI] Tourani, R., Misra, S., Mick, T., and G. Panwar, "Security, Privacy, and Access Control in Information- Centric Networking: A Survey", IEEE Communications Surveys and Tutorials Volume 20, Issue 1, pp 566-600, September 2017, . Prakash Suthar, et al. Expires January 26, 2021 [Page 35] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 [TS23.203] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 10.9.0, September 2013, . [TS23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013, . [TS23.501] 3GPP, "System Architecture for the 5G System", 3GPP TS 23.501 15.2.0, June 2018, . [TS23.714] 3GPP, "Technical Specification Group Services and System Aspects: Study on control and user plane separation of EPC nodes", 3GPP TS 23.714 0.2.2, June 2016, . [TS29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 3.19.0, March 2004, . [TS33.310] 3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", 3GPP TS 33.310 10.7.0, December 2012, . [TS33.320] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 10.5.0, June 2012, . Authors' Addresses Prakash Suthar Cisco Systems Inc. Rosemont, Illinois 60018 USA Email: psuthar@cisco.com Prakash Suthar, et al. Expires January 26, 2021 [Page 36] Internet-Draft draft-irtf-icnrg-icn-lte-4g-08 July 2020 Milan Stolic Cisco Systems Inc. Rosemont, Illinois 60018 USA Email: mistolic@cisco.com Anil Jangam (editor) Cisco Systems Inc. San Jose, California 95134 USA Email: anjangam@cisco.com Dirk Trossen Huawei Technologies Riesstrasse 25 Munich 80992 Germany Email: dirk.trossen@huawei.com Ravishankar Ravindran Sterlite Technologies 5201 Greatamerica Pkwy Santa Clara, California 95054 USA Email: ravishankar.ravindran@sterlite.com Prakash Suthar, et al. Expires January 26, 2021 [Page 37]