Patent Description:
The invention further relates to a method of receiving an interest message and a method of transmitting an interest message.

The invention also relates to a computer program product enabling a computer system to perform such methods.

Information-Centric Networking (ICN) is a new networking paradigm with the goal of evolving the current Internet infrastructure away from a host-oriented system towards a data-oriented system. Instead of addressing endpoints via IP addresses, data itself is addressed in ICN. By dividing data into chunks, and giving each of those chunks a unique and hierarchical name, ICN allows clients to ask the network for a given named data object, without having to worry where that data is located/stored. One of the benefits of naming data is that each intermediate network node, such as a switch or a router, has the ability to cache the data packets that flow through it. In this way, if a new consumer requests data which is already cached in the network, its request does not need to travel through the network towards the original producer of the data, but can instead be served by one of the intermediate network nodes holding a copy of that data.

Current ICN architectures have two elementary types of messages at their core: interest messages and data messages. When an application wants to retrieve a particular data object, it sends out an interest message for that data object. The most important part of this interest message is the name of the object, or, in cases where the full name of the object is not known, a prefix.

An example of such an ICN architecture is Named Data Networking (NDN) described in "<NPL>. This publication describes that when a network node receives an interest message, it first checks whether its Content Store (CS - the node's cache) happens to contain a named data object that matches the name in the interest message. If a corresponding named data object is found, it is wrapped in a data message and sent back over the interface over which the interest message was received.

In the case where the object is not cached, the next step is to check whether the requested name is already in the so-called Pending Interest Table (PIT). The PIT maintains a list of existing, pending data object requests and the corresponding interfaces through which they were requested. When a data message comes in, it is forwarded to all interfaces that according to the PIT have an unsatisfied interest for the corresponding name. The entry in the PIT is then deleted. When a name in an incoming interest message is not listed in the PIT, it is added along with the interface over which it was received. The interest message is then forwarded on one or more outgoing interfaces according to the Forwarding Information Base (FIB - the ICN equivalent of a routing table) and the Strategy layer, in search of the requested data at another node. In an alternative implementation, the network node first checks whether the requested name is already in the PIT and only checks whether its CS happens to contain a named data object that matches the name in the interest message if it is not.

Now, in both the cases when checking the CS or FIB, there may be multiple entries whose name matches the name indicated in the interest. A scenario which becomes even more likely when Range Name Components (RNC) are used in the interest name. Range Name Components are described in "<NPL>.

A so-called "data selection strategy" is applied by an ICN router to select which data item to return to the requester. When an ICN router receives an interest matching multiple CS entries, then by default the leftmost child (the data object whose name is first in an alphabetic ordering of matching names) is selected. It is possible to specify in an interest message that the next network node should instead select the rightmost child (the data object whose name is last in an alphabetic ordering of matching names) using the "ChildSelector" field. It is also possible to specify in the interest message whether the returned data item must be fresh using the "MustBeFresh" field. If the FreshnessPeriod of the selected (leftmost or rightmost) child has expired, no data item is returned. The FreshnessPeriod cannot be set by the requestor.

Similarly, a so-called "forwarding strategy" takes care of deciding on the communication interface on which a certain interest message is forwarded. "<NPL> describes the various forwarding strategies supported in NDN. It is not necessary to select only one communication interface to forward interest messages on. When using the Multicast strategy, every interest message is forwarded on all communication interfaces that correspond to a prefix in the FIB to which the interest name matches. Often, the Best Route strategy is used, according to which an interest message is forwarded on the communication interface, i.e. to the upstream node, with the lowest routing cost.

The NDN Developer's Guide also discloses two strategies in which network properties are used to decide on the communication interface on which a certain interest message is forwarded: the NCC and Access Router strategies. The NCC strategy is a reimplementation of CCNx <NUM>. <NUM> default strategy and essentially selects the interface on which the interest will be sent based on the interface's ability to return the forwarded data within a certain time-out. The basic idea of the Access Router strategy is to multicast the first interest, learn which next hop can serve the content, and forward the bulk of subsequent interests towards the chosen next hop. If the next hop does not respond, the strategy involves starting to multicast again to find an alternative path.

Thus, these data selection and forwarding strategies in NDN allow network nodes to make decisions based either on the names of the data matches, such as the ChildSelector, which returns the matching entry that comes first or last alphabetically, or based on network properties e.g. the NCC and Access Router strategies. However, the requesting node (i.e. the requestor) may still be required to perform different iterations to obtain the sought data object, or may not receive the sought data object fast enough, or not receive the sought data object at all (i.e. receive an unwanted data object instead).

<CIT> describes a content-discovery system allowing a node in a Content Centric Networks (CCN) to discover content over CCN. The CCN node can generate an Interest that includes a query for discovering content associated with a given name prefix, and after disseminating the Interest over CCN, can receive a query-result Content Object that includes a listing of matching Content Objects and their reputation information. The CCN node can also process Interests issued by other CCN nodes that would like to discover content. After receiving an Interest comprising a query for discovering content, the CCN node searches a repository for a set of Content Objects that match the query. The CCN node generates a results list that includes the Content Object in the search results and their reputation information. The CCN node then generates and returns a query-result Content Object that includes the Interest's name, and whose payload includes the results list.

