Enabling Correct Interest Forwarding and Retransmissions in a Content Centric Network

Enabling Correct Interest Forwarding and Retransmissions in a Content Centric Network

J. J. Garcia-Luna-Aceves and Maziar Mirzazad-Barijough
Computer Engineering Department, University of California, Santa Cruz, CA 95064
PARC, Palo Alto, CA 94304

We show that the mechanisms used in the name data networking (NDN) and the original content centric networking (CCN) architectures may not detect Interest loops, even if the network in which they operate is static and no faults occur. Furthermore, we show that no correct Interest forwarding strategy can be defined that allows Interest aggregation and attempts to detect Interest looping by identifying Interests uniquely. We introduce SIFAH (Strategy for Interest Forwarding and Aggregation with Hop-Counts), the first Interest forwarding strategy shown to be correct under any operational conditions of a content centric network. SIFAH operates by having forwarding information bases (FIBs) store the next hops and number of hops to named content, and by having each Interest state the name of the requested content and the hop count from the router forwarding an Interest to the content. We present the results of simulation experiments using the ndnSIM simulator comparing CCN and NDN with SIFAH. The results of these experiments illustrate the negative impact of undetected Interest looping when Interests are aggregated in CCN and NDN, and the performance advantages of using SIFAH.

Information-centric networks, Interest forwarding strategies





Theory, Design, Performance

1 Introduction

A number of information-centric networking (ICN) architectures have been proposed to improve the performance and the end-user experience of the Internet [2, 20]. ICN architectures focus on (1) enabling access to content and services by name, rather than by original location; (2) protecting content rather than links or connections; and (3) exploiting in-network storage of content.

A leading approach in ICN architectures can be characterized as Interest-based content-centric networking and is the focus of this paper. Directed Diffusion [12] is one of the first examples of this approach. Requests for named content (called Interests) are diffused throughout a sensor network, and data matching the Interests are sent back to the issuers of Interests. Subsequent proposals (e.g., DIRECT [18]) use a similar approach in MANETs subject to connectivity disruption. Nodes use opportunistic caching of content and flood Interests persistently. The limitation of Directed Diffusion and other similar approaches is the need to flood the network with Interests, an approach that cannot be applied at Internet scale.

The original CCN proposal [13] was the first example of an Interest-based content-centric architecture applicable to wired networks in which Interests do not state the identity of the sender. Today, NDN [16] and CCN [4] are the leading proposals for content-centric networking based on Interest forwarding. In general, an Interest-based forwarding strategy consists of: populating forwarding information bases (FIB) of routers with routes to name prefixes denoting content, sending content requests (called Interests) for specific named data objects (NDO) over paths implied by the FIBs, and delivering content along the reverse paths traversed by Interests.

Section 2 summarizes the operation of the forwarding strategies of NDN and CCN. The designers of NDN and CCN have argued [13, 16, 21, 22] that an Interest stating a name of requested content and a nonce or unique identifier can be forwarded correctly towards an intended node advertising the content name, that routers can aggregate Interests so that a router can forward an Interest for the same content only once, and that Interest loops can be detected whenever they occur. However, no prior work has been reported proving these claims.

Section 3 demonstrates that the forwarding strategies of the original CCN and NDN architectures [13, 21, 25] do not work correctly, in that some Interests may never return data objects to the consumers who issued the Interests, even if the content does exist in the network, the network topology and routing are stable, and all transmissions are successful. More importantly, it is also shown that there is no correct forwarding strategy with Interest aggregation and Interest-loop detection based on the matching of Interest-identification data carried in Interests. In this context, Interest-identification data can be names of requested content, nonces, unique identifiers, or the path traversed by an Interest.

Section 4 introduces the Strategy for Interest Forwarding and Aggregation with Hop-counts (SIFAH), which is the first Interest-based forwarding strategy shown to be correct. SIFAH operates by having FIBs store the next hops and number of hops to named content, and by forwarding each Interest based on the name of the requested content and a hop count from the forwarding router to the requested content. A router accepts to forward an Interest only if the hop count stated in the Interest is larger than the hop count from the router to the content as stated in its FIB. Similarly, a router that has forwarded an Interest for a given NDO accepts to aggregate an Interest it receives while waiting for the requested NDO only if the hop count stated in the Interest is larger than the hop count of the Interest sent by the router.

Section 5 proves that SIFAH works correctly when Interest loops occur and Interests are aggregated.

