1 Introduction
-
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.
2 Related works
2.1 Overview of CCN protocols
2.2 Problems due to mobile sources in CCN
3 Proposed CCN partial path extension scheme
-
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.×
-
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.×