CONTENT-CENTRIC NETWORK ON-DEMAND DISTANCE VECTOR ROUTE METHOD

Abstract

The present invention relates to a content-centric network on-demand distance vector route method, comprising: a request source node of a required request route broadcasts a route request packet CCN_RREQ to other nodes in a network, and starts a route discovery process; after a target node receives the route request packet CCN_RREQ, replying with a route reply packet CCN_RREP; after the request source node receives the route reply packet CCN_RREP returned by the target node, establishing a path between the request source node and the target node according to the content of the route reply packet CCN_RREP.

Claims

1. A content-centric network on-demand distance vector route method, comprising: step 1), broadcasting, by a request source node that needs to request a route, a route request packet CCN_RREQ to other nodes in a network to start a route discovery process, wherein the route request packet CCN_RREQ is carried in an interest packet of the content-centric network, and comprises at least the following information: a hash value of a requested content, an address of the request source node and a sequence number of the request source node; step 2), replying, by a target node after receiving the route request packet CCN_RREQ, with a route reply packet CCN_RREP, wherein the route reply packet CCN_RREP is carried in a data packet of the content-centric network, and comprises at least the following information: the hash value of the requested content, an address of a content provider and a sequence number of the content provider; and step 3), establishing, by the request source node after receiving the route reply packet CCN_RREP returned by the target node, a path between the request source node and the target node according to a content contained in the route reply packet CCN_RREP.

2. The content-centric network on-demand distance vector route method of claim 1, further comprising: step 4) deleting an invalid path with a route error packet CCN_RRER when a node is invalid or a route is invalid due to an update of a cache, wherein the route error packet CCN_RRER comprises at least: an unreachable requested content, a number of entries of the unreachable requested content, an identification of an unreachable content provider and a sequence number of the unreachable content provider.

3. The content-centric network on-demand distance vector route method of claim 1, wherein the step 2) comprises: step 201), receiving, by a node, the route request packet CCN_RREQ; step 202), checking, by the node, whether the route request packet CCN_RREQ is transmitted by the node itself, that is, whether the request source node in the route request packet CCN_RREQ is the node; if yes, performing the next step, otherwise turning to step 204); step 203), discarding the route request packet CCN_RREQ, and ending operations; step 204), checking, by the node, whether a received route request packet CCN_RREQ has been received previously; if yes, performing the step 203), otherwise per the next step; step 205), checking, by the node, whether a content requested by the route request packet CCN_RREQ exists in its own cache table; if yes, the node being the content provider, and performing the next step, otherwise turning to step 207); step 206), replying with the route reply packet CCN_RREP to the node that transmits the route request packet CCN_RREQ; step 207), reviewing, by the node, whether an entry corresponding to a valid path of the content requested by the route request packet CCN_RREQ exists in a route table; if yes, performing the step 206), otherwise performing the next step; and step 208), caching and broadcasting the route request packet CCN_RREQ.

4. The content-centric network on-demand distance vector route method of claim l, wherein the step 3) comprises: step 301), receiving, by a node, the route reply packet CCN_RREP; step 302), judging, by the node, whether a valid route from the node to a target hash is saved in its own route table; if yes, performing the next step, otherwise turning to step 307); wherein the target hash refers to the hash value of the content contained in the route reply packet CCN_RREP, and the valid route refers to a route that a lifetime of a route entry does not expire; step 303), judging, by the node, whether the valid route to a content target in the route reply packet CCN_RREP of a same content provider exists in its own route table; if yes, performing the next step, otherwise turning to step 306); step 304), comparing a sequence number of a destination node of a respective route entry in a route table and the sequence number of the destination node in the route reply packet CCN-RREP; if the sequence number of the destination node in the route reply packet CCN_RREP is more recent, turning to step 307), otherwise performing the next step; step 305) performing step 307) if the sequence number of the destination node in the route reply packet CCN_RREP is the same as the sequence number of the destination node of the respective route entry in the route table, but has a less number of hops; otherwise turning to step 308); step 306), judging whether a multi-path table item of a content in the route table is already saturated; if yes, turning to step 308), otherwise performing the next step; step 307), adding or updating the respective route entry, forwarding the route reply packet CCN_RREP to a previous hop node according to an hate rest table of CNN, and ending operations; and step 308), discarding the route reply packet CCN_RREP, and ending the operations.

