Partial path extension scheme for mobile content source in content-centric networking (CCN)

Abstract

Due to rapid developments in mobile technology as well as various multimedia features like messaging, browsing, and streaming, user-created mobile contents are increasing, both in terms of quantity and quality, and at the same time are shared in real time. To get into step with such movements, new content-centric networking (CCN) has appeared. However, CCN has not taken the effect of consumer device movements into consideration. So, this paper proposes a partial path extension scheme to provide lower communication overhead, shorter download time, and lower network resource consumption in mobile consumer environments.

1 Introduction

According to the analysis of the patterns of Internet usage, one significant point has been shown, i.e., the Internet usage has shifted away from web browsing to content dissemination [1–3]. That is, content users do not care where and how to obtain a piece of content. Instead, they make much of how fast and reliably the requested content can be accessed. However, to meet such trends, the current Internet inherently requires additional operations and control overheads, such as multi-staged address resolution, add-on security, frequent location updates, and congestion control [4, 5]. Many research efforts have attempted to adjust and redesign the current Internet’s content exchange model causing a lot of signaling overhead, especially in the case of mobile devices. So, efficient networking devices have considered using a radically different approach, namely information-centric networking [6, 7] where content queries and data are routed based on the content name itself instead of the IP address. Typical examples are Data-Oriented Networking Architecture (DONA) [8], Publish-Subscribe Internet Routing Paradigm (PSIRP) [9], Network of Information (NetInf) [10], and content-centric networking (CCN) [11]. PSIRP and NetInf utilize a two-phase resolution with mapping of the content name to the locator and then routing to the content source. That is, they require a resolution server to find the location of the content and can be incrementally deployed on the current Internet. Meanwhile, DONA and CCN exploit one-phase resolution with direct content name-based routing to a content source. That is, they do not need any additional resolution servers. Among these proposals, this paper focuses on the CCN scheme because it has been regarded as a very promising solution to new global-scale networking. When compared to the current TCP/IP communication model, CCN has the following characteristics:

• Named data: CCN treats small chunks of named data, not host-addressed packets.

• Receiver-centric model: A device wishing to retrieve some content data sends interest packets. At most, one data packet is delivered in response to an interest.

• In-network caching: A piece of named content may be retrieved from any nodes that have previously owned a copy.

• Built-in security: CCN signs the binding between the content’s name and the content itself at inception. It signs content at packet level.

However, there has been little consideration for the effects due to device movement in CCN environments. Especially, content source mobility brings about big problems such as frequent routing updates and low routing aggregation. That is, a mobile content source has to update routing tables of all relevant content routers, which is very slow. Moreover, many mobile content sources would pollute the routing tables with specific prefixes, tarnishing the advantages of prefix aggregation using the hierarchical name structure.

In this paper, we present a partial path extension-based mobility management scheme for mobile content sources acting as content sources in CCN to reduce network convergence time and the number of routing table entries. The basic idea of the mobility management is to partially update routing information only between the original domain of the mobile content source and the domain where it currently stays.

The rest of the paper is organized as follows. Section 2 briefly describes CCN messages and their delivery and then shows the effect of mobile consumer devices acting as the content source in CCN environments. Section 3 presents the design and detailed description of the proposed path extension-based CCN scheme. Then, we present the evaluation results and then make a conclusion.

2 Related works

This section covers the details regarding the data transmission procedure in CCN environments and relevant problems due to device movements.

2.1 Overview of CCN protocols

The CCN protocol is composed of two packet types, namely interest and data packets [11, 12]. The interest packet carries a name that identifies the desired data. That is, the interest packet acts as a query for content. The data packet is utilized to carry the actual content. The interest packet contains a unique identifier (content name), a set of parameters such as the order preference (selector), and a random nonce value to prevent the packet from looping. The most important field among them is the content name. Figure 1 shows an example of the content name. Each name prefix has a hierarchical structure, and the “/” character represents the delimiter between different components.

Fig. 1

Example of content naming in CCN

Each CCN device basically has three functional blocks for content delivery: content store (CS), pending interest table (PIT), and forwarding information base (FIB). The FIB has the role to forward interest packets toward the potential content holder(s) of matching data. It is almost similar to an FIB table of an IP router. The CS looks like the content cache. It stores data packets to be used in the future by other content requesters. So, CCN can provide localized transmission near content requesters. This is the main difference from the IP router that forgets a packet after it has been forwarded. The PIT keeps track of interests forwarded toward the content source(s) so that returned data can be sent back to its requester(s). PIT entries are eliminated as soon as they have been consumed to forward a matching data packet. PIT entries for interests that never find a matching data are eventually timed out and naturally eliminated.

