Method and system for facilitating forwarding a packet in a content-centric network

The present invention generally relates to a communication network, and more specifically, the present invention relates to a method and a system thereof for packet transfer in a content central network.

In current IP (Internet Protocol) based naming methods, the identification of the host that stores the content is often implicit in the name that indicates the corresponding content. For example, "" http: //www.amazon.com/index.html "" is discovered by contacting the machine "www.amazon.com". The related technique is described in Patent Document 1.

<p><patcit num="1"><text>U.S. Patent Application No. 12/332560</text></patcit></p>

<p num="0004"> However, this contact requires a domain name server (DNS) to translate a human-readable host name into an IP address (eg, 209.34.123.178). No method has yet been presented for forwarding packets without knowing the destination address in existing networking devices (such as IP routers and Ethernet® switches).</p>

<p num="0005"> One embodiment provides a system that facilitates packet transfer. During operation, the system receives a packet with a hierarchically structured variable-length identifier (henceforth, hierarchically structured variable-length identifier: HSVLI). The system then performs a lookup on the forwarding engine based on at least the HSVLI of the packet. The transfer engine is implemented using a hardware-based fully matched search engine, a hardware-based longest prefix matched search engine, or both. Performing a search involves searching for a match for at least one of the content store (storage device), pending interest table (pending interest table), and transfer information base. The system further makes a transfer decision based on the search.</p><p num="0006"> In other embodiments, the HSVLI presents a piece of content and includes adjacent components that are hierarchically structured and ordered from the most general level to the most specific level. In addition, the length of each identifier is not fixed.</p><p num="0007"> Also, in one embodiment, the transfer engine provides a look-up table (correspondence table) containing entries from the content store, pending interest table, and transfer information base.</p><p num="0008"> In another embodiment, the system determines if the packet contains content that corresponds to interest or HSVLI.</p><p num="0009"> In another embodiment, in response to a packet containing interest in one content, and a matched search in the content store, the system places one content pre-stored in the content store as the source of that interest. Source).</p><p num="0010"> In another embodiment, in response to a packet containing interest in one content, and a search that was matched in the pending interest table but not in the content store, the system responded to the corresponding pending interest entry. Update the pending interest table to include the input interface for packets with.</p><p num="0011"> In other embodiments, the system forwards in response to a packet containing interest in one content, and a search that is consistent in the forwarding information base but not in the content store or pending interest table. Forward the packet to one or more interfaces that correspond to the alignment in the information base.</p><p num="0012"> In another embodiment, the system forwards the packet to the interface corresponding to the matching in the pending interest table in response to the packet containing one content and the search for which matching was obtained in the pending interest table. The system also stores a copy of the packet in the content store and deletes the corresponding pending interest in the pending interest table.</p>

<figref num="1">It is a figure which shows the exemplary architecture of the content central network (CCN) by one Embodiment of this invention.</figref><figref num="2">It is a figure which shows an exemplary CCN transferer for forwarding a CCN packet having HSVLI according to one Embodiment of this invention.</figref><figref num="3">It is a flowchart which shows the process which facilitates the packet transfer which has one HSVLI by one Embodiment.</figref><figref num="4">It is a flowchart which shows the operation of the CCN transfer engine which contains the content store, the pending interest table, and the transfer information-based search entry by one Embodiment.</figref><figref num="5">It is a figure which shows the example CCN transferer by one Embodiment.</figref>

In the figure, the same components are given similar reference numbers.

In embodiments of the present invention, the problem of forwarded packets in a content central network (CCN) is solved by using a search engine that combines a plurality of correspondence tables to transfer the content or its interests. Specifically, the content-centric routine engine combines forwarding information from several types of correspondence tables to provide a synergistic forwarding scheme based on a hierarchically structured variable-length identifier for packets. The following describes the content central network and content names. Since then, the transfer mechanism in the content central network has been described in more detail.

In the following description, "content consumer" or "consumer" refers to an entity that requests or receives content. A "content provider" or "provider" refers to an entity that provides content.