5. The content-centric network on-demand distance vector route method of claim 2, wherein the step 4) comprises: step 401), detecting, by a previous hop node of a destination node in a path, whether the route is invalid; if the node when forwarding the interest packet finds that a distance from itself to the content provider is 1, the node is the previous hop node of the destination node, and the node starts a timeout timer when sending the interest packet; step 402), judging, by the node, that the path is already invalid, if the timeout timer has already expired, but the previous hop node of the destination node does not receive the data packet sent by a corresponding content provider as expected; step 403), marking, by the previous hop node of the destination node, a corresponding path as invalid, and sending the route error packet CCN_RRER to its pervious hop node in the corresponding path to notify the previous hop node that the path is already invalid; and step 404), reviewing first, by the node after receiving the route error packet CCN_RRER, whether a valid path of the corresponding content provider exists; if yes, marking the corresponding path as invalid, and sending the route error packet CCN_RRER to the previous hop node in the corresponding path to notify the node that the path is already invalid; if no, discarding the route error packet CCN_RRER.

6. The content-centric network on-demand distance vector route method of claim 2, wherein the step 2) comprises: step 201), receiving, by a node, the route request packet CCN_RREQ; step 202), checking, by the node, whether the route request packet CCN_RREQ is transmitted by the node itself, that is, whether a request source node in the route request packet CCN_RREQ is the node; if yes, performing the next step, otherwise turning to step 204); step 203), discarding the route request packet CCN_RREQ, and ending operations; step 204), checking, by the node, whether a received route request packet CCN_RREQ has been received previously; if yes, performing the step 203), otherwise performing the next step; step 205), checking, by the node, whether a content requested by the route request packet CCN_RREQ exists in its own cache table; if yes, the node being the content provider, and performing the next step, otherwise turning to step 207); step 206), replying with the route reply packet CCN_RREP to the node that transmits the route request packet CCN_RREQ; step 207), reviewing, by the node, whether an entry corresponding to a valid path of the content requested by the route request packet CCN_RREQ exists in a route table; if yes, performing the step 206), otherwise performing the next step; and step 208), caching and broadcasting the route request packet CCN_RREQ.

7. The content-centric network on-demand distance vector route method of claim 2, wherein the step 3) comprises: step 301), receiving, by a node, the route reply packet CCN_RREP: step 302), judging, by the node, whether a valid route from the node to a target hash is saved in its own route table; if yes, performing the next step, otherwise turning to step 307); wherein the target hash refers to the hash value of a content contained in the route reply packet CCN_RREP, and the valid route refers to a route that a lifetime of a route entry does not expire; step 303), judging, by the node, whether the valid route to a content target in the route reply packet CCN_RREP of a same content provider exists in its own route table; if yes, performing the next step, otherwise turning to step 306); step 304), comparing the sequence number of a destination node of a respective route entry in the route table and the sequence number of the destination node in the route reply packet CCN-RREP; if the sequence number of the destination node in the route reply packet CCN_RREP is more recent, turning to step 307), otherwise performing the next step; step 305) performing step 307) if the sequence number of the destination node in the route reply packet CCN_RREP is the same as the sequence number of the destination node of the respective route entry in the route table, but has a less number of hops; otherwise turning to step 308); step 306), judging whether a multi-path table item of a content in the route table is already saturated; if yes, turning to step 308), otherwise performing the next step; step 307), adding or updating the respective route entry, forwarding the route reply packet CCN_RREP to a previous hop node according to an Intesrst table of CNN, and ending operations; and step 308), discarding the route reply packet CCN_RREP, and ending the operations.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0040] FIG. 1 is a schematic diagram of a data structure of a route request packet CCN_RREQ;

[0041] FIG. 2 is a schematic diagram of a data structure of a route reply packet CCN_RREP;

[0042] FIG. 3 is a schematic diagram of a data structure of a route error packet CCN_RRER;

[0043] FIG. 4 is a flow diagram for a target node replying with the route reply packet CCN_RREP in a method according to the present invention;