<CIT> describes a network device in a Named Data Networking (NDN) network which receives an Interest from a consumer including a name and an Expected Data Size of data requested through the Interest. The network device forwards the Interest along a path to a producer of the data based on the name. As a result, the network device receives data that has traversed the path in reverse and satisfies the forwarded Interest. The network device determines an actual data size of the received data. The network device compares the actual data size to the Expected Data Size. If the actual data size is greater than the expected data size, and if a level of traffic congestion associated with forwarding the received data to the consumer is below a threshold, forwarding the received data to the consumer along a path based on the name of the data.

It is a first object of the invention to provide a network node, which is able to select one or more items from a plurality of items which match an interest such that a requesting node is able to obtain a sought data object sufficiently fast.

It is a second object of the invention to provide a requesting node, which helps a network node select one or more items from a plurality of items which match an interest such that the requesting node is able to obtain a sought data object sufficiently fast.

It is a third object of the invention to provide a method of receiving an interest message, which helps a network node select one or more items from a plurality of items which match an interest such that a requesting node is able to obtain a sought data object sufficiently fast.

It is a fourth object of the invention to provide a method of transmitting an interest message, which helps a network node select one or more items from a plurality of items which match an interest such that a requesting node is able to obtain a sought data object sufficiently fast.

According to the invention, the first object is realized in that the network node for an Information Centric Networking architecture comprises at least one communication interface and at least one processor configured to receive, from a requesting node, on a communication interface of said at least one communication interface, an interest message for requesting a data object, said interest message comprising a request for a data object and metadata, said metadata specifying one or more criteria to be used for selecting a subset of a plurality of items, determine whether there is a match between said requested data object and a plurality of items, and select a subset of said plurality of items by applying said one or more criteria if said match has been determined to exist, wherein at least one of said one or more criteria is a preference specified for at least one of: factual properties of said plurality of items, usage data related to said plurality of items, usage data related to said at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in said interest message.

By allowing a requesting node to specify in metadata of the interest message one or more criteria for selecting a subset of a plurality of items, of which at least one criterion is a preference specified for at least one of: factual properties of the plurality of items, usage data related to the plurality of items, usage data related to the at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in the interest message, and applying these one or more criteria at the network node, the requesting node (and possibly the user thereof) is provided more flexibility and higher customization capabilities. This additional flexibility and these higher customization capabilities allow the requesting node to obtain the sought data object faster and reduce the number of unwanted data objects that it receives. The one or more criteria are used to select one or more items from a plurality of items which match the interest, but should preferably be ignored when only one item matches the interest. Preferably, matching is initially done based on name. Once a plurality of matches is found, the one or more criteria are applied to narrow done the matches.

A preference specified for factual (objective) properties of items, e.g. the sizes or content types of the data objects, increases the chance that the returned data object matches the requesting node's preferences compared to the known "ChildSelector" field, which specifies a preference for unfactual (subjective) properties of data objects, i.e. the names of the data objects. Similarly, the "MustBeFresh" field specifies a requirement for unfactual (subjective) properties of data objects, because the FreshnessPeriod is set (chosen) by the content producer and cannot be set by the requesting node. Furthermore, the "MustBeFresh" field specifies a requirement rather than a preference, because no data object is returned if only one data object in the CS matches the required data object and the FreshnessPeriod of this one data object has expired.

A data selection strategy and/or a forwarding strategy that allows the network node to make use of usage data will in most cases return the sought data object faster. Since a requesting node may know whether he is looking for a popular data object or not, it is beneficial to allow the requesting node to specify which usage data to preferably use. Allowing the requesting node to specify a preference for a position in a range specified in the interest message provides more customization capabilities when a Range Name Component (RNC) is used in the interest name. The above-mentioned criteria may also be beneficially applied when they are configured in the network node, e.g. in user-specific policies, in addition to or instead of being specified in the metadata of the interest message.

Said at least one processor may be configured to determine whether a plurality of data objects in one or more memories of said network node matches said requested data object and select one of said plurality of data objects by applying said one or more criteria and return said selected data object in a data message on said communication interface of said at least one communication interface if said plurality of data objects has been determined to match said requested data object, wherein at least one of said one or more criteria is a preference specified for at least one of: factual properties of said plurality of data objects, usage data related to said plurality of data objects, and a position in a range specified in said interest message. This provides more flexibility and higher customization capabilities to the requesting node with respect to the data selection strategy.

Said one or more criteria may comprise a criterion which is a preference specified for factual properties of said plurality of data objects and comprises at least one of: a preferred data object size, a preferred minimum data object size, a preferred maximum data object size, a preferred data object content type, a preference for a date and time after which the data object was produced, a preference for a date and time before which the data object was produced, and a preference for the most recently produced data object, for example.

Said one or more criteria may comprise a criterion which is a preference specified for usage data related to said plurality of data objects and comprises at least one of: a preference for the most frequently transmitted data object, a preference for the least frequently transmitted data object, a preference for the most recently transmitted data object, and a preference for the least recently transmitted data object, for example.