The term "interest" or "query" refers to a request for some content. The packet of interest is irrelevant of what content is desired (from a collection of content that may exist in the network) and, if necessary, undesired content (whether it is already owned by the requester or contextually). Encodes a special form of query that represents (content that is known to be). An important part of the query is the desired content name prefix. A hierarchical structure of content names, also referred to as hierarchically structured variable-length identifiers (HSVLS (s)) described below, identifies (potential) sets of content with such prefixes. The other part of the query narrows down which content is desired from the set. A forwarder is responsible for sending content data that satisfies the interest, or for sending the interest itself to one or more next-hop destinations that are more likely to be closer to some source of the corresponding content. Fulfill.

The terms "content", "content data", "content packet", and "data packet" refer to a unit of content. In CCN, the content packet is self-identifying: the content packet carries the entire content name, but the part of the name that is the hash (value) of the content itself can be treated implicitly. The transferor generally transfers content data to the corresponding source of interest, while also serving to hold a cached copy that can generally be used to meet future interests.

The term "face" refers to an interface on a CCN transporter that connects an application or network. The face may be hardware or software based. Such a CCN interface is called a "face" and is distinguished from the general meaning of "interface" as a physical network interface in router terminology. Interest and content packets are sent and received via the face. A face connects a single application, a single remote node over a two-point network connection, or a collection of nodes such as a broadcast or multicast group in a network.

The terms "forwarding information base: FIB" and "forwarding table" refer to a data structure that allows a name prefix search (lookup) to determine where to send interest. A search in the CCN's FIB generally allows the packet of interest or content packet to be forwarded to multiple faces, so the reference value is returned to one or more output faces.

The term "content store and CS" refers to a data structure that holds content packets so that they are distributed in response to matching interests. The use of data named in CCN is designed to decouple content from its location and make it easy to trade storage at any location on the network. The CCN content store (CS) is substituted for the queue buffer memory associated with the output interface in traditional IP routers. Rather than storing the packet on the external interface (which is performed by the IP router) when the communication is congested, the CCN transferor stores the data packet in the CS. CS is implemented as a "distributed memory hierarchy", which is simplified by the fact that multiple copies can exist without adjustment because each packet is self-identifying and immutable. ..

The term "pending interest table and PIT" refers to a data structure that allows a search to identify a corresponding pending interest based on a prefix of the CCN name of a content packet. Based on the results of the search, the CCN transfer device can determine where and how to forward the content packet. The PIT stores a reference value for each pending interest in a list of faces that have provided interest. In other words, the PIT maintains a record of how content packets should be sent to a source of interest that has already generated the corresponding interest, and the corresponding interest is one or more. It remains on hold until it is filled with content packets.

Content-centric networks can bring new approaches to content transport. Instead of seeing network traffic at the application level as a terminal-to-terminal conversation in which the content travels, the content is partially requested or returned based on the name given to the content. The present embodiment provides a CCN transfer device that transfers interest to a content host node and returns the corresponding content to the content consumer. The CCN transfer engine combines a transfer information base, a content store, and a pending interest table to facilitate the transfer of both interest and content. Unlike traditional topology-based forwarding mechanisms (such as those implemented on IP routers) that require spanning tree-based routing, the CCN forwarding engine forwards packets to multiple egress faces and loops. None Transfer can be ensured.

In CCN, content includes any form of data such as text, images, video and / or audio. The content consumer or provider may be an automated process such as a computer user or application. One content refers to the entire content or individual parts of the content. For example, a newspaper article may be represented by a large number of contents embodied as data packets. A piece of content is associated with metadata that serves to describe or augment the content with information such as authentication data, created data, content owners, and so on.

In general, a CCN packet corresponds to an interest in one content or one content corresponding to the interest. Whether the packet payload is of interest or content data, the packet is identified by a hierarchical structured variable length identifier (HSVLI). This HSVLI is also the corresponding content name. For example, the HSVLI "" abcd / bob / papers / CCN / news "" represents the name of the content and identifies the corresponding packet (s). This HSVLI, also known as the "content name," is a "news" from a collection of newspaper "CCN" for users named "" Bob "" in the organization named "" ABCD "". Mention the article.