Section 6 analyzes the storage requirements of SIFAH and NDN and shows that SIFAH is a more desirable approach than using nonces to attempt to detect Interest loops. Furthermore, it presents simulation results based on the unmodified implementation of the NDN forwarding strategy and our implementation of SIFAH in ndnSIM. The simulation results help to illustrate that consumers submitting Interests must receive NDO messages or negative acknowledgments (NACK) when SIFAH is used, while some Interests may go unanswered in NDN and the original CCN design due to undetected Interest loops, even in stable topologies with correct entries in FIBs. Furthermore, the results indicate that Interest loops increase the number of PIT entries and end-to-end delays experienced by consumers even when Interest loops are rare.

2 Existing Interest Forwarding

In NDN and CCN, a given router uses three primary data structures to implement any of the forwarding strategies defined for Interest-based content-centric architectures: a forwarding information base (), a pending Interest table (), and a content store ().

The forwarding strategy determines the interaction among , , and needed to forward Interests towards nodes advertising having copies of requested content, send NDOs back to consumers who requested them over reverse paths traversed by Interests, and send any other signal indicating the inability to satisfy an Interest.

is used to route incoming Interests to the appropriate next hops towards the desired content producer advertising a content prefix name .

is populated using content routing protocols or static routes and matches Interest names stating a specific NDO to entries of prefix names using longest prefix match.

serves as a cache of Interest state, such that content objects that satisfy Interests may follow the reverse Interest path back to the original requester. is a cache for content objects.

In the rest of this paper, we use the term name data object (NDO) or content object interchangeably, and use the term neighbor instead of interface or face. We denote the name of NDO by , and the name prefix that includes that NDO name by . We denote the existence of an entry for a prefix or NDO with name in the FIB, PIT or CS of router by , , and , respectively.

Two Interest-based forwarding strategies proposed to date are the original CCN strategy [13] and the NDN forwarding strategy [21, 25]. In both strategies, an Interest created by source for NDO states and a nonce . The pair is used to denote an Interest uniquely with a large-enough probability. Furthermore, the same pair is used to detect whether an Interest is traversing a loop.

In the context of NDN and the original CCN, we use to denote an Interest that requests NDO with name and that is originated by consumer , who assigns nonce to the Interest. A content-object message (or NDO message) sent in response to an Interest , denoted , states the name and nonce of the Interest, a signature payload used to validate the content object, and the object itself.

1:  function Process Interest
2:  INPUT: , , ;
3:  INPUT: received from ;
4:  if   then
5:     send to
6:  else
7:     if  then
8:         create ; call Forwarding Strategy()
9:     else
10:        % There is a PIT entry for
11:        if  with  then
12:           % A duplicate Interest is detected [NDN] send to ; drop
13:        else
14:           % Interest can be aggregated create ;
15:           if  is exprired then
16:               call Forwarding Strategy();
17:           end if
18:        end if
19:     end if
20:  end if
Algorithm 1 NDN Processing of Interest at router
1:  function Forwarding Strategy
2:  INPUT: , , ;
3:  INPUT:
4:  if  then
5:     for each neighbor in by rank do
6:        if  for all for all  then
7:           if  is available then
8:               ; start ; forward to neighbor ; return
9:           end if
10:        end if
11:     end for
12:      [NDN] send to ;drop delete
13:  else
14:      send to ; drop ; delete
15:  end if
Algorithm 2 NDN forwarding of Interest at router

The entry in for name prefix is denoted by and consists of and the list of neighbors that can be used to reach the NDO. If neighbor is listed in , then we state . In NDN [22], the FIB entry for an NDO also contains a stale time after which the entry could be deleted; the round-trip time through the neighbor; a rate limit; and status information stating whether it is known or unknown that the neighbor can bring data back, or is known that the neighbor cannot bring data back.

The entry in for NDO with name is denoted by and consists of a vector of one or multiple tuples, one for each nonce processed for the same NDO name. The tuple for a given NDO states the nonce used, the incoming and the outgoing neighbor(s). The tuple created as a result of processing Interest received from and forwarded to a set of neighbors is denoted by , and the set of outgoing neighbors in is denoted by .

Each PIT entry has a lifetime, which should be larger than the estimated round-trip time to a site where the requested NDO can be found.

We denote by the NACK sent in response to , where states the reason why the NACK is sent.

Algorithms 1 and 2 illustrate the NDN Interest processing approach [21, 22] using the notation we have introduced, and correspond to Interest-processing and forwarding-strategy algorithms in [22]. Algorithm 2 does not include the probing of neighbors proposed in NDN, given that this aspect of NDN is still being defined [22]. Routers forward NACKs received from those neighbors to whom they sent Interests, unless the PIT entries have expired or do not match the information provided in the NACKs. The NDN forwarding strategy augments the original CCN strategy by introducing negative acknowledgements (NACK) sent in response to Interests for a number of reasons, including: routers identifying congestion, routers not having routes in their FIBs to the requested content, or Interest loops being detected. Algorithms 1 and 2 indicate the use of NACKs that is not part of the original CCN design by “[NDN].”