The content retrieval in CCN is as follows. When an interest packet arrives on any face, a lookup at the CS is done on the basis of its content name. If the matched content data is found in the CS, then the data packet is served that consumes the interest packet. If the content is not found in the CS, it is compared against the PIT to check whether it has already received another request for the same content. If a match is found in the PIT, then the CCN device adds the face on which the new interest packet arrived. When the data packet that consumes the interest arrives at the device, it is replicated and sent out on all faces in the PIT entry for the content. If the content name matches neither the CS nor the PIT, then the FIB is referenced to determine the outgoing face where the interest packet should be forwarded. Moreover, an entry is added to the PIT for the forwarded interest packet. From the added entry, the received data packet can be sent back to the original content requester. That is, data packet processing is relatively simple since data is not routed but simply follows the chain of PIT entries back to the original requestor.

2.2 Problems due to mobile sources in CCN

Even though CCN is efficient for content sharing, there may be cases in which such inherent benefits are lost if content consumers/sources are mobile devices.

For mobile CCN clients (i.e., mobile content consumers/requesters), there may be an unnecessary network resource consumption [13]. Basically, CCN assumes the identical path for interest and data packets. That is, data packets from the content source are routed back along the path that interest packets are traversed. During the content sharing phase, the old content router does not know the movement of the mobile consumer device. So, data packets are unnecessarily transmitted around the previous location of the mobile consumer device. Interest packets are repeatedly transmitted after handover to again request data packets that were already requested at the previous location but not yet received. Meanwhile, as data packets stored near the old location are not available until the routing table update, the data packets re-requested after handover may be delivered from the remotely located content source, not from nearby CCN devices with cached content. To find locally cached content, significant routing updates are required. Hence, it results in the high complexity of CCN routing on hierarchical identifiers and long latency during device movement. To solve such problems, [13] proposed a smooth content migration mechanism that can provide both low control overhead and low packet loss regardless of device movement.

Contrary to client mobility, the content source mobility in CCN creates a complicated situation. As CCN requires content name-based routing information for content delivery, errors in routing information may cause interest packets to be misrouted. Therefore, when the movement of content sources happens, all relevant content routers should update their routing information for the successful delivery of future/ongoing content requests toward mobile content sources (MCSs). However, it takes much time to update the routing tables of all content routers. So, the interest packets may not be reached if the route to the MCS has not made changes to the new location; hence, the interest packets that have not yet been satisfied are unnecessarily sent again because content requesters do not know whether no data receptions are brought about by either a network problem like congestion/network failure or route breaks due to node movement.

3 Proposed CCN partial path extension scheme

The point of the proposed scheme is to reduce both routing update overhead and network convergence time during content source movement in CCN environments.

The proposed scheme starts when a MCS sends a “prefix registration (PREG)” message to its home domain content router (CR) to inform its movement event. At that time, a MCS locally announces its name prefix to advertise its presence. Intermediate CRs forward the PREG message toward the original domain of the MCS. Through the exchange of prefix registration and “prefix registration acknowledgement (PACK)” messages, the extended path can be configured from the original domain to the new domain where the MCS is currently located. That is, an extended path to the MCS can be configured to provide seamless reachability.

The operation of a partial path extension (PPx) scheme is largely made up of four steps. The detailed procedures are as follows:

• Step 1. Movement indication: A MCS detects whether to change network status by using underlying physical link information or network address information. Generally, MCS enters the network via the wireless access points. It is assumed that the initialization data is provided to the MCS by the wireless access points that would contain a relevant domain prefix information. From the initialization data, the MCS can decide whether a prefix registration message is required. Upon detecting a change in network location through the comparison of domain name prefix, MCS sends a PREG message to announce its movement event. The PREG message includes the signed information to validate whether the PREG originator is valid (as shown in Fig. 2). The “Preg” component announces that this message is a type of prefix registration, and therefore, it has to be delivered to the target name domain.

  Fig. 2

  

  Prefix registration message format

