Internet DRAFT - draft-auge-dmm-hicn-mobility-deployment-options
draft-auge-dmm-hicn-mobility-deployment-options
DMM Working Group J. Auge
Internet-Draft G. Carofiglio
Intended status: Informational L. Muscariello
Expires: 9 January 2021 M. Papalini
Cisco
8 July 2020
Anchorless mobility management through hICN (hICN-AMM): Deployment
options
draft-auge-dmm-hicn-mobility-deployment-options-04
Abstract
A novel mobility management approach has been proposed, 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). In virtue of its
anchorless property, we denote this approach as hICN-AMM (hICN
Anchorless Mobility Management) hereinafter.
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 or 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.
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
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Auge, et al. Expires 9 January 2021 [Page 1]
Internet-Draft hICN mobility: deployment options 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 9 January 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. 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) . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Control plane considerations . . . . . . . . . . . . . . 16
5. Deployment considerations . . . . . . . . . . . . . . . . . . 16
5.1. hICN in a slice . . . . . . . . . . . . . . . . . . . . . 17
5.2. End-to-end deployment . . . . . . . . . . . . . . . . . . 17
5.3. Network-contained deployment . . . . . . . . . . . . . . 18
5.4. Alternative data planes: joint hICN/SRv6 deployment . . . 18
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Auge, et al. Expires 9 January 2021 [Page 2]
Internet-Draft hICN mobility: deployment options July 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:
Auge, et al. Expires 9 January 2021 [Page 3]
Internet-Draft hICN mobility: deployment options July 2020
* the flexibility of multi-source/multi-path connectionless pull-
based transport. An example is the native support for consumer
mobility, i.e. the transparent emission of data requests over
multiple and varying available network interfaces during node
mobility;
* 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 9 January 2021 [Page 4]
Internet-Draft hICN mobility: deployment options July 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.
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 |
+-------+ +-------+ +---+---+ +-------+ +-------+
Auge, et al. Expires 9 January 2021 [Page 5]
Internet-Draft hICN mobility: deployment options July 2020
Figure 2: 5G reference architecture
The mobility management subsystem corresponds to the bottom part of
the picture and distinguishes user and control planes.
* 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.
* 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
anchor in the core (N6), the latter preventing convergence with non-
3GPP network accesses.
Auge, et al. Expires 9 January 2021 [Page 6]
Internet-Draft hICN mobility: deployment options July 2020
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 9 January 2021 [Page 7]
Internet-Draft hICN mobility: deployment options July 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 9 January 2021 [Page 8]
Internet-Draft hICN mobility: deployment options July 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
(eg. 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 9 January 2021 [Page 9]
Internet-Draft hICN mobility: deployment options July 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
(eg. 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 9 January 2021 [Page 10]
Internet-Draft hICN mobility: deployment options July 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 9 January 2021 [Page 11]
Internet-Draft hICN mobility: deployment options July 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 9 January 2021 [Page 12]
Internet-Draft hICN mobility: deployment options July 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
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 | |
+--------+ +-----------------+ | +-----------------+ | +--------+ |
| | |
Auge, et al. Expires 9 January 2021 [Page 13]
Internet-Draft hICN mobility: deployment options July 2020
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*
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.
Auge, et al. Expires 9 January 2021 [Page 14]
Internet-Draft hICN mobility: deployment options July 2020
+------------------+ +------------------+
| AMF | | SMF |
+-+--------------+-+ +-+--------------+-+
| | | |
| N1 | N2 | N4 | N4
| | | |
+---+---+ +---+---+ N3 +---+---+ N9 +---+---+ N6 +-------+
| UE +------+ gNB +------+ UPF +------+ UPF +------+ DN |
+-------+ +-------+ ^ +-------+ ^ +-------+ +-------+
| |
| |
hICN insertion
Figure 12: Replacement of N3 and N9 interfaces
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).
Auge, et al. Expires 9 January 2021 [Page 15]
Internet-Draft hICN mobility: deployment options July 2020
*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
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.
Auge, et al. Expires 9 January 2021 [Page 16]
Internet-Draft hICN mobility: deployment options July 2020
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.
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].
Auge, et al. Expires 9 January 2021 [Page 17]
Internet-Draft hICN mobility: deployment options July 2020
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
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.
Auge, et al. Expires 9 January 2021 [Page 18]
Internet-Draft hICN mobility: deployment options July 2020
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.
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.
Auge, et al. Expires 9 January 2021 [Page 19]
Internet-Draft hICN mobility: deployment options July 2020
+-----------------------+------+
hICN penetration: | UE | Proxy | None |
Benefit: Deployment option: | 1a 1b | 2a 2b | 2b | 2b |
+------------------------------------+-------+-------+-------+------+
| Additional state for static cons. | Y Y | Y N | N | N |
| Additional state for static prod. | Y Y | Y N | N | N |
| Additional state for mobile cons. | Y Y | Y N | N | N |
| Additional state for mobile prod. | 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 ongoing flows | 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 : bw 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
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,
<https://www.rfc-editor.org/info/rfc7476>.
7.2. Informative References
Auge, et al. Expires 9 January 2021 [Page 20]
Internet-Draft hICN mobility: deployment options July 2020
[CICN] io, Linux Foundation fd., "CICN project", 2018.
[I-D.auge-dmm-hicn-mobility]
Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility through hICN", Work in
Progress, Internet-Draft, draft-auge-dmm-hicn-mobility-03,
6 January 2020, <http://www.ietf.org/internet-drafts/
draft-auge-dmm-hicn-mobility-03.txt>.
[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", Work in
Progress, Internet-Draft, draft-homma-dmm-5gs-id-loc-
coexistence-03, 23 April 2019, <http://www.ietf.org/
internet-drafts/draft-homma-dmm-5gs-id-loc-coexistence-
03.txt>.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", Work in Progress, Internet-Draft, draft-
ietf-spring-segment-routing-15, 25 January 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-spring-
segment-routing-15.txt>.
[I-D.irtf-icnrg-deployment-guidelines]
Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", Work in Progress, Internet-Draft,
draft-irtf-icnrg-deployment-guidelines-07, 3 September
2019, <http://www.ietf.org/internet-drafts/draft-irtf-
icnrg-deployment-guidelines-07.txt>.
[I-D.muscariello-intarea-hicn]
Muscariello, L., Carofiglio, G., Auge, J., Papalini, M.,
and M. Sardara, "Hybrid Information-Centric Networking",
Work in Progress, Internet-Draft, draft-muscariello-
intarea-hicn-04, 20 May 2020, <http://www.ietf.org/
internet-drafts/draft-muscariello-intarea-hicn-04.txt>.
[TR.29.892-3GPP]
3rd Generation Partnership Project (3GPP), "Study on User
Plane Protocol in 5GC, 3GPP TR 29.892 (study item)", 2017.
Auge, et al. Expires 9 January 2021 [Page 21]
Internet-Draft hICN mobility: deployment options July 2020
[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",
DOI 10.1145/2984356.2984361, Proceedings of the 2016
conference on 3rd ACM Conference on Information-Centric
Networking - ACM-ICN '16, 2016,
<https://doi.org/10.1145/2984356.2984361>.
Authors' Addresses
Jordan Auge
Cisco Systems
11, rue Camille Desmoulins
92130 Issy-les-Moulineaux
France
Email: augjorda@cisco.com
Giovanna Carofiglio
Cisco Systems
11, rue Camille Desmoulins
92130 Issy-les-Moulineaux
France
Email: gcarofig@cisco.com
Luca Muscariello
Cisco Systems
11, rue Camille Desmoulins
92130 Issy-les-Moulineaux
France
Email: lumuscar@cisco.com
Michele Papalini
Cisco Systems
11, rue Camille Desmoulins
Auge, et al. Expires 9 January 2021 [Page 22]
Internet-Draft hICN mobility: deployment options July 2020
92130 Issy-les-Moulineaux
France
Email: micpapal@cisco.com
Auge, et al. Expires 9 January 2021 [Page 23]