[0044] FIG. 5 is a flow diagram for establishing a path between a request source and a target node in a method according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0045] Now the present invention is further described in conjunction with the accompanying drawings.

[0046] A content-centric network on-demand distance vector route method according to the present invention mainly adopts three route control messages, which are respectively: a route request packet CCN_RREQ a route reply packet CCN_RREP and a route error packet CCN_RRER, wherein the route request packet CCN_RREQ may be carried in an interest packet of the content-centric network, and include the following information: a hash valve of a requested content, an address of a requesting source node, a sequence number of the requesting source node or the like; the route reply packet CCN_RREP may be carried in a data packet of the content-centric network, and include the following information: a hash value of the requested content, an address of a content provider, a sequence number of the content provider and the like.

[0047] The above described three route control messages play an important role in the route method according to the present invention. Data structures of these packets are explained further below.

[0048] FIG. 1 is a schematic diagram of a data structure of a route request packet CCN_RREQ, wherein Type refers to a type of the packet, a value thereof is set as 1. P is a flag bit that only a content provider may reply with the CCN-RREQ packet, meaning that only the content provider may respond to this CCN-RREQ packet and an intermediate node which has a route but has no content cannot respond to this CCN-RREQ packet. U is a sequence number-unknowable flag bit, which means that the sequence number of the content provider is unknown for the present node. Reserved is a reserved bit, the value thereof is 0 currently. Hop Count represents the number of hops from an originating node for the CCN-RREQ packet to a node processing the packet. RREQ ID is an ID of the CCN-RREQ packet, and generated by the node generating the CCN packet, and used together with a subsequent Originator ID. Originator ID is an ID of a node generating the CCN packet. Target hash is a hash value of the requested content. Provider ID is an ID of a content provider known by the present node. Provider Sequence Number is a serial number of the above described Provider ID. The last two items may be null if there is no known content provider.

[0049] FIG. 2 is a schematic diagram of a data structure of a route reply packet CCN_RREP, wherein Type refers to a type of the packet, a value thereof is set as 2. P is a content provider flag bit, which means that the CCN-RREP packet is transmitted by the content provider. S, F and R are reserved bits, the values thereof are 0 currently. Hop Count represents the number of hops from a node generating the CCN-RREP packet to a node processing the packet. Provider ID is an ID of the node generating the CCN-RREP packet. Provider Sequence Number is a sequence number of a generating node associated with the route. Lifetime is a lifetime of a route in ms. Target hash is a hash value of a required content.

[0050] FIG. 3 is a schematic diagram of a data structure of a route error packet CCN_RRER, wherein. Type is a type of the packet, the value thereof is set as 2. N is a “don't delete” flag bit. T is a target hash-unreachable flag bit. L is a link interruption flag bit. R is a reserved bit, the value thereof is 0 currently. Target Count is the number of entries of unreachable hash values in the message. Unreachable Provider ID is an ID of an unreachable content provider. Unreachable Provider Sequence number is a sequence number associated with the above-described content provider. Target Hash is a hash value of unreachable content.

[0051] Specific implementation steps of the method according to the present invention are explained below in detail.

[0052] Step 1), broadcasting, by a node when needing to request a route (this node is also referred to as a request source), a route request packet CCN_RREQ to other nodes in a network to start a route discovery process;

[0053] step 2), replying, by a target node after receiving the route request packet CCN_RREQ, with a route reply packet CCN_RREP;

[0054] step 3), establishing, by the request source after receiving the route reply packet CCN_RREP returned by the target node, a path between the request source and the target node according to content contained in the packet.

[0055] In step 1), the circumstances that the node needs to request a route comprise: when a node needs a route to a hash value of a certain content, and no corresponding valid route entries exists in a route table of the node.

[0056] Referring to FIG. 4, the step 2) further comprises:

[0057] step 201), receiving, by a node, the route request packet CCN_RREQ:

[0058] step 202), checking, by the node, whether the route request packet CCN_RREQ is transmitted by the present node on its own, that is, whether a request source node in the route request packet CCN_RREQ is the present node; if yes, performing the next step, otherwise turning to step 204);