• Step 2. Path extension: The CR receiving a PREG message compares its name prefix domain with that of the PREG message. If its domain prefix is different from that of the PREG packet, the CR just forwards the PREG packet to the content source’s original domain based on the FIB reference. Otherwise, it does not forward the PREG packet and then transmits the PACK message to the MCS. Then, each intermediate CR draws out the name prefix information from the received PREG message and then checks its routing table about an entry for the MCS. The path related to the MCS is created and then is marked as “tentative.”

  On receiving the PREG message, the CR serving the name prefix or the MCS checks if the original initiator of the PREG message is valid. If the signature is proved to be valid, the CR sends a PACK message indicating that the prefix update is successful and then the name prefix of the MCS is recorded in its routing table. When receiving the PACK message, intermediate CRs look up the routing table again. If the tentative entry exists that corresponds with the name prefix in the received PACK message, intermediate CRs update the status of the path entry as “valid.” At this time, the subsequent interest packets toward the MCS can be delivered through the path that is established by the exchange of PREG and PACK. Moreover, if intermediate CRs receiving the PACK message already have another entry for the relevant name prefix, they change the status of the old entry from “valid” to “stale.” The extended path information is not exchanged among neighboring CRs during the routing update phase to prevent increasing the number of routing entries.

• Step 3. Interest redirection: After a while, a content consumer may request a content data to the MCS. The interest packets are delivered toward the original domain of the MCS. One of the CRs in the original domain of the MCS can deliver the interest packets from the lookup of its routing table toward the domain where the MCS is currently located. That is, CRs can deliver all interest packets to the MCS through a normal CCN forwarding procedure.

• Step 4. Path update and revocation: In case that the MCS moves away into another prefix domain, the previous partial route has to be updated. The establishment procedure for a new extended path is identical to the path extension phase in step 2. Meanwhile, in order to keep the minimal routing information and prevent wrong routing, the previous extended path information has to be revoked. On receiving the new PREG message, the CR in the original prefix domain of the MCS sends a “prefix revocation (PREV)” message through the old routing information. Each intermediate CRs receiving the PREV message deletes the relevant routing entry with “stale” status (as shown in Fig. 3). For example, after receiving the PACK message, CR4 in Fig.6, which already has one FIB entry for the MCS, changes the status of the old entry from “valid” to “stale.” Then, CR4 removes the stale entry with the reception of the PREV message.

  Fig. 3

  

  Prefix registration update and revocation

Meanwhile, the proposed scheme seems to have a similarity with the Mobile IPv6 (MIPv6) method [14, 15]. The main difference between them is for data packet processing. MIPv6 needs to encapsulate and decapsulate packets toward the MCS. That is, for the requested data transfers, all content request packets must reach the MCS. Contrary to that, the proposed PPx scheme is that intermediate nodes between the CR (CR _H ) at MCS’s original domain and foreign domain can serve the requested content through the content caching functionality. This may allow stable content delivery even in the case when wireless channels of MCS are prone to high bit error rates, high bandwidth variation, high interferences, and so on. Especially, as most of interest packets relevant to data packets of MCS are relayed through CR _H , CR _H can directly deliver cached content to the content requestors thanks to CR _H ’s cache, which leads to the traffic offloading at MCS. Moreover, from CCN’s inherent security characteristics, the processing for location update can be done without additional security mechanisms. That is, in MIPv6, binding update and binding acknowledgement messages must be protected by IP security using Encapsulating Security Payload (ESP) protection with a non-NULL payload authentication algorithm [14, 15] while the proposed scheme can do the validity check of the “PREG” message through the embedded signature.

4 Performance evaluations

To assess the improvements of the proposed partial path extension scheme, we created a series of simulations where the mobility speed of a mobile device was varied. We constructed a flat random network topology consisting of multiple CRs (i.e., 40 to 200), in which each CR is connected to one wireless router. The route refresh is assumed to be triggered by new name prefix advertisement. Content consumers and a MCS are initially placed at a random position. As the simulation proceeds, a MCS moves according to the smooth random mobility model because it makes user movements smoother and more realistic than other models [16]. A MCS initially selects its speed among 9.7, 11.1, and 12.5 m/s with probabilities of $\frac {1}{5}$, $\frac {3}{5}$, and $\frac {1}{5}$, respectively. The speed is updated at a time interval which follows an exponential distribution with a mean of μ _v =25 s. Whenever a new speed is determined, the MCS accelerates or decelerates until the new speed is reached or a new speed is decided again. From [16], the maximum acceleration and deceleration speeds are obtained as 2 and −4 m/s², respectively. It also decides whether to change its movement direction or whether to keep it with probabilities of $\frac {1}{6}$ and $\frac {5}{6}$, respectively, at a time interval with an exponential distribution and a mean of $\mu _{\phi _{\text {new}}}=50$ s.

