Skip to main content

MAP-Me : Managing Anchorless Mobility in Content Centric Networking
draft-irtf-icnrg-mapme-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-03-18
RFC stream Internet Research Task Force (IRTF)
Formats
Additional resources Mailing list discussion
Stream IRTF state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-irtf-icnrg-mapme-00
ICNRG                                                       J. Auge, Ed.
Internet-Draft                                        G. Carofiglio, Ed.
Intended status: Informational                       L. Muscariello, Ed.
Expires: September 18, 2018                             M. Papalini, Ed.
                                                     Cisco Systems, Inc.
                                                            mar 17, 2018

  MAP-Me : Managing Anchorless Mobility in Content Centric Networking
                       draft-irtf-icnrg-mapme-00

Abstract

   Mobility has become a basic premise of network communications,
   thereby requiring a native integration into 5G networks.  Despite
   numerous efforts to propose and standardize effective mobility-
   management models for IP, the result is a complex, poorly flexible
   set of mechanisms.  The natural support for mobility offered by ICN
   (Information Centric Networking) makes it a good candidate to define
   a radically new solution relieving limitations of the traditional
   approaches.  If consumer mobility is supported in ICN by design, in
   virtue of its connectionless pull-based communication model, producer
   mobility is still an open challenge.  In this document, we focus on
   two prominent ICN architectures, CCN (Content Centric Networking) and
   NDN (Named Data Networking) and describe MAP-Me, an anchor-less
   solution to manage micro-mobility of content producers via a name-
   based CCN/NDN data plane, with support for latency-sensitive
   applications.

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 September 18, 2018.

Auge, et al.           Expires September 18, 2018               [Page 1]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 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
   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.  State-of-the-art and benefits of anchorless mobility
       solutions . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Design principles . . . . . . . . . . . . . . . . . . . . . .   6
   4.  MAP-Me description  . . . . . . . . . . . . . . . . . . . . .   7
   5.  Update protocol . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Update propagation  . . . . . . . . . . . . . . . . . . .   8
     5.3.  Concurrent updates  . . . . . . . . . . . . . . . . . . .  11
   6.  MAP-Me Notification/Discovery protocol  . . . . . . . . . . .  12
     6.1.  Interest Notification . . . . . . . . . . . . . . . . . .  13
     6.2.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.3.  Full approach . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  MAP-Me Messages . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  MAP-Me additional Network Information . . . . . . . . . .  14
   8.  Algorithm description . . . . . . . . . . . . . . . . . . . .  15
     8.1.  IU/IN transmission at producer  . . . . . . . . . . . . .  15
     8.2.  IU/IN transmission at network routers . . . . . . . . . .  16
     8.3.  Hop-by-hop IU/IN acknowledgement  . . . . . . . . . . . .  16
     8.4.  Face removal at producer/network nodes  . . . . . . . . .  17
     8.5.  Consumer request forwarding in case of producer discovery  17
   9.  Security considerations . . . . . . . . . . . . . . . . . . .  19
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  19
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     13.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

Auge, et al.           Expires September 18, 2018               [Page 2]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

1.  Introduction

   With the phenomenal spread of portable user devices, mobility has
   become a basic requirement for almost any communication network as
   well as a compelling feature to integrate in the next generation
   networks (5G).  The need for a mobility-management paradigm to apply
   within IP networks has striven a lot of efforts in research and
   standardization bodies (IETF, 3GPP among others), all resulting in a
   complex access-dependent set of mechanisms implemented via a
   dedicated control infrastructure.  The complexity and lack of
   flexibility of such approaches (e.g.  Mobile IP) calls for a
   radically new solution dismantling traditional assumptions like
   tunneling and anchoring of all mobile communications into the network
   core. \changes{This is particularly important with the increase in
   rates and mobile nodes (IoT), a vast amount of which never moves.}

   The Information Centric Network (ICN) paradigm brings native support
   for mobility, security, and storage within the network architecture,
   hence emerging as a promising 5G technology candidate.  Specifically
   on mobility management, ICN has the potential to relieve limitations
   of the existing approaches by leveraging its primary feature, the
   redefinition of packet forwarding based on _names_ rather than on
   _network addresses_. We believe that removing the dependence on
   location identifiers is a first step in the direction of removing the
   need for any anchoring of communications into fixed network nodes,
   which may considerably simplify and improve mobility management.
   Within the ICN paradigm, several architectures have been proposed, as
   reported in [xylomenos2014survey] and [ahlgren2012survey].

   As a direct result of CCN/NDN design principles, consumer mobility is
   natively supported}: a change in physical location for the consumer
   does not translate into a change in the data plane like for IP.  The
   retransmission of requests for data not yet received by the consumers
   takes place without involving any signaling to the network.  Producer
   mobility and realtime group communications present more challenges,
   depending on the frequency of movements, latency requirements, and
   content lifetime.  The topology does not reflect the naming
   structure, and we have to preserve key functionalities such as
   multipath, caching, etc.  In all cases, beyond providing connectivity
   guarantees, additional transport-level mechanisms might be required
   to protect the flow performance (see [carofiglio2016mwldr] for
   instance).

   MAP-Me aims at tackling such problems by exploiting key CCN/NDN
   characteristics.  Previous attempts have been made in CCN/NDN (and
   ICN in general) literature to go beyond the traditional IP
   approaches, by using the existing CCN/NDN request/data packet
   structures to trace producer movements and to dynamically build a