To request a piece of content, the node expresses interest in that content by means of the content name (ie, HSVLI) (eg, broadcast). The CCN transferer transfers interest to the node (s) that have the content and returns it to the requester of the content. Ideally, the CCN forwarding infrastructure intelligently propagates interest to promising nodes that are likely to have information, and then reverts the path that interest crosses to carry available content.

Note that traditional packet forwarding is based on "addresses" assigned to multiple nodes (or interfaces of multiple nodes). For example, in IP addressing, an address such that the first part of the IP address identifies the network, the second part identifies the subnetworks in the network, and the last part identifies a particular host in the subnetwork. Hierarchical division is used. With this configuration, the responsibility for assigning special addresses can be entrusted and distributed, and the Internet can be standardized on a global scale. This configuration also enables standardization by limiting the amount of information that the IP router needs to process when forwarding packets to the output port.

In contrast, in CCN, the hierarchical structure of HSVLI is more advantageous than the hierarchical structure of IP addresses (or other types of addresses such as Ethernet MAC addresses). Interest can be explicitly described via name rather than implicitly through an IP routing table entry that includes a subnet mask. In this way, with HSVLI, naming errors in the hierarchy are detected by inspection, but IP-based subnet mask errors can route packets to the wrong address, making them more difficult to detect. ..

The HSVLI that is part of the packet of interest can be matched by any content name that has HSVLI as a prefix. For example, "" / park. com / van / presentation. The interest to display "pdf" is the content name: "" / park. com / van / presentation. pdf / p1 "" and "/ park. com / van / presentation. It can be matched by pdf / p2. "". Any node that receives an interest and has content that is consistent with this interest can respond with the content. Content that matches an interest is described as "consuming" that interest. This re-expresses the corresponding interest so that if the content consumer wants to continue receiving the content, more content packets will be distributed to the consumer. Content can be different, but can be aligned with a number of interests.

FIG. 1 shows an exemplary architecture of CCN according to an embodiment of the present invention. In this example, CCN180 includes components 100-145. Each node in the network is connected to one or more other nodes. The network connection 185 is an example of such a connection. Network connections are shown by solid lines, but each line can also show a subnetwork or supernetwork that connects two nodes. The network connection may be broadband, wireless, telephone, satellite, or any type of connection. A node can be any entity, such as a host (computer system), a cluster or network of hosts, an application, and / or a device that creates interest or content.

Consumers can generate interest in one content and then send that interest to the nodes of CCN180. The corresponding content may be stored in the CCN180 node by a publisher or content provider that may be located inside or outside the network. For example, in FIG. 1, interest in one content is created at node 105. If the content is not available on node 105, interest is transferred to one or more nodes connected to node 105, such as node 115. If node 115 does not remember a copy of the requested content, node 115 sends its interest to node 125, which further transfers that interest to node 130. The pathways that interest has crossed are shown in interest flows 150, 155 and 160 in FIG. Since node 130 remembers a copy of its content, the content then reverts the path it crossed until interest arrives at node 105 to which the content is distributed (content flow 165, 170). And 175). Each node involved in the flow of interest or content can perform any authentication operation on the flow of interest or content.

In CCN180, any number of intermediate nodes (nodes 1-145) in the passage between the content holder (node 130) and the interest-generating node (node 105) cache a local copy of the content as it traverses the network. You can participate in (save). Content can be stored in the content store (CS) of each node. Caching reduces the load on the network for a second subscriber located in close proximity to other subscribers by implicitly sharing access to locally cached content.

In one embodiment, the CCN transfer engine is loaded with entries to CS, PIT, and FIB. The search results are subject to the assigned priority, and the matching obtained from the desired correspondence table is used by the transfer engine. Appropriate post-search processing, including further matching inspection or inquiry processing, is then performed on the matching results.