3 Undetected Interest Loops
in CCN an NDN

The use of nonces in NDN and the original CCN approach can be extrapolated to include the case in which an Interest states a nonce and the path traversed by the Interest by assuming that equals the tuple . If a nonce and path traversed by the Interest are used, deciding whether an Interest has not traversed a loop can be based on whether . However, including path information in Interests reveals the identity of originators of Interests.

The key aspect of the forwarding strategies that have been proposed for NDN and CCN is that a router determines whether or not an Interest is a duplicate Interest based solely on the content name and Interest-identification data for the Interest (a nonce in NDN’s case). To discuss the correctness of the forwarding strategy and other strategies, we define an Interest loop as follows.

Interest Loop: An Interest loop of hops for NDO with name occurs when one or more Interests asking for are forwarded and aggregated by routers along a cycle such that router receives an Interest for NDO from while waiting for a response to the Interest it has forwarded to for the same NDO, with , , and .

According to the NDN forwarding strategy, a router can select a neighbor to forward an Interest if it is known that it can bring content and its performance is ranked higher than other neighbors that can also bring content. The ranking of neighbors is done by a router independently of other routers, which can result in long-term routing loops implied by the FIBs if the routing protocol used in the control plane does not guarantee instantaneous loop freedom (e.g., NLSR [14]).

Figure 1: Undetected Interest loops in NDN and CCN

Figure 1 illustrates Interest looping in NDN. Arrowheads in the figure indicate the next hops to content advertised by router according to the FIB entries stored in routers. Thick lines indicate that the perceived performance of a neighbor is better than neighbors shown with thinner lines. Dashed lines indicate the traversal of Interests over links and paths. The time when an event is processed at a router is indicated by . Figure 1(a) shows the case of a long-term Interest loop formed because the multi-paths implied in FIBs are not loop-free, even though all routing tables are consistent. Figure 1(b) shows the case of a temporary Interest loop when single-path routing is used and FIBs are inconsistent due to a topology change at time (link fails). In both cases, router aggregates the Interest from at time , router aggregates the Interest from at time , and the combined steps preclude the detection of Interest looping. This results in and having to wait for their Interests to time out, before they can retransmit. Furthermore, there is no guarantee that their retransmissions will elicit a response (content or NACK).

As Theorem 1 proves, the CCN and NDN forwarding strategies specified in [13, 22, 25] cannot ensure that Interest loops are detected when Interests are aggregated, even if nonces were to denote Interests uniquely. The theorem assumes that all messages are sent correctly and that no routing-table changes occur to show that the NDN forwarding strategy can fail to return any content or NACK in response to Interests independently of network dynamics. Furthermore, Theorem 2 shows that no forwarding strategy can be correct if it allows Interest aggregation and attempts Interest-loop detection by the matching of Interest-identification data.

Theorem 1

Interest loops can go undetected in a stable, error-free network in which NDN or CCN is used, even if nonces were to denote Interests uniquely.


Consider the NDN or CCN forwarding strategy running in a network in which no two nonces created by different nodes for the same content are equal, all transmissions are received correctly, and no topology or routing-table changes occur after time . Let denote the lifetime of at router .

Assume that Interests may traverse loops when they are forwarded according to the forwarding strategy, and let a loop exist for NDO , and let Interest start traversing the chain of nodes (with ) at time .

Assume that reaches router at time and that router forwards Interest to its next hop at time , where , , and may be .

According to the Interest processing strategy in NDN and CCN, router creates an entry in its PIT for at time , and perceives any Interest for name and a nonce different than received after time , and before its PIT entry for is erased, as a subsequent Interest.

Let when router receives from router at time , where . According to the Interest processing strategy in NDN and CCN, router must treat as a subsequent Interest for content that is aggregated, because is waiting for at time .

Because of the existence of , Interest must be forwarded from to . Let denote the time when reaches , where , and assume that . According to NDN’s Interest processing strategy, must treat as a subsequent Interest, because it is waiting for at time .

Given the Interest aggregation carried out by nodes and , nodes in the chain process only , nodes in the chain process only , and no Interest loop detection can take place. Therefore, no content can be submitted in response to and .

Similar results to Theorem 1 can be proven for NDN and the original CCN operating in a network in which routing tables are inconsistent as a result of network or content dynamics. In this case, Interest loops can go undetected even if the control plane supports only single-path forwarding of Interests.

Theorem 2

No correct forwarding strategy exists with Interest aggregation and Interest loop detection based on the matching of Interest-identification data.