The delivery ratio is the ratio of the number of interest packets received by the MCS over the expected number of total interest packets sent by all content consumers. It is presented as a function of the mobility speed of MCS and the network size in Fig. 4. For MIPv6, we did an ICMP request delivery test on MCS. It shows that when the network size increases, the proposed scheme is better than a basic CCN scheme and a Mobile IPv6 scheme because it provides faster route reachability and content caching at intermediate nodes. That is, on switching to another network, the basic CCN scheme re-issues all route reconfiguration for the name prefix of the MCS. Only after that, it can execute one-to-one exchange of interest and data packets with content requesters. Meanwhile, through content caching capability at intermediate nodes, the proposed scheme may provide seamless delivery during the movement of a MCS.

Fig. 4

Delivery ratio

Figure 5 shows the results obtained when measuring the time required by the proposed and basic CCN schemes to converge. The time until the basic CCN achieves stability varies deeply depending on both the number of CRs which form that network and the route refresh interval. That is, as the number of CRs increases, it takes long latency that every CR knows the route to arrive to the MCS. However, the proposed scheme keeps this latency more or less constant until it reaches stabilization. That is due to the fact that the route reachability is achieved in a short amount of time through a partial route update that the extended route information is managed only along CRs that constitute the path between the original location and the new one. The event-driven routing refresh for MCS can also reduce the route convergence time. Meanwhile, the extended CCN shows longer convergence latency than Mobile IPv6, which is due to the fact that the extended CCN has additional processing to revoke the old extended path.

Fig. 5

Route convergence time

Fig. 6

Router processing overhead

The processing overhead is to measure the number of received interest packets in CRs including the original content request and retransmitted interest plus extra location update packets. It is presented as a function of the number of nodes in Fig. 6. As the number of nodes increases, the processing load of basic CCN sharply grows compared to the proposed extended CCN. Even though the extended CCN reduces any retransmitted interest packets by shorter route update latency, it requires extra control messages for path updates and revocations. However, it can provide very low processing load thanks to the partially extended path updates. In basic CCN, however, the number of retransmitted interest packets increases due to longer route update latency. Moreover, the basic CCN needs to invoke routing updates in the whole CCN networks whenever an access network change happens. That is, the extended CCN can restrict the increasing amount of processing load at CRs only between a home domain and a moved domain.

Finally, let us focus on the impact of common content cache of the extended CCN scheme on content delivery in Fig. 7. For comparison, at initial time, we run the simulation, wherein a set of contents are shared at least one time. That is, all contents of MCS are shared through the CR at its original domain and then some content data may be stored at the CR. It is shown how many performance gains the proposed scheme can get over the MIPv6 and basic CCN schemes through the cached content at the CR acting as the common content relay point. In MIPv6, any content request packets for MCS have to be delivered to the MCS. So, it cannot avoid any service disruption because it has to look for a new path whenever device handover happens. Even though the proposed scheme has a similar operation with MIPv6, it can provide an improvement over MIPv6 for a couple of reasons. First, the CCN path extension shortens the number of hops of interest through the content caching functionality of CR at MCS’s original domain. Second, it can keep content download time stable irrespective of MCS movement as cached content can be retrieved from the CR at MCS’s original domain. These contribute to keep content download time a little uniform.

Fig. 7

Impact of content caching in terms of content delivery latency

5 Conclusions

This paper makes the following main points. First, it shows that the frequent network change of mobile devices causes the performance degradation of content sharing in CCN environments. The full routing update architecture of CCN prevents mobile content sources from providing seamless service reachability. It may result in long download latency and high resource consumption. Second, it presents a partial path extension scheme to compensate for the effects of content source movement. The mobile content source announces its movement to content routers on the path between the original domain and the new domain through a prefix registration and update. From that, it can save resource consumption (in terms of high interest delivery ratio and low routing overhead) of CCN devices and reduce content retrieval latency by limiting the range of routing update only to the path between the original location and the current location when compared to the basic CCN approach. This feature is important in mobile-centric content-based networks since mobile content sources inherently cause dynamic topology change, high resource consumption, and low route aggregation.