Auge, et al.           Expires September 18, 2018               [Page 3]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   reverse-forwarding path (see [NDN-survey] for a survey).  They still
   rely on a stable home address to inform about producer movements or
   on buffering of incoming requests at the producer's previous point of
   attachment -- PoA --, which prevents support for latency-sensitive
   streaming applications.  We focus on this class of applications (e.g.
   live streaming or videoconferencing) as they have the most stringent
   performance requirements: negligible per-packet loss-rate and delays.
   In addition, they typically originate from a single producer and
   don't allow for the use of caching.

   MAP-Me defines a name-based mechanism operating in the forwarding
   plane and completely removing any anchoring, while aiming at latency
   minimization.  It has the following characteristics:

   o  MAP-Me addresses micro (e.g. intra Autonomous Systems) producer
      mobility.  Addressing macro-mobility is a non-goal of the
      proposal.  We are focusing here on complementary mechanisms able
      to provide a fast and lightweight handover, preserving the
      performance of flows in progress.

   o  MAP-Me does not rely on global routing updates, which would be too
      slow and too costly, but rather works at a faster timescale
      propagating forwarding updates and leveraging real-time
      notifications left as breadcrumbs by the producer to enable live
      tracking of its position.  For simplicity, we use the word
      'producer' in place of the more correct expression producer name
      prefixes.  The objective being the support of high-speed mobility
      and real-time group applications

   o  MAP-Me leverages core CCN/NDN features like stateful forwarding,
      dynamic and distributed Interest load balancing to update the
      forwarding state at routers, and relaying former and current
      producer locations.

   o  MAP-Me is designed to be access-agnostic, to cope with highly
      heterogeneous wireless access and multi-homed/mobile users.

   o  Finally, low overhead in terms of signaling, additional state at
      routers, and computational complexity are also targeted in the
      design to provide a solution able to scale to large and dynamic
      mobile networks.

   MAP-Me performance has been thoroughly analyzed and provides
   guarantees of correctness, stability and bounded stretch [MAPME].

Auge, et al.           Expires September 18, 2018               [Page 4]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

2.  State-of-the-art and benefits of anchorless mobility solutions

   Many efforts have been made to define mobility-management models for
   IP networks in the last two decades, resulting in a variety of
   complex, often not implemented, proposals.  A good survey of these
   approaches is [RFC6301].  Likewise, within the ICN family, different
   approaches to mobility management have been presented
   [tyson2013survey].

   When facing high-frequency mobility, those so-called Resolution-Based
   (RB) approaches present a similar trade-off: for every packet the
   consumer has to resolve the producer's location or use stale
   information and run the risk to reach an old position, incurring in
   timeout, or Nack, etc.

   Specifically for the CCN/NDN solutions, several surveys of mobility-
   management approaches can be found [NDN-survey], [feng2016mobility].
   In [NDN-survey] for instance, the authors distinguish three
   categories of solutions -- routing, mapping, and tracing-based --
   depending on the type of indirection point (also called Rendez-Vous,
   RV).  We build on such classification and extend it to distinguish a
   fifth class of approaches not relying upon the existence of any
   anchor point as the RV (Anchor-less approaches):

   Routing-based (RT)  solutions rely on intra-domain routing, and
         require updating all routing in the AS after a mobile's
         movement.  Scalability of these solutions is widely recognized
         as a concern which explains why they are usually ruled out, in
         particular for CCN/NDN where the name space is even larger than
         IP.

   Resolution-based (RB)  solutions rely on dedicated RV nodes (similar
         to DNS) which map content names into routable location
         identifiers.  To maintain this mapping updated, the producer
         signals every movement to the RV node.  Once the resolution is
         performed, packets can be correctly routed from the consumer
         along the shortest path, with unitary path stretch (defined as
         the ratio between the realized path length over the shortest
         path one).  Requiring explicit resolution, together with a
         strict separation of names and locators, RB solutions involve a
         scalable CCN/NDN routing infrastructure able to leverage
         forwarding hints; however, scalability is achieved at the cost
         of a large hand-off delay as evaluated e.g. in due to RV update
         and name resolution.  To summarize, RB solutions show good
         scalability properties and low stretch in terms of consumer to
         producer routing path, but result to be unsuitable for frequent
         mobility and for reactive rerouting of latency-sensitive
         traffic, which are key objective of MAP-Me.