Assume any forwarding strategy in which a router remembers an Interest it has forwarded as long as necessary to detect Interest loops, and detects the occurrence of an Interest loop by matching the Interest-identification data carried in an Interest it receives with the Interest-identification data used in the Interest it forwarded previously asking for the same content. Let denote the Interest asking for with Interest-identification data created by router .

Assume that an Interest loop for NDO with name exists in a network using the forwarding strategy. Let Interest start traversing the chain of nodes (with ) at time .

Assume that reaches router at time and that router forwards Interest to its next hop at time , where , . Let traverse the chain of nodes , reaching at time , where .

By assumption, Interest aggregation occurs, and hence aggregates at time , and aggregates at time . Therefore, independently of the amount of information contained in and , cannot receive from and cannot receive from . It thus follows that no node in can successfully use the matching of Interest-identification data to detect that Interests for are being sent and aggregated along and the theorem is true.

The results in Theorems 1 and 2 can also be proven by mapping the Interest processing strategy of NDN, and any forwarding strategy that attempts to detect Interest loops by matching Interest-identification data, to the problem of distributed termination detection over a cycle, where Interests serve as the tokens of the algorithm [7, 15]. Because Interest aggregation erases a token traversing the ring (Interest loop) when any node in the ring has previously created a different token, correct termination detection over the ring (i.e., Interest loop detection) cannot be guaranteed in the presence of Interest aggregation.

Obviously, a loop traversed by an Interest can be detected easily if each Interest is identified with the route it should traverse. This is easy to implement but requires routers in the network to have complete topology information (e.g., [14, 17, 19]) or at least path information or partial topology information (e.g., [3, 17]). Similarly, carrying the path traversed by an Interest in its header also ensures that an Interest loop is detected if it occurs. In these two cases, however, there is no need for using nonces to detect Interest loops. More importantly, path information reveals the identity of the source router requesting content and hence defeats one of the key objectives of the NDN and CCN forwarding strategies.

Another view of the problem would be to say that Interest aggregation is not common and hence undetected Interest loops should be too rare to cause major performance problems. However, if Interests need not be aggregated, then very different architectures could be designed for content-centric networking that do not require using PITs.

4 Sifah

4.1 Design Rationale

It is clear from the results in the previous section that using nonces or identifying Interests uniquely is useless for Interest-loop detection when Interests are aggregated, and that source routing of Interests or including the path traversed by an Interest are not desirable. Accordingly, for an Interest forwarding strategy to be correct in the presence of Interest aggregation, it must be the case that, independently of the identity of an Interest or how Interests for the same content are aggregated, at least one router detects that it is traversing a path that is not getting the Interest closer to a node that has advertised the requested content.

Ensuring that at least one router in an Interest loop detects the incorrect forwarding of the Interest can be attained if Interests were to carry any type of ordering information that cannot be erased by the use of Interest aggregation. Fortunately, distance information for advertised name prefixes is exactly this type of ordering information.

Given that forwarding information bases (FIB) are populated from the routing tables maintained in the control plane of a network, they constitute a readily-available tool to establish the proper interaction between the forwarding strategy operating in the data plane and the distances to advertised content prefixes maintained by the routing protocol operating in the control plane. This is the basis of the Strategy for Interest Forwarding and Aggregation with Hop-Counts (SIFAH).

4.2 Information Stored and Exchanged

A router maintains a FIB, a PIT, and an optional content store. is indexed using content name prefixes. The FIB entry for prefix is denoted by , and consists of a list of one or more tuples. Each tuple states a next hop to and a hop count to the prefix. The set of next hops to listed in is denoted by . The hop count to through neighbor is denoted by .

An Interest sent by node requesting NDO is denoted by , and states the name , and the hop count () from node to the name prefix that is the best match for NDO name when forwards the Interest.

An NDO message sent in response to the Interest is denoted by , and states the name of the Interest, a signature payload used to validate the content object, and the object itself.

The NACK sent by router in response to an Interest is denoted by where states the reason why the NACK is sent. Possible reasons for sending a NACK include: (a) an Interest loop is detected, (b) a route failed towards the requested content, (c) no content is found, and (d) the PIT entry expired.

is indexed using NDO names. denotes the entry created in for NDO with name , and specifies: the name of the NDO; the hop count assumed by router when it forwards Interest ; the set of incoming neighbors from which Interests for are received (); the set of outgoing neighbor(s) () to whom router forwards its Interest; and the remaining lifetime for the Interest ().

4.3 Interest Loop Detection