FIG. 2 shows an exemplary CCN transporter for forwarding CCN packets with HSVLI according to an embodiment of the invention. In this example, the CCN transfer device 200 includes a large number of faces such as faces 212 and 214. The switch fabric 210 interconnects with these faces.

The CCN forwarding engine 202 controls the switch fabric 210 to determine how to process or forward incoming packets. The CCN transfer engine 202 contains FIB204, CS206, and PIT208.

As mentioned above with respect to FIG. 1, content consumers generally generate interest (assuming they do not already have a copy of the content) and transfer that interest to the default next hop node. Send. The next hop node processes the packet of interest, and depending on whether the node remembers a copy of the content or has previously forwarded a similar interest, the node (generally the same face on which the interest arrives). The content may be returned to the consumer and the corresponding input face may be added to the PIT, or the interest may be transferred based on the FIB search. The detailed operation of each CCN transfer device such as the CCN transfer device 200 will be described below.

Upon receiving the packet from the input face, the CCN forwarding engine 202 first determines whether the packet is a packet of interest or a content packet. If the packet contains interest, the CCN forwarding engine 202 first searches the CS206 to determine if there is content consistent with the HSVLI in the packet of interest. In one embodiment, CS206 is indexed by content name, which corresponds to the HSVLI of the packet of interest. If there is a hit in the CS (ie, if there is content that matches the packet of interest), the CCN transfer engine 202 retrieves the content from the CS206 and sends the content to the same face where the interest arrives. If CS206 does not remember a copy of the requested content, transfer engine 202 searches for PIT208. A hit on the PIT 208 means that the previous interest in the same content has already been transferred. Therefore, the transfer engine 202 adds an input face to which the interest arrives to the PIT 208, which allows the content to be traced back to the source of interest when the content is returned from the network.

If the PIT 208 does not contain a matching interest, the FIB 204 is retrieved by the HSVLI prefix (notation) of the packet of interest. In one embodiment, the forwarding engine 202 performs the longest prefix search on the FIB 204 based on the HSVLI prefix of the packet of interest. The longest prefix-matched search is important for forwarded packets with HSVLI (s). For example, HSVLI showing interest in "/ park / home / smetters" is described in "/ park / home / smetters / testers". "txt" "and" "/ park / home / texters / bar. txt. Consistent with both "". Note that the prefix exhibits one or more adjacent components in HSVLI starting from the most common level components. For example, "" / a / b "" is a prefix of "" / a / b / c / d "", where "" / a "" is the most common level and "" a ". "", "" B "", "" c "", and "" d "" are adjacent components. The HSVLI may have multiple prefixes. For example, "" / a / b / c "" is also a prefix of "" / a / b / c / d "". With respect to the number of name components, the longest prefix matching is considered to be the best because it is the most special.

If a match is found in FIB204, the search result identifies one or more faces to which the packet of interest can be forwarded. Therefore, the packet of interest is forwarded to these faces (s). In addition, the interest (ie, its HSVLI) and the corresponding input face are stored in the PIT 208.

If no match is found in FIB204, the forwarding engine 202 may forward the packet of interest to the default output face. In one embodiment, the FIB204 may produce a default result if there is no explicit match, and this default result will produce the longest prefix match in the absence of any other match. It is generated either by an entry with a real value of zero (0) or by some special processing. Such default results may be treated as a match in FIB204. If desired, the forwarding engine 202 may drop the packet of interest if no explicit alignment is found in FIB204.

If the incoming packet is a content packet, the forwarding engine 202 first searches the PIT 208 to determine if there is a pending interest satisfied by the content packet. If the PIT 208 is inconsistent, this means that there is currently no pending interest in the corresponding content, and the forwarding engine 202 can drop the content packet. In one embodiment, the transfer engine 202 can optionally store a copy of the content in the CS206, and if it receives a consistent interest that arises in the future, the stored content will be consumed. Can be supplied to the person in a timely manner.

