DMM Working Group J. Auge Internet-Draft G. Carofiglio Intended status: Informational L. Muscariello Expires: July 9, 2020 M. Papalini Cisco January 06, 2020 Anchorless mobility management through hICN (hICN-AMM): Deployment options draft-auge-dmm-hicn-mobility-deployment-options-03 Abstract A novel mobility management approach is described in [I-D.auge-dmm-hicn-mobility], that leverages routable location- independent identifiers (IDs) and an Information-Centric Networking (ICN) communication model integrated in IPv6, also referred to as Hybrid ICN (hICN) [I-D.muscariello-intarea-hicn]. Such approach belongs to the category of pure ID-based mobility management schemes whose objective is (i) to overcome the limitations of traditional locator-based solutions like Mobile IP, (ii) to remove the need for a global mapping system as the one required by locator- identifier separation solutions like LISP [I-D.ietf-lisp-introduction] or ILA [I-D.herbert-intarea-ila]. ID-based networking as proposed by ICN architectures allows to disentangle forwarding operations from changes of network location, hence removing tunnels and user plane or control plane anchors. In virtue of its anchorless property, we denote this approach as hICN- AMM (hICN Anchorless Mobility Management) hereinafter. This document discusses hICN-AMM deployment options and related tradeoffs in terms of cost/benefits. Particular attention is devoted to the insertion in the recently proposed 5G Service Based Architecture under study at 3GPP where an hICN-AMM solution might present a more efficient alternative to the traditional tunnel-based mobility architecture through GTP-U. 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 Auge, et al. Expires July 9, 2020 [Page 1] Internet-Draft hICN mobility: deployment options January 2020 working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 9, 2020. 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. Overview of a mobile access network and the 5G architecture . 4 3. Transparent integration (option #1) . . . . . . . . . . . . . 7 3.1. MEC deployment (option #1a) . . . . . . . . . . . . . . . 7 3.2. hICN deployment as a UPF (option #1b) . . . . . . . . . . 10 3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. "Integrated" approaches: data-plane alternatives to GTP-U (option #2) . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. hICN insertion at N9 interface only (option #2a) . . . . 13 4.2. hICN deployment at both N9 and N3 interfaces (option #2b) 15 4.3. Control plane considerations . . . . . . . . . . . . . . 17 5. Deployment considerations . . . . . . . . . . . . . . . . . . 17 5.1. hICN in a slice . . . . . . . . . . . . . . . . . . . . . 17 5.2. End-to-end deployment . . . . . . . . . . . . . . . . . . 18 5.3. Network-contained deployment . . . . . . . . . . . . . . 18 5.4. Alternative data planes: joint hICN/SRv6 deployment . . . 18 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Auge, et al. Expires July 9, 2020 [Page 2] Internet-Draft hICN mobility: deployment options January 2020 1. Introduction The steady increase in mobile traffic observed in the recent years has come with a growing expectation from next generation 5G networks of a seamless latency-minimal service experience over multiple heterogeneous access networks. Motivated by stringent next- generation applications requirements and by the convergence of diverse wireless radio accesses, 5G standardization bodies have encouraged re-consideration of the existing Mobile IP and GTP-based architecture aiming at a simplified and sustainable mobility solution. Specifically, enhanced user plane solutions are currently investigated where GTP-U tunnels would be replaced by more flexible and dynamic forwarding schemes tailored to application needs and enabling novel use cases such as caching/computing at the edge (MEC/ FOG), coordinated use of multiple network accesses in parallel, etc. It is commonly accepted that the inefficiencies of tunnels in terms of state and network overhead, as well as the presence of anchors in the data plane are a direct consequence of using locators as identifiers of mobile nodes/services. This has motivated the introduction of a class of approaches distinguishing locators and identifiers, known as Loc/ID split, and more recently of pure ID- based approaches inspired from name-based Information-Centric Networking (ICN) architectures. The focus of this document is on the latter category of solutions and more precisely on the hICN-AMM proposal in [I-D.auge-dmm-hicn-mobility], that aims at a simplified anchorless mobility management through Hybrid ICN (hICN), a fully-fledged ICN architecture in IPv6 [I-D.muscariello-intarea-hicn]. hICN-AMM benefits result both from the flexibility of pure ID-based mobility solutions, that completely decouple data delivery from underlying network connectivity, and from the native mobility support of ICN architectures. Forwarding operations are performed directly based on location- independent IDs stored in routers' FIBs and no mapping of ID into locators is required. In this way, purely ID-based architectures remove the need to maintain a global mapping system at scale, and its intrinsic management complexity. Additional benefits brought by ICN communication model include: o the flexibility of multi-source/multi-path connectionless pull- based transport. An example is the native support for consumer Auge, et al. Expires July 9, 2020 [Page 3] Internet-Draft hICN mobility: deployment options January 2020 mobility, i.e. the transparent emission of data requests over multiple and varying available network interfaces during node mobility; o the opportunity to define fine-grained per-application forwarding and security policies. An overview of ICN principles and advantages for a simplified mobility management resulting from name-based forwarding can be found in [RFC7476], while a detailed description of the proposal is presented in [I-D.auge-dmm-hicn-mobility]. In this document, we discuss the integration of hICN-AMM proposal within an existing mobile network architecture and analyze the resulting tradeoffs in terms of cost/benefits. The 3GPP 5G architecture is used here as a reference as the envisaged target for hICN-AMM insertion. After a short overview of 5G architecture, we first discuss hICN-AMM insertion with no modification to the existing 3GPP architecture. We then consider the additional benefits emerging from a tighter integration involving optimization of data plane interfaces. Finally, we consider the impact of different degrees of hICN penetration, ranging from end-to-end to fully network-contained deployments. 2. Overview of a mobile access network and the 5G architecture Figure 1 schematizes a typical mobile network composed of edge, backhaul and core network segments. In the rest of this document, we assume an IPv6-based network. Auge, et al. Expires July 9, 2020 [Page 4] Internet-Draft hICN mobility: deployment options January 2020 , - , , - , , - , Cell site , ' ' , , ' ' , , ' ' , __ , ,__, ,__, , __/ A\ , /X/| /X/| , / A\__/ __ IP edge |_|/ IP backhaul |_|/ IP core __ \__/ A\ /X/| , , , , /X/| / A\__/ |_|/ network ,__ network ,__ network |_|/ \__/ A\ |, /X/| /X/| | \__/ | , |_|/, |_|/, ,| | , , ' | , , '' | , , ' | | ' - , ' | ' - , ' | ' - , ' | +-+-+ +-+-+ +-+-+ +-+-+ | | | | | | | | |DDC| |DDC| |DDC| |DDC| | | | | | | | | +---+ +---+ +---+ +---+ Figure 1: Overview of a typical mobile network architecture With the adoption of virtualization and softwarization technologies, services are increasingly hosted in Distributed Data Centers (DDC) deployed at the network edge (Mobile Edge Computing, MEC). 5G network has been designed around such evolved Service Based Architecture (SBA) [TS.23.501-3GPP], exploiting SDN and NFV capabilities. It consists in a set of modular functions with separation of user and control planes. Figure 2 gives the traditional representation of this architecture (as of Release 15) in its service-based representation. Auge, et al. Expires July 9, 2020 [Page 5] Internet-Draft hICN mobility: deployment options January 2020 Service Based Interfaces +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ | NSSF | | NRF | | DSF | | UDM | | NEF | | PCF | | AUSF | +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ | | | | | | | ----+------+--+---------+---------+-------+-+---------+---------+----- | | +--------+---------+ +---------+--------+ MOBILITY | AMF | | SMF | MANAGEMENT +-+--------------+-+ +++--------------+-+ | | | | control | N1 | N2 | N4 | N4 plane ...|..............|..............|..............|.................... | | | | user plane | | | | +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | +-------+ +-------+ +---+---+ +-------+ +-------+ Figure 2: 5G reference architecture The mobility management subsystem corresponds to the bottom part of the picture and distinguishes user and control planes. o the *user plane* (UP) represents the path followed by user traffic, between the mobile node or User Equipment (UE), and the Data Network (DN) corresponding to the egress point interfacing the ISP network and the Internet. The UP consists of the Radio Access Network (RAN), terminated by the gNB function, and of a series of User Plane Functions (UPFs) which are generic functions to transport/ process the traffic up to the egress point. In particular, UPFs serve as Layer 2 and Layer 3 anchors respectively in the RAN, and at the interface with the DN (to advertise IP prefixes). The interfaces between gNB and UPF (N3), and in- between UPFs (N9) are those where GTP tunnels are currently established, and where there are opportunities for optimization. o the principal *control plane* functions are the Access Management Function (AMF) which is responsible for the radio access, and the Session Management Function (SMF) which is taking care of the sessions established between a UE and a DN. The resulting protocol stack between user plane components is represented in Figure 3. It illustrates the encapsulation overhead of this solution at the various UPFs, and well as tunnel inefficiencies due to the transport of all mobile traffic up to the Auge, et al. Expires July 9, 2020 [Page 6] Internet-Draft hICN mobility: deployment options January 2020 anchor in the core (N6), the latter preventing convergence with non- 3GPP network accesses. UE 5G-AN N3 UPF N9 UPF N6 | | | +--------+ | | | | App. |--------------------------------------------------------| +--------+ | | +--------+ | | IP PDU |---------------------------------------------| IP PDU | | +--------+ +-----------------+ | +-----------------+ | +--------+ | | | |\ relay /| | |\ relay /| | | | | | | | \_____________/ |-|-| \_____________/ |-|-| | | | | | | GTP-U | | | GTP-U | GTP-U | | | GTP-U | | | | | +--------+ | +--------+--------+ | +--------+ | | 5G | | 5G | UDP |-|-| UDP | UDP |-|-| UDP | | | AN |-| AN +--------+ | +--------+--------+ | +--------+ | |protocol| |protocol| IP |-|-| IP | IP |-|-| IP | | | layers | | layers +--------+ | +--------+--------+ | +--------+ | | | | | L2 |-|-| L2 | L2 |-|-| L2 | | | | | +--------+ | +--------+--------+ | +--------+ | | | | | L1 |-|-| L1 | L1 |-|-| L1 | | +--------+ +-----------------+ | +-----------------+ | +--------+ | | | | Figure 3: 5G protocol stack 3. Transparent integration (option #1) This section discusses the insertion of hICN-AMM in an unmodified 3GPP 5G reference architecture, where GTP tunnels are preserved. As previously stated, maintaining GTP tunnels does not allow to overcome limitations of anchor-based approaches. However, a transparent integration of hICN-AMM limits to the minimum deployment costs and already brings advantages over the baseline architecture. We consider two cases: a) hICN-AMM deployment within Mobile Edge Computing (MEC) platforms, exploiting the local breakout capabilities of 5G networks, b) hICN-AMM deployment as User Plane Function (UPF) inside mobile user plane. 3.1. MEC deployment (option #1a) Option #1a refers to the deployment of an hICN forwarder within Mobile Edge Computing platforms. It relies on the local breakout capability introduced in 5G, i.e. a specific UPF denoted UL/CL (uplink classifier) that locally diverts specific flows to an alternative DN, filtering packets based for instance on information carried in packet headers. Auge, et al. Expires July 9, 2020 [Page 7] Internet-Draft hICN mobility: deployment options January 2020 In the hICN-AMM case, this function is used to realize the hICN punting function described in [I-D.muscariello-intarea-hicn], i.e. to identify hICN traffic (Interest and Data packets) and forward it to the local MEC hICN instance. The MEC deployment is illustrated in Figure 4. It is worth noticing that option #1a shares similarities with the deployment approach for ID/Loc solutions proposed in [I-D.homma-dmm-5gs-id-loc-coexistence]. +------------------+ +------------------+ | AMF | | SMF | +-+--------------+-+ +++--------------+-+ | | .| | | N1 | N2 N4 .| N4 | N4 | | .| | +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ | UE +------+ gNB +------+ UL/CL +------+ UPF +------+ DN | +-------+ +-------+ +---+---+ +-------+ +-------+ .| .| N9 .| _ +--++---+ N9 +-------+ MEC _( )___ | UPF +------+ DN +------( hICN )_ +-------+ +-------+ (_________) ^ ^ ^ |_______________| | local breakout hICN insertion Figure 4: hICN insertion in MEC Although it preserves tunnels and anchor points, option #1a permits an early termination of tunnels and the distribution of hICN capabilities close to the edge like in path caching and rate/loss/ congestion control which may be leveraged for efficient low-latency content distribution, especially in presence of consumer mobility. Let us analyze more in details such advantages. *Pro: Benefits of edge caching* The ability for the UE to communicate with an endpoint close to the access is a pre-requisite of latency-sensitive and interactive applications such as AR/VR. Option #1a avoids forwarding of high- throughput traffic into the core, when it can be terminated locally at MEC. hICN ability to take dynamic hop-by-hop forwarding decisions facilitates edge/core traffic load-balancing. In addition, the pull- based transport model enables request aggregation removing traffic Auge, et al. Expires July 9, 2020 [Page 8] Internet-Draft hICN mobility: deployment options January 2020 redundancy and facilitates the use of dynamically discovered sources. This is the case of requests directly satisfied from locally buffered temporary copies. In this way, hICN implicitly realizes opportunistic multicast distribution of popular content with benefits for improved users' QoE for services such as VoD or live streaming as well as reduced traffic cost by offloading the mobile core. We remark that for caching of data or of requests to be effective, a sufficient level of aggregation is required: one can thus expect hICN instances to be useful in the backhaul and core locations (with an eventual hierarchy of caches), while low-latency applications will benefit from deployments close to the cell site. *Pro: Consumer mobility improvements* Consumer mobility is natively supported in ICN. It is sufficient for a mobile UE to keep sending interests as soon as it connects to a new network interface. The combined use of identifiers and of a pull- model in hICN-AMM allows for seamless mobility across heterogeneous wired and wireless networks, as well as their simultaneous use for multi-homing and bandwidth aggregation. Figure 5 illustrates a mobility scenario considering a 3GPP access and a non-3GPP WiFi access tunneled to a N3 Inter-networking Function (N3IWF) offering a N3 interface for connection to the first UPF. In this setting, both wireless accesses are assumed to be connected through the same backhaul link, and thus to converge into the same first UPF. Placing an hICN instance at the aggregation of the two accesses would be beneficial both in terms of mobility and of local loss recovery, as a lost packet would be fast retransmitted directly from local hICN instance. tunnelled non-3GPP radio (e.g. WiFi) +------+ N3 +------+ N3IWF+-------+ hICN / +------+ \ + / \ | +---+---+ +-------+ N3 +---+---+ N9 +---+---+ N6 +---+---+ | UE +-----+ gNB +----+ UL/CL +----+ UPF +----+ DN +---+ hICN +-------+ +-------+ +---+---+ +-------+ +-------+ Figure 5: Example of a UE connection to two local radio accesses *Pro: Multihoming and multi-source communications* Auge, et al. Expires July 9, 2020 [Page 9] Internet-Draft hICN mobility: deployment options January 2020 A specific feature of hICN transport is to control the use of multiple path/sources of content at the same time, for instance caches located at the edge of different fixed/mobile network accesses. The consumer is able to use both network accesses in parallel adapting load-balancing on a per-packet granularity, based on network conditions in order to exploit the full aggregated bandwidth and/or to compensate variations induced by UE mobility or by random fluctuations of individual radio channel conditions. Figure 6 presents the case of a mobile consumer fetching data simultaneously from two distinct sources, for instance local caches behind each radio access. tunnelled non-3GPP radio (e.g. WiFi) +-------+ N3 +-------+ N9 +-------+ N6 +-------+ +-----+ N3IWF +----| UL/CL +----+ UPF +----+ DN +----+ hICN / +-------+ +-------+ +-------+ +-------+ / +---+---+ +-------+ N3 +-------+ N9 +---+---+ N6 +---+---+ | UE +----+ gNB +----+ UL/CL +----+ UPF +----+ DN +----+ hICN +-------+ +-------+ +---+---+ +-------+ +-------+ Figure 6: Multi-source communication with hICN *Con: Remaining IP anchors hinder producer mobility* hICN-AMM MEC deployments are not suitable for handling producer mobility effectively due to the presence of an anchor node in the core at the N6 interface which traffic has to pass through. An alternative would be to put in place dedicated control mechanisms to update routers FIB following mobility events, but such coordination between hICN forwarders would involve interaction with SMF. *Con: Loss of 3GPP control plane* More generally, traffic in between forwarders in the MEC will be out of reach for the mobile core. At the time of this writing, MEC interfaces are not well standardized; slicing and QoS functions will only be available up to the breakout point. 3.2. hICN deployment as a UPF (option #1b) The design of hICN makes it a good candidate for being deployed as a UPF in NFV environments, for instance within a container (see Figure 7. This solution has the advantage of preserving the interface with the 3GPP control plane, including support for slicing or QoS. Auge, et al. Expires July 9, 2020 [Page 10] Internet-Draft hICN mobility: deployment options January 2020 +------------------+ +------------------+ | AMF | | SMF | +-+--------------+-+ +-+--------------+-+ | | | | | N1 | N2 | N4 | N4 | | | | +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | +-------+ +-------+ +-------+ +-------+ +-------+ ^ ^ |________________| hICN insertion Figure 7 *Improved traffic engineering* On-path deployments of hICN-AMM, as early as at the first UPF, bring additional advantages in terms of opportunities to optimize traffic engineering, including multipath and load balancing support. As an example, one may consider hICN deployment at the PDU Session Anchor, with dynamic congestion-aware and per-application control of multiple downstream paths to the edge. *Network-assisted transport* hICN ability to provide in-network assistance for rate/loss/ congestion control is an additional advantage, e.g. to support rate adaptation in the case of dynamic adaptive streaming, or to improve reliability of WiFi communications via local wireless detection and recovery [WLDR]. We illustrate the latter case in Figure 8, where an hICN UPF is deployed as the first UPF following the WiFi access. hICN UPF can exploit network buffers to realize loss detection and recovery of the packet transiting on the unreliable radio access, thus offering superior performance for WiFi traffic with respect to a traditional end-to-end recovery approach. Such feature could be fundamental for low-latency reliable services. Auge, et al. Expires July 9, 2020 [Page 11] Internet-Draft hICN mobility: deployment options January 2020 +-- Loss Detection and Recovey V +-------+ N3 +-------+ +-----+ N3IWF +----| hICN | / +-------+ +---+---+ / N9 | +---+---+ +-------+ N3 +---+---+ N9 +---+---+ N6 +---+---+ | UE +----+ gNB +----+ UPF +----+ UPF +----+ DN +----+ hICN +-------+ +-------+ +---+---+ +-------+ +-------+ Figure 8: In-network loss detection and recovery with hICN *Producer mobility* Option #1b is appropriate for handling producer mobility; however, it would be supported through traditional DMM approaches for identifier- based mobility. 3.3. Summary This section has reviewed various insertion strategies for hICN, including overlay deployments using local breakout to hICN instances situated in MEC, or hICN forwarders deployed within an UPF. While those approaches have the merit of allowing an easy or early integration of hICN and exploiting some of its benefits, they do not fully exploit purely ID-based capabilities nor the dynamic hICN forwarding. 4. "Integrated" approaches: data-plane alternatives to GTP-U (option #2) The section describes more integrated hICN-AMM/3GPP 5G approaches leveraging hICN capabilities in the mobile backhaul network in alternative to GTP-U tunnels over N9 (and possibly N3) interface(s), as shown in Figure 2 and Figure 3. It is proposed to replace GTP tunnels at N9 and optionally at N3 interfaces by an hICN-enabled data plane operating on location- independent identifiers advertised by the routing protocol and whose forwarding information is stored/updated in routers' FIBs according to the hICN-AMM approach. We remind that an hICN data plane does not require the presence of a mapping system nor the enablement of all routers, since hICN traffic is transparently forwarded by regular hICN-unaware IP routers. Auge, et al. Expires July 9, 2020 [Page 12] Internet-Draft hICN mobility: deployment options January 2020 4.1. hICN insertion at N9 interface only (option #2a) Option #2a answers the question of the ongoing 3GPP study of alternative technologies for the N9 interface [TR.29.892-3GPP]. with no impact on gNB as illustrated in Figure 9. The corresponding protocol layering is shown in Figure 10 where we assume hICN- enablement of the end-points (an alternative in-network hICN enablement via proxies is possible but not considered by this document). In the protocol layer, hICN is associated to IPv6 PDU layer, transported over N9 directly over L2. +------------------+ +------------------+ | AMF | | SMF | +-+--------------+-+ +-+--------------+-+ | | | | | N1 | N2 | N4 | N4 | | | | +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | +-------+ +-------+ +-------+ +-------+ +-------+ ^ | hICN insertion Figure 9: Replacement of N9 interface Auge, et al. Expires July 9, 2020 [Page 13] Internet-Draft hICN mobility: deployment options January 2020 UE 5G-AN N3 UPF N9 UPF N6 | | | +--------+ | | | | App. |--------------------------------------------------------| +--------+ | | +--------+ | | IP PDU | | | | IP PDU | | | (hICN) |---------------------------------------------| (hICN) | | +--------+ +-----------------+ | +-----------------+ | | | | | | |\ relay /| | |\ decap / | | | | | | | \_____________/ |-|-| \_____________/ | | | | | | | | GTP-U | | | GTP-U | | | | | | | | +--------+ | +--------+ | | | | | 5G | | 5G | UDP |-|-| UDP | | | | | | AN |-| AN +--------+ | +--------+ | | | | |protocol| |protocol| IP |-|-| IP | | | | | | layers | | layers +--------+ | +--------+--------+ | +--------+ | | | | | L2 |-|-| L2 | L2 |-|-| L2 | | | | | +--------+ | +--------+--------+ | +--------+ | | | | | L1 |-|-| L1 | L1 |-|-| L1 | | +--------+ +-----------------+ | +-----------------+ | +--------+ | | | | Figure 10: Replacement of N9 interface - Protocol layers *Anchorless consumer and producer mobility* Option #2a realizes a fully anchorless solution as the traffic does not need to go up to the anchor point in the core, nor to depend on the resolution performed by a mapping node. As illustrated in Figure 11, communication between two UEs can take place by forwarding traffic between their first UPFs, and thus avoids unnecessarily overload of links up to the core. In this way option #2a provides an effective traffic offloading and increased resiliency of network operations in the event of a failure that would disconnect the edge from the mobile core (e.g. disaster recovery scenario). +---+---+ +---+---+ N3 +-------+ | UE +------+ gNB +------+ UPF +------ ... +-------+ +-------+ +---+---+ | N9 hICN domain +---+---+ +---+---+ N3 +-------+ | UE +------+ gNB +------+ UPF +------ ... +-------+ +-------+ +---+---+ Figure 11: Offloading of inter-UE communications *Low state and signaling overhead* Auge, et al. Expires July 9, 2020 [Page 14] Internet-Draft hICN mobility: deployment options January 2020 Unlike traditional 3GPP GTP-based mobility management, hICN-AMM does not involve signaling/ additional state to be maintained to handle static consumers/producers or mobile consumers. Forwarding updates are required only in the event of producer mobility to guarantee real-time re-direction of consumer requests without triggering routing updates. *Dynamic forwarding strategies / UPF selection* Dynamic selection of next hop or exit point is simplified by hICN-AMM as it can be performed locally based on names and/or name-based locally available information (e.g. measurements of congestion status or residual latency up to the first data source). 4.2. hICN deployment at both N9 and N3 interfaces (option #2b) Option #2b proposes to additionally remove GTP tunnels between the RAN and the first UPF (N3 interface). It is illustrated in Figure 12 and Figure 13. +------------------+ +------------------+ | AMF | | SMF | +-+--------------+-+ +-+--------------+-+ | | | | | N1 | N2 | N4 | N4 | | | | +---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+ | UE +------+ gNB +------+ UPF +------+ UPF +------+ DN | +-------+ +-------+ ^ +-------+ ^ +-------+ +-------+ | | | | hICN insertion Figure 12: Replacement of N3 and N9 interfaces Auge, et al. Expires July 9, 2020 [Page 15] Internet-Draft hICN mobility: deployment options January 2020 UE 5G-AN N3 UPF N9 UPF N6 | | | +--------+ | | | | App. |--------------------------------------------------------| +--------+ | +--------+--------+ | +--------+ | | IP PDU | | | IP PDU | IP PDU | | | IP PDU | | | (hICN) |-----------------------| (hICN) | (hICN) |-|-| (hICN) | | +--------+ +-----------------+ | | | | | | | | | | |\ decap / | | | | | | | | | | | \_____________/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5G | | 5G | | | | | | | | | | AN |-| AN | | | | | | | | | |protocol| |protocol| | | | | | | | | | layers | | layers +--------+ | +--------+--------+ | +--------+ | | | | | L2 |-|-| L2 | L2 |-|-| L2 | | | | | +--------+ | +--------+--------+ | +--------+ | | | | | L1 |-|-| L1 | L1 |-|-| L1 | | +--------+ +-----------------+ | +-----------------+ | +--------+ | | | | Figure 13: Replacement of N3 and N9 interfaces : Protocol layers *Full tunnel removal; No internetworking between N3 and N9* A clear advantage is the elimination of all GTP tunnels and a similar specification of both N3 and N9 interfaces as recommended by 3GPP, so removing challenges of inter-networking between N3 and N9. Also, it leads to a flat and simpler architecture, allowing convergence with other non-3GPP accesses (and related management and monitoring tools). *State and signaling reduction* A direct consequence is the extension to N3 of the property of hICN- AMM above described, namely the absence of signaling and additional state to be maintained to handle static consumers/producers or mobile consumers. *Dynamic first UPF selection* Dynamic forwarding capabilities are extended to the selection of the first UPF, hence closer to the edge w.r.t. option #2a. The advantage can be significant in the case of dense deployments scenarios: here hICN-AMM makes possible to isolate the core network from local edge mobility (a design objective of 5G mobile Auge, et al. Expires July 9, 2020 [Page 16] Internet-Draft hICN mobility: deployment options January 2020 architecture), while still permitting distributed selection of ingress UPFs, and load-balancing of traffic across them. 4.3. Control plane considerations By operating directly on router FIBs for mobility updates and for dynamic policy-based forwarding strategies etc., hICN inherits the simplicity of IP forwarding and can reuse legacy IP routing protocols to advertise/route ID prefixes. In this way it remains compatible with the exiting control plane architecture as proposed in the 3GPP standard, with no change required to N1, N2 or N4. hICN-AMM producer mobility management does not require SMF interaction, but could be implemented by means of SMF signaling, at the condition to follow the same procedure described for MAP-Me protocol in hICN-AMM. In the analysis of pros and cons of SMF interaction, it is worth noticing that the absence of SMF interaction might be beneficial in case of dense deployments or of failure of the central control entities (infrastructure-less communication scenarios) to empower distributed control of local mobility within an area. 5. Deployment considerations The benefits previously described can be obtained by an upgrade of only a few selected routers at the network edge. The design of hICN allows the rest of the infrastructure to remain unmodified, and to leverage existing management and monitoring tools. 5.1. hICN in a slice The use of hICN does not impose any specific slicing of the network as the architecture uses regular IPv6 packets, and is designed to coexist with regular traffic. In that, hICN contrasts with previous approaches integrating ICN in IP networks by using separate slices and/or different PDU formats as reviewed in [I-D.irtf-icnrg-deployment-guidelines]. Although not required, slicing can ease a transition of services towards hICN, and/or the coexistence of different mobility management solutions with hICN-AMM or of different hICN deployment options. An example use of slicing would be to create multiple slices for optimizing the delivery of services having different requirements such as a low-latency communication slice with hICN instances deployed very close to the edge, and a video delivery service with caches deployed in locations aggregating a sufficient number of users to be effective. Auge, et al. Expires July 9, 2020 [Page 17] Internet-Draft hICN mobility: deployment options January 2020 5.2. End-to-end deployment Deployment of the hICN stack in the endpoints is the preferred insertion option and offers the full range of benefits. hICN client and network stacks are available through two reference implementations based on the CICN project [CICN]. They share the objective of smooth deployment in existing devices, and are fully user-space based. The first one is built on top of existing IP primitives and proposed as an application/library for all major OS vendors including iOS, Android, Linux, macOS and Windows. The second one targets high- performance routers and servers, and leverages the VPP technology [VPP]. 5.3. Network-contained deployment In case it is not possible to insert hICN stack at endpoints, an hICN deployment fully contained in the network can be envisaged through the deployment of proxies. An overview of different options implemented at the network, transport or application level is provided in [I-D.irtf-icnrg-deployment-guidelines]. An example would be the deployment of HTTP (or RTP) proxies (as made available through the CICN project) at the ingress and egress (resp. first and last UPFs), in order to benefit from content awareness in the network. Such configuration however reduces the flexibility and dynamic forwarding capabilities in endpoints. In particular, existing transport protocols have limited support for dynamically changing paths/discovered sources or network conditions. In such configuration, traffic that is not handled through hICN-AMM mechanisms can still benefit from the lower overhead and anchorless mobility capabilities coming from the removal of GTP tunnels, as well as dynamic forwarding capabilities that are inherent to the forwarding pipeline. This results from the ability to assign location-independent identifiers to endpoints even without the deployment of a full hICN stack. The advantages of removed identifier/location mapping and of a lightweight FIB update process are maintained. No encapsulation is required and packet headers are not modified, which may allow the network to have visibility of the source and/or destination identifiers. 5.4. Alternative data planes: joint hICN/SRv6 deployment hICN is designed to operate inside an IPv6 network by means of an enriched communication layer supporting ICN primitives. The targeted deployment of a few hICN-empowered nodes leads to the tradeoff between incremental deployment and benefits which are proportionally Auge, et al. Expires July 9, 2020 [Page 18] Internet-Draft hICN mobility: deployment options January 2020 related to the degree of hICN penetration. The association of hICN with other data planes technologies is investigated as a possibility to overcome the above-mentioned tradeoff yielding to a selective, yet fully beneficial insertion of hICN in IP networks. To this aim, we focus on hICN insertion in a Segment Routing (SR) enhanced data plane, specifically considering SRv6 instantiation of SR [I-D.ietf-spring-segment-routing]. hICN/SRv6 combination inherits all SRv6 advantages presented in SR- dedicated section of this document, namely "underlay" management (fast reroute, etc.), service chaining or fine-grained TE, for instance. In addition, it allows extending the reach of hICN on regular IP routers with SRv6 functionality. One realization being to create SRv6 domains in between hICN nodes. The hICN router (through forwarding strategies) would then act as a control plane for SRv6 by specifying the list of SIDs to insert in the packet. SRv6 forwarding of packets between hICN hops would permit to enforce dynamic per-application hICN forwarding strategies and their objectives (path steering, QoS, etc.), which would be otherwise not possible over not hICN-enabled IP network segments. It would also allow dynamic multi-path and load balancing in hICN-unaware IP network segments and enforcing the symmetry of the request/reply path for more accurate round trip delay measurements and rate/congestion control). 6. Summary hICN proposes a general purpose architecture that combines the benefits of a pure-ID (name-based) architecture with those of ICN. An hICN enabled network offers native offloading capabilities in virtue of the anchorless properties resulting from the pure-ID communication scheme. It does so without the need for a mapping system, and further requires no change in the 5G architecture nor in its control plane. The architecture will further leverage the incremental insertion of Information-Centric functionalities through proxies or direct insertion in user devices as the technology gets adopted and deployed. While a full deployment is recommended to make efficient use of available network resources, it is still possible to opt for a partial or phased deployment, with the associated tradeoffs that we summarize in Figure 14. Auge, et al. Expires July 9, 2020 [Page 19] Internet-Draft hICN mobility: deployment options January 2020 This table reviews the various insertion options in the 3GPP architecture earlier introduced - namely options #1a (MEC), #1b (UPF), #2a (N9) and #2b (N9/N3) -, assuming endpoints are hICN- enabled. Various levels of hICN penetration are then considered : (UE) the UE is hICN-enabled, (proxy) hICN processing is available through proxies, (None) no hICN function, the traffic is purely forwarded using endpoint identifiers rather than content identifiers. +-----------------------+------+ hICN penetration: | UE | Proxy | None | Benefit: Deployment option: | 1a 1b | 2a 2b | 2b | 2b | +--------------------------------------+-------+-------+-------+------+ | Additional state for static consumer | Y Y | Y N | N | N | | Additional state for static producer | Y Y | Y N | N | N | | Additional state for mobile consumer | Y Y | Y N | N | N | | Additional state for mobile producer | Y Y | Y N | N | N | +--------------------------------------+-------+-------+-------+------+ | Signalization for static consumer | Y Y | N N | N | N | | Signalization for static producer | Y Y | N N | N | N | | Signalization for mobile consumer | Y Y | N N | N | N | | Signalization for mobile producer | Y Y | Y Y | Y | Y | +--------------------------------------+-------+-------+-------+------+ | Removed tunnel/encap overhead | N N | P Y | Y | Y | | Preserve perf. of flows in progress | N N | Y Y | Y | Y | +--------------------------------------+-------+-------+-------+------+ | Local offload | P N | Y Y | Y | Y | | Anchorless for UP | N N | Y Y | Y | Y | | Anchorless for CP | N N | Y Y | Y | Y | | Dynamic egress UPF selection | N N | Y Y | Y | Y | | Dynamic ingress UPF selection | N N | N Y | Y | Y | +--------------------------------------+-------+-------+-------+------+ | Edge caching : low-latency | Y Y | Y Y | P | N | | Edge caching : multicast | Y Y | Y Y | P | N | | Seamless mobility across het. RAT | Y Y | Y Y | Y | P | | Multi-homing ; Bandwidth aggregation | Y Y | Y Y | Y | P | | Multi-source | Y Y | Y Y | Y | N | | In-network assistance | N Y | Y Y | P | N | +--------------------------------------+-------+-------+-------+------+ | Integration with 3GPP CP | N Y | Y Y | Y | Y | +--------------------------------------+-------+-------+-------+------+ LEGEND: (Y) Yes - (N) No - (P) Partial Figure 14 Auge, et al. Expires July 9, 2020 [Page 20] Internet-Draft hICN mobility: deployment options January 2020 7. References 7.1. Normative References [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, . 7.2. Informative References [CICN] io, Linux., "CICN project", 2018. [I-D.auge-dmm-hicn-mobility] Auge, J., Carofiglio, G., Muscariello, L., and M. Papalini, "Anchorless mobility through hICN", draft-auge- dmm-hicn-mobility-02 (work in progress), July 2019. [I-D.herbert-intarea-ila] Herbert, T. and P. Lapukhov, "Identifier-locator addressing for IPv6", draft-herbert-intarea-ila-01 (work in progress), March 2018. [I-D.homma-dmm-5gs-id-loc-coexistence] Homma, S., Kawakami, K., Akhavain, A., Rodriguez-Natal, A., and R. Shekhar, "Co-existence of 3GPP 5GS and Identifier-Locator Separation Architecture", draft-homma- dmm-5gs-id-loc-coexistence-03 (work in progress), April 2019. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.irtf-icnrg-deployment-guidelines] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", draft-irtf-icnrg-deployment- guidelines-07 (work in progress), September 2019. Auge, et al. Expires July 9, 2020 [Page 21] Internet-Draft hICN mobility: deployment options January 2020 [I-D.muscariello-intarea-hicn] Muscariello, L., Carofiglio, G., Auge, J., and M. Papalini, "Hybrid Information-Centric Networking", draft- muscariello-intarea-hicn-03 (work in progress), October 2019. [TR.29.892-3GPP] 3rd Generation Partnership Project (3GPP), "Study on User Plane Protocol in 5GC, 3GPP TR 29.892 (study item)", 2017. [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "System Architecture for 5G System; Stage 2, 3GPP TS 23.501 v2.0.1", December 2017. [VPP] io (Linux Foundation), FD., "Vector Packet Processing (VPP)", url https://wiki.fd.io/view/VPP, n.d.. [WLDR] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, N., and X. Zeng, "Leveraging ICN In-network Control for Loss Detection and Recovery in Wireless Mobile networks", Proceedings of the 2016 conference on 3rd ACM Conference on Information-Centric Networking - ACM-ICN '16, DOI 10.1145/2984356.2984361, 2016. Authors' Addresses Jordan Auge Cisco Systems 11, rue Camille Desmoulins Issy-les-Moulineaux 92130 France Email: augjorda@cisco.com Giovanna Carofiglio Cisco Systems 11, rue Camille Desmoulins Issy-les-Moulineaux 92130 France Email: gcarofig@cisco.com Auge, et al. Expires July 9, 2020 [Page 22] Internet-Draft hICN mobility: deployment options January 2020 Luca Muscariello Cisco Systems 11, rue Camille Desmoulins Issy-les-Moulineaux 92130 France Email: lumuscar@cisco.com Michele Papalini Cisco Systems 11, rue Camille Desmoulins Issy-les-Moulineaux 92130 France Email: micpapal@cisco.com Auge, et al. Expires July 9, 2020 [Page 23]