Field
The present disclosure relates generally to information-centric networks (ICNs). More specifically, the present disclosure relates to an ICN architecture that replaces the Pending Interest Table with a Data Answer Touting Table (DART).
Related Art
The proliferation of the Internet and e-commerce continues to fuel revolutionary changes in the network industry. Today, a significant number of information exchanges, from online movie viewing to daily news delivery, retail sales, and instant messaging, are conducted online. An increasing number of Internet applications are also becoming mobile. However, the current Internet operates on a largely location-based addressing scheme. The two most ubiquitous protocols, the Internet Protocol (IP) and Ethernet protocol, are both based on end-host addresses. That is, a consumer of content can only receive the content by explicitly requesting the content from an address (e.g., IP address or Ethernet media access control (MAC) address) that is typically associated with a physical object or location. This restrictive addressing scheme is becoming progressively more inadequate for meeting the ever-changing network demands.
Recently, information-centric network (ICN) architectures have been proposed in the industry where content is directly named and addressed. Content-Centric Networking (CCN) and Named Data Networking (NDN) are the leading Interest-based ICN approaches. In CCN, instead of viewing network traffic at the application level as end-to-end conversations over which content travels, content is requested or returned based on its unique name, and the network is responsible for routing content from the provider to the consumer. Note that content includes data that can be transported in the communication system, including any form of data, such as text, images, video, and/or audio. A consumer and a provider can be a person at a computer or an automated process inside or outside the CCN. A piece of content can refer to the entire content or a respective portion of the content. For example, a newspaper article might be represented by multiple pieces of content embodied as data packets. A piece of content can also be associated with metadata describing or augmenting the piece of content with information, such as authentication data, creation date, content owner, etc.
In existing interest-based ICN approaches, including CCN and NDN, routers (or nodes in the network) need to maintain a Pending Interest Table (PIT) in order to store the Interest state, including the interfaces from which Interests for specific named data objects (NDOs) are received and the interfaces over which such Interests are forwarded. The PIT allows NDOs that satisfy Interests to follow the reverse path back to the original requester while hiding the identity of the original requester. However, as the number of Interests handled by a router grows, so does the size of the PIT, which can be many orders of magnitude larger than the size of traditional routing tables because routers handle far more Interests than the number of routers in a network.
The terms used in the present disclosure are generally defined as follows (but their interpretation is not limited to such):
One embodiment of the present invention provides a router in an information-centric network (ICN). The router includes a receiving module configured to receive an interest for a piece of content. The interest indicates a name associated with the piece of content. The router further includes an interest-processing module configured to: determine whether the interest can be forwarded; in response to determining that the interest can be forwarded to a second router, obtain a label that is specific to the second router; and attach the label to the interest. The router also includes a forwarding module configured to forward the interest to the second router with the attached label.
In a variation on this embodiment, the forwarding module is further configured to send a response to the interest in response to the interest-processing module determining that the interest cannot be forwarded.
In a further variation, the interest-processing module is configured to determine that the interest cannot be forwarded based on one of: the piece of content cannot be found, no route can be found to a destination router advertising the piece of content, and the interest is traversing a loop; and the response sent by the forwarding module includes a negative acknowledgment.
In a further variation, the interest further indicates a hop count to a destination router advertising the piece of content, and the interest-processing module is configured to determine that the interest is traversing the loop based on routing information stored in the router and the hop count.
In a further variation, the interest-processing module is configured to determine that the router has a copy of the piece of content based on the name associated with the piece of content, and the response sent by the forwarding module includes a copy of the piece of the content.
In a further variation, the forwarding module is configured to: send the response to an originator of the interest along a reverse path traversed by the interest, or send the response to the originator of the interest along a path that is different from the reverse path traversed by the interest.
In a further variation, the interest further indicates a nonce specific to an originator of the interest. The router further comprises a response-processing module configured to: perform a lookup in a locally stored table for a matching entry based on the nonce, with the matching entry including one or more tuples and a respective tuple indicating a neighboring router and a label specific to the neighboring router; select a tuple from the one or more tuples; and label the response using the label indicated by the selected tuple. The forwarding module is configured to send the labeled response to a router indicated by the selected tuple.
In a variation on this embodiment, the interest further includes a previous label. The interest-processing module is configured to: perform a lookup in a locally stored table for a matching entry based on the previous label, with the matching entry indicating the second router and the label that is specific to the second router; and in response to the matching entry not being found, generate and store an entry in the local table, with the stored entry indicating the second router and the label that is specific to the second router.
In a further variation, attaching the label to the interest comprises replacing the previous label with the label that is specific to the second router.
In the figures, like reference numerals refer to the same figure elements.
Embodiments of the present invention provide a CCN system that implements Data Answer Routing Table (CCN-DART). More specifically, routers implementing CCN-DART no longer need to maintain a Pending Interest Table (PIT). Instead, a CCN-DART router maintains a data-answer routing table (DART), which is similar to a label-swapping table used in a label-switching network. An Interest states the name of the requested content, a hop count, a destination-and-return token (dart), and a nonce. The hop count is used to ensure correct Interest loop detection. The dart is used by forwarding routers to leave a trace of the path traversed by the Interest using local identifiers of the previous hop and the current hop. It changes on a hop-by-hop basis and is route-specific. The dart allows a named data object (NDO) or a negative acknowledgment (NACK) to be sent back to the content requester, without disclosing the source of the Interest. The nonce of an Interest is used by a content producer or a caching router to associate multiple paths traversed by Interests with the same originating router, without knowing the identity of that router. The nonces enable routers to forward Interests and NDOs or NACKs over the multiple paths established between content consumers and content providers, rather than requiring reverse-path forwarding.
In general, CCN uses two types of messages: Interests and Content Objects. An Interest carries the hierarchically structured variable-length identifier (HSVLI), also called the “name,” of a Content Object and serves as a request for that object. If a network element (e.g., router) receives multiple Interests for the same name, it may aggregate those Interests. A network element along the path of the Interest with a matching Content Object may cache and return that object, satisfying the Interest. The Content Object follows the reverse path of the Interest to the origin(s) of the Interest.
As mentioned before, an HSVLI indicates a piece of content, is hierarchically structured, and includes contiguous components ordered from a most general level to a most specific level. The length of a respective HSVLI is not fixed. In content-centric networks, unlike a conventional IP network, a packet may be identified by an HSVLI. For example, “abcd/bob/papers/ccn/news” could be the name of the content and identifies the corresponding packet(s), i.e., the “news” article from the “ccn” collection of papers for a user named “Bob” at the organization named “ABCD.” To request a piece of content, a node expresses (e.g., broadcasts) an Interest in that content by the content's name. An Interest in a piece of content can be a query for the content according to the content's name or identifier. The content, if available in the network, is sent back from any node that stores the content to the requesting node. The routing infrastructure intelligently propagates the Interest to the prospective nodes that are likely to have the information and then carries available content back along the reverse path traversed by the Interest message. Essentially the Content Object follows the breadcrumbs left by the Interest message, thus reaching the requesting node.
In accordance with an embodiment of the present invention, a consumer can generate an Interest for a piece of content and forward that Interest to a node in network 180. The piece of content can be stored at a node in network 180 by a publisher or content provider, who can be located inside or outside the network. For example, in
In network 180, any number of intermediate nodes (nodes 100-145) in the path between a content holder (node 130) and the Interest generation node (node 105) can participate in caching local copies of the content as it travels across the network. Caching reduces the network load for a second subscriber located in proximity to other subscribers by implicitly sharing access to the locally cached content.
In conventional CCNs or NDNs, each node (also called as a router) maintains three major data structures, including a Forwarding Information Base (FIB), a Content Store (CS), and a Pending Interest Table (PIT). The forwarding plane uses information stored in these three tables to forward Interests toward nodes advertising copies of requested content, and to send NDOs or other responses back to consumers who requested them over reverse paths traversed by the Interests.
FIB is used to forward Interest packets toward potential source(s) of matching Content Objects. Typically, a routing protocol is used to populate the FIB among all nodes in the network. In conventional CCNs, the FIB entries are often indexed by the name prefixes, with each entry including a physical address of at least one face to which the matching Interest should be forwarded. In NDNs, the FIB entry for a name prefix also contains a stale time after which the entry could be deleted, the round-trip time through the interface, a rate limit; and status information stating whether it is known or unknown that the interface can or cannot bring data back. While forwarding Interest messages, longest-prefix-match lookups of names are performed at the FIB to find a matching entry.
Content Store (CS) is similar to the buffer memory used in an IP router. More particularly, CS temporarily buffers Content Objects that pass through this node, allowing efficient data retrieval by different consumers. When a router receives an Interest packet, it first checks whether there is a matching Content Object in its content store prior to issuing an Interest upstream.
Pending Interest Table (PIT) serves as a cache of Interest state. The PIT keeps track of neighbor to which NDO messages or control messages (e.g., NACKs) should be sent back in response to Interests. This preserves upstream and downstream network flow, allows Interest to not disclose their sources, and enables Interest aggregation. In CCN, only Interest packets are routed. In NDN, a PIT entry can include a vector or one or more tuples, with one tuple for each nonce processed for the same NDO name. Each tuple states the nonce used, the incoming faces, and the outgoing faces. Each PIT entry also has a lifetime, which typically is larger than the estimated round-trip time to a node having the requested NDO.
When a router receives an Interest, it checks whether there is a match for the content requested in its CS. In CNN, exact Interest-matching mechanism is used to find the matching content. If a match to the Interest is found, the router sends back an NDO over the reverse path traversed by the Interest. If no match is found in the CS, the router checks the PIT for an entry for the same content. In NDN where nonces are used to identify Interests, if the Interest states a nonce that differs from those stored in the PIT entry for the requested content, the router aggregates the Interest by adding the incoming face and the nonce to the PIT entry without forwarding the Interest. On the other hand, if the same nonce in the Interest is already listed in the PIT entry for the requested content, the router sends a NACK over the reverse path traversed by the Interest, indicating a loop has been detected. In CCN, aggregation is done if the Interest is received from a face that is not listed in the PIT entry for the requested content, and a repeated Interest received from the same face is simply dropped.
If the router does not find a match in its CS and PIT, the router forwards the Interest along a route (or multiple routes) listed in its FIB for the best prefix match. In NDN, a router can select a face to forward an Interest if such a face is known to bring content and its performance ranked higher than other faces that can also bring content. A router performs the ranking of the faces independently of other routers.
As discussed previously, maintaining a PIT and checking for matches in the PIT can be inefficient, because the size of the PIT grows in the order of the number of Interests handled by the routers, and such a number can be orders of magnitude more than the number of routers in a network. Hence, it is desirable to design an Interest-based ICN system that does not rely on PIT to return NDOs to their original requesters.
CCN with Data Answer Routing Table (CCN-DART): Principle
The design of CCN-DART is based on the following observations. First, network simulation shows that, as the capacity of Content Stores increases, content caching makes the occurrence of Interest aggregation extremely rare. The inter-arrival times of Interest for the same content and round-trip times (RTTs) between consumers and Content Stores storing the requested content are such that content is available at caches by the time subsequent Interests requesting the same content arrive. This is the case even when the simulation parameters are set to favor Interest aggregation. On the other hand, independent of CS sizes, the number of PIT entries grows dramatically with the Interest submission rate, and Interest aggregation can lead to undetected Interest loops.
Second, the number of routers in a network is orders of magnitude smaller than the number of named data objects (NDOs), and thus the number of Interests requesting them. Hence, maintaining forwarding state based on the routes going through a router can be orders of magnitude smaller than maintaining forwarding state based on the Interests traversing the router.
Third, a correct Interest-forwarding strategy can be based on an ordering of the routers that forward a given Interest, rather than attempting to identify each Interest uniquely.
Lastly, there is no inherent reason to require reverse-path forwarding to be used to forward NDOs or NACKs sent in response to Interests, provided that the control plane supports multipath routing to name prefixes and the proper forwarding state is maintained efficiently.
A number of assumptions can be made in the description of CCN-DART. It can be assumed that Interests are retransmitted only by the originating consumers, rather than by the relaying routers. Routers are assumed to know which interfaces are neighboring routers and which interfaces are local consumers, and forward Interests on a best-effort basis. Furthermore, routers are assumed to use exact matching of Interest.
During operation, CCN-DART uses Interests, control messages (e.g., NACKs), and data objects (e.g., NDOs) to implement the exchange of content among nodes. More specifically, destination-and-return tokens (darts) and Interest nonces are used to enable correct forwarding of Interests, NDOs, and NACKs. The darts are local identifiers that can uniquely denote routes established between source and destination routers. The nonces are global identifiers that can associate two or more routes established between the same source and destination routers.
An Interest sent by a node k requesting NDO n(j) is denoted I[n(j),hI(k),IDI(k),dartI(k)], which states the requested NDO name (n(j)), a hop count (hI(k)) from node k to the nearest instance of name prefix n(j)* that is the best match for n(j), a nonce (IDI(k)) created by the originating router of the Interest, and a dart (dartI(k)) used to establish anonymous routes back to the sources of the Interest. In some embodiments, the nonce and the dart can be included in a header field of the Interest packet, in a way that is similar to a label being part of the datagram header in label-swapping networking. A content object sent by router i in response to Interest I[n(j),hI(k),IDI(k),dartI(k)] is denoted D[n(j),sig(j),IDI(i),dartI(i)], which states the name (n(j)) of the NDO being sent, a signature payload (sig(j)) used optionally to validate the content object, the nonce (IDI(i)), and the dart (dartI(i)) to be used to forward the NDO. On the other hand, the control message (NACK) sent by router i in response to Interest I[n(j),hI(k),dartI(k)] is denoted NI[n(j),CODE,IDI(i),dartI(i)], where CODE states the reason for sending the NACK. Possible reasons for sending a NACK include: (a) an Interest loop is detected, (b) no route is found toward the requested content, (c) no content is found, and (d) the DART entry expired.
To implement the forwarding of Interests, NDOs and NACKs, a CCN-DART router maintains five tables: an optional content store (CSi), a FIB (FIBi), a data-answer routing table (DARTi), an origin nonce table (ONTi), and a destination nonce table (DNTi). CS' is the same as in conventional CCNs or NDNs. CSi lists the NDOs stored in local caches, and is indexed by the names of the NDOs. In some embodiments, the optional content store can be replaced with an optional requested content table (RCT), which not only serves as an index of local content but also keeps track of local requests for remote content. An entry in the RCT can include the name of the content, a pointer to the local storage where the content is stores, and a number of identifiers identifying a list of local consumers (if any) that have requested the content. The RCT could be implemented as two separate indexes, one for local content and one for requests for remote content.
To better understand CCN-DART, the concepts of predecessor, successor, and anchor are introduced here. At router i, a predecessor for an Interest regarding name prefix n(j)* is a router that forwarded an Interest to router i regarding NDO n(j), which matches name prefix n(j)*, and a successor for Interests related to n(j)* is a router to which router i forwards an Interest regarding NDO n(j), which matches name prefix n(j)*. An anchor of a prefix is a router that has advertised the prefix.
Anchor ai(a, p) is the anchor (router a) for which the forwarding state is established at router i. Predecessor pi(a, p) is the predecessor (router p) of the route to a. Predecessor dart pdi(a, p) equals the dart received in Interest from p toward anchor a. Successor si(a, p) is the name of router s, which is selected by router i to forward Interests from p toward anchor a. Successor dart sdi(a, p) is the dart included in Interests sent toward anchor a through router s. Hop count hi(a, p) is the number of hops to anchor a through successor s when the dart entry was established. LTi(a, p) is the lifetime of the DART entry. The lifetime of a DART entry is decremented while the router stores it. A DART entry is deleted when its lifetime reaches zero. In contrast to the lifetime of an entry in a PIT, the lifetime of a DART entry is not a critical design parameter. An entry in a DART can remain in storage for a long period (e.g., many seconds) in the absence of topology changes. Furthermore, the removal of a DART entry causes only a minor slowdown of some Interests. In a stable network, it is most likely that the replacement of a DART entry states the same information as the erased entry.
CCN-DART implements a distance-based forwarding strategy to prevent Interest looping. Such a forwarding strategy ensures that a router accepts an Interest from router k only if the router determines that it is closer to the prefix through at least one next hop neighbor than k when k forwards the Interest. A detailed description of the distance-based forwarding strategy that can be used to prevent Interest loops can be found in the co-pending patent application Ser. No. 14/572,608 (Attorney Docket No. PARC-20140178US01), entitled “SYSTEM AND METHOD FOR DISTANCE-BASED INTEREST FORWARDING,” by inventor Jose J. Garcia-Luna-Aceves, filed 16 Dec. 2014, the disclosure of which is incorporated herein by reference in its entirety.
When routers implementing CCN-DART receive Interests, they first determine whether to accept the Interests using an Interest-forwarding rule (IFR), which states that a router i can accept an Interest I[n(j),hI(k),IDI(k),dartI(k)] from a neighbor k if the following condition is satisfied:
∃v(vεSn(j)*ihI(k)>h(i,n(j)*,v)).
One can use a tuple (v, h, r) to indicate a neighbor, its hop count, and its ranking. Note that such a tuple can be entries listed in the FIB under name prefix n(j)*. For example, FIBnode 504 can list tuples (node 506,4,1), (node 510,4,2), and (node 508,6,3). Similarly, FIBnode 502 can list a tuple (node 504,5,1); FIBnode 506 can list tuples (node 508,6,1), (node 504,5,2), and (node 512, 3,3); and FIBnode 508 can list tuples (node 506,5,1) and (node 504, 5,2). Note that partial FIB entries for nodes 510 and 512 are also shown in
Router 506 receives I[n(j),hI(node 504)=4,IDI,dartI(node 504)] at time t2, and accepts it because 4=hI(node 504)>h(node 506,n(j)*,node 512)=3. Router 506 then uses router 512 as the next hop for the Interest because router 512 is the highest-ranked neighbor that satisfies the IFR. The route traversed by the Interest is indicated by a dashed line following time sequence t1→t2→t3. Note that each router along the way swaps the dart included in the Interest to ensure that the returning NDO can follow the reverse path of the Interest.
Similarly, the Interest generated by router 508 is forwarded to router 512 toward n(j) (the route is indicated by a different dashed line following time sequence t3→t4→t5) without traversing a loop, because each relaying router must satisfy the IFR.
When the link between router 604 and router 610 fails, router 606 updates its FIB to reflect the link failure at time t0, as shown in
As in NDN and CCN, routers in CCN-DART maintain routes to anchors of name prefixes, and populate their routing tables using a routing protocol operating in the control plane.
In NDN and CCN, the response to an Interest takes the reverse path traversed by the Interest. The path is incrementally stored in the PITs of the routers along the path. In CCN-DART, there are no PITs in routers; instead, the routers maintain DARTs, ONTs, and DNTs. DARTs and ONTs can allow Interest responses to be sent back to the correct consumers over reverse paths of the Interests. On the other hand, DNTs can enable the forwarding of an NDO message of NACK back to the Interest source over a path that may not be the reverse path of the Interest.
The dart mappings stored in DARTs are similar to the label mappings in the packet-switching networks. These mappings can be used to allow multiple Interests asking for NDOs associated with the same name prefix to be multiplexed in the same route segments between the originating routers and an anchor of the prefix or a cache site of the content. In addition to the darts, which are locally unique identifiers, routers can also create globally unique nonces to unambiguously associate local consumers with Interests sent on their behalf without revealing the identities of the local consumers.
In this disclosure, it is assumed that the nonce table at a router has been populated with all the nonces locally assigned to local consumers, and that DART entries are silently deleted when their lifetime expires. For convenience, it is also assumed that an anchor of a name prefix stores all the NDOs associated with the prefix in its CS. In addition, it is assumed that the control plane updates the FIB to reflect any changes in hop counts to prefixes resulting from topology changes. For example, if router i detects that connectivity to a neighbor k is lost, it deletes all entries in DARTi for which k is the predecessor or the successor of a path toward any anchor.
When router i receives an Interest from local consumer c, it checks its content store for the requested content and returns, if any, a matching NDO (line 3 in
If there is a matching FIB entry, router i uses the highest ranked neighbor and forwards an Interest (lines 9-15 in
If the content is not cached locally, router i determines whether a DART entry exists for the dart stated in the Interest from router k, i.e., if a predecessor dart is the same as the dart stated in the Interest. The existence of a matching entry in DART means that the IFR has been satisfied by a previous Interest on the same route to an anchor of the prefix and the existing mapping can be used. Consequently, such a DART entry can be used to forward Interest. More specifically, the successor specified by the DART entry is the router to which the Interest is forwarded, and the dart included in the forwarded Interest is the successor dart specified by the DART entry (line 9 in
If there is no matching DART entry found, router i needs to find a successor for the received Interest and create a DART entry. A NACK will be sent if no entry can be found in FIBi for n(j)* (line 11 in
In the algorithm shown in
As discussed previously, Interests can be forwarded to the same anchor over multiple paths, with each path being identified by a different set of dart mappings. The router that responds to the Interest stores in its DNT the mappings between the nonces included in the Interests and the routes over which the Interests were received (identified by the neighbor routers and darts in the Interests). Given that nonces are assigned with a low probability of collision, an NDO message or NACK can be sent by the responding router over a path that is different from the one traversed by the Interest. This can enable load balancing, which is beyond the scope of this disclosure.
NDN supports multicasting by the reverse path forwarding (RPF) of responses to Interests over paths traversed by aggregated Interests. Interests serve the dual purpose of maintaining multicast forwarding trees (MFT) and pacing multicast sources. CCN-DART also supports multipoint communication using the RPF approach, but separates the establishment of an MFT from the mechanisms used to pace a source or disseminate multicast data over the tree.
CCN-DART uses Content Stores and multicast data answer routing tables (MDART) to maintain MFTs. A single dart can be used to denote all the predecessors and successors in the MFT of a group at each router. This means that a single dart can be used to label all the branches of the MFT of a multicast group. The dart used for multicast group name g(j) is denoted as d(g(j)) and can be made part of the group name to simplify its dissemination.
A router with local receivers of a multicast group maintains the mapping of the names of local receivers to the name of the multicast group in its RCT. The MDART at router i is denoted by MDARTi and is indexed by the names of the multicast groups for which the router forwards traffic. The entry for multicast group with name g(j) in MDARTi states: the dart of the group (d(g(j))), the successor selected by router i to join the group, the set of routers (predecessors) that requested to join g(j) through router i, and the hop-count distance to the anchor of g(j) when router i established the MDART entry for the group (hi(g(j))).
If router i has local receivers for group g(j), then it sends a join request (JR), denoted as JR[g(j),hJ(i),IDJ(i),dartJ(i)], where hI(i)=hi(g(j)) and dartJ(i)=d[g(j)]. The forwarding of JRs is based on FIB entries and is similar to the forwarding of Interests. A relay router can forward a JR towards the anchor of g(j) in two cases. If no MDART entry exists and IFR is satisfied, an MDART entry is created for the group. If an MDART entry exists, then the router simply adds a new predecessor for the group in the existing MDART entry. Negative acknowledgments may be sent if no routes to g(j) are found, the IFR is not satisfied, or MDART entries become invalid due to topology changes.
Multicast data dissemination or pacing of multicast sources is beyond the scope of this disclosure.
Faces 1102-1106 can include not only physical interfaces but also application processes capable of sending and receiving packets, including Interests and NDOs. Interest-processing module 1108 is responsible for processing the Interests received on the various faces. In some embodiments, Interest-processing module 1108 determines whether to accept an incoming Interest based on the aforementioned Interest-forwarding rule (IFR). If the Interest is accepted, Interest-processing module 1108 checks the DART maintained in database 1116 to find a dart mapping, and swaps the dart included in the Interest based on the mapping. Interest-processing module 1108 may further create a nonce (if the Interest is received from a local consumer) for the Interest. Forwarding module 1110 is responsible for forwarding packets, such as Interests or NDOs, to the faces. In some embodiments, forwarding module 1110 forwards the Interests/NDOs based on the dart mapping. Control-message generation module 1114 generates control messages, which can include different NACK messages, when Interest-processing module 1108 rejects or drops an Interest. In some embodiments, control-message generation module 1114 generates NACK messages under various conditions, including but not limited to when: an Interest loop is detected, no route is found toward the requested content, no content is found, and the corresponding DART entry expires. A NACK message in response to an Interest for name n(j) is denoted as NI[n(j),CODE,IDI(k),dartI(k)], where CODE states the condition under which the NACK is sent. NDO/NACK processing module 1112 is responsible for processing NDO/NACK messages received in response to Interests. In some embodiments, NDO/NACK processing module 1112 checks the DART maintained in database 1116 to find a dart mapping, and swaps the dart included in the NDO/NACK message based on the mapping. Database 1116 stores the data structures needed for CCN-DART operation: the FIB, the DART, the ONT, and the DNT. Database 1116 optionally stores a Content Store.
In
Router 1202 has two content consumers (cp and cq). At router 1202, Interests originated from router 1202 on behalf of consumers cp and cq are labeled with nonces IDp1202 and IDq1202, respectively. Similarly, router 1214 uses nonce IDw1214 to label Interests it originates on behalf of local consumer cw.
The DART mappings maintained at router 1202 show that the predecessor and predecessor dart pair [1202,1202(i)] maps to the successor and successor dart pair [1204,1202(i)]. At router 1204, [1202,1202(i)] maps to [1206,1204(j)]; and at router 1206, [1204,1204(j)] maps to [1208,1206(i)]. At router 1208, the DART entry for the content only specifies the predecessor and predecessor dart pair [1206,1206(i)]. Note that indices i, j, k, m, u shown in
Similarly, DART mappings shown in
Dashed arrow 1226 indicates the route from router 1214 to anchor 1208, i.e., (node 1214, node 1204, node 1206, node 1208). The set of DART mappings for this route is shown italicized in
All the Interests originated by consumers cp, cq, and cw regarding content advertised by anchor 1208 can be routed toward router 1208 using the same few darts shown in
In addition to supporting correct Interest forwarding and correct reverse-path forwarding of NDO messages and NACKs using DARTs and ONTs, CCN-DART can also support forwarding of NDOs and NACKs to routers originating Interests over paths not traversed by the Interests. As shown in
As discussed previously, the CCN with Data Answer Routing Table (CCN-DART) system implements a forwarding strategy for Interest-based ICN that does not require pending Interest tables (PITs) to operate. CCN-DART operates by requiring that FIBs store the next-hop neighbors and the hop count through such neighbors to named content, and by having each Interest state the name of the content requested, the hop count from the relaying router to the content, a nonce that is unique to the consumer requesting the content, and a destination and return token (dart) that is unique to the route traversed by the Interest. Interests are not aggregated, and Interest loop detection is based on distances to content prefixes. The forwarding states of the Interests are maintained by the DARTs kept at each router. A DART entry maps the incoming face and the outgoing face of Interests traversing a segment of the network. The state of a DART is a function of routes traversed toward routers that advertise content prefixes, rather than the routes traversed by individual Interests requesting specific NDOs, as in conventional CCN or NDN networks. In addition, the nonce included allows responses to Interests to be sent back to the originating router of the Interests over paths that are not the reverse path of the Interests.
Using DARTs to maintain the forwarding states of Interests shows greater advantages over the approach that keeps the per-Interest forwarding state in the PIT, especially when the rate of content requests is high. The size of the PITs can grow dramatically as the rate of content requests increases, whereas the size of the DARTs can remain substantially constant with respect to the content request rates. In fact, when the content-request rate is low, the average number of entries in the DARTs may be larger than the average number of entries in the PITs. This is because the DART entries are kept for long periods of time (e.g., seconds) regardless of whether or not the routes they denote are actually used by Interests and their responses. On the other hand, a PIT entry is deleted immediately after the corresponding Interest is satisfied. However, as the content request rate increases, the size of a PIT can be more than 10 times the size of a DART, because a given DART entry can be used for many Interests, whereas a different PIT entry is needed for each Interest. In general, it can be expected that the cost of maintaining DART entries that may not be used at light loads can be compensated for by the significant reduction in the signaling delays derived from many Interests forwarded using existing DART entries at high loads.
In some embodiments, modules 1332, 1334, 1336, and 1338 can be partially or entirely implemented in hardware and can be part of processor 1310. Further, in some embodiments, the system may not include a separate processor and memory. Instead, in addition to performing their specific tasks, modules 1332, 1334, 1336, and 1338, either separately or in concert, may be part of general- or special-purpose computation engines.
Storage 1330 stores programs to be executed by processor 1310. Specifically, storage 1330 stores a program that implements a system (application) for On-demand Content Exchange with Adaptive Naming. During operation, the application program can be loaded from storage 1330 into memory 1320 and executed by processor 1310. As a result, system 1300 can perform the functions described above. System 1300 can be coupled to an optional display 1380 (which can be a touchscreen display), keyboard 1360, and pointing device 1370, and can also be coupled via one or more network interfaces to network 1382.
The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. The computer-readable storage medium includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed.
The methods and processes described in the detailed description section can be embodied as code and/or data, which can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and/or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.
Furthermore, methods and processes described herein can be included in hardware modules or apparatus. These modules or apparatus may include, but are not limited to, an application-specific integrated circuit (ASIC) chip, a field-programmable gate array (FPGA), a dedicated or shared processor that executes a particular software module or a piece of code at a particular time, and/or other programmable-logic devices now known or later developed. When the hardware modules or apparatus are activated, they perform the methods and processes included within them.
The above description is presented to enable any person skilled in the art to make and use the embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.