If the content packet received in the PIT 208 is matched, the forwarding engine 202 can forward the content packet to the face associated with the corresponding HSVLI of the PIT matching. That is, the content is transmitted to the face (s) that the pending interest has previously arrived at. In this way, the transfer engine 202 ensures that the content traces back to the source of the pending interest. In addition, a copy of the content packet is stored in CS206. Since each content packet is immutable and self-identifying, the content packet can be stored in the CS206 for a long time, in which case the storage step may be skipped (or the CS206 may be skipped). Does not affect the state of).

After the content packet has been forwarded to all faces identified in PIT208, the corresponding interest is removed from PIT208 because the interest has been filled in the node and is no longer in hold. In one embodiment, each content pair of interest acts as a flow control mechanism, in which the content consumer can issue a new interest after the previously transmitted interest has been satisfied.

FIG. 3 is a flowchart showing a process of transferring packets in CCN according to an embodiment of the present invention. During operation, the system receives an incoming packet (operation 302). The system then determines whether the packet is an interest packet or a content packet based on the packet header or payload information (operation 304).

If the received packet is a packet of interest, the system further performs a search in the CS to determine if there is content that matches the interest in the CS (operation 306). If there is a match, a copy of the content (or a copy of one or more content packets) is returned to the source of interest via the same face on which the interest arrives (action 307). If there is an inconsistency in the CS, the transfer engine further performs a search in the PIT to determine in the PIT whether there is already a pending interest in the same content (operation 308). If there is a match in the PIT, the system updates the corresponding PIT entry (action 310) to include the face on which the interest arrives, and subsequently receives the next incoming packet.

If the packet of interest is inconsistent in the PIT, the system performs a search in the FIB (operation 312). If there is a match, the system forwards the packet of interest to the matched face (s) based on the FIB search (operation 314). The system also updates the PIT containing the packet of interest before receiving the next incoming packet (operation 310). If there is an inconsistency in the FIB, the system can either forward the packet of interest to the default face or drop the packet, if desired (operation 316).

If the received packet is a content packet (operation 304), the system first performs a search on the PIT (operation 318). If there is an inconsistency in the PIT, this means that there is no pending interest in the incoming content packet, and the system drops the content packet (operation 319). If desired, the system can also anticipate future packets of interest and store a copy of the content packet.

If the content packet is matched in the PIT, the system forwards the content packet to the face (s) returned from the PIT (operation 320). The system also stores a copy of the content packet in the CS (operation 322). The system then deletes the pending interest entry in the PIT (operation 324).

In any practical implementation of the CCN transfer, the storage capacity of the internal data structure is bounded on the assumption that the data structure will be full. Various memory management methods can be used to deal with these scenarios (scenarios).

When the CS (content storage device) is full, a policy of what to do with new content packets is required. One policy is to replace content packets (which may be more than one) that have been used less frequently in CS with new content packets. It is also possible to implement a fairly complex policy, such as discarding a new content packet with a prefix of a particular name, or discarding an old packet with some key signed. In one CCN transfer model, the memory is created for the CS rather than the packet queue (queue), so if the policy is that the content packet is not stored in the CS when the CS arrives, the content packet will be transferred anywhere. Not done. Content packets may also contain annotations from publishers that state a maximum hold period that they expect the data to be out of date after a period of time. When the CS is full, old packets are periodically dropped and preferentially selected and exchanged. Unlike traditional IP forwarding, which is less desirable for storing arbitrary data in the packet queue, the CCN architecture allows the CS to have the opportunity to resolve future requests locally. It is designed to be the best for storing as much data as possible. That is, in the case of line congestion, it is preferable to use the memory that already exists in the transfer device, rather than not using it.

The system can implement a variety of policies to accommodate the situation when the PIT is full. Unlike content data in CS, the lifespan of interest is bounded as part of the design, so old interest is no longer reserved for consumers who have disappeared. Consumers who do not receive the corresponding content can also periodically retransmit their interests if they remain unsatisfied. Similar to CS, in one embodiment the PIT can also act as a buffer for interest, instead of the traditional packet queue. If the policy is not to store the inconsistent interests in the PIT, the interests will not be transferred anywhere, and the consistent content data that happens to arrive will not be transferred.