Said at least one processor may be configured to record a time at which said selected data object is returned upon returning said selected data object in said data message. This may help the network node gather Most Recently Used (MRU) and Least Recently Used (LRU) statistics if at least one of the one or more criteria is a preference specified for usage data related to the plurality of data objects.

Said at least one processor may be configured to record a number of times said selected data object has been returned upon returning said selected data object in said data message. This may help the network node gather Most Frequently Used (MFU) and Least Frequently Used (LFU) statistics if at least one of the one or more criteria is a preference specified for usage data related to the plurality of data objects.

Said at least one processor may be configured to determine whether said requested data object matches one or more prefixes in a forwarding table and whether said one or more matching prefixes are associated with a plurality of communication interfaces and may be further configured to select a subset of said plurality of communication interfaces by applying said one or more criteria and forward said interest message on said subset of said plurality of communication interfaces if said one or more matching prefixes are associated with a plurality of communication interfaces, wherein at least one of said one or more criteria is a preference specified for at least one of: usage data related to said at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in said interest message.

This provides more flexibility and higher customization capabilities to the requesting node with respect to the forwarding strategy. Furthermore, by forwarding interest messages to the most likely destination and thereby avoiding having to send additional interest messages, the load on the network may be reduced. A requested data object may match one or more prefixes in a forwarding table if the name of the requested data object matches the one or more prefixes in the forwarding table.

If the name of the requested data object comprises a range, it becomes more likely that the name matches multiple prefixes in the forwarding table. Each prefix is normally associated with at least one communication interface and thus, multiple prefixes are normally associated with multiple communication interfaces, although these multiple communication interfaces are not necessarily (all) different. By selecting a subset of the multiple prefixes based on a specified position in the range, a subset of the multiple communication interfaces is selected. Furthermore, a single prefix may be associated with multiple communication interfaces. In such a case, usage data relating to the multiple communication interfaces and/or the effort to obtain data from another network node (e.g. to obtain data on a certain communication interface) may be used to select a subset of these multiple communication interfaces.

Said one or more criteria may comprise a criterion which is a preference specified for an effort to obtain data from another network node and comprises a preferred maximum number of hops between the originator of said interest message and a network node which stores and transmits a data object matching said requested data object and/or a preferred maximum latency between the originator of said interest message and a network node which stores and transmits a data object matching said requested data object, for example.

Said one or more criteria may comprise a criterion which is a preference specified for usage data related to said at least one communication interface and comprises at least one of: a preference for a communication interface on which data messages have been received most frequently, a preference for a communication interface on which data messages have been received least frequently, a preference for a communication interface on which a data message was received most recently, and a preference for a communication interface on which a data message was least recently received, for example. When this criterion is applied at the network node, the network node will normally exclude the communication interface on which the interest message was received from consideration, as it does not want to forward an interest message to a network node that already received the interest.

Said at least one processor may be configured to record a time at which a data message is received on a communication interface upon receiving said data message on said communication interface. This may help the network node gather Most Recently Used (MRU) and Least Recently Used (LRU) statistics if at least one of the one or more criteria is a preference specified for usage data related to the at least one communication interface.

Said at least one processor may be configured to record a number of times the data messages have been received on a communication interface upon receiving a data message on said communication interface. This may help the network node gather Most Frequently Used (MFU) and Least Frequently Used (LFU) statistics if at least one of the one or more criteria is a preference specified for usage data related to the at least one communication interface.

According to the invention, the second object is realized in that the requesting node for an Information Centric Networking architecture comprises at least one communication interface and at least one processor configured to create an interest message for requesting a data object, said interest message comprising a request for a data object and metadata specifying one or more criteria to be used by a network node for selecting a subset of a plurality of items when there is a match between said requested data object and said plurality of items, at least one of said one or more criteria being a preference specified for at least one of: factual properties of said plurality of items, usage data related to said plurality of items, usage data related to at least one communication interface of said network node, an effort to obtain data from another network node, and a position in a range specified in said interest message, and transmit said interest message on said at least one communication interface.

According to the invention, the third object is realized in that the method of receiving an interest message in an Information Centric Networking architecture comprises receiving, from a requesting node, an interest message for requesting a data object, said interest message comprising a request for a data object and metadata, said metadata specifying one or more criteria to be used for selecting a subset of a plurality of items, determining whether there is a match between said requested data object and a plurality of items and, and selecting a subset of said plurality of items by applying said one or more criteria if said match has been determined to exist, wherein at least one of said one or more criteria is a preference specified for at least one of: factual properties of said plurality of items, usage data related to said plurality of items, usage data related to at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in said interest message. Said method may be performed by software running on a programmable device. This software may be provided as a computer program product.

According to the invention, the fourth object is realized in that the method of transmitting an interest message in an Information Centric Networking architecture comprises creating an interest message for requesting a data object, said interest message comprising a request for a data object and metadata specifying one or more criteria to be used by a network node for selecting a subset of a plurality of items when there is a match between said requested data object and said plurality of items, at least one of said one or more criteria being a preference specified for at least one of: factual properties of said plurality of items, usage data related to said plurality of items, usage data related to at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in said interest message, and transmitting said interest message. Said method may be performed by software running on a programmable device. This software may be provided as a computer program product.