To define a correct forwarding strategy, special attention must be paid to the fact that updates made to the FIBs stored at routers occur independently of and concurrently with the updates made to their PITs. For example, once a router has forwarded an Interest that assumed a given distance to content prefix and waits for its Interest to return a data object, its distance to the same content may change based on updated to its FIB. Hence, simply comparing the minimum distance from a router to content against a distance to content stated in an Interest is not enough to ensure that Interests are not incorrectly forwarded to routers that are farther away form the requested content.

SIFAH takes into account the fact that FIBs and PITs are updated independently by requiring that a router that forwards an Interest for a given piece of content remembers in its PIT entry the value of the distance to content assumed when it issues its Interest. The following rule is then used for a given router to determine whether an Interest may be propagating over an Interest loop.

The number of hops to requested content is used as the metric for the invariant condition. This is done for two reasons, storing hop-count distances in the FIB incurs less storage overhead than storing complex distance values, and the next hops to a prefix stored in the FIB can be ranked based on the actual distances to content.

HFAR–Hop-Count Forwarding with Aggregation Rule: Router can accept from router if one of the following two conditions is satisfied:

The first condition ensures that router accepts an Interest from neighbor only if determines that is closer to through at least one neighbor than was when it sent its Interest. The second condition ensures that router accepts an Interest from neighbor only if was closer to than when and sent their Interests.

Section 5 proves that using HFAR is sufficient to ensure that an Interest loop cannot occur without a router in the loop detecting that the Interest has been forwarded incorrectly. This result is independent of whether Interests are aggregated or sent over one or multiple paths, or how Interests are retransmitted.

Similar forwarding rules based on more sophisticated lexicographic orderings could be defined based on the same general approach stated in HFAR. The requirement for such forwarding rules is that more information needs to be maintained in the FIBs, such as distance values to name prefixes that take into account such factors as end-to-end delay, reliability, cost, or bandwidth available.

HFAR is very similar to sufficient conditions for loop-free routing introduced in the past, in particular sufficient conditions for loop-free routing based on diffusing computations [8, 19, 24]. Indeed, the approach we introduce for Interest-loop detection in SIFAH can be viewed as a case of termination detection based on diffusing computations [6].

It should be pointed out that, because HFAR is not necessary to detect loops, there are cases in which HFAR is not satisfied even though no Interest loops exist. However, prior results on multi-path routing based on diffusing computations [23] indicate that this does not constitute a performance problem. Given that FIBs are updated to reflect correct hop counts, or correct complex distance values in general, a sufficient condition for loop detection operating with multi-path routing is a good baseline for an Interest-based forwarding strategy.

4.4 SIFAH Operation

Algorithms 3 to 8 specify the steps taken by routers to process Interests, forward Interests, return NDOs, process perceived link failures, handle Interest-lifetime expirations, and send NACKs according to SIFAH. Optional steps and data in algorithms are indicated by “[o]”.

The algorithms used to describe SIFAH were not designed to take into account such issues as load balancing of available paths, congestion-control, or the forwarding of an Interest over multiple concurrent paths. For simplicity, it is assumed that all Interest retransmissions are carried out on an end-to-end basis (i.e., by the consumers of content) rather than routers. Hence, routers do not attempt to provide any “local repair” when a neighbor fails or a NACK to an Interest is received; the origin of an Interest is in charge of retransmitting it after receiving a NACK for any reason. Interest retransmissions could also be done by routers. The design and analysis of Interest retransmission strategies implemented by routers or by content consumers is a topic deserving further study.

Algorithm 3 implements HFAR. Router determines that an Interest can be forwarded because Condition 1 in HFAR is satisfied (Line 9 of Algorithm 3), or an Interest can be aggregated because Condition 2 of HFAR is satisfied (Line 17 of Algorithm 3). Content requests from local content consumers are sent to the router in the form of Interests stating infinite hop counts to content, and each router knows which neighbors are remote and which are local.

1:  function Process Interest
2:  INPUT: , , , ;
3:  if then send to
4:  if   then
5:     if  then
6:        if  then
7:           % Route failed for : send to ; drop
8:        else
9:           if  then
10:              % Interest can be forwarded: call Forwarding Strategy()
11:           else
12:               % Interest may be traversing a loop: send to ;   drop
13:           end if
14:        end if
15:     else
16:        % There is a PIT entry for :
17:        if   then
18:            % Interest can be aggregated:
19:        else
20:            % Interest may be traversing a loop: send to ;  drop
21:        end if
22:     end if
23:  end if
24:  end function
Algorithm 3 SIFAH Processing of Interest at router