The FIB (Transfer Information Base) is a transfer data structure that is not automatically updated during a transfer operation. FIB updates are performed offline, either by manually configuring or by implementing some routing protocol. If the memory space of the FIB is insufficient, the connectivity of the transfer device may be restricted. However, for CCN's FIB usage, by enhancing entries with a common prefix at the expense of bandwidth for sending interest to additional destinations that are unlikely to give good results of interest. Note that it can potentially be safely reduced.

In some embodiments, the CCN transfer engine uses a strategic layer that facilitates dynamic optimization of the CCN transfer device. For example, the system can use a transporter with connectivity over two separate networks to make performance-based transfers. A basic routing configuration can specify that a packet with a particular HSVLI prefix is forwarded to one or more faces. First, such packets can be forwarded to multiple faces. Strategic features are used to observe that consistent content is received through one face faster than other content. The system then determines to forward packets of interest with the same HSVLI prefix to this face for faster content delivery. These dynamic optimizations can be performed asynchronously as a separate function of collecting transfer statistics used by the strategic layer to coordinate the FIB.

As mentioned earlier, the CCN transfer engine is loaded with entries to CS, PIT, and FIB. The search results follow the assigned priority and the transfer engine uses matching from the desired correspondence table. Post-search processing includes further matching or query processing and is performed on these results.

The CCN transfer engine has two additional unique features: Multiple entries: The CCN correspondence table has multiple entries for a given HSVLI (or prefix), which is a single entry per address (or prefix) to avoid looping. Moreover, it is different from the conventional transfer device that has only one. Thus, the matching result in the CCN forwarding engine can be a pointer to a list of actual content packets, interests, or faces, depending on whether the search occurs in the CS, PIT, or FIB. Priority mechanism: In one embodiment, the CCN transfer engine applies a particular priority to matching results that are likely to result in multiple matches. For example, using ternary content addressable memory (TCAM), a priority encoder is used to select the first entry of multiple matching entries, which gives priority to the order in which they are loaded. Used to indicate rank. Using tree-based lookup, the system can explicitly prioritize multiple entries on the same node. Note that each table may have a list of entries as described above, as the CCN transfer engine combines three correspondence tables (CS, PIT, and FIB) and these multiple alignments are entered from different tables. I want to be.

In one embodiment, the CCN transfer engine proceeds as follows: 1. 1. Packets are received from the network via the input face. 2. The search (lookup) is performed on the packet prefix using a matched common search engine. Up to this point, there is no difference in the handling of the two CCN packet types (ie, the interest packet and the content packet). 3. 3. The search result is a content packet from CS, an interest from PIT, or a face from FIB, and further processing of the packet can be controlled based on the packet type of CCN. 4. Depending on the packet type and the result after processing, the incoming packet is transmitted via one or more output faces, the content packet from the CS is transmitted via the input face, or the incoming packet is dropped.

FIG. 4 is a flowchart showing the operation of the combined CCN transfer engine according to the embodiment of the present invention. During operation, the system receives incoming packets (operation 402). The system then performs a search based on the HSVLI of the packet in the composite transfer engine, which includes a simultaneous search with entries for CS, PIT, and FIB (operation 403). After the search is complete and the results are obtained, the system determines if the packet is an interest packet or content packet based on the packet header or payload information (operation 404). Note that the search results may include content packets (supporting CS matching), pending interests (supporting PIT matching), and output faces (supporting FIB matching).

If the received packet is a packet of interest, the system further determines whether the search (lookup) has obtained CS matching based on the search results (operation 406). If there is CS matching, a copy of the content (or a copy of one or more content packets) is returned to the source of interest via the same face on which the interest arrives (operation 407). If there is no CS alignment, the transfer engine further determines if there is already a pending interest in the same content of the PIT based on the corresponding PIT search results (operation 408). If the PIT is consistent, the system updates the corresponding PIT entry to include the face on which the interest arrives (action 410) and continues to receive the next incoming packet.