Auge, et al.           Expires September 18, 2018               [Page 5]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   Anchor-based (AB)  proposals are inspired by Mobile IP, and maintain
         a mapping at network-layer by using a stable home address
         advertised by a RV node, or anchor.  This acts as a relay,
         forwarding through tunneling both interests to the producer,
         and data packets coming back.  Advantages of this approach are
         that the consumer does not need to be aware of producer
         mobility and that it has low signaling overhead because only
         the anchor has to be updated.  It however inherits the
         drawbacks of Mobile IP -- e.g.  triangular routing and single
         point of failure -- and others more specific to the CCN/NDN
         context: potential degradation of caching efficiency, bad
         integrity verification due to the renaming of content during
         movement.  It also hinders multipath capabilities and limits
         the robustness to failure and congestion initially offered by
         the architecture.  In contrast, MAP-Me maintains names intact
         and avoid single point-of-passage of the traffic.

   Tracing-based (TB)  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.  Like AB though, this approach assumes that the data
         is published under a stable RV prefix.

   Anchor-less (AL)  approaches allow the mobile nodes to advertise
         their mobility to the network without requiring any specific
         node to act as a RV.  They are less common and introduced in
         CCN/NDN to enhance the reactivity with respect to AB solutions
         by leveragingzhang2014kite CCN/NDN name-based routing.  The PoA
         starts buffering incoming Interests for the mobile producer
         until a forwarding update is completed and a new route is built
         to reach the current location of the producer.  Enhancement of
         such solutions considers handover prediction.  Besides the
         potentially improved delay performance w.r.t. other categories
         of approaches, some drawbacks can be recognized: buffering of
         Interests may lead to timeouts for latency-sensitive
         applications and handover prediction is hard to perform in many
         cases.  In contrast MAP-Me reacts after the handoff, without
         requiring handover prediction, and avoids Interests buffering
         but introduces network notification and discovery mechanism to
         reduce the handoff latency.

3.  Design principles

   MAP-Me is an anchor-less, name-based, layer-2 agnostic approach
   operating at forwarding plane designed according to the following
   design principles:

Auge, et al.           Expires September 18, 2018               [Page 6]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   o  Transparent: MAP-Me does not involve any name nor modifications to
      basic request/reply operations to be compatible with standard CCN/
      NDN design and to avoid issues caused by name modifications like
      triangular routing, caching degradation, or security
      vulnerabilities.

   o  Distributed: MAP-Me is designed to be fully distributed, to
      enhance robustness w.r.t. centralized mobility management
      proposals subject to single point-of-passage problem.

   o  Localised: MAP-Me updates affect the minimum number of routers at
      the edge of the network to restore connectivity.  The goal is to
      realize effective traffic off-load close to the end-users.

   o  Lightweight: MAP-Me mobility updates are issued at prefix
      granularity, rather than content or chunk/packet granularity, to
      minimize signaling overhead and temporary state kept by in-network
      nodes;

   o  Reactive: MAP-Me works at forwarding layer to enable updates in
      FIBs at network latency, i.e. round-trip time scale.  Specific
      mechanisms are defined, referred to as network notifications and
      discovery, to maximise reactivity in mobility management in case
      of real-time producer tracking and of latency-sensitive
      communications;

   o  Robust to network conditions (e.g. routing failure, wireless or
      congestion losses, and delays), by leveraging hop-by-hop
      retransmissions of mobility updates.

4.  MAP-Me description

   As a data plane protocol, MAP-Me handles producer mobility events by
   means of dynamic FIB updates with the objective of minimizing
   unreachability of the producer.  It relies on the existence of a
   routing protocol responsible for creating/updating the FIB of all
   routers, possibly with multipath routes, and for managing network
   failures [NLSR].

   MAP-Me is composed of:

      an Update protocol (MAP-ME-IU) (Section Section 5), which is the
      central component of our proposal;

      a Notification/Discovery protocol (Section Section 6), to be
      coupled with the Update protocol (the full approach is referred to
      as MAP-ME) to enhance reactivity in mobility management for
      realtime/latency-sensitive application.

Auge, et al.           Expires September 18, 2018               [Page 7]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

5.  Update protocol