The Maximum Interest Life-time () assumed by a router before it deletes an Interest from its PIT should be large enough to preclude an excessive number of retransmissions. On the other hand, should not be too large to cause the PITs to store too many Interests for which no NDO messages or NACKs will be sent due to failures or transmission errors. A few seconds would be a viable value for . In practice, however, the consumer submitting an Interest to its local router could provide an initial value for the Interest lifetime estimated over a number of Interests submitted for NDOs in the same NDO group corresponding to a large piece of content (e.g., a movie). This is specially the case given our assumption that Interest retransmissions are carried out by content consumers, rather than by routers.

Algorithm 4 describes a simple forwarding strategy in which router simply selects the first neighbor in the ranked list of neighbors stored in the FIB for prefix that satisfies the first condition in HFAR (Line 4 of the algorithm). More sophisticated strategies can be devised that attain load balancing among multiple available routes towards content and can be close to optimum (e.g., [19]). In addition, the same Interest could be forwarded over multiple paths concurrently, in which case content could be sent back over some or all the paths that the Interest traversed successfully. To be effective, however, these approaches should require the adoption of a loop-free multi-path routing protocol in the control plane (e.g., [9, 11]). In this context, the control plane establishes valid multi-paths to content prefixes using long-term performance measures, and the data plane exploits those paths using HFAR and short-term performance measurements, without risking the long delays associated with backtracking due to looping.

1:  function Forwarding Strategy
2:  INPUT: , , , ;
3:  for each by rank do
4:     if  then
5:         create ; ; ; ; ; forward to ; return
6:     end if
7:  end for
8:  % No neighbor can be used in : for each send to
9:  end function
Algorithm 4 SIFAH Interest forwarding at router

Algorithm 5 outlines the processing of NDO messages received in response to Interests. A router accepts an NDO received from a neighbor if it has a PIT entry waiting for the content and the NDO message came from one of the neighbors over which the Interest was sent (Line 5 of the algorithm). The router forwards the valid NDO to any neighbor that requested it and deletes the corresponding PIT entry. A router stores an NDO it receives optionally (Step 7 of Algorithm 5). The caching of NDOs is done according to the caching strategy used in the network, which can be path-based or edge-based [5], for example. However, SIFAH works independently of the caching strategy adopted in the network.

1:  function Process NDO message
2:  INPUT: , , , received from ;
3:  [o] verify ;
4:  [o] if verification fails then drop
5:  if  then
6:     for each do send to ;
7:     [o] store the content with name in ;
8:     delete
9:  else
10:     drop
11:  end if
12:  end function
Algorithm 5 Process NDO message from at router

Algorithm 6 shows a simple approach to handle the case when a PIT entry expires with no NDO or NACK being received. Given that routers do not initiate Interest retransmissions, router simply sends NACKs to all neighbors from which it received Interests for . A more sophisticated approach would be needed for the case in which routers must provide Interest retransmissions in a way similar to on-demand routing protocols that support local repair of route requests.

1:  function Process Interest Life-time Expiration
2:  INPUT: , ;
3:  for each do send
4:  delete
5:  end function
Algorithm 6 Process Interest life-time expiration

Algorithm 7 states the steps taken to handle NACKs. Router forwards the NACK it receives for to all those neighbors from whom it received Interests for and deletes the Interest entry after that. Supporting Interest retransmissions by routers would require a more complex approach for the handling of NACKs.

1:  function Process NACK
2:  INPUT: , ;
3:  if   then
4:     drop
5:  else
6:     if then drop ;
7:     if   then
8:        for each do send ;
9:        delete
10:     end if
11:  end if
12:  end function
Algorithm 7 Process NACK at router
1:  function Process Link Failure
2:  INPUT: ;
3:  for each  do
4:     if  then
5:         ; if then delete ;
6:     end if
7:     if  then
8:         ;
9:        if  then
10:           for each  do
11:               send
12:           end for
13:           delete
14:        end if
15:     end if
16:  end for
17:  end function
Algorithm 8 Process failure of link at router

Algorithm 8 lists the steps taken by a router in response to the failure of connectivity with a neighbor. Reacting to the failure of perceived connectivity with a neighbor over which Interests have been forwarded could be simply to wait for the life-times of those Interests to expire. However, such an approach can be very slow reacting to link failures compared to using Algorithm 8. The algorithm assumes that the control plane updates to reflect any changes in hop counts to name prefixes resulting from the loss of connectivity to one or more neighbors. For each Interest that was forwarded over the failed link, router sends a NACK to all neighbors whose Interests were aggregated.

4.5 Examples of SIFAH Operation

Figures 2(a) to (d) illustrate how SIFAH operates using the same example used in Figure 1. Figures 2(a) and (b) address the case in which the control plane establishes multiple paths to each name prefix but does not guarantee loop-free routing tables. Figures 2(c) and (d) illustrate how SIFAH operates when single-path routing is used.

