| ICNRG | J. Auge, Ed. |
| Internet-Draft | G. Carofiglio, Ed. |
| Intended status: Informational | L. Muscariello, Ed. |
| Expires: September 19, 2018 | M. Papalini, Ed. |
| Cisco Systems, Inc. | |
| mar 18, 2018 |
MAP-Me : Managing Anchorless Mobility in Content Centric Networking
draft-irtf-icnrg-mapme-00
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.
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 19, 2018.
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.
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 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:
MAP-Me performance has been thoroughly analyzed and provides guarantees of correctness, stability and bounded stretch [MAPME].
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):
MAP-Me is an anchor-less, name-based, layer-2 agnostic approach operating at forwarding plane designed according to the following design principles:
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:
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.
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 |
+---+ +---+ +---+ +---+
^ ^ ^ ^
/ \ / \
+---+ +---+ +---+ +---+
| 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
+---+
^ 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].
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
+---+ +---+
/ ^ ^
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.
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, 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.
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.
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 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.
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.
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.
Two new optional fields are introduced in a CCN/NDN Interest header:
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 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
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.
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:
The operations in the forwarding pipeline for IU/IN processing are reported in Figure 4.
| 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
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.
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.
| 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.
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.
This memo includes no request to IANA.
| [RFC6301] | Zhu, Z., Wakikawa, R. and L. Zhang, "A Survey of Mobility Support in the Internet", RFC 6301, DOI 10.17487/RFC6301, July 2011. |