If the packets of interest are not matched in the PIT, the system determines if there is FIB matching (operation 412). If there is FIB matching, the system forwards the packet of interest to the matched face (s) based on the FIB search (operation 414). The system also further updates the PIT having the packet of interest before receiving the next incoming packet (operation 410). If there is an inconsistency in the FIB, the system either forwards the packet of interest to the default face or drops the packet as needed (operation 416).

If the received packet is a content packet (see operation 404), the system first determines if there is a match in the PIT (operation 418). If there is an inconsistency in the PIT, this means that there is no pending interest in the incoming content packet, and the system drops the content packet (operation 419). If desired, the system can anticipate upcoming packets of interest and store a copy of the content packet.

If there is a match for the content packet in the PIT, the system forwards the content packet to the face (s) based on this PIT match (operation 420). The system further stores a copy of the content packet in the CS (operation 422). The system then deletes the pending interest entry in the PIT (operation 424).

It should be noted that the above transfer process, which combines the searches in CS, PIT, and FIB into one search process, is the only way to implement the CCN transfer engine. The transfer method shown in FIG. 3 can also be used, although the optimization is insufficient. The following description shows in more detail how the entries from each correspondence table (ie, CS, PIT, and FIB) are loaded into a common search engine.

FIB: In FIB, each transfer prefix is once put into a common CCN search engine. Entries from the FIB have the lowest priority. The longest prefix search is the preferred search method for FIB. No other alignment is required after processing after the FIB search.

PIT: PIT is treated in the same way as FIB. Put each pending interest prefix into a common CCN search engine. Entries from PIT have the highest priority. The longest prefix matching of PIT is then matched with the rest of the processed query terms. For example, any query term that constrains the publisher, if any, needs to be taken into account.

CS: For each CS content packet, one entry is added to the common search engine for all possible CCN prefixes. In this way, search engine entries are provided that are included in all possible prefixes that are queried to obtain any available content packet. A large number of content packets in a CS can share a prefix, resulting in multiple entries for the same CS entry in a common search engine. As with PIT, after the longest prefix matching, matching with other terms such as publishers continues. Queries may also request content that is relative to a particular prefix in the content name tree, which is ideally evaluated after a search to find a good match. The priority of entries from CS is medium, lower than PIT entries, but higher than FIB entries.

Content Packets: An initial search for the name of a content packet gives one of the following consistency (descending order of priority): PIT: There are consumers of this content packet that have not yet been filled with what is locally available in CS if there is a match of pending interest. The transfer engine can send the content packet to all faces that are the source of the pending interest, input the content packet to the CS, and remove the pending interest. Note that these steps involve modifying common search engine content (and other data structures), but these steps are performed in the background rather than in real time. CS: Since the priority of CS entries is low, CS alignment suggests that there is no pending interest in the content packet. In general, this ends packet processing because we want to avoid consuming CS storage for undesired content. Alternatively, the transferor determines whether post-processing should add a copy of the incoming content packet to the CS regardless of lack of interest if a copy of the incoming content packet is already stored in the CS or not. More flexible policies can be implemented. FIB: FIB matching suggests that there is no pending interest in the content packet, and the transporter behavior is the same as CS matching. Inconsistent: Inconsistent means that there is no pending interest in the content packet, and the operation of the transfer device is the same as CS inconsistency.

Packets of Interest: An initial search for prefixes in packets of interest yields one of the following matches (descending priority): PIT: PIT matching indicates that this query has already been forwarded. The incoming face is added to the face list for pending interest and the end time is updated. CS: CS alignment indicates that there is no pending interest already processed, but there is local data that satisfies the incoming query. Matching content packets are transmitted via the incoming face. FIB: FIB alignment indicates that incoming interest is forwarded towards a possible source of requested content, as there is no pending interest or local content. Packets of interest are sent through each face associated with FIB matching and put into the PIT in relation to the input face. Note that this final step involves modifying the content of a common search engine, but in the background, not the main packet forwarding path.

