Anchorless mobility through hICN
draft-auge-dmm-hicn-mobility-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jordan Auge , Giovanna Carofiglio , Luca Muscariello , Michele Papalini | ||
| Last updated | 2018-06-20 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-auge-dmm-hicn-mobility-00
DMM Working Group J. Auge
Internet-Draft G. Carofiglio
Intended status: Informational L. Muscariello
Expires: December 22, 2018 M. Papalini
Cisco Systems Inc.
June 20, 2018
Anchorless mobility through hICN
draft-auge-dmm-hicn-mobility-00
Abstract
This document presents how mobility management is handled in Hybrid-
ICN [I-D.muscariello-intarea-hicn]. The objective of the document is
to present how end-points mobility is managed in two main cases: the
end-point sends data (data producer ) or the end-point receive data
(data consumer). These two cases are taken into account entirely to
provide anchorless mobility management in hICN.
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/.
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 December 22, 2018.
Copyright Notice
Copyright (c) 2018 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
Auge, et al. Expires December 22, 2018 [Page 1]
Internet-Draft Anchorless mobility through hICN June 2018
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Anchors and anchorless mobility . . . . . . . . . . . . . 3
2. Towards locator-independent network architectures . . . . . . 4
3. Information-Centric Networking (ICN) . . . . . . . . . . . . 5
3.1. Hybrid-ICN overview . . . . . . . . . . . . . . . . . . . 5
3.2. Consumer and producer mobility . . . . . . . . . . . . . 6
4. Hybrid-ICN Anchorless Mobility Management (hICN-AMM) . . . . 7
4.1. Signalization messages; acknowledgements and
retransmission . . . . . . . . . . . . . . . . . . . . . 8
4.2. Dynamic face creation and producer-triggered
advertisements . . . . . . . . . . . . . . . . . . . . . 8
4.3. Update protocol . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Illustration . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Message content . . . . . . . . . . . . . . . . . . . 10
4.3.3. Processing at network routers . . . . . . . . . . . . 11
4.4. Notifications and scoped discovery . . . . . . . . . . . 11
4.4.1. Notification processing . . . . . . . . . . . . . . . 11
4.4.2. Illustration . . . . . . . . . . . . . . . . . . . . 12
5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Simplicity, scalability, efficiency . . . . . . . . . . . 13
5.3. Reduced latency through caching . . . . . . . . . . . . . 14
5.4. Improved reliability through caching . . . . . . . . . . 15
5.5. Local mobility and recovery from common cache . . . . . . 16
5.6. Additional reliability through consumer multihoming . . . 17
5.7. Bandwidth aggregation with consumer multihoming . . . . . 19
5.8. Traffic and signalization offload . . . . . . . . . . . . 20
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Interaction with non-hICN enabled routers . . . . . . . . 22
6.3. Security considerations . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
Mobility has become a basic feature of network communications.
Fueled by rapid advances in mobile technology and by the increasing
digitization of network edge, mobile traffic has driven overall
Auge, et al. Expires December 22, 2018 [Page 2]
Internet-Draft Anchorless mobility through hICN June 2018
Internet traffic growth in the last years and such trend is expected
to continue.
However, mobility was not considered in the original IP network
design. Current solutions provide mobility support by means of
overlays added on top of the network as an afterthought. Notable
examples are IETF Mobile IP and its variants [RFC3344] and [RFC3775]
3GPP GTP-based architecture [TS29.274], both based on tunnelling and
encapsulation.
With the deployments of novel applications such as mobile video, AR/
VR or vehicular networking, mobile networks are more challenged than
ever, and the currently centralized architectures show limitations in
terms of performance and scalability.
One identified difficulty in proposing mobility models in IP lies in
the semantic overloading of IP addresses which are both host
identifiers, and locators used for routing. Starting with LISP, the
identifier/locator split paradigm has shown promising results in
virtue of its scalability properties with respect to routing tables
entries, and the possibilities it offers in terms of mobility.
Several solutions have been proposed around this concept, namely
ILNP, ILSR, and ILA.
The document proposes a mobility approach based on Hybrid ICN as
described in [I-D.muscariello-intarea-hicn] and analyzes more in-
depth mobility considerations in hICN, comparatively with state-of-
the-art solutions, and how the hICN may allow for the expected
performance from future networks, paving the way for innovation and
new applications, while keeping the simplicity and end-to-end design
of the current Internet.
1.1. Anchors and anchorless mobility
Because they are intrinsically bound to the topological location of a
node, session established through locators require additional
mechanisms to support mobility, including the presence of anchor
points in the network. The notion of _anchor_ and the resulting
_anchorless_ properties of mobility schemes are prone to different
interpretation depending on the context. The following definitions
attempt to reconcile those interpretations and propose a unifying
terminology used throughout this document.
Anchor An anchor refers to a specialized node or service, possibly
distributed, functionally required by a network architecture for
forwarding or mobility. This is in contrast to decentralized
architectures. Configuration of these anchors, including their
location, will directly affect the overall scheme performance. We
Auge, et al. Expires December 22, 2018 [Page 3]
Internet-Draft Anchorless mobility through hICN June 2018
follow the classic distinction between control plane and user (or
data, or forwarding) plane to distinguish control-plane anchors
and user-plane anchors.
User-plane anchor A user-plane anchor is a node through which
traffic is forced to pass. An example of such anchor is the
indirection point in Mobile IP.
Control-plane anchor A control-plane anchor refers to a node that is
not responsible for carrying traffic, but is needed for the
operation of the forwarding and/or the mobility architecture. An
example of such anchor is the resolution or mapping service of
LISP. We remark that while not being on path, such anchors might
affect the performance of the user-plane due to resolution delays
or indirection (following a mapping cache miss for instance).
Anchorless This term qualifies approaches that do not involve any
user-plane not control-plane anchor.
2. Towards locator-independent network architectures
We distinguish network architectures based on their use of location
independent identifiers (or names) and locators for forwarding.
*Locator-based architectures*
As mentioned earlier, IP architectures are typically operated based
on locators corresponding to the IP addresses of the host interfaces
in their respective network attachment, used also as session
identifiers. This results in a complex mobility architecture built
on top, involving traffic anchors and tunnels to preserve the
identifier exposed to the transport layer: IP/IP or GRE tunnels in
Mobile IP, and GTP tunnels in 3GPP architectures.
The limitations of locator-based schemes in terms of complexity,
overhead and efficiency are well-recognized and led to other
alternatives to be considered.
*Locator-ID separation architectures*
LISP [RFC6830] was the first proposal to distinguish between the
usage of IP addresses as locators or identifiers by explicitly
defining two namespaces, respectively used for endpoint
identification and forwarding. A mapping service is further used to
bind an identifiers to a given location, and updated after mobility.
From there, several approaches have been defined, either host-based
like SHIM6 [RFC5533] or HIP [RFC4423]), or network-based, like LISP
Auge, et al. Expires December 22, 2018 [Page 4]
Internet-Draft Anchorless mobility through hICN June 2018
[RFC6830], ILSR, ILNP [RFC6740] or ILA [I-D.herbert-intarea-ila] to
cite a few.
An overview of these approaches and their use in mobility is
presented in {?I-D.bogineni-dmm-optimized-mobile-user-plane}}.
The main challenge consists in maintaining a (distributed) mapping
service at scale, including the synchronization of local caches
required for scalability and efficiency.
*ID-based architectures*
A third class of approaches exists that redefines IP communication
principles (i.e. network and transport layers) around location-
independent network identifiers of node/traffic. The interest of
such architectures is highlighted in [I-D.vonhugo-5gangip-ip-issues]
(referred to as ID-oriented Networking) for it removes the
limitations introduced by locators and simplifies the management of
mobility. The draft however question the possibility to realize such
an architecture where node status and mobility would not affect
routing table stability.
The work done around Information-Centric Networking (ICN) falls into
such class of approaches that we refer to as purely ID-based, also
known as name-based [I-D.irtf-icnrg-terminology], although as we will
see, mobility management often departs from this principle.
3. Information-Centric Networking (ICN)
ICN is a new networking paradigm centering network communication
around named data, rather that host location. Network operations are
driven by location-independent data names, rather than location
identifiers (IP addresses) to gracefully enable user-to-content
communication.
Although there exist a few proposals, they share the same set of core
principles, resulting in several advantages including a simplified
mobility management [RFC7476]. For clarify, this section we focus on
hICN [I-D.muscariello-intarea-hicn] an ICN implementation for IPv6.
3.1. Hybrid-ICN overview
Hybrid ICN (hICN) is an ICN architecture that defines integration of
ICN semantics within IPv6. The goal of hICN is to ease ICN insertion
in existing IP infrastructure by:
Auge, et al. Expires December 22, 2018 [Page 5]
Internet-Draft Anchorless mobility through hICN June 2018
1. selective insertion of hICN capabilities in a few network nodes
at the edge (no need for pervasive fully hICN network
deployments);
2. guaranteed transparent interconnection with hICN-unaware IPv6
nodes, without using overlays;
3. minor modification to existing IP routers/endpoints;
4. re-use of existing IP control plane (e.g. for routing of IP
prefixes carrying ID-semantics) along with performing mobility
management and caching operations in forwarding plane;
5. fallback capability to tradition IP network/transport layer.
hICN architecture is described in [I-D.muscariello-intarea-hicn].
Together with MAP-Me [I-D.irtf-icnrg-mapme], it forms the basis for
the mobility management architecture we describe in the rest of this
document.
3.2. Consumer and producer mobility
*Consumer mobility* The consumer end-point is the logical
communication termination that receives data. Due to the pull-based
and connection-less properties of hICN communications, consumer
mobility comes natively with ICN. It is indeed sufficient that the
consumer reissues pending interests from the new point-of-attachment
to continue the communication. Consumer mobility is anchorless by
design. As will be discussed below, it is however necessary to have
appropriate transport layer on top able to cope with the disruptions
and path variations due to the mobility, at an eventual fine
granularity.
*Producer mobility* The producer end-point is the logical
communication termination that sends data. Producer mobility is not
natively supported by the architecture, rather handled in different
ways according to the selected producer mobility management scheme.,
some of which diverge from the concept of pure ID-based architecture
through their use of locators.
In fact, many schemes proposed for ICN are adaptations to the vast
amount of work made in IP over the last two decades [RFC6301].
Surveys for the ICN family, resp. for CCN/NDN-specific solutions, are
available in [SURVEYICN], respectively [SURVEY1] and [SURVEY2].
There has been however a recent trend towards anchorless mobility
management, facilitated by ICN design principles, that has led to new
proposals and an extension of previous classifications in
[I-D.irtf-icnrg-mapme] and [MAPME] to the four following categories:
Auge, et al. Expires December 22, 2018 [Page 6]
Internet-Draft Anchorless mobility through hICN June 2018
o _Resolution based_ solutions rely on dedicated rendez-vous nodes
(similar to DNS) which map content names into routable location
identifiers. To maintain this mapping updated, the producer
signals every movement to the mapping system. Once the resolution
is performed, packets can be correctly routed directly to the
producer.
o _Anchor-based_ proposals are inspired by Mobile IP, and maintain a
mapping at network-layer by using a stable home address advertised
by a rendez-vous node, or anchor. This acts as a relay,
forwarding through tunneling both interests to the producer, and
data packets coming back.
o _Tracing-based_ solutions allow the mobile node to create a hop-
by-hop forwarding reverse path from its RV back to itself by
propagating and keeping alive traces stored by all involved
routers. Forwarding to the new location is enabled without
tunneling.
o _Anchorless_ approaches allow the mobile nodes to advertise their
mobility to the network without requiring any specific node to act
as a rendez-vous point.
4. Hybrid-ICN Anchorless Mobility Management (hICN-AMM)
The consumer end-point does not require mobility management. So any
time an end-host fetches data from a data source, mobility is managed
by hICN without any impact the transport session.
Producer mobility is not natively supported by hICN, and additional
procedures have to be performed to maintain reachability as it moves
in the network.
In an hICN network, regular routing protocols such as BGP, ISIS or
OSPF can be used for propagating all prefix announcements and
populate routers' FIBs. However, these protocols are not appropriate
and should not be used to manage name prefix mobility, for
scalability and consistency reasons.
The default mobility management for hICN is designed following the
same principles and protocols as MAP-Me, an anchorless producer
mobility management protocol initially proposed for ICN
[I-D.irtf-icnrg-mapme] [MAPME]. It builds on an initial forwarding
state bootstrapped by the routing protocol, and performs a
lightweight path repair process as the producer moves. For
simplicity, we refer to it as simply MAP-Me in the rest of the
document.
Auge, et al. Expires December 22, 2018 [Page 7]
Internet-Draft Anchorless mobility through hICN June 2018
In the rest of this section, we describe the specific realization of
the protocol in an hICN context. Additional background and details
are available in [I-D.irtf-icnrg-mapme] and [MAPME].
4.1. Signalization messages; acknowledgements and retransmission
Signalization messages follow hICN design principles and use data
plane packets for signalization. Signalization messages and
acknowledgement are respectively Interest and Data packet (requests
and replies) according to hICN terminology
[I-D.muscariello-intarea-hicn]. Upon processing of those
advertisements, the network will send an acknowledgement back to the
producer using the name prefix as the source and the locator of the
producer as the destination, plus the sequence number allowing the
producer to match which update has been acknowledged.
Pending signalization interests that are not acknowledged are
retransmitted after a given timeout.
4.2. Dynamic face creation and producer-triggered advertisements
The producer is responsible for mobility updates and should be hICN-
enabled. It stores a sequence number incremented at each mobility
event.
Faces in the producer are assumed synchronized with layer 2
adjacencies, upon joining a new point-of-attachment, a new face
should be created. Face creation will trigger the increase of the
sequence number, and per-prefix advertisement packets to be sent to
the joined network.
Those advertisements should contain:
o the name prefix as the destination address, plus a field
indicating the associated prefix length;
o the locator of the producer as the source address, that will serve
for receiving acknowledgements;
o a sequence number sequentially increased by the producer after
each movement;
o a security token (see Section 6.3).
Upon producer departures from a PoA, the corresponding face is
destroyed. If this leads to the removal of the last next hop, then
faces that were previously saved are restored in FIB to preserve the
original forwarding tree and thus global connectivity.
Auge, et al. Expires December 22, 2018 [Page 8]
Internet-Draft Anchorless mobility through hICN June 2018
4.3. Update protocol
Based on the information transmitted in the packet, and its local the
network's local policy, the network might decide to update its
forwarding state to reflect this change.
The update process consists in updating a few routers on the path
between the new and a former point-of-attachment. More precisely,
this is done in a purely anchorless fashion by sending a signalling
message from the new location towards the name prefix itself. This
packet will be forwarded based on the now-stale FIB entries, and will
update forwarding entries to point to the ingress interfaces of each
traversed router.
4.3.1. Illustration
{fig-mapme-update}} illustrates the situation of a P moving between
access routers AR1 and AR2 while serving user requests:
1. A first interest towards the producer originates from remote.
The producer answers with a Data packet.
2. Following this, the producer detaches from AR1 and moves to AR2.
3. As soon as it is attached to AR2, the producer sends an Interest
Update towards its own prefix, which is forwarded from AR2
following the FIB towards AR1 (one of its former positions in the
general case).
4. At each hop, the message fixes the FIB to point towards the
ingress face, until the message cannot be further forwarded in
AR1.
5. A subsequent message from remote will follow the updated FIB and
correctly reach the producer's new location in AR2.
Auge, et al. Expires December 22, 2018 [Page 9]
Internet-Draft Anchorless mobility through hICN June 2018
P (radio link) AR1 AR2 GW Internet
| | | | |
1 | | | |<~~~~~~~~~~~~~|
| |<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| Interest |
|<~~~~~~~~~~~~~~| | | |
|-------------->| | | |
2 [] Data |---------------|-------------->| |
/ | | | |------------->|
| |(attach to AR2)| | | |
-X]...............|...............| | |
3 |===============|==============>o FIB update | |
| Update | |==============>o FIB update |
4 | o<==============|===============| |
| FIB update | | | |
5 | | | |<~~~~~~~~~~~~~|
| | |<~~~~~~~~~~~~~~| |
|<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| | |
|---------------|-------------->| | |
| | |-------------->| |
| | | |------------->|
| | | | |
Figure 1: Signalization during producer mobility (MAP-Me)
Through this process, MAP-Me trades-off path optimality for a fast,
lightweight and loop-free forwarding update. It has been shown in
[MAPME] that stretch is bounded and typically kept low in scenarios
of interest. This results from the fact that MAP-Me operations
preserve the initial structure of the forwarding tree/DAG (direct
acyclic graph), by only flipping its edges toward the new producer
location.
MAP-Me does not perform a routing update. The protocol is
complementary to the routing protocol in that it can run in between
routing updates to handle producer mobility, at a faster timescale,
and with a lower overhead. Routing updates can be performed at a
lower-pace, to re-optimize routes once a node has relocated for
instance.
4.3.2. Message content
The update messages should contain :
o the name prefix as the destination address, plus a field
indicating the associated prefix length;
o the locator of the producer as the source address, that will serve
for receiving acknowledgements;
Auge, et al. Expires December 22, 2018 [Page 10]
Internet-Draft Anchorless mobility through hICN June 2018
o a sequence number sequentially increased by the producer after
each movement;
o an optional security token.
4.3.3. Processing at network routers
At the reception of advertisement/update packets, each router
performs a name-based Longest Prefix Match lookup in FIB to compare
sequence number from the received packet and from FIB}. According to
that comparison:
o if the packet carries a higher sequence number, the existing next
hops associated to the lower sequence number in FIB are used to
forward it further and temporarily stored to avoid loss of such
information before completion of the acknowledgement process.
o If the packet carries the same sequence number as in the FIB, its
originating face is added to the existing ones in FIB without
additional packet processing or propagation. This may occur in
presence of multiple forwarding paths.
o If the packet carries a lower sequence number than the one in the
FIB, FIB entry is not updated as it already stores 'fresher
information'. To advertise the latest update through the path
followed by the packet, this one is re-sent through the
originating face after having updated its sequence number with the
value stored in FIB.
4.4. Notifications and scoped discovery
The update protocol is responsible for reestablishing global
connectivity with minimal changes to the FIBs. In order to further
improve the reactivity of the scheme and better support QoS
constraints of latency-sensitive traffic, we propose an additional
mechanism named *Notifications*. It assumes hICN-enabled routers at
the edge, and the existence of links between access routers, which
are typically used for handover, and proposes to exploit them during
mobility events, or to delay updates when possible.
4.4.1. Notification processing
Upon receiving a valid advertisement, the point-of-attachment will
remember the presence of the producer, update its corresponding FIB
entry but send no update. Previous next hops should be saved and
restored upon face deletion so as to preserve the forwarding tree/DAG
structure.
Auge, et al. Expires December 22, 2018 [Page 11]
Internet-Draft Anchorless mobility through hICN June 2018
The rationale is that during mobility events, the producer will move
access connected and neighbouring base stations. It will be then
sufficient to make a scoped discovery around the last position known
to forwarding to find the producer within a few hops.
4.4.2. Illustration
Figure 2 illustrate such as situation where an Interest is sent to
the producer before it had the time to complete the update.
P (radio link) AR1 AR2 GW Internet
| | | | |
1 | | | |<~~~~~~~~~~~~~|
| |<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| Interest |
|<~~~~~~~~~~~~~~| | | |
|-------------->| | | |
2 [].....Data.....-)---------------|-------------->| |
/ | | | |------------->|
| |(attach to AR2)| | | |
-Y]...............|...............+ | |
3 | | | |<~~~~~~~~~~~~~|
4 | X--|<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| |
| | | | |
5 |===============|==============>o FIB update | |
| Notification | | | |
| |~~~~~~~~~~~~~~>| (scoped discovery) |
6 |<~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~| | |
7 |---------------|-------------->| | |
| |<--------------| | |
| |---------------|-------------->| |
| | | |------------->|
| | | | |
Figure 2: Scoped discovery during producer mobility
1. A first interest towards the producer originates from remote.
The producer answers with a Data packet.
2. Following this, the producer detaches from AR1 and moves to AR2.
3. A subsequent message from remote arrives before the update could
take place, and is thus forwarded to AR1.
4. AR1 has no valid face anymore towards the producer, and enters
discovery mode by broadcasting the interest to neighbours.
5. In the meantime, we assume the notification reaches AR2.
Auge, et al. Expires December 22, 2018 [Page 12]
Internet-Draft Anchorless mobility through hICN June 2018
6. Because the producer is attached to AR2, the producer can be
directly reachable. Otherwise, AR2 would iterate the discovery
to neighbours only if it had more recent information about the
producer location than its predecessor (based on sequencing of
regular Interests and Interest Updates).
7. The Data packet follows the reverse path to the consumer as
usual.
5. Benefits
We now review the potential benefits of the general architecture we
have presented using features from the hICN data plane for supporting
consumer and producer mobility.
5.1. Overview
*Native mobility* : This mobility management process follows and
exploits hICN design principles. It makes producer mobility native
in the architecture by preserving all benefits of hICN even when
consumers and/or producers are moving.
*Anchorless mobility* : 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 (conf)using locators as identifiers and requiring tunnels,
and (ii) to remove the need for a global mapping system as the one
required by locator-identifier separation solutions. The result is a
fully anchorless solution both in the data plane and in the control
plane.
*Local and decentralized mobility management* : Mobility updates are
handled locally and the routers that are affected are those on path
between successive positions of the producer. In particular, remote
endpoints are not affected by the event. Mobility is managed in a
fully distributed manner and no third party is required. This does
not prevent any centralized control (as discussed in
[I-D.auge-dmm-hicn-mobility-deployment-options]), but makes the
network robust to disconnectivity events.
The next section will discuss more in depth the following advantages
5.2. Simplicity, scalability, efficiency
As emerges from the points raised in the previous section, consumer
mobility is transparently supported by an hICN network in virtue of
the pull-based model and the way the forwarding path works. After
moving, a consumer can just reissue pending interests once attached
Auge, et al. Expires December 22, 2018 [Page 13]
Internet-Draft Anchorless mobility through hICN June 2018
to the new access router at layer 2, without requiring any more
information from L3 and above. This ensures a fast and simple
handover, which can be further enhanced through additional mechanisms
such as in-network caching. Consumer mobility is fully anchorless
with hICN, and does not incur any signalization nor tunneling
overhead.
This is particularly interesting considering that most mobile users
are consumers only (e.g. linear video distribution, or large scale
video conferencing where we typically have few presenters and most
users are simply consumers).
Another aspect of using the unifying hICN architecture in replacement
of the traditional tunnel-based mobile core is that it removes the
need to maintain state for consumers and producers which are not
mobile (eg. IoT sensors), or not currently moving.
5.3. Reduced latency through caching
While this is not strictly linked to mobility, we first illustrate
the benefits of caching content close to the edge to reduce user
latencies. This is particularly important for wireless networks such
as WiFi or LTE which have non-negligible latencies especially during
connection setup, or after an idle period. The characteristics of
those radio networks are thus of interest for the performance of the
mobility architecture as a whole.
The example in Figure 3 considers a mobile node that can move access
two accesses linked to Access Routers (AR) AR1 and AR2, both
connected to the Internet though a common gateway (GW). This same
setup will be later used to illustrate the flow of packets during
mobility events, eventually specializing AR into AP or eNB when it
makes more sense.
+-----+ .-~-.
_,--+ AR1 +--, .- ~ ~-( )_ _
+-----+ / +-----+ \ +----+ | ~-. +-----+
| C += =+ GW +----+ Internet \--//--+ P |
+-----+ \_ +-----+ / +----+ \ .' +-----+
'--+ AR2 +--' ~- . ___________.-~
+-----+
Figure 3: Simple topology with a multi-homed consumer
We represent in Figure 4 a simple data flow between the different
entities involved in the communication between the mobile node M, and
a remote producer available over the Internet.
Auge, et al. Expires December 22, 2018 [Page 14]
Internet-Draft Anchorless mobility through hICN June 2018
C AR1 AR2 GW Internet
| | | | |
1 |~~~~~~~~~~~~~~>| | | |
| Interest X |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| |
| | | |~~~~~~~~~~~~~>|
| | | | |...
| | | |<-------------|
| Data X |<--------------|---------------| |
|<--------------| | | |
| | | | |
2 |~~~~~~~~~~~~~~>| | | |
3 | Interest Y |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>X Cache hit |
| |<--------------|---------------X |
|<--------------| | | |
| Data Y | | | |
LEGEND:
~~~~>: Interest <---- Data ====> Signalization
....-: L2 detach .....+ L2 attach X failure o event
Figure 4: Reduced latency through caching
Numbers on the left refer to the following comments relative to the
data flow:
1. The consumer issues a first interest towards name prefix X, which
is transported up to the producer. A Data packet comes back
following the reverse path and populating intermediate caches.
Latency of the exchange can be seen by the distance between lines
on the vertical axis.
2. The consumer now requests content B, which has previously been
requested by another consumer located on the same gateway.
Interest B thus hits the cache, refreshes the entry, and allows a
lower round-trip latency to content both for consumer C and any
subsequent request of the same content.
5.4. Improved reliability through caching
Mobile networks might consist in unreliable access technologies, such
as WiFi, responsible for packet losses. Figure 5 considers a similar
scenario with a lossy channel (eg. WiFi) between the mobile and the
first access router.
Auge, et al. Expires December 22, 2018 [Page 15]
Internet-Draft Anchorless mobility through hICN June 2018
C (radio link) AR1 AR2 GW Internet
| | | | |
1 |~~~~~~~X | | | |
2 |~~~~~~~~~~~~~~>| | | |
| Interest |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| |
| | | |~~~~~~~~~~~~~>|
| | | | | ...
| | | |<-------------|
| Data |<--------------|---------------| |
3 | X-------| | | |
| | | | |
4 |~~~~~~~~~~~~~~>X Cache hit | | |
|<--------------X | | |
| | | | |
Figure 5: IU propagation example
1. The first issued interest is lost due to bad radio conditions.
2. Upon detection (either after a timeout, the consumer can just
reissue the lost Interest.
3. This time the remote producer successfully replies but the Data
packet is lost on the radio link.
4. Upon a similar detection, the consumer can reissue the lost
Interest that will hit a locally stored copy at the router where
the loss occurred (or again use a detection mechanism to
retransmit the Data packet).
5.5. Local mobility and recovery from common cache
The same mechanism can be used to recover from mobility losses after
the consumer reconnects to the new network as the content will
already be available in the cache at the junction router between the
two accesses. This is particularly interesting in case of micro-
mobility between access routers that are topologically close in the
network.
This is also the opportunity to manage those losses on behalf of the
transport protocol, so that only losses due to congestion are exposed
to it, and don't perturb the feedback loop by unnecessarily reducing
the transfer rate.
Auge, et al. Expires December 22, 2018 [Page 16]
Internet-Draft Anchorless mobility through hICN June 2018
C (radio link) AR1 AR2 GW Internet
| | | | |
1 |~~~~~~~~~~~~~~>| | | |
| Interest |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| |
| | | |~~~~~~~~~~~~~>|
|(detach fm AR1)| | | |
2 ..|...............- | |<-------------|
| |<--------------|---------------| |
3 | Data X-| | | |
| | | | |
|(attach to AR2 | | | |
4 ..|...............|...............+ | |
5 |~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~>| | |
6 | | |~~~~~~~~~~~~~~>X Cache hit |
| | |<--------------X |
|---------------|---------------| | |
| | | | |
Figure 6: IU propagation example
1. The consumer issues an interest before moving to a new location
2. It detaches from the first Access Router AR1
3. This causes the returning data packet to be lost as there is no
more a valid face towards the consumer.
4. The consumer has finished attachment to the new access router
AR2.
5. It can retransmit pending interests immediately.
6. The interests will hit the cache at the first junction point
between AR1 and AR2 which have previously seen the data packet
coming back.
5.6. Additional reliability through consumer multihoming
Because mobility is implemented at layer 3 and is thus agnostic to
the physical layer, this allows a mobile consumer to seamlessly
switch to a different access layer, eg. WiFi to LTE, following the
unreachability of the preferred radio access.
Figure 7 illustrates a fallback to LTE which can be performed
transparently for the application.
Auge, et al. Expires December 22, 2018 [Page 17]
Internet-Draft Anchorless mobility through hICN June 2018
C WiFi GW LTE enB PGW Internet
| | | | | |
1 |~~~~~~~~~~~>| | | | |
| |~~~~~~~~~~~>| | | |
| | |~~~~~~~~~~~~|~~~~~~~~~~~~|~~~~~~~~~~~>|
| | | | | |
| | |<-----------|------------|------------|
| |<-----------| | | |
|<-----------| | | | |
2 | X | | | |
3 |~~~~~~~~~~~~X~~~~~~~~~~~~|~~~~~~~~~~~>| | |
| X | |~~~~~~~~~~~>| |
| X | | |~~~~~~~~~~~>|
| | | | | |
| | | | |<-----------|
| | | |<-----------| |
|<-----------|------------|------------| | |
4 |~~~~~~~~~~~>|... | | | |
| | | | | |
Figure 7
1. First interest is sent on the WiFi link.
2. WiFi unavailability due to failure for instance.
3. The application seamlessly switches to the LTE link.
4. Upon recovery, the traffic can be brought back on the WiFi
interface.
hICN handles consumer mobility from one access to the other (e.g.
WiFi to LTE or vice-versa) without any a-priori knowledge of the
multiple networks to use as it is the case of MPTCP or QUIC
approaches. Moving rate and congestion control at the receiver end
results to be a significant advantage w.r.t. all existing
alternatives in controlling dynamically multiple and new discovered
network accesses in presence of mobility.
This use case highlights the importance of having a compatible
transport, as the WiFi and LTE paths will have much different
characteristics in terms of delay, jitter and capacity.
Evaluations of the scheme have shown this scheme to preserve the
performance of flows like mobile video distribution up to very high
switching rates in the order of a second, not even considering
optimization occurring from network support.
Auge, et al. Expires December 22, 2018 [Page 18]
Internet-Draft Anchorless mobility through hICN June 2018
Mobility is handled transparently at the network layer with very fast
handover times, due to the connection-less property of hICN. This
makes it possible to offer reliable WiFi connectivity, besides its
lossy nature as observed in previous use case and besides the
frequency of mobility from one network access to the other.
5.7. Bandwidth aggregation with consumer multihoming
Bandwidth aggregation can be realized dynamically through a
congestion-aware load-balancing forwarding strategy at the client,
with no a priori knowledge of paths. This is done similarly in the
network by hICN forwarders, allowing a combination of multi-homing,
multipath and multi-source data transfers. As all the paths are used
at the same time, hICN offers the full network capacity to the users
and tends to smooth fluctuations due to the radio channels.
Over an heterogeneous network access, hICN also offers a simple and
cost-effective realization of heterogeneous channel bonding allowing
an user to seamlessly roam across different radios or fixed lines
(for increased reliability or reduced costs), or aggregate their
bandwidth for high-throughput applications such as video streaming.
We illustrate a simplified data flows with one mobile consumer C
alternating interests between a WiFi and LTE access points. The load
balancing strategy would in that case optimize the split ratio
between the two access to realize an optimal split. Note that in
that case the relative distances on the vertical axis have not been
respected here for readability.
C WiFi GW LTE enB PGW Internet
| | | | | |
|~~~~~~~~~~~~|~~~~~~~~~~~~|~~~~~~~~~~~>| | |
|~~~~~~~~~~~>| | |~~~~~~~~~~~>|~~~~~~~~~~~>|
| |~~~~~~~~~~~>| | | |
| | |~~~~~~~~~~~~|~~~~~~~~~~~~|~~~~~~~~~~~>|
| | | | | |
| | | | |<-----------|
| | | |<-----------| |
|<-----------|------------|------------| | |
| | |<-----------|------------|------------|
| |<-----------| | | |
|<-----------| | | | |
| | | | | |
| | | | | |
Fine grained control from the application allows fully exploiting
available bandwidth, resulting in an aggregated throughput equal to
Auge, et al. Expires December 22, 2018 [Page 19]
Internet-Draft Anchorless mobility through hICN June 2018
the sum of access throughputs, which is hard to achieve with existing
solutions.
5.8. Traffic and signalization offload
As a natural consequence of its anchorless behavior, an hICN network
can continue to operate in disconnected mode, for local mobility,
even though no upstream entity is available.
In order to illustrate this, we slightly extend the previous topology
in Figure 8 with an additional access network. To show that local
mobility induces no traffic on upstream links, we further assume a
failure on the link between the gateway (GW) and the Internet.
+-----+
_,--+ AR1 +--,
+-----+ / +-----+ \ .-~~~-.
| P += \ .- ~ ~-( )_ _
+-----+ \_ +-----+ +----+ | ~ -.
'--+ AR2 +-----+ GW +----X----+ Internet \
+-----+ +----+ FAIL \ .'
/ ~- . _____________ . -~
+-----+ +-----+ /
| C +------+ AR3 +-'
+-----+ +-----+
Figure 8: Access network disconnected from core
The data flow represented in Figure 9 illustrates the communication
between a consumer connected to AR3, and a mobile producer moving
from AR1 to AR2.
Auge, et al. Expires December 22, 2018 [Page 20]
Internet-Draft Anchorless mobility through hICN June 2018
C P AR1 AR2 AR3 GW X Internet
| | | | | | X |
|~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~>| | X |
| | | | |~~~~~~~~~>| X |
| | |<~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~~| X |
| |<~~~~~~~~~| | | | X |
| |--------->| | | | X |
| | |----------|----------|--------->| X |
| | | | |<---------| X |
|<--------|----------|----------|----------| | X |
| | | | | | X |
| |..........- | | | X |
| |..........|..........+ | | X |
| |==========|=========>o | | X NO |
| | Update | |==========|=========>o X TRAFFIC |
| | o<=========|==========|==========| X |
| | | | | | X |
|~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~~|~~~~~~~~~>| | X |
| | | | |~~~~~~~~~>| X |
| | | |<~~~~~~~~~|~~~~~~~~~~| X |
| |<~~~~~~~~~|~~~~~~~~~~| | | X |
| |----------|--------->| | | X |
| | | |----------|--------->| X |
| | | | |<---------| X |
|<--------|----------|----------|----------| | X |
| | | | | | X |
Figure 9: Anchorless mobility in network disconnected from core
We see that both the data and the signalization remain local to the
zone where the mobility occurs, and that communications during
mobility are not affected by the failure of the link upstream. This
is a sign that the mobile core is not loaded with unnecessary
traffic, and that communications remain local, thus improving user
flow latencies. The offload of both data and signalization allows
reducing the cost of the infrastructure by increasing the diversity
of resources used at edge, mutualizing their capacity, and lower
requiring network and compute capacity in the mobile core. A direct
consequence is also a more robust and reliable network.
6. Discussion
6.1. Scope
Both consumer and producer mobility support multiple paths, however
the support of mobility for a multihomed producer, is left for future
updates of the present document.
Auge, et al. Expires December 22, 2018 [Page 21]
Internet-Draft Anchorless mobility through hICN June 2018
Similarly, the proposed producer mobility solution is appropriate for
the management of micro-mobility; its extension to multiple domains
is out of scope.
6.2. Interaction with non-hICN enabled routers
The realization of the architecture in a partial hICN deployment
where some routers are not extended to support hICN mechanisms
requires either to introduce additional functionalities or protocol
support, or to reuse existing protocols achieving similar objectives
(following hICN design).
One such example is the combination of ICMP redirect messages and
Neighbour Discovery Proxies (NDProxy), that partially realizes the
objectives of the update process:
o ICMP packets do not include sequence numbers however they can be
transported as part of the payload; verification is deferred to
the next hICN node which should send the packet backwards in case
of verification failure to fix the incorrect path update.
o multipath is not supported in the pure-IP part of the network
(which is the expected behaviour)
Identified concerns might be about the unexpected use of such
protocols, the lack of available implementation for NDProxy, and
security aspect related to redirect messages. The latter shares the
fate of source routing, which has long been advocated against, and
has recently gained popularity within the SPRING context. A proper
security scheme is certainly the right way to address this problem,
and we believe the set of benefits that we have listed are worth
reconsidering such aspects.
6.3. Security considerations
As indicated in previous sections, signalization messages transmitted
across trust boundaries must be secured. The choice of the solution
will intimately depend on the selected protocols.
The use of ICMP packet might allow reusing existing security schemes
such as AH headers [RFC4302], or SEND [RFC3971] (and its proxy
extensions [RFC6496], [RFC5909]).
Alternatively, [SEC] has reviewed standard approaches from the
literature and proposes a fast, lightweight and distributed approach
that can be applied to MAP-Me and fits its design principles.
Auge, et al. Expires December 22, 2018 [Page 22]
Internet-Draft Anchorless mobility through hICN June 2018
7. IANA Considerations
This memo includes no request to IANA.
8. References
8.1. Normative References
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4",
RFC 3344, DOI 10.17487/RFC3344, August 2002,
<https://www.rfc-editor.org/info/rfc3344>.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004,
<https://www.rfc-editor.org/info/rfc3775>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <https://www.rfc-editor.org/info/rfc4423>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing
Neighbor Discovery Proxy: Problem Statement", RFC 5909,
DOI 10.17487/RFC5909, July 2010,
<https://www.rfc-editor.org/info/rfc5909>.
[RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility
Support in the Internet", RFC 6301, DOI 10.17487/RFC6301,
July 2011, <https://www.rfc-editor.org/info/rfc6301>.
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
Martinez, "Secure Proxy ND Support for SEcure Neighbor
Discovery (SEND)", RFC 6496, DOI 10.17487/RFC6496,
February 2012, <https://www.rfc-editor.org/info/rfc6496>.
Auge, et al. Expires December 22, 2018 [Page 23]
Internet-Draft Anchorless mobility through hICN June 2018
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012,
<https://www.rfc-editor.org/info/rfc6740>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<https://www.rfc-editor.org/info/rfc7476>.
8.2. Informative References
[I-D.auge-dmm-hicn-mobility-deployment-options]
Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility management through hICN
(hICN-AMM): Deployment options", draft-auge-dmm-hicn-
mobility-deployment-options-00 (work in progress), June
2018.
[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.irtf-icnrg-mapme]
Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "MAP-Me : Managing Anchorless Mobility in
Content Centric Networking", draft-irtf-icnrg-mapme-00
(work in progress), March 2018.
[I-D.irtf-icnrg-terminology]
Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
D., and C. Tschudin, "Information-Centric Networking
(ICN): CCN and NDN Terminology", draft-irtf-icnrg-
terminology-00 (work in progress), December 2017.
[I-D.muscariello-intarea-hicn]
Muscariello, L., Carofiglio, G., Auge, J., and M.
Papalini, "Hybrid Information-Centric Networking", draft-
muscariello-intarea-hicn-00 (work in progress), June 2018.
Auge, et al. Expires December 22, 2018 [Page 24]
Internet-Draft Anchorless mobility through hICN June 2018
[I-D.vonhugo-5gangip-ip-issues]
Hugo, D. and B. Sarikaya, "Review on issues in discussion
of next generation converged networks (5G) from an IP
point of view", draft-vonhugo-5gangip-ip-issues-03 (work
in progress), March 2017.
[KITE] Zhang, Y., Zhang, H., and L. Zhang, "Kite", Proceedings of
the 1st international conference on Information-centric
networking - INC '14, DOI 10.1145/2660129.2660159, 2014.
[MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L.,
Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less
Producer Mobility in Content-Centric Networks", IEEE
Transactions on Network and Service Management Vol. 15,
pp. 596-610, DOI 10.1109/tnsm.2018.2796720, June 2018.
[ravindran20175g]
Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and
G. Wang, "5G-ICN: Delivering ICN Services over 5G Using
Network Slicing", IEEE Communications Magazine Vol. 55,
pp. 101-107, DOI 10.1109/mcom.2017.1600938, May 2017.
[SEC] Compagno, A., Zeng, X., Muscariello, L., Carofiglio, G.,
and J. Auge, "Secure producer mobility in information-
centric network", Proceedings of the 4th ACM Conference on
Information-Centric Networking - ICN '17,
DOI 10.1145/3125719.3125725, 2017.
[SURVEY1] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A
survey of mobility support in Named Data Networking", 2016
IEEE Conference on Computer Communications Workshops
(INFOCOM WKSHPS), DOI 10.1109/infcomw.2016.7562050, April
2016.
[SURVEY2] Feng, B., Zhou, H., and Q. Xu, "Mobility support in Named
Data Networking: a survey", EURASIP Journal on Wireless
Communications and Networking Vol. 2016,
DOI 10.1186/s13638-016-0715-0, September 2016.
[SURVEYCC]
Ren, Y., Li, J., Shi, S., Li, L., Wang, G., and B. Zhang,
"Congestion control in named data networking - A survey",
Computer Communications Vol. 86, pp. 1-11,
DOI 10.1016/j.comcom.2016.04.017, July 2016.
Auge, et al. Expires December 22, 2018 [Page 25]
Internet-Draft Anchorless mobility through hICN June 2018
[SURVEYICN]
Tyson, G., Sastry, N., Rimac, I., Cuevas, R., and A.
Mauthe, "A survey of mobility in information-centric
networks", Proceedings of the 1st ACM workshop on Emerging
Name-Oriented Mobile Networking Design - Architecture,
Algorithms, and Applications - NoM '12,
DOI 10.1145/2248361.2248363, 2012.
[TS23.501]
3gpp-23.501, "Technical Specification Group Services and
System Aspects; System Architecture for the 5G System
(Rel.15)", n.d..
[TS29.274]
3gpp-29.274, "3GPP Evolved Packet System (EPS); Evolved
General Packet Radio Service (GPRS) Tunnelling Protocol
for Control plane (GTPv2-C); Stage 3", n.d..
Authors' Addresses
Jordan Auge
Cisco Systems Inc.
Email: augjorda@cisco.com
Giovanna Carofiglio
Cisco Systems Inc.
Email: gcarofig@cisco.com
Luca Muscariello
Cisco Systems Inc.
Email: lumuscar@cisco.com
Michele Papalini
Cisco Systems Inc.
Email: micpapal@cisco.com
Auge, et al. Expires December 22, 2018 [Page 26]