The pair of numbers next to each link outgoing from a node in Figure 2(a) indicates the hop count to through a neighbor and the ranking of the neighbor in the FIB. The example assumes that: (a) routers execute a routing protocol that does not enforce loop-free FIBs; and (b) the ranking of neighbors is determined independently at each router using some data-plane strategy based on the perceived performance of each path and interface. It should be noted that the distance value of a path need not be directly proportional to the hop-count value of the path shown in the figure.

Let the tuple (: ) indicate a neighbor, its hop count and its ranking. In Figure 2(a), lists (: 7, 1), (: 7, 2), and (: 9, 3), which is shown in green font. Similarly, states (: 8, 1); states (: 10, 2), (: 8, 1), and (: 6, 3); states (: 7, 1), (: 9, 2), and (: 9, 3); and states (: 8, 1) and (: 8, 2). Some of the FIB entries for , and are shown in black font.

Figure 2: Interest looping is avoided or detected with SIFAH

In Figure  2(b), router originates an Interest for and sends to . Router receives the Interest from router at time and, given that , it accepts the Interest because it has at least one neighbor that satisfies HFAR. Router sends to because it is the highest-ranked neighbor satisfying HFAR. Router aggregates at time , because it sent at time and . Router receives the Interest from at time ; accepts it because it has at least one neighbor that satisfies HFAR (); and sends to because is the highest-ranked neighbor of that satisfies HFAR. This is an example that Interests are forwarded along loop-free paths if SIFAH is used and the FIBs maintained by routers have consistent information, even if some of the multi-paths implied in the FIBs involve loops. The next section proves this result in the general case.

Figure 2(c) shows the hop count values stored in the FIBs for name prefix when single-path routing is used. Each router has a single next hop and one hop count for each prefix listed in its FIB. Router updates its FIB to reflect the failure of link at time , while router sends an Interest to router requesting . Routers have inconsistent FIB states for while routing updates propagate and Interests are being forwarded.

As shown in Figure 2(d), router must send to , because and HFAR is not satisfied. In turn, when receives the NACK from , it must forward to and to . Eventually, the routing protocol running in the control plane makes routers and change the hop count to in their FIBs to reflect the failure of link . At that point, a retransmission of the Interest from would state and would make forward to .

5 Correctness of SIFAH

The following theorems show that SIFAH enforces correct Interest forwarding and aggregation, and constitutes a safe Interest forwarding strategy. The results are independent of whether the network is static or dynamic, the specific caching strategy used in the network (e.g., at the edge or along paths traversed by NDO messages [5]), or the retransmission strategy used by content consumers after experiencing g a timeout or receiving a NACK from attached routers. SIFAH ensures that Interests cannot be incorrectly propagated and aggregated along loops without meeting routers that detect the incorrect forwarding and hence send NACKs in return.

Theorem 3

Interest loops cannot occur and be undetected in a network in which SIFAH is used.


Consider a network in which SIFAH is used. Assume for the sake of contradiction that nodes in a loop of hops send and possibly aggregate Interests for along , with no node in detecting the incorrect forwarding of any of the Interests sent over the loop.

Given that exists by assumption, must send to node for , and must send to node . For , let denote the value of when node sends to node , with . Let denote the value of when when node sends to node , with .

Because no node in detects the incorrect forwarding of an Interest, each node in must aggregate the Interest it receives from the previous hop in or it must send its own Interest as a result of the Interest it receives from the previous hop in . This implies that must accept before expires for , and must accept before expires.

According to SIFAH, if aggregates , then it must be true that . Similarly, if aggregates , then it must be the case that .

On the other hand, if sends to as a result of receiving from , then it must be true that for . Similarly, if sends to as a result of receiving from , then .

It follows from the above argument that, for to exist when each node in the loop follows SIFAH to send Interests asking for , it must be true that and for . However, this is a contradiction, because it implies that for . Therefore, the theorem is true.

The proof of Theorem 3 can be augmented to account for Interest forwarding strategies based on complex distance values rather than hop counts.

To be safe, an Interest forwarding strategy must ensure that either an NDO message with the requested content or a NACK is received within a finite time by the consumer who issues an Interest. The following theorem shows that this is the case for SIFAH, independently of the state of the topology or the fate of messages.

Theorem 4

SIFAH ensures that an NDO message for name or a NACK is received within a finite time by any consumer who issues an Interest for NDO with name .