A non-transitory computer-readable storage medium stores at least a first software code portion, the first software code portion, when executed or processed by a computer, being configured to perform executable operations comprising: receiving an interest message, said interest message comprising a request for a data object and metadata, said metadata specifying one or more criteria to be used for selecting a subset of a plurality of items, determining whether there is a match between said requested data object and a plurality of items and, and selecting a subset of said plurality of items by applying said one or more criteria if said match has been determined to exist, wherein at least one of said one or more criteria is a preference specified for at least one of: factual properties of said plurality of items, usage data related to said plurality of items, usage data related to at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in said interest message.

A non-transitory computer-readable storage medium stores at least a second software code portion, the second software code portion, when executed or processed by a computer, being configured to perform executable operations comprising: creating an interest message comprising a request for a data object and metadata specifying one or more criteria to be used by a network node for selecting a subset of a plurality of items when there is a match between said requested data object and said plurality of items, at least one of said one or more criteria being a preference specified for at least one of: factual properties of said plurality of items, usage data related to said plurality of items, usage data related to at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in said interest message, and transmitting said interest message.

Embodiments of the network node and the requesting node of the invention and further network nodes <NUM>, <NUM> and <NUM> are shown in <FIG>. The network node <NUM> comprises a set of communication interfaces <NUM>, a processor <NUM> and a memory <NUM>. The processor <NUM> is configured to receive an interest message on a communication interface of the set of communication interfaces <NUM>. The interest message comprises a request for a data object and metadata. The metadata specifies one or more criteria to be used for selecting a subset of a plurality of items. The processor <NUM> is further configured to determine whether there is a match between the requested data object and a plurality of items and select a subset of the plurality of items by applying the one or more criteria if the match has been determined to exist. At least one of the one or more criteria is a preference specified for at least one of: factual properties of the plurality of items, usage data related to the plurality of items, usage data related to the at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in the interest message.

The requesting node <NUM> comprises a communication interface <NUM>, a processor <NUM> and a memory <NUM>. The processor <NUM> is configured to create an interest message comprising a request for a data object and metadata specifying one or more criteria to be used by a network node for selecting a subset of a plurality of items when there is a match between the requested data object and the plurality of items. At least one of the one or more criteria is a preference specified for at least one of: factual properties of the plurality of items, usage data related to the plurality of items, usage data related to at least one communication interface of the network node, an effort to obtain data from another network node, and a position in a range specified in the interest message. The processor <NUM> is further configured to transmit the interest message on the communication interface <NUM>.

In the embodiment of <FIG>, the processor <NUM> is configured to determine whether a plurality of data objects in the memory <NUM> of the network node matches the requested data object and select one of the plurality of data objects by applying the one or more criteria and return the selected data object in a data message on the communication interface of set of communication interfaces <NUM> if the plurality of data objects has been determined to match the requested data object. In other words, the invention is applied as part of the data selection strategy. The selection can be performed if at least one of the one or more criteria is a preference specified for at least one of: factual properties of the plurality of data objects, usage data related to the plurality of data objects, and a position in a range specified in the interest message.

In the embodiment of <FIG>, the processor <NUM> is further configured to record a time at which the selected data object is returned upon returning the selected data object in the data message and record a number of times the selected data object has been returned upon returning the selected data object in the data message.

In the embodiment of <FIG>, the processor <NUM> is configured to determine whether the requested data object matches one or more prefixes in a forwarding table and whether the one or more matching prefixes are associated with a plurality of communication interfaces of the set of communication interfaces <NUM> and if the one or more matching prefixes are associated with a plurality of communication interfaces, select a subset of the plurality of communication interfaces by applying the one or more criteria and forward the interest message on the subset of the plurality of communication interfaces. In other words, the invention is applied as part of the data forwarding strategy. The selection can be performed if at least one of the one or more criteria is a preference specified for at least one of: usage data related to the at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in the interest message.

In the embodiment of <FIG>, when the requested data object is determined to match a plurality of prefixes in the forwarding table and if the interest message indicates a preference specified for a position in a range specified in the (e.g. name of the) interest message, this preference is used to select a subset of the prefixes. If each prefix is associated with at least one communication interface, this means that the matching prefixes are associated with a plurality of communication interfaces and that by selecting a subset of the matching prefixes, a subset of the (plurality of) communication interfaces is selected, although the communication interfaces in this subset are not necessarily (all) different.

If the interest message further indicates a preference for the use of (certain) usage data and/or for a certain (maximum) effort to obtain data from another network node, this preference or these preferences can be used to select a subgroup of the subset of communication interfaces, i.e. to reduce the subset even further. If the interest message does not specify a criterion which can be used to select a subgroup of the subset of communication interfaces, the interest message may be forwarded on all communication interfaces of the subset. If the subset comprises multiple instances of the same communication interface, the interest message only needs to be forwarded once on this communication interface.

In the embodiment of <FIG>, the processor <NUM> is further configured to record a time at which a data message is received on a communication interface upon receiving the data message on the communication interface and record a number of times data messages have been received on a communication interface upon receiving a data message on the communication interface.