5.1.  Rationale

   The rationale behind MAP-Me is that the producer announces its
   movements to the network by sending a special Interest Packet, named
   Interest Update (IU) to "itself" after it reattaches to the network.
   Such a message looks like a regular Interest packet named with the
   prefix advertised by the producer.  As such, it is forwarded
   according to the information stored in the FIBs of traversed routers
   towards previous locations of the producer known by router FIBs.  A
   special flag carried in the header of the IU enables all routers on
   the path to identify the Interest as a mobility update and to process
   it accordingly to update their FIBs (a detailed description of the IU
   processing is provided in Sec. Section 8.

   The key aspect of the proposal is that it removes the need for a
   stable home address (present in Tracing-Based approaches for
   instance) by directly leveraging name-based forwarding state created
   by CCN/NDN routing protocols or left by previous mobility updates.
   FIB updates are triggered by the reception of mobility updates in a
   fully distributed way and allow a modification on-the-fly to point to
   the latest known location of the producer.

5.2.  Update propagation

   MAP-ME-IU aims at quickly restoring global reachability of mobile
   prefixes with low signaling overhead, while introducing a bounded
   maximum path stretch (i.e. ratio between the selected and the
   shortest path in terms of hops).

   Let us illustrate its behavior through the example in
   Figure Figure 1, where a single producer serving prefix /p moves from
   position P0 to P1 and so on.  Figure Figure 1 (a) shows the tree
   formed by the forwarding paths to the name prefix /p where IU
   initiated by the producer propagates.

                            +---+                        +---+
                            | 0 | P0                      | 0 | P0
                            +---+                         +---+
                             ^ ^                           ^ ^
                            /   \                         /   \
                        +---+    +---+                +---+    +---+
                        | 0 |    | 0 |                | 0 |    | 0 |
                        +---+    +---+                +---+    +---+
                         ^ ^                           ^ ^
                        /   \                         /   \

Auge, et al.           Expires September 18, 2018               [Page 8]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

                    +---+    +---+                +---+    +---+
                    | 0 |    | 0 |                | 0 |    | 0 |
                    +---+    +---+             A  +---+    +---+
                     ^ ^                  IU1 /    ^ ^
                    /   \                    /    /   \
                +---+    +---+          .... .+---+.   +---+
                | 0 |    | 0 |         .   P1 | 1 | .  | 0 |
                +---+    +---+        .       +---+ .  +---+
                 ^ ^                  .        ^ ^    .
                /   \                 .       /   \     .
            +---+    +---+            .   +---+    +---+  .
            | 0 |    | 0 |            .   | 0 |    | 0 |  .
            +---+    +---+            .   +---+    +---+ .
                                       ..................

                     (a)                       (b)

                                                   .................
                            +---+               ...       +---+     ..
                            | 0 | P0           .          | 1 | P0    .
                            +---+             .        A  +---+       .
                             ^ ^             .  IU(1) /    / ^        .
                            /   \            .       /    V   \       .
                        +---+    +---+      .         +---+    +---+  .
                        | 0 |    | 0 |     .          | 1 |    | 0 |  .
                        +---+    +---+    .        A  +---+    +---+  .
                         ^ ^              . IU(1) /    / ^           .
                        /   \            .       /    V   \         .
            ........+---+.   +---+      .         +---+    +---+   .
           .        | 1 | .  | 0 |     .          | 1 |    | 0 |   .
          .  FIB    +---+ .  +---+    .        A  +---+    +---+   .
         . updated   / ^   .          . IU(1) /    / ^            .
         .          V   \   ....      .      /    V   \          .
         .      +---+    +---+  .     .       +---+    +---+   .
         .  P1  | 1 |    | 0 |  .     .    P1 | 1 |    | 0 |   .
         .      +---+    +---+  .     .       +---+    +---+   .
         .       ^ ^            .     .        ^ ^            .
         .      /   \          .       .      /   \         .
         .  +---+    +---+    .        .  +---+    +---+  .
         .  | 0 |    | 0 |   .         .  | 0 |    | 0 |  .
         .  +---+    +---+  .          .  +---+    +---+  .
          ..................            ..................

                     (c)                       (d)

                            +---+
                            | 1 | P1
                            +---+

Auge, et al.           Expires September 18, 2018               [Page 9]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

                           ^  A  ^
                         /    |    \
                    +---+   +---+   +---+
                    | 0 |   | 0 |   | 1 |
                    +---+   +---+   +---+
                                     ^ ^
                                    /   \
                                +---+    +---+
                                | 0 |    | 1 |
                                +---+    +---+
                                          ^ ^
                                         /   \
                                     +---+    +---+
                                 P0  | 1 |    | 0 |
                                     +---+    +---+
                                      ^
                                     /
                                 +---+
                                 | 0 |
                                 +---+

                              (e)

                     Figure 1: IU Propagation example

   Network FIBs are assumed to be populated with routes toward P0 by a
   name-based routing protocol.  After the relocation of the producer
   from P0 to P1, once the layer-2 attachment is completed, the producer
   issues an IU carrying the prefix /p and this is forwarded by the
   network toward P0 (in general, toward one of its previous locations
   according to the FIB state of the traversed routers).

   Figure Figure 1 (b) shows the propagation of the IU.  As the IU
   progresses, FIBs at intermediate hops are updated with the ingress
   face of the IU (Figure Figure 1 (c) and (d)).  IU propagation stops
   when the IU reaches P0 and there is no next hop to forward it.  The
   result is that the original tree rooted in P0 becomes re-rooted in P1
   (Figure Figure 1 (e)).  Looking at the different connected regions
   (represented with dotted lines), we see that IU propagation and
   consequent FIB updates have the effect of extending the newly
   connected subtree (represented as a red cloud): at every step, an
   additional router and its predecessors are included in the connected
   subtree.  The properties of the update propagation process in terms
   of bounded length and stretch are studied in [MAPME].

Auge, et al.           Expires September 18, 2018              [Page 10]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

5.3.  Concurrent updates

   Frequent mobility of the producer may lead to the propagation of
   concurrent updates.  To prevent inconsistencies in FIB updates, MAP-
   Me-IU maintains a sequence number at the producer end that increases
   at each handover and identifies every IU packet.  Network routers
   also keep track of such sequence number in FIB to verify IU
   freshness.  Without detailing the specific operations in MAP-Me to
   guarantee update consistency (whose description is provided in
   Section Section 8, we can say that modification of FIB entries is
   only triggered when the received IU carries a higher sequence number
   than the one locally stored, while the reception of a less recent
   update determines a propagation of a more recent update through the
   not-yet-updated path.

   An example of reconciliation of concurrent updates is illustrated in
   Figure Figure 2 (f), when the producer has moved successively to P1
   and then to P2 before the first update is completed.

                            +---+                         +---+
                            | 0 | P0                      | 2 | P0
                            +---+                      A  +---+
                             ^ ^                IU(2) /    / ^
                            /   \                    /    V   \
                        +---+    +---+                +---+    +---+
                        | 0 |    | 0 |           <!>  | 2 |    | 0 |
                        +---+ A  +---+             A  +---+ A  +---+
                         ^ ^   \            IU(1) /    ^ \   \
                        /   \   \  IU(2)         /    /   V   \ IU(2)
                    +---+    +---+                +---+    +---+
                    | 0 |    | 2 | P2             | 1 |    | 2 |
                 A  +---+    +---+             A  +---+    +---+
          IU(1) /    ^ ^                  IU1 /    / ^
               /    /   \                    /    V   \
                +---+    +---+                +---+    +---+
             P1 | 1 |    | 0 |             P1 | 1 |    | 0 |
                +---+    +---+                +---+    +---+
                 ^ ^                           ^ ^
                /   \                         /   \
            +---+    +---+                +---+    +---+
            | 0 |    | 0 |                | 0 |    | 0 |
            +---+    +---+                +---+    +---+

                     (f)                       (g)

                            +---+                      +---+
                            | 2 | P0                   | 2 | P2
                            +---+                      +---+

Auge, et al.           Expires September 18, 2018              [Page 11]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

                             / ^                         ^
                            V   \                        |
                        +---+    +---+                 +---+
                    <!> | 2 |    | 2 |                 | 2 |
             IU(2)  /   +---+    +---+                 +---+
                   /     ^ \                           ^   ^
                  V     /   V                         /     \
                    +---+    +---+                +---+     +---+
                    | 2 |    | 2 | P2         P0  | 2 |     | 2 |
          IU(2)  /  +---+    +---+                +---+     +---+
                /    / ^                           ^         ^ ^
               V    V   \                         /    P1   /   \
                +---+    +---+                 +---+    +---+   +---+
             P1 | 1 |    | 0 |                 | 0 |    | 2 |   | 0 |
                +---+    +---+                 +---+    +---+   +---+
                 ^ ^                                     ^ ^
                /   \                                   /   \
            +---+    +---+                          +---+    +---+
            | 0 |    | 0 |                          | 0 |    | 0 |
            +---+    +---+                          +---+    +---+

                     (h)                                 (i)

                                 Figure 2

   Both updates propagate concurrently until the update with sequence
   number 1 (IU(1)) crosses a router that has been updated with fresher
   information -- that has received IU with higher sequence number
   (IU(2)) as in Figure Figure 1 (g).  In this case, the router stops
   the propagation of IU(1) and sends back along its path a new IU with
   an updated sequence number (Figure 1 (h)).  The update proceeds until
   ultimately the whole network has converged towards P2 (Figure 1 (i)).

   MAP-Me-IU protocol reacts at a faster timescale than routing --
   allowing more frequent and numerous mobility events -- and over a
   localized portion of the network edge between current and previous
   producer locations.  We thus expect MAP-Me-IU respectively to
   minimize disconnectivity time and to reduce the link load, which are
   the main factors affecting user flow performance, as show in [MAPME]
   evaluations.

6.  MAP-Me Notification/Discovery protocol

   IU propagation in the data plane accelerates forwarding state re-
   convergence w.r.t. global routing (GR) or resolution-based (RB)
   approaches operating at control plane, and w.r.t. anchor-based (AB)
   approaches requiring traffic tunneling through the anchor.  Still,

Auge, et al.           Expires September 18, 2018              [Page 12]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   network latency makes IU completion not instantaneous and before an
   update completes, it may happen that a portion of the traffic is
   forwarded to the previous PoA and dropped because of the absence of a
   valid output face leading to the producer.

   Previous work in the Anchor-Less category has suggested the buffering
   of Interests at previous producer location to prevent such losses by
   increasing network reactivity.  However, such a solution is not
   suitable for applications with stringent latency requirements (e.g.
   real-time) and may be incompatible with IU completion times.
   Moreover, the negative effects on latency performance might be
   further exacerbated by IU losses and consequent retransmissions in
   case of wireless medium.  To alleviate such issues, we introduce two
   separate enhancements to MAP-Me-IU protocol, namely (i) an _Interest
   Notification_ mechanism for frequent, yet lightweight, signaling of
   producer movements to the network and (ii) a scoped _Producer
   Discovery_ mechanism for consumer requests to proactively search for
   the producer's recently visited locations.

6.1.  Interest Notification

   An Interest Notification (IN) is a breadcrumb left by producers at
   every encountered PoA.  It looks like a normal Interest packet
   carrying a special identification flag and a sequence number, like
   IUs.  Both IU and IN share the same sequence number (producers
   indistinctly increase it for every sent message) and follow the same
   FIB lookup and update processes.  However, unlike IU packets, the
   trace left by INs at the first hop router does not propagate further.
   It is rather used by the discovery process to route consumer requests
   to the producer even before an update process is completed.

   It is worth observing that updates and notifications serve the same
   purpose of informing the network of a producer movement. \changes{The
   IU process restores connectivity and as such has higher latency/
   signaling cost than the IN process, due to message propagation.  The
   IN process provides information to track producer movements before
   update completion when coupled with a scoped discovery.  The
   combination of both IU and IN allows to control the trade-off between
   protocol reactivity and stability of forwarding re-convergence.

6.2.  Discovery

   The extension of MAP-Me with notifications relies on a local
   discovery phase: when a consumer Interest reaches a PoA with no valid
   output face in the corresponding entry, the Interest is tagged with a
   _discovery_ flag and labeled with the latest sequence number stored
   in FIB (to avoid loops).  From that point on, it is broadcasted with
   hop limit equal to one to all neighbors and discarded unless it finds

Auge, et al.           Expires September 18, 2018              [Page 13]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   the breadcrumbs left by the producer to track him (notifications).
   The notifications can either allow to forward consumer Interests
   directly to the producer or give rise to a repeated broadcast in case
   of no valid output face.  The latter is the case of a breadcrumb left
   by the producer with no associated forwarding information because the
   producer has already left that PoA as well.  A detailed description
   of the process is reported in Section 8.

   The notification/discovery mechanism proves important to preserve the
   performance of flows in progress, especially when latency-sensitive.

6.3.  Full approach

   The full approach is a combined update and notification/discovery
   approach consisting of sending a IN immediately after an attachment
   and a IU at most every Tu seconds, referred to as MAP-Me, to reduce
   signaling overhead especially in case of high mobility.  The update-
   only proposal, denoted as MAP-Me-IU, is equally interesting on its
   own and might be a fit depending on the use case.

7.  Implementation

   In this section we describe the changes to a regular CCN/NDN
   architecture required to implement MAP-ME and detail the above-
   described algorithms.  This requires to specify a special Interest
   message, additional temporary information associated to the FIB entry
   and additional operations to update such entry.

7.1.  MAP-Me Messages

   Two new optional fields are introduced in a CCN/NDN Interest header:

   o  a special _Interest Type_ (T) to specify four types of messages:
      Interest Updates (IU), Interest Notifications (IN), as well as
      their associated acknowledgment (Ack) messages (IU_Ack and
      IN_Ack).  Those flags are recognized by the forwarding pipeline to
      trigger special treatment;

   o  a _sequence number_ to handle concurrent updates and prevent
      forwarding loops during signaling, and to control discovery
      interests' propagation;

7.2.  MAP-Me additional Network Information

   FIB entries are enriched with a sequence number, initialized to 0,
   say, by routing protocol and updated by MAP-Me upon reception of IU/
   IN messages.  The Data about not-yet-acknowledged messages are
   temporarily stored in what we denote as _Temporary FIB buffer, or

Auge, et al.           Expires September 18, 2018              [Page 14]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   TFIB_, to ensure reliability of the process, and removed upon
   reception of the corresponding acknowledgement.

   As sketched in Figure Figure 3, each TFIB entry is composed of an
   associative array (F -> T) mapping a face F on which IU has been sent
   with the associated retransmission timer T (possibly Null).  Note
   that the update mechanism is a constant delay operation at each
   router and is performed at line rate.

            IU (IN) input face(s)            IU (IN) output face

      +-----------+-------------------+.......+.......................+
      |  /prefix  |  { next hop(s) }  |  seq  |  { face : rx_timer }  |
      +-----------+-------------------+.......+.......................+
       \_____________ _______________/ \______________ ______________/
                     V                                V
                original FIB                     TFIB section

                   Figure 3: MAP-ME FIB/TFIB description

8.  Algorithm description

8.1.  IU/IN transmission at producer

   MAP-Me operations are triggered by producer mobility/handover events.
   At the producer end, a mobility event is followed by a layer-2
   attachment and, at network layer, a change in the FIB.  More
   precisely, a new face is created and activated upon attachment to a
   new PoA.  This signal triggers the increase of MAP-Me sequence number
   and the transmission of an IU or IN for every served prefix carrying
   the updated sequence number.

   To ensure reliable delivery of IUs, a timer is setup in the temporary
   section of the FIB entry (TFIB).  If an acknowledgement of the IU/IN
   reception is not received within t seconds since the packet
   transmission, IU is retransmitted.

   We define the SendReliably(F, type, E) function fpr sending Special
   Interests of a given type on faces F based on FIB entry E.  It
   schedules their retransmission through a timer T stored in TFIB:
   E.TFIB = E.TFIB U (F -> T) and removed on Ack.

Auge, et al.           Expires September 18, 2018              [Page 15]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

8.2.  IU/IN transmission at network routers

   At the reception of IU/IN packets, each router performs a name-based
   Longest Prefix Match lookup in FIB to compare sequence number from
   IU/IN and from FIB}. According to that comparison:

   o  if the IU/IN packet carries a higher sequence number, the existing
      next hops associated to the lower sequence number in FIB are used
      to forward further the IU (INs are not propagated) and temporarily
      copied into TFIB to avoid loss of such information before
      completion of the IU/IN acknowledgement process (in case of IN,
      such entries in TFIB are set with a $\bot$ timer to maintain a
      trace of the producer recent attachment).  Also, the originating
      face of the IU/IN is added to FIB to route consumer requests to
      the latest known location of the producer.

   o  If the IU/IN packet carries the same sequence number as in the
      FIB, the originating face of the IU/IN 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 IU/IN 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 IU/IN packet, this one is re-sent through the
      originating face after having updated its sequence number with the
      value stored in FIB.

8.3.  Hop-by-hop IU/IN acknowledgement

   The operations in the forwarding pipeline for IU/IN processing are
   reported in Figure 4.

Auge, et al.           Expires September 18, 2018              [Page 16]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   | Algorithm 1 : ForwardSpecialInterest(SpecialInterest SI, Ingress face F)
   |
   |  CheckValidity()
   |  // Retrieve the FIB entry associated to the prefix
   |  e, T <- FIB.LongestPrefixMatch(SI.name)
   |  if SI.seq >= e.seq then
   |  .   // Acknowledge reception
   |  .   s <- e.seq
   |  .   e.seq <- SI.seq
   |  .   SendReliably(F, SI.type + Ack, e)
   |  .   //Process special interest
   |  .   if F in e.TFIB then
   |  .   .   // Remove outdated TFIB entry (eventually cancelling timer)
   |  .   .   e.TFIB = e.TFIB \ F
   |  .   if SI.seq > s then
   |  .   .   if SI.type == IU then
   |  .   .   .   // Forward the IU following the FIB entry
   |  .   .   .   SendReliably(e.NextHops, SI.type, e
   |  .   .   else
   |  .   .   .   // Create breadcrumb and preserve forwarding structure
   |  .   .   .   e.TFIB = e.TFIB U {( f -> NULL) : for all f in e.NextHops}
   |  .   .   e.NextHops = {}
   |  .   e.NextHops = e.NextHops U { F }
   |  else
   |  .   // Send updated IU backwards
   |  .   SI.seq = e.seq
   |  .   SendReliably(F, SI.type, e)

                                 Figure 4

8.4.  Face removal at producer/network nodes

   Upon producer departures from a PoA, the corresponding face is
   destroyed.  If this leads to the removal of the last next hop, then
   faces in TFIB with Null timer (entries generated by notifications)
   are restored in FIB to preserve the original forwarding tree and thus
   global connectivity.

8.5.  Consumer request forwarding in case of producer discovery

   The forwarding of regular Interests is mostly unaffected in MAP-Me,
   except in the case of discovery Interests that we detail in Figure 5.
   The function SendToNeighbors(I) is responsible for broadcasting the
   Interest I to all neighboring PoAs.

Auge, et al.           Expires September 18, 2018              [Page 17]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   | Algorithm 2:  InterestForward(Interest I, Origin face F)
   |
   |  // Regular PIT and CS lookup
   |  e <- FIB.LongestPrefixMatch(I.name)
   |  if e = 0 then
   |  .   return
   |  if I.seq = 0 then
   |  .   // Regular interest
   |  .   if hasValidFace(e.NextHops) or DiscoveryDisabled then
   |  .   .   ForwardingStrategy.process(I, e)
   |  .   else
   |  .   .   // Enter discovery mode
   |  .   .   I.seq <- e.seq
   |  .   .   SendToNeighbors(I)
   |  else
   |  .   // Discovery interest: forward if producer is connnected
   |  .   if hasProducerFace(e.NextHops) then
   |  .   .   ForwardingStrategy.process(I, e)
   |  .   // Otherwise iterate iif higher seq and breadcrumb
   |  .   else if e.seq >= I.seq and EXISTS f | (f -> NULL) in e.TFIB then
   |  .   .   I.seq <- e.seq
   |  .   .   SendToNeighbors(I)

                                 Figure 5

   When an Interest arrives to a PoA which has no valid next hop for it
   (because the producer left and the face got destroyed), it enters a
   discovery phase where the Interest is flagged as a Discovery Interest
   and with the local sequence number, then broadcasted to neighboring
   PoAs.

   Upon reception of a Discovery Interest, the PoA forwards it direcly
   to the producer if still attached, otherwise it repeats the one-hop
   brodcast discovery to neighboring PoAs if it stores a recent
   notification of the producer presence, i.e. an entry in TFIB having
   higher sequence number than the one in the Discovery Interest.
   Otherwise, the Discovery Interest is discarded.

   It is worth observing that the discovery process is initiated only in
   the case of no valid next hop, and not every time a notification is
   found in a router.  This is important to guarantee that the
   notification/discovery process does not affect IU propagation and
   completion.

Auge, et al.           Expires September 18, 2018              [Page 18]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

9.  Security considerations

   All mobility management protocols share the same critical need for
   securing their control messages which have a direct impact on the
   forwarding of users' traffic. [compagno2017secure] reviews standard
   approaches from the literature before developing a fast, lightweight
   and distributed approach based on hash chaining that can be applied
   to MAP-Me and fits its design principles.

10.  Acknowledgements

11.  Contributors

   o  Giulio Grassi (UPMC/UCLA)

   o  Giovanni Pau (UPMC/UCLA)

   o  Xuan Zeng (UPMC/SystemX)

12.  IANA Considerations

   This memo includes no request to IANA.

13.  References

13.1.  Normative References

   [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>.

13.2.  Informative References

   [ahlgren2012survey]
              B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher and B.
              Ohlman,, "A survey of information-centric networking",
              IEEE Communications Magazine, vol. 50, no. 7, pp. 26-36,
              2012.

   [carofiglio2016mwldr]
              G. Carofiglio et al., "Leveraging ICN In-network Control
              for Loss Detection and Recovery in Wireless Mobile
              Networks", ACM SIGCOMM ICN  , 2016.

   [compagno2017secure]
              A. Compagno et al., "Secure Producer Mobility in
              Information-Centric Network", ACM SIGCOMM ICN  , 2017.

Auge, et al.           Expires September 18, 2018              [Page 19]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   [feng2016mobility]
              B. Feng et al., "Mobility support in Named Data
              Networking", EURASIP Journal on Wireless Communications
              and Networking  , 2016.

   [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
              TNSM, vol. PP, no. 99, pp. 1-1, 2018.

   [NDN-survey]
              L. Zhang et al., "Secure Producer Mobility in Information-
              Centric Network", Workshop on Name-Oriented Mobility:
              Architecture, Algorithms and Applications  , 2016.

   [NLSR]     L. Zhang et al., "Named-data link state routing protocol",
              ACM SIGCOMM ICN  , 2013.

   [tyson2013survey]
              G. Tyson et al., "Secure Producer Mobility in Information-
              Centric Network", Communications of the ACM no. 56, pp.
              90-98 , 2013.

   [xylomenos2014survey]
              G. Xylomenos et al., ""A Survey of Information-Centric
              Networking Research"", IEEE Communications Surveys &
              Tutorials vol. 16, no. 2, pp. 1024-1049, 2014.

Authors' Addresses

   Jordan Auge (editor)
   Cisco Systems, Inc.

   Email: jordan.auge@cisco.com

   Giovanna Carofiglio (editor)
   Cisco Systems, Inc.

   Email: gcarofig@cisco.com

   Luca Muscariello (editor)
   Cisco Systems, Inc.

   Email: lumuscar@cisco.com

Auge, et al.           Expires September 18, 2018              [Page 20]
Internet-Draft     Managing Anchorless Mobility in CCN          mar 2018

   Michele Papalini (editor)
   Cisco Systems, Inc.

   Email: micpapal@cisco.com

Auge, et al.           Expires September 18, 2018              [Page 21]