Consider being issued by consumer at time . The forwarding of Interests assumed in SIFAH is based on the best match of the requested NDO name with the prefixes advertised in the network. Furthermore, according to Algorithm 3, a router sends back an NDO message to a neighbor that sent an Interest for NDO only if has an exact match of the name in its content store. According to Algorithm 5, a router that receives an NDO message in response to an Interest it forwarded must forward the same NDO message. Hence, the wrong NDO message cannot be sent in response to an Interest. There are three cases to consider next: (a) there are no routes to the name prefix of the requested NDO, (b) the Interest traverses an Interest loop, or (c) the Interest traverses a simple path towards a router that can reply to the Interest.

Case 1: If there is no route to , then it follows from the operation of SIFAH (Algorithm 4) that a router issues a NACK stating that there is no route. That NACK is either forwarded successfully back to or is lost due to errors or faults. In the latter case, it follows from Algorithms 6 and 8 that a router must send a NACK back towards stating that the Interest expired or the route failed.

Case 2: If is forwarded along an Interest loop and does not reach any node with a copy of , then it follows from Theorem 3 that the Interest must either reach some router that detects the incorrect forwarding of the Interest and must issue a NACK in response, or the Interest is dropped due to faults or transmission errors before reaching such router .

If reaches a router that detects the loop and issues , then according to SIFAH (Algorithm 7), every router receiving the NACK originated by router from the neighbor to whom the Interest was sent must relay the NACK towards . Hence, if no errors or faults prevent the NACK from reaching , the consumer receives a NACK stating that an Interest loop was found.

On the other hand, if either the Interest traversing an Interest loop or the NACK it induces at some router is lost, it follows from Algorithms 6 and 8 that a router between and router must send a NACK towards indicating that the Interest expired or that the route failed. Accordingly, consumer must receive a NACK within a finite time after issuing its Interest in this case.

Case 3: If the Interest traverses a simple path towards a router that advertises or has a content store containing , then the Interest must either reach or not.

If the Interest is lost and does not reach , then it follows from Algorithms 6 and 8 that a router between and router must send a NACK towards indicating that the Interest expired or that the route failed. As a result, must receive a NACK originated by some router between and .

If the Interest reaches , then that router must either send the requested NDO back, or (in the case that advertises and does not exist) issue a NACK stating that does not exist. According to Algorithms 5 and 7, the NDO message or NACK originated by is forwarded back towards along the reversed simple path traversed by the Interest. If no fault or errors occur between and , it follows that the theorem is true for this case. Alternatively, if the NDO or NACK originated by is lost due to faults or errors, it follows from Algorithms 6 and 8 that a router between and router must send a NACK towards indicating that the Interest expired or that the route failed.

6 Performance Comparison

We compare SIFAH with NDN and the original CCN forwarding strategy in terms of the storage complexity of the approaches; the average time that a PIT entry remains in the PIT waiting for an NDO message or a NACK to be received in response, which we call PIT entry pending time; the end-to-end delay experienced by content consumers in receiving either the content they request or negative feedback; and the number of entries in the PITs maintained by content routers.

The storage complexity of each approach provides an indication of the storage overhead induced by the type of information required for routers to detect Interests loops. The simulation results we present on PIT entry pending times, end-to-end delays, and PIT sizes should be viewed simply as indications of the negative effects that undetected Interest loops have on the performance of NDN and CCN, and the fact that they can be completely avoided using SIFAH.

6.1 Storage Complexity

There is a large difference in the storage overhead incurred with the NDN forwarding strategy compared to SIFAH.

In SIFAH, router uses only the value of to determine whether the Interest it receives from may be traversing an Interest loop, and does not store . Hence, the PIT storage size for SIFAH is

where is the number of pending Interests in when SIFAH is used, is the number of bits used to store , and is the average storage required to maintain information about the incoming and outgoing neighbors for a given Interest. For a given NDO with name , the amount of storage needed to maintain the incoming and outgoing neighbors is

The NDN forwarding strategy requires each router to store the list of different nonces used to denote valid Interests for a given NDO name . With each nonce being of size and router having up to neighbors that send valid Interests for an NDO, the PIT storage size for NDN is

where is the number of pending Interests in when NDN is used. Hence, even if is the same as , the amount of additional PIT storage needed in NDN over SIFAH is

A maximum hop count of 255 for an Interest is more than enough. Hence, with the size of a nonce in NDN of four bytes, the savings in PIT storage obtained with SIFAH compared to NDN is . This represents enormous savings of RAM in large networks. Furthermore, because the NDN forwarding strategy may not detect loops when Interests are aggregated, many Interest entries in PITs may have to be stored until their lifetimes expire. Accordingly, can be much smaller than . This is confirmed by the simulation results presented subsequently.

The additional FIB storage overhead in SIFAH compared to the NDN forwarding strategy consists of storing the hop count information for each prefix from each neighbor. This amounts to at router , where is the number of neighbors of router and is the number of entries in . Given that and are of the same order and