<FIG> depicts an example in which a 'commercial' user (i.e. interested in passenger flights) requests information regarding the flight schedule of Schiphol airport in Amsterdam using an interest with the name /Schiphol/flight_schedule. Upon receipt of this interest by network node <NUM> over the network (e.g. Internet) <NUM>, network node <NUM> will have to make a decision regarding which data to use from its CS stored in memory <NUM> to respond to this interest or (if it has no data) which interface to use to forward this interest on, based on its FIB. The FIB may be stored in memory <NUM> as well.

In the example of <FIG>, the CS <NUM> of network node <NUM> is populated as follows:.

The incoming interest therefore matches two entries of the CS (entries <NUM> & <NUM>). In the current NDN implementation, network node <NUM> would have selected a data object from its CS which would not always be the desired data object. If a strategy of selecting the data object based on alphabetic order would have been followed by network node <NUM>, it would have resulted in the return of the data object /Schiphol/flight_schedule/cargo, which is not the data object the requesting node <NUM> desires (as its user is a commercial user).

Assuming that most users requesting this information are 'commercial' users (individual persons using commercial flights are orders of magnitude more than companies using cargo flights), this is not the desired data object for the majority of requesting nodes, which would hence need to transmit an additional interest message in order to retrieve the desired data object.

For this reason, the network node <NUM> has been configured to be able to decide better which of the multiple matches in its CS to return. In the embodiment of <FIG>, the network node <NUM> decides this based on usage data on request of the requesting node <NUM>. Since likely the flight schedule for commercial flights is accessed much more frequently (and probably more recently) than the flight schedule for cargo flights, a strategy that uses the Most Frequently Used (MFU) or Most Recently Used (MRU) statistics results in the return of the data object /Schiphol/flight_schedule/commercial. In most cases, returning that data object result in faster user satisfaction and less interest message retransmissions. Use of the MFU statistics comprises selecting the matching data object with the highest number of times this data object has been returned in this case. Use of the MRU statistics comprises selecting the matching data object with the most recent recorded time at which this data object was returned in this case.

If the network node <NUM> would have had no matching data objects in its CS, the network node <NUM> would have had to decide over which communication interface to forward the incoming interest based on its FIB entries. In the example of <FIG>, FIB <NUM> of network node <NUM> is populated as follows:.

There are two interfaces that satisfy the criteria (f1 & f2, as specified in entry <NUM>) for the incoming interest and the decision of network node <NUM> depends on the applied forwarding strategy. In the current NDN implementation, network node <NUM> would have either only forwarded the interest message on one of these two interfaces (to the one with the lower cost) if the 'Best route' forwarding strategy would have been used or it would have forwarded the interest message on both interfaces if the 'Multicast' forwarding strategy would have been used.

Both of these outcomes are not optimal, as can be seen in CS <NUM> of the network node <NUM> and CS <NUM> of the network node <NUM>, respectively:.