Malocclusion: Malocclusion of each correspondence table is processed as follows after the search process: PIT: Malocclusion for a PIT entry may be due to a pending interest with a related prefix (from the name of the content packet or the prefix of interest), but the interest has other queries. Therefore, it is not an actual match. In this case, a new search is executed for the shorter prefix length, the process can be repeated, and malocclusion can be avoided. Alternatively, the slow path can use other data structures to directly implement the conceptual transfer algorithm. The malocclusion for a PIT entry may be a hash collision, in which case a slow path is invoked to use the CS and FIB data structures loaded with a common search engine. CS: Malocclusion for CS entries may result in content being present in the content store that does not match all the query terms of interest or does not match the content packet. In the case of incoming interest packets, the query may have been made to the content related to the discovered content packet, so the result of the malocclusion may be an input to a scan of other CS data structures. is there. In the case of an incoming content packet, the packet is either discarded or inserted into the CS because the match from the CS already indicates the absence of pending interest, as it did not exist there. Again, the malocclusion may be due to a hash collision, in which case a slow path needs to be invoked to use the FIB data structure loaded with a common search engine. FIB: Since the FIB works only for prefix matching, there can be no malocclusion in the FIB entry based on the query term. However, hash collisions can occur. For CCN, unlike IP, there is no problem with unnecessarily forwarding packets of interest through faces that are unlikely to meet, except for the cost of some wasted bandwidth. The important thing is that the correct destination is entered in the list. Therefore, it is acceptable to ignore the hash collisions that can occur in the FIB entry. Again, it is possible to inspect and activate slow routes using a common search engine loaded FIB data structure.

FIG. 5 shows an exemplary CCN transporter according to one embodiment. In this example, the CCN (Content Central Network) transfer device 500 includes a processor 502, a memory 504, and a storage device 506. The CCN transfer device 500 is connected to the network 522 and, if necessary, to the display 520, the keyboard 524, and the pointing device 124. The storage device 506 stores computer instructions for applications 516 and 518 as well as the CCN transfer engine 508. The CCN transfer engine 508 further includes a CS (content store) 510, a PIT (pending interest table) 512, and a FIB (transfer information base) 514. During operation, instructions to the CCN transfer engine 508 are loaded into memory 504 and executed by processor 502 to perform the various functions described above.

The data structures and codes described in "Modes for Carrying Out the Invention" are generally stored in a computer-readable storage medium, which is a code and / or code for use by a computer system. It may be any device or medium capable of storing data. Computer-readable storage media include, but are not limited to, magnetic and optical such as volatile memory, non-volatile memory, disk drives, magnetic tapes, CDs (compact discs), DVDs (discs with versatile digital or digital video discs). Includes storage devices, or media capable of storing currently known or upcoming codes and / or data.

The methods and processes described in "Modes for Carrying Out the Invention" are embodied as codes and / or data, which codes and / or data are stored in a computer read storage medium as described above. obtain. When a computer system reads and executes a code and / or data stored in a computer read storage medium, the computer system embodies the data structure and code as well as the methods and processes stored in the computer read storage medium. Execute.

In addition, the methods and processes described herein may be included in a hardware module or device. These modules or devices include, but are not limited to, application specific integrated circuit (ASIC) chips, field programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software modules or code at specific times. And / or other programmable logic devices known or likely to be developed in the future may be included. When hardware modules or devices are started, they perform the methods and processes they contain.

As described above, various embodiments of the present invention have been made only for illustration and explanation, and are not limited to the disclosed embodiments of the present invention. Accordingly, the above and other modifications may be made to this form and detail as long as it does not deviate from the spirit and scope of the invention. In addition, the above disclosure is not intended to limit the invention.

100 nodes 105 nodes 110 nodes 115 nodes 120 nodes 125 nodes 130 nodes 135 nodes 140 nodes 145 nodes 150, 155, 160 Interest flow 165, 170, 175 content flow 185 network connection 180 CCN 204 Transfer Information Base 206 Content Store 208 Pending Interest Table 202 CCN transfer engine 210 switch fabric 200 CCN transporter