[0059] step 203), discarding the route request packet CCN_RREQ, ending operations;

[0060] step 204), checking, by the node, whether the received route request packet CCN_RREQ has been received previously; if yes, performing step 203), otherwise performing the next step;

[0061] step 205), checking, by the node, whether the content requested by the route request packet CCN_RREQ (i.e. content corresponding to the hash value of the requested content in the route request packet CCN_RREQ) exists in its own cache table: if yes, the node being the content provider, and performing the next step, otherwise turning to step 207);

[0062] step 206), replying with the route reply packet CCN_RREP to the node that transmits the route request packet CCN_RREQ;

[0063] step 207), reviewing, by the node, whether an entry corresponding to a valid path of the content requested by the route request packet CCN_RREQ exists in the route table; if yes, performing step 206), otherwise performing the next step;

[0064] step 208), caching and broadcasting the route request packet CCN_RREQ; the step of caching the route request packet CCN_RREQ can prevent the identical CCN_RREQ packet from being received by the node later, and the step of broadcasting the route request packet CCN_RREQ aids other nodes in the network to receive the route request packet CCN_RREQ.

[0065] Referring to FIG. 5, the step 3) further comprises;

[0066] step 301), receiving, by a node, the route reply packet CCN_RREP; the node may be an arbitrary node between a destination node to the request source node;

[0067] step 302), judging, by the node, whether a valid route from the present node to a target hash is saved in its own route table; if yes, performing the next step, otherwise turning to step 307); wherein the target hash refers to the hash value of the content contained in the route reply packet CCN_RREP; the valid route refers to the route that a lifetime of the route entry does not expire;

[0068] step 303), judging, by the node, whether a valid route to a content target in the route reply packet CCN_RREP of the same content provider exists in its own route table; if yes, performing the next step, otherwise turning to step 306);

[0069] step 304), comparing a sequence number of the destination node of a respective route entry in the route table and a sequence number of the destination node in the route reply packet CCN_RREP, if the sequence number of the destination node in the route reply packet CCN_RREP is more recent, turning to step 307), otherwise performing the next step;

[0070] step 305), per step 307) if the sequence number of the destination node in the route reply packet CCN_RREP is the same as the sequence number of the destination node of the respective route entry in the route table but has a less number of hops; otherwise turning to step 308);

[0071] step 306), judging whether a multi-path table item of the content in the route table is statured; if yes, turning to step 308), otherwise performing the next step;

[0072] step 307), adding or updating a respective route entry, forwarding the route reply packet CN_RREP to the previous hop node according to an Intesrst table of CCN, and ending operations;

[0073] step 308), discarding the route reply packet CCN_RREP, and ending operations.

[0074] As an optional implementation, the method according to the present invention further comprises:

[0075] step 4), deleting an invalid path with a route error packet CCN_RRER when the node is invalid or the route is invalid due to the update of a cache.

[0076] This step specifically comprises:

[0077] step 401), detecting, by a previous hop node of the destination node in the path, whether the route is invalid; if a node when forwarding an interest packet finds that the distance from itself to the content provider is 1, the node is the previous hop node of the destination node, and the node starts a time-out timer when sending the interest packet;

[0078] step 402), judging, by the node, that this path is already invalid if the time-out timer has already expires and the previous hop node of the destination node has not received a data packet sent by a corresponding content provider as expected;

[0079] step 403), marking, by the previous hop node of the destination node, a corresponding path as invalid, and sending the CCN_RRER packet to its previous node in the corresponding path to notify the previous hop node that this path is already invalid;

[0080] step 404), reviewing first, by the node after receiving the CCN_RRER packet, whether a valid path of the corresponding content provider exists; if yes, marking the corresponding path as invalid and sending the CCN_RRER packet to the previous hop node in the corresponding path to notify the node that this path is already invalid; if no, discarding the CCN_RRER packet.

[0081] Finally, it should be noted that the aforementioned embodiments are only used for illustrating, rather than limiting the technical solution of the present invention. Although the present invention has been described in detail with reference to the embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solution of the present invention without departing from the scope and spirit of the technical solution of the present invention, and thereby should all be covered by the scope of the claims of the present invention.