In the first case ("Best route"' forwarding strategy), the interest message would have been forwarded over interface f1 to network nodes <NUM> and <NUM> and it would then have travelled longer in the network (than if the interest message had been forwarded to network node <NUM>) and would have returned a data object that is useless to the user, as the user is a commercial user and not interested in cargo. In the second case ("Multicast" forwarding strategy), the interest message would have been forwarded over both interfaces reaching network nodes <NUM>, <NUM> and <NUM> and this would have resulted in the return of the desired data object, but at the cost of imposing an increased load on the network by multicasting all interest messages.

For this reason, the network node <NUM> has been configured to be able to decide better which communication interface(s) to forward the interest name on. In the embodiment of <FIG>, the network node <NUM> decides this based on usage data on request of the requesting node <NUM>.

Similar as when selecting a data object from the CS, a strategy that uses the Most Frequently Used (MFU) or Most Recently Used (MRU) statistics may be used, which leads to the decision to forward the interest message over interface f2 and results in the desired data object /Schiphol/flight_schedule/commercial being returned by network node <NUM>. In this case, use of the MFU statistics comprises selecting a communication interface (from communication interfaces associated with the one or more prefixes which match the interest) on which data objects have been received the highest number of times. In this case, use of the MRU statistics comprises selecting a communication interface (from communication interfaces associated with the one or more prefixes which match the interest) on which a data object has been received most recently in this case.

If a matching prefix is associated with the communication interface on which the interest message was received, this communication interface is disregarded. Statistics may not only be gathered per interface with respect to received data objects, but also with respect to received interest messages. This helps in case interests received on a certain interface are often similar to each other, but not similar to interests received on another interface. In the example shown in <FIG>, if the network node <NUM> would be connected to the Internet and to an Intranet via different interfaces, it might be possible to determine from the interface on which the interest message is received (i.e. the incoming interface) whether the user is likely interested in commercial flights (if the interest message is received via the Internet), for example.

The network node <NUM> may be a network router, for example. The network node <NUM> may be a dedicated router or may be a user device performing network routing, for example. The network node <NUM> may be a mobile device, for example. In the embodiment shown in <FIG>, the network node <NUM> comprises one processor <NUM>. In an alternative embodiment, the network node <NUM> comprises multiple processors. The processor <NUM> of the network node <NUM> may be a general-purpose processor, e.g. an Intel or an AMD processor, or an application-specific processor, for example. The processor <NUM> may comprise multiple cores, for example. The processor <NUM> may run a Unix-based or Windows operating system, for example. In the embodiment shown in <FIG>, the network node <NUM> comprises one device. In an alternative embodiment, the network node <NUM> comprises multiple devices.

The set of communication interfaces <NUM> may comprise one or more optical ports, one or more wireless transceivers and/or one or more Ethernet ports, for example. The set of communication interfaces <NUM> may comprise one or more internal interfaces, for example. If the network node <NUM> is running both a client and a server, the client and the server may use an internal communication interface to exchange interest messages and data messages, for example. An internal communication interface may comprise a Unix domain socket and/or an inter-process communication socket, for example. In the embodiment of <FIG>, the processor <NUM> uses the set of communication interfaces <NUM> to communicate with network nodes <NUM> and <NUM> and to access the network <NUM>.

The memory <NUM> may comprise one or more magnetic hard disks, one or more optical drives, and/or one or more solid state memories, for example. The memory <NUM> may be used to store data objects (as part of data message and/or separately) and/or other information like a Pending Interest Table (PIT) and a Forwarding Information Base (FIB), for example. The collection of stored data objects may be referred to as a Content Store (CS). The network nodes <NUM> - <NUM> may comprise a processor configured in the same way as the processor <NUM> of network node <NUM>.

The requesting node <NUM> may be a user device, for example. The requesting node <NUM> may be a laptop, a tablet, a mobile phone, a device embedded in a vehicle or a vehicle, for example. The requesting node <NUM> may further comprise a display. In the embodiment shown in <FIG>, the requesting node <NUM> comprises one processor <NUM>. In an alternative embodiment, the requesting node <NUM> comprises multiple processors. The processor <NUM> of the requesting node <NUM> may be a general-purpose processor, e.g. an Intel or an AMD processor, or an application-specific processor, for example. The processor <NUM> may comprise multiple cores, for example. The processor <NUM> may run a Unix-based operating system, for example.

The communication interface <NUM> may comprise a wired and/or wireless (e.g. cellular and/or WiFi) data transceiver for example. The requesting node <NUM> may further comprise other components typical for a user device, e.g. a power supply. The memory <NUM> may comprise one or more magnetic hard disks, one or more optical drives, and/or one or more solid state memories, for example. The memory <NUM> may be used for storing received data objects and/or for storing a PIT, for example.

<FIG> shows second embodiments of the network node and the requesting node, which are part of a vehicular network. <FIG> depicts an Intelligent Transportation System (ITS) paradigm which utilizes NDN networking over V2X Communication. In the embodiment shown in <FIG>, the requesting node <NUM> is used in a vehicle. For example, the requesting node <NUM> is a vehicle, is embedded in a vehicle or is a (e.g. mobile) device used in a vehicle. The requesting node <NUM> and vehicles <NUM> to <NUM> are located at or near a first intersection and transmit their position and possibly other information like their speed to the network node <NUM> via base station <NUM>. Vehicles <NUM> to <NUM> are located at or near a second intersection and transmit their position and possibly other information like their speed to the network node <NUM> via a base station <NUM>. One or more of the vehicles <NUM> to <NUM> and <NUM> to <NUM> may comprise a processor configured in the same way as the processor <NUM> of requesting node <NUM>. The network node <NUM> may comprise a processor configured in the same way as the processor <NUM> of network node <NUM> (see <FIG>).

In the embodiment shown in <FIG>, the vehicles have the functionality of both requestor and producer. The vehicles have the capability of wirelessly communicating among them and are connected to a (backbone) network <NUM> through wireless communications with base stations (or alternatively Road Side Units). <FIG> is used to illustrate how the invention can be used to enhance the efficiency of Range Name Components (RNCs).

In the embodiment shown in <FIG>, the vehicle comprising requesting node <NUM> is heading East on the main road and would like to know what the current speed is of vehicles at the next intersection. Even though the navigation functionality that the vehicle has onboard may allow it to be aware of the exact geographical latitude (Lat) and longitude (Long) of that intersection (in this case Lat = <NUM>, Long = <NUM>), it is not desirable to issue an interest message with these exact coordinates in its name, as it is not certain that another vehicle is positioned at those exact coordinates and can (or has in the recent past) produce data to satisfy this interest message. A more desirable approach is for the requesting node <NUM> to issue an RNC interest message, which would allow it to request the current speed of any other vehicle that is "close enough" to the intersection of interest. Using this approach the requesting node <NUM> may issue an RNC interest message with the following name: <MAT>.

This interest message requests the current speed of any vehicle whose geographical coordinates satisfy the limits of the respective range, hence increasing its chances of receiving a data message in response.

The RNC interest message issued by requesting node <NUM> is received by base station <NUM> and reaches network node <NUM> through network node <NUM>. Network node <NUM> receives ITS data from all vehicles around the selected intersection, in particular the vehicles with a latitude between <NUM> and <NUM> and a longitude between <NUM> and <NUM> (indicated as area <NUM> in <FIG>), through base station <NUM> and has some of the requested data in its CS. Alternatively, network node <NUM> might not have any data in its CS, but may then be able to forward the RNC interest message to the appropriate vehicle through base station <NUM>, based on the geographical range specified in the interest message. In the example depicted in <FIG>, the CS <NUM> of the network node <NUM> is populated as follows:.

There are multiple vehicles with geographical coordinates in the requested range of the RNC interest which could return a data message containing their current speed. With legacy NDN, there is no guarantee that network node <NUM> would return the most suitable data object among the multiple matches in its CS.

For example, network node <NUM> may decide to return the current speed of vehicle <NUM> (car <NUM>) as data object, since its geographical coordinates fall in the range requested by requesting node <NUM>. However, this is not the optimal data object to be returned, as vehicle <NUM> (car <NUM>) is the furthest one from the intersection (from the vehicles with geographical coordinates that fall in the specified range) while vehicle <NUM> (car <NUM>) is much closer to the intersection and has the same heading as the vehicle comprising requesting node <NUM>, making it a much better fit for the interest of requesting node <NUM>.

By allowing the requesting node <NUM> to specify a position in the range in the metadata of the interest message, the requesting node <NUM> may, for example, be able to define that it is interested in the requested range with a preference for data items closer to its average/median (or closer to the minimum, or maximum), thereby receiving the best fitting data. Alternatively or additionally, network node <NUM> might be able to select more appropriate matches for the range requests based on usage data (e.g. in rush hour most requests will be for a certain heading). The network node <NUM> may use further information specified in the metadata in combination with the usage data gathered at the network node <NUM>. This further information may comprise the heading of the vehicle that issued the interest message, the geographical coordinates of the vehicle that issued the interest message and/or the time at which the vehicle issued the interest message, for example.

Similar criteria may be applied to select a subset from a plurality of communication interfaces associated with one or more matching prefixes in the FIB when forwarding the interest message. With Range Name Components and legacy NDN, if network node <NUM> does not have a matching data object in its CS and needs to forward the interest message, a returned data object may meet the range criteria, but is likely not the most suitable data object. Applying the one or more criteria in order to select a subset of communication interfaces has similar advantages as applying the one or more criteria to select from multiple matching data objects in the CS.

For example, if the interest name is "/ITS/Lat={<NUM>:<NUM>}/Long={<NUM>:<NUM>}/Speed", the metadata specifies a preference for a position closest to the center of the range and the prefixes in the FIB specify "/ITS/Lat=<NUM>" for car1, "/ITS/Lat=<NUM>" for car2 and "/ITS/Lat=<NUM>" for car3, then the interest message is forwarded on the communication interface associated with car2 (whose longitude of <NUM> is closest the center of the range: longitude <NUM>).

Embodiments of the methods of transmitting and receiving an interest message are shown in <FIG>. A step <NUM> comprises a requesting node <NUM> creating an interest message comprising a request for a data object and metadata specifying one or more criteria to be used by a network node for selecting a subset of a plurality of items when there is a match between the requested data object and the plurality of items. At least one of the one or more criteria is a preference specified for at least one of: factual properties of the plurality of items, usage data related to the plurality of items, usage data related to at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in the interest message. A step <NUM> comprises the requesting node transmitting the interest message.

A step <NUM> comprises a network node <NUM> receiving the interest message. A step <NUM> comprises the network node checking whether the interest, in this embodiment the name specified in the interest message, is already present in the PIT. If the interest is already present in the PIT, the process with respect to this interest message will stop and the network node will continue to wait for a data message in response to a previously transmitted interest message. If the interest is not present in the PIT, step <NUM> is performed next. Step <NUM> is optional. For example, no PIT may be used in an alternative embodiment. Steps <NUM> and <NUM> comprise the network node determining whether there is a match between the requested data object and a plurality of items, steps <NUM> and <NUM> comprise the network node selecting a subset of the plurality of items by applying the one or more criteria if the match has been determined to exist. Steps <NUM>, <NUM>, <NUM> and <NUM> are described in more detail in the next paragraphs.

Step <NUM> comprises the network node determining whether a plurality of data objects in the CS matches the requested data object, in this embodiment the name specified in the interest message. If a plurality of data objects has been determined to match the requested data object, step <NUM> is performed next. Step <NUM> comprises the network node selecting one of the plurality of data objects by applying the one or more criteria. Step <NUM> requires that at least one of the one or more criteria is a preference specified for at least one of: factual properties of the plurality of data objects, usage data related to the plurality of data objects, and a position in a range specified in the interest message.

If none of the data objects in the CS matches the requested data object, step <NUM> is performed next. If only one of the data objects in the CS matches the requested data object, this one data object is returned in a data message in step <NUM>. Otherwise, the data object selected in step <NUM> is returned in a data message in step <NUM>. Step <NUM> comprises the requesting node receiving the data message.

Step <NUM> comprises the network node determining whether the requested data object matches one or more prefixes in the FIB and whether the one or more matching prefixes are associated with a plurality of communication interfaces. Normally, a default route is configured and a requested data object therefore matches at least one prefix in the FIB. If the one or more matching prefixes are associated with a plurality of communication interfaces (e.g. if the requested data object matches a plurality of prefixes), step <NUM> is performed next. If the one or more matching prefixes are associated with only one communication interface, the interest message is forwarded on this one communication interface in a step <NUM>.

Step <NUM> comprises the network node selecting a subset of the plurality of communication interfaces by applying the one or more criteria. Step <NUM> requires that at least one of the one or more criteria is a preference specified for at least one of: usage data related to the communication interfaces of the network node, an effort to obtain data from another network node, and a position in a range specified in the interest message. Next, step <NUM> comprises the network node forwarding the interest message on the selected communication interface(s).

Step <NUM> further comprises the network node adding the interest to the PIT. Step <NUM> comprises the network node receiving a first data message comprising a first data object in response to the forwarded interest message. Next, the network node forwards the first data message to the requesting node in step <NUM>. The interest added to the PIT in step <NUM> is removed from the PIT in step <NUM>.

In the example shown in <FIG>, the interest message is forwarded on three communication interfaces and a data message is received back on these three communication interfaces. Step <NUM> comprises the network node receiving a second data message which comprises a second data object in response to the forwarded interest message. Step <NUM> comprises the network node receiving a third data message which comprises a third data object in response to the forwarded interest message. The second and the third data objects are not returned to the requesting node.

The following criteria may be beneficial for selecting one from a plurality of data objects in a CS:.

The number of child nodes associated with a data object may be calculated by determining the highest hierarchical level to which the data object belongs, but which is not specified in the interest name, and determining the number of data objects belonging to this hierarchical level. For example, if an interest message specifies the interest name "/schiphol", then the data objects named "schiphol/flight_schedule/cargo" and "schiphol/flight_schedule/commercial" in the CS <NUM> of network node <NUM> of <FIG> are associated with two child nodes (hierarchical level "flight_schedule" has two data objects belonging to it) and the data object named "schiphol/lostNfound/commercial" in the CS <NUM> is associated with one child node (hierarchical level "lostNfound" has one data object belonging to it).

Alternatively or additionally, RNC interest messages may specify a criterion which indicates a preference for an item matching a certain part of the specified range, such as:.

For example, in case a requesting node issues an interest message with the name: /NL/airtraffic/Arrivals_Schedule and there are <NUM> matches in a network node's CS with the names /NL/airtraffic/Arrivals_Schedule/Schiphol-Amsterdam and /NL/airtraffic/Arrivals_Schedule/Eindhoven, they are both good candidates, but if the metadata of the issued interest message specifies a preference for the most frequently used item (and assuming that the arrivals schedule in Schiphol-Amsterdam is more popular because that's a bigger airport), then the /Schiphol-Amsterdam variant is returned.

The following criteria may be beneficial for selecting a subset from a plurality communication interfaces associated with one or more matching prefixes in a FIB:.

If the requested data object, e.g. the name of the interest, matches a plurality of prefixes, this criterion may be used to select a subset of the plurality of prefixes and thereby a subset of the plurality of communication interfaces. This criterion may be applied to an RNC interest message if the range relates to a part of the prefix, e.g. if the interest name specifies "/ITS/Lat={<NUM>:<NUM>}/Long={<NUM>:<NUM>}/Speed" and the prefix in the FIB specifies "/ITS/Lat=<NUM>".

For example, in case a requesting node issues an interest message with the name: /temperature/Amsterdam/Kalverstraat and there are <NUM> matches in the FIB with the names /temperature/Amsterdam/Kalverstraat/streetnumber/<NUM> and /temperature/Amsterdam/Kalverstraat/streetnumber/<NUM>, they are both good candidates, but if data objects received on the communication interface associated with the /streetnumber/<NUM> prefix are on average located <NUM> hops away and if data objects received on the communication interface associated with the /streetnumber/<NUM> prefix are on average located one hop away, then the communication interface associated with the /streetnumber/<NUM> prefix is selected for forwarding. Information on how many hops away data objects received on a communication interface associated with a prefix are on average located may be stored in the FIB in relation to the prefix or may be stored elsewhere in relation to the communication interface, for example.

<FIG> depicts a block diagram illustrating an exemplary data processing system that may perform the methods as described with reference to <FIG>.

Examples of input devices may include, but are not limited to, a keyboard, a pointing device such as a mouse, or the like.

Claim 1:
A network node (<NUM>) for an Information Centric Networking architecture, comprising:
at least one communication interface (<NUM>); and
at least one processor (<NUM>) configured to:
- receive, from a requesting node, on a communication interface of said at least one communication interface (<NUM>), an interest message for requesting a data object, said interest message comprising a request for a data object and metadata, said metadata specifying one or more criteria to be used for selecting a subset of a plurality of items,
- determine whether there is a match between said requested data object and a plurality of items, and
- select a subset of said plurality of items by applying said one or more criteria if said match has been determined to exist,
wherein at least one of said one or more criteria is a preference specified for at least one of: factual properties of said plurality of items, usage data related to said plurality of items, usage data related to said at least one communication interface, an effort to obtain data from another network node, and a position in a range specified in said interest message.