INFORMATION CENTRIC NETWORK

Technical field

The present application relates to a method in a serving node, a computer-readable medium, and a node in an information centric network.

Background

Information Centric Networking (ICN) [icnrg.org] is a new networking paradigm.

Content Centric Networking (CCN) [ccnx.org] is one approach within the ICN paradigm. Instead of focusing on connecting communicating endpoints (as traditional networking protocols, such as IP, do), it focuses on the content object that should be retrieved. In ICN networking, messages are routed based on the globally unique names of content objects rather than on endpoint addresses referring to physical boxes (as is the case with TCP/IP). A very brief overview of key features of the CCN embodiment of ICN is provided immediately below.

In CCN [1] [2], a content object is retrieved by issuing an Interest message to the network containing the name of the content object. Such a message is routed by the network towards the source/ publisher of the object. Nodes along the path check if they have a cached copy of the object. If so they will respond to the Interest message with a Content Object message containing the requested content object and the Interest message will not be propagated any further. The routing is helped by making the name a structured name (similar to domain names, but with richer syntax). Routers maintain a Forwarding Information Base (FIB) about where to forward which name or name prefix of an Interest. The routers along the path of the Interest message keep a record of the Interest messages they have forwarded (where it came from and what content object it was naming) in their Pending Interest Table (PIT). If other Interest messages with the same name arrive at the router, it does not forward them but just notes them and the interface over which they arrived in the PIT besides the entry for this name. This is called Interest aggregation, preventing needless propagation upstream of the same Interest. In this way, the PIT entries for the same name may form a tree in the network with receivers at the leaves. When the Interest message reaches an endpoint (or router) having a copy of the content object (perhaps cached), the Interest message is responded to with a Content Object message, with the content as its payload, and is propagated backwards along the path the Interest message took. The backward path is learned from the entries the Interest message left in the PIT of the routers along the path. If there were multiple Interests arriving at a router for this name, as identified in the PIT, the Content Object message containing the content object is replicated towards each direction where the Interest messages came from.

The Content Object is cached in the Content Store (CS) of an intermediate router, so as to be able to serve future Interests with that name directly from the router rather than forwarding the Interest towards the publisher. After forwarding a Content Object matching a pending Interest, the routers delete the corresponding entry in the PIT; thus these entries are expected to be short-lived. When the original endpoint(s) generating the Interest message(s) receive the Content Object the transaction is considered closed. One benefit of CCN is the ability to send the same information to multiple places in the network. Since routers may cache Content Objects in a Content Store at every router besides forwarding them, Content Objects need not be served from the original publisher and thus traverse the entire network every time a new requester becomes interested in them - a local cached copy suffices. Another advantage with CCN is the aggregation of Interest messages. In the case of a flash crowd event, where suddenly thousands of endpoints request the same content, the source will only be reached by one request for the content, while all other requests will be served from the Content Store caches of routers along the path towards the source.

A critical feature needed for Web and media traffic is to understand at least how many requests have been received for a given resource (a web page, a video etc.) and ideally by whom these requests were made. This is of great commercial value as such

measurements are used to set advertising rates, determine the cost allocated by the content providers to the business entities (such as CDNs) that serve the content, etc. These measurements are also necessary for network and infrastructure planning.

As CCN objects can be served from the Content Store (CS) of an intermediate CCN node which may have been in the path of an initial request for an object, and indeed this is the primary efficiency advantage of CCN that is often cited, a publisher therefore loses any visibility on the number of requests and, indeed, any information on the nature of its consumers. Similarly, Interest aggregation at an intermediate node, should it happen based on a large number of request for the same object (e.g., in a flash crowd situation) resulting in a single Interest reaching the publisher, offers no information on the number of aggregated requests it subsumed. Thus, the publisher of a content item has no way to ascertain independently the number of requests for its published content.

Figure 1 illustrates this loss of visibility in a CCN node 100 comprising a pending interest table 110, a content store 120 and a forwarding information base 130. CCN node 100 further comprises a plurality of incoming interfaces 140 and a plurality of outgoing interfaces 150. When an incoming Interest for a named object is received, the Content Store (CS) 120 is consulted to see if the object might have been cached (owing to a previous request for the same object). Steps 1-4 show how an Interest for object with <namel > is served directly from the content store 120. Thus, the publisher does not know that this request was received and served. Subsequent requests for the same object would be similarly served, and also remain uncounted by the publisher.

For an incoming Interest for a named object that is not in the CS 120, the Pending Interest Table (PIT) 110 is consulted to see if there is an Interest already sent for that named object. In Figure 1, the (first) Interest for object with <name2> (step 5) is not in the CS 120 (step 7), nor the PIT 110. Its incoming interface 12 is therefore added to the PIT 110 (step 8) and an outgoing Interest is routed appropriately upstream (step 9) by the Forwarding information base (FIB) 130 and the outgoing interface for that Interest is recorded in the PIT 110 (step 10). Note that a second Interest for the same named object arriving over interface 13 (step 6) follows the same path until step 8, where the incoming interface 140 for this Interest is recorded in the PIT 110. As an Interest for that same content has already been sent, no additional Interest is sent upstream. Thus, once again the publisher is unaware that there is another Interest for that content. This repeats for every other Interest for that same named content. Such Interests could indeed be a large number, as would be the case with very popular content.

Finally, for completeness, when the Content Object for the pending Interest with <name2> is received (step 11), a check is made in the PIT 110 that there was indeed a previous request (step 12) for that named object which is further consulted to see if there are any pending Interests for that named object, which is the case in this example. The received content object is cached (step 13) in content store 120 and all the pending Interests for the object with <name 2> are then served (steps 14-15) over their respective incoming interfaces 140. The publisher remains unaware that one request for a content item served multiple Interests. In fact, the Interest (step 9) might have been served by a cache upstream from this CCN node 100, in which case the publisher remains quite unaware of all these requests. Subsequent requests for the object with <name2> will be served from the CS 120, again without the knowledge of the publisher.

Summary

A solution to the above described problem of how to record an accurate measurement of the number of Interests served by intermediate CCN nodes is presented herein. The solution addresses both the situation where a named content object is served from the content store of an CCN node and the situation where a plurality of Interest messages are aggregated by the PIT and then served from the local content store CS. Accordingly, there is provided a method in a node of an information centric network, the method comprising: receiving a request for a content object from a requesting node; retrieving the content object from a local content store; returning the content object to the requesting node; and sending a measurement message to a measurement node. The measurement node may be an upstream node, a measurement server, or the publishing server for the named content object. The named content object may indicate where a measurement message should be sent. The named content object may include the address of the measurement node. By sending a measurement message when a content object is served from a local content store of a serving node, the serving node can efficiently inform a content publisher that a client device has accessed their content. Thus, a content publisher can learn how popular its content is. This functionality is important to content publishers using today's non ICN internet, and it is important that an ICN network can provide this functionality. The method may further comprise identifying whether the content object comprises a measurement indicator, and sending a measurement message to a measurement node dependent on the value of the measurement indicator.

The method may further comprise sending a request message to an upstream node if the content object is not stored in the local content store; receiving the content object from the upstream node; and storing the content object in the local content store. The method may further comprise storing the request message in an interest table if the content object is not stored in the local store.

The measurement message may comprise at least one of: information about the serving node; information about the requesting node; the incoming interface from which the request for the content object was received; the date and time when the content object was returned to the requesting node; the number of request messages for the content object that were answered by the node; the named object identifying an address to which the measurement message must be sent; a hash of the message payload, encrypted by the public key of the publisher; an indication that the lifetime of the measurement message within a node is zero; and a just forward indicator.

In one embodiment, the measurement message comprises: the named object identifying an address to which the measurement message should be delivered; information about the serving node; the date and time when the content object was returned to the requesting node; the number of request messages for the content object that were answered by the node; an indication that the lifetime of the measurement message within a node is zero; and a just forward indicator.

When a CCN node receives an Interest message or measurement message comprising a "just forward" indicator, that message is sent directly to the FIB for onward routing to another node, without checking the CS and the PIT. In contrast, an Interest message or measurement message without the "just forward" indicator, when received at the CCN node, causes that node to check the CS and FIB, and of the requested content object is cached in the CS, then that content object is returned and the message is not forwarded to another node. The "just forward" indicator prompts the CCN node to bypass some of the steps involved in the processing of a message without the "just forward" indicator. A message marked "just forward" is neither aggregated nor stored in the PIT in anticipation of a response.

Accordingly, there is provided a method in a serving node of an information centric network the method comprising: receiving a request for a named content object from a requesting node; and if the received request comprises a just forward indicator, then sending the request to another node.

There is further provided a serving node of an information centric network the serving node arranged to: receive a request for a named content object from a requesting node; and if the received request comprises a just forward indicator, then send the request to another node.

The request may be sent to another node according to the usual routing procedure employed by the CCN node.

There is further provided a computer-readable medium, carrying instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined herein.

There is further provided a node in an information centric network, the node

comprising: an input for receiving a request for a content object from a requesting node; a local content store from which the content object is retrieved; an output for sending the content object to the requesting node and for sending a measurement message to a measurement node.

The node may further comprise a processor for identifying the content object as comprising a measurement indicator, wherein a measurement message is sent to a measurement node only if the content object comprises a measurement indicator.

The processor may be arranged to check if the content object is stored in the local content store, and if it is not, then a request message is sent to an upstream node via the output. The input may be further arranged to receive the content object from the upstream node. The local content store may be arranged to store the received content object. The node may further comprise an interest table for storing the received request message if the content object is not stored in the local store.

Brief description of the dr wings

A method and apparatus for improved content delivery measurement in an

information centric network will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 illustrates the problem content publishers face when trying to track consumption of their content in a content centric network;

Figure 2 illustrates an Interest message 200;

Figure 3 illustrates a measurement count message being sent from a CCN node;

Figure 4 shows measurement message flows in an information centric network; Figure 5 illustrates a method in a serving node of an information centric network; Figure 6 illustrates an alternative method in a serving node of an information centric network; and

Figure 7 illustrates a node in an information centric network.

Detailed description

The solutions presented herein include the following:

• A special one-way Interest message sent from a CCN node when it serves a content object from its CS or when a received named content object is sent to multiple receivers downstream because the CCN node has aggregated multiple Interests for the same named object. The message contains information about the node that served the content, the incoming interface (called "face" in the CCN terminology) over which the Interest was received, the date and time when such content was served and the number of Interests satisfied.

• Security measures to ensure that the measurement data returned is integrity protected and that intermediate nodes cannot read or alter the measurement data as identifying a particular content item. • A method for use in conjunction with untrusted intermediate networks by which a publisher can insert a small marker object which is identified as non-cacheable, the retrieval of which by an end user will signal to the publisher the request for the page in which it is embedded.

The proposed method requires that this special Interest message be sent from a CCN node under certain circumstances. An Interest message 200 is shown in Figure 2. The Interest message 200 comprises a name 210, metadata 220 and a payload 230. In the example shown, the name 210 is '/com/nytimes/measurement/encpu _N YTp ash of payload] ', where 'encpuK-NYTpiash of payload]' is the cryptographic hash of payload 230 using the encryption key PUK-NYT. The metadata field 220 comprises a lifetime field taking value Ό', and a JustForward field taking value 'TRUE'.

The payload 230 is encrypted using the encryption key PUK-NYT. The payload 230 is shown here comprising fields for the object served, the serving node's identifier, the interfaces (faces) at the serving node over which the content was served, the timestamp showing the time when the content was served and a count of the number of Interests served.

The measurement count message is expressed as an Interest 200 for a special measurement object 210, as chosen by the publisher, named for example

/com/nytimes/measurement. (Note that the publisher can advertise a well-known object name to serve as its sink for measurements, or a naming convention could be chosen to target a publisher's measurement "object". It could also be sent to a trusted third party that the publisher uses as its measurement service.)

Each Interest message carrying the measurement is made unique by appending a hash of the message payload 230, encrypted by the public key (in our example, PUK-NYT) of the publisher, to the measurement object name 210. This makes each such measurement count message unique and not aggregate-able at any intermediate CCN node. The publisher can compare the hash of the received payload with the one received in the name to ensure that the payload was not modified in transit. The metadata field 220 sets the lifetime of this Interest at every CCN node to zero, implying that it is a one-way message and that no response is expected. Thus, no state needs to be maintained at the node's PIT after this Interest is forwarded. An additional field, JustForward, with a Boolean value set to TRUE, requires that this Interest is sent directly to the FIB for onward routing on receipt at an intermediate CCN node without checking the CS and the PIT, as would be the case with a normal Interest message. This bypasses some of the steps involved in the processing of a "normal" Interest message at an intermediate node and avoids needless processing at these points in the usual request routing procedure at an intermediate CCN node, as this special type of Interest will neither be aggregated not stored in the PIT in anticipation of a response.

The payload field 230 of such an Interest message contains name-value pairs, as follows:

• The "Object" identifies the name of the content object about which the measurements are being reported;

· The "Node identifier", taking the format of a CCN name such as

/com/verizon/ny/node2, identifies the CCN node that originated the message, allowing the publisher to analyse the received counts against the "regions" from which the requests arise and gain appropriate insights;

• The "Count" reports the number of Interests served with that content object from the content store at that node; and

• The "Timestamp" provides the date and time at which such content was served. All these values are protected from tampering by encrypting the entire payload with the public key of the publisher. Figure 3 illustrates when a measurement count message is sent from a CCN node 300 to the publisher of a content item. A CCN node 300 comprising a pending interest table 310, a content store 320 and a forwarding information base 330. CCN node 300 further comprises a plurality of incoming interfaces 340 and a plurality of outgoing interfaces 350. CCN node 300 of Figure 3 operates in the same way as CCN node 100 of figure 1, the differences are described herein.

A content item CI is already present in the CS 320 and any received Interest for it causes the previously cached copy to be returned (see sequence 1-2-3-4 in Figure 3). Step 3a shows a measurement count message, which is an Interest message coded as shown in Figure 2, sent upstream to the publisher of CI at the same time that the content is returned downstream. The count is 1, and such a message is sent every time there is a new cache hit. Steps 11-12 show a received content item C2 that satisfies two pending Interests identified in the PIT. The content C2 is cached in the CS 320 (step 13) and the content C2 sent out on both the downstream interfaces 340 (steps 14 and 15). At the same time, a measurement message (step 14a) is sent upstream to the publisher to provide the count (2, in this example) of Interests that have been satisfied for the named content item. Thus, measurements are always sent after the content is served from the CCN node's CS 320, irrespective of whether these are individual or aggregated requests.

In the case of a general CCN node operating on the public CCN-based "Internet", such protocol behaviour for sending measurements as described above may be hard to enforce. For one thing, there will be a myriad content publishers and a general node may not be provisioned with the name of the reporting entity per content owner. (Of course, this opens up the possibility of third parties acting as measurement brokers, taking on the task of collecting data from network nodes and identifying the appropriate sources to which data should be reported.) The solution presented herein is directly applicable to a closed network, such as that offered by a cable or telco service provider, for example Comcast or Verizon, respectively. Such networks can prepare and name content they license using CCN guidelines, provision the name of the reporting entity in the CCN nodes in their networks and require that CCN nodes follow the measurement reporting protocol as described above. There is also a greater level of trust in the data received from such network nodes than would be the case of a general CCN node in the public network. Thus, it is possible to save processing by not encrypting the payload field of the measurement message when used inside a closed network. An alternative solution is shown at the end of this section to deal with the case of untrusted CCN

nodes/ networks, as may be the case when used CCN is used as a delivery mechanism on the Internet.

Figure 4 summarizes the various ways in which requests (Interest) for Content Objects can be satisfied and the flow of measurement count message towards the publisher arising as a consequence. Figure 4 shows an information centric network 400 comprising a plurality of CCN nodes 410 arranged to provide communication between a content publisher 420 and a plurality of client devices 450.

Figure 4 shows measurements (P, Q, M, and N) flowing through the ICN network 400 from different nodes 410 towards the content publisher (CP) 420 arising from serving Interests for a particular Content Object. The initial Interests resulting in these measurements are not shown. The initial Interest will always be served from the CP 420, so this does not need a measurement report. As more Interests are generated for that content item, the Content Stores (CS) in the CCN nodes 410 within the network en route to the CP 420 get populated so that subsequent Interests are served from the CS of those nodes, which are reported.

CCN1, CCN3 and CCN 5 in the figure report individual requests (P, N and Q

respectively) served from their CS for that content object. Similarly, CCN2 will report the initial aggregated Interests from CCN1 and CCN3 recorded in its PIT (or individual requests, if not at the same or close in time) during the startup phase when requests for the content item are flooding the network. Thus, as noted after Figure 3, measurements are always sent after the content is served from the CCN node's CS, irrespective of whether these are individual or aggregated requests.

The description provided thus far allows for measurements to be recorded for every content object. However, it is possible that not all content objects served need to be recorded/ measured and a publisher may seek to limit the measurements that it seeks, keeping those to only the ones that it deems significant. For example, a request for a web page consists of multiple content objects including images, text, Javascript, CSS-based page layout instructions, ad tags etc. The initial Interest for such a web page may return a manifest identifying such components, each to be returned via separate requests. A publisher may only be interested in a measurements of the overall page request and not each and every included component. For example, the measurement of an icon image served may not be very meaningful while that for an ad slot might be. Thus, to limit the number of measurement messages, a Content Object may include a measurement indicator as a metadata field which defaults to "do not measure" (or FALSE), i.e., the absence of such a field in a Content Object means that no measurement needs to be sent. This retains backward compatibility with current CCN. However, a Content Object with this measurement indicator field set to TRUE requires that a measurement report be sent if and when it is served.

Figure 5 illustrates a method in a serving node of an information centric network. The method comprises receiving 510 a request for a named content object from a requesting node, and retrieving 520 the named content object from a local content store. The method further comprises a returning 530 the content object to the requesting node; and sending 540 a measurement message to a measurement node. The named content object may indicate where a measurement message should be sent. The named content object may include the address of the measurement node.

By sending a measurement message when a content object is served from a local content store of a serving node, the serving node can efficiently inform a content publisher that a client device has accessed their content. Thus, a content publisher can learn how popular its content is. This functionality is important to content publishers using today's non ICN internet, and it is important that an ICN network can provide this functionality.

Figure 6 illustrates an alternative method in a serving node of an information centric network. The method comprises receiving 610 a request for a named content object from a requesting node, and retrieving 620 the named content object from a local content store. The method further comprises identifying 625 whether the content object comprises a measurement indicator. If the content object does not have a measurement indicator, then the serving node returns 645 the requested content object to the requesting node. If the content object does have a measurement indicator, then the serving node sends 640 a measurement message to a measurement node, and then returns 645 the content object to the requesting node.

The measurement indicator may comprise a field labelled measurement indicator, the field taking a value of true or false.

The above methods may further comprise sending a request message to an upstream node if the content object is not stored in the local content store; receiving the content object from the upstream node; and storing the content object in the local content store. Also, if the content object is not stored in the local store, then the serving node may store the request message in an interest table.

The measurement message may comprise at least one of: information about the serving node; information about the requesting node; the incoming interface from which the request for the content object was received; the date and time when the content object was returned to the requesting node; the number of request messages for the content object that were answered by the node; the named object identifying an address to which the measurement message must be sent; a hash of the message payload, encrypted by the public key of the publisher; an indication that the lifetime of the measurement message within a node is zero; and a just forward indicator.

In one embodiment, the measurement message comprises: an address to which the measurement message should be delivered; information about the serving node; the date and time when the content object was returned to the requesting node; the number of request messages for the content object that were answered by the node; an indication that the lifetime of the measurement message within a node is zero; and a just forward indicator. When a CCN node receives a measurement message comprising a "just forward" indicator, that message is sent directly to the FIB for onward routing to another node, without checking the CS and the PIT. In contrast, a general Interest message without the "just forward" indicator, when received at the CCN node, causes that node to check the CS and FIB following the normal processing rules for an Interest as described in [1]. The "just forward" indicator prompts the CCN node to bypass some of the steps involved in the processing of an Interest message without the "just forward" indicator. A message marked "just forward" is neither aggregated nor stored in the PIT in anticipation of a response. There is further provided a method in a serving node of an information centric network the method comprising: receiving a request for a named content object from a requesting node; and if the received request comprises a just forward indicator, then sending the request to another node. There is further provided a serving node of an information centric network the serving node arranged to: receive a request for a named content object from a requesting node; and if the received request comprises a just forward indicator, then send the request to another node.

The request may be sent to another node according to the usual routing procedure employed by the CCN node.

There is further provided a computer-readable medium, carrying instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined herein.

Figure 7 illustrates a node 700 in an information centric network the node comprising at least one input 740, a storage component 720, and at least one output 750. The node receives a request at input 740 from a requesting node, the request for a content object. Storage component 720 operates as a local content store from which the requested content object is retrieved. The node sends, from the output 750 both: the requested content object to the requesting node; and a measurement message to a measurement node.

Node 700 is shown comprising a processor 715 for identifying the content object as comprising a measurement indicator, wherein a measurement message is sent to a measurement node only if the content object comprises a measurement indicator. The processor 715 may be arranged to receive instructions which, when executed, causes the processor 715 to carry out the methods described herein. The instructions may be stored on a memory 725.

The processor 715 may be further arranged to check if the content object is stored in the local content store 720, and if it is not, then a request message is sent to an upstream node via the output 750. The input 740 is further arranged to receive the content object from the upstream node; and the local content store 720 is arranged to store the received content object. Node 700 may further comprise an interest table 710 for storing the received request message if the content object is not stored in the local store 720.

The measurement message may comprises at least one of: information about the node; information about the requesting node; the incoming interface from which the request for the content object was received; the date and time when the content was returned to the requesting node; the number of request messages for the content object that were answered by the node; an address to which the measurement message must be sent; a hash of the message payload, encrypted by the public key of the publisher; an indication that the lifetime of the measurement message within a node is zero; and a just forward indicator.

The solution described above requires trust that the deployed CCN nodes will provide the implementation of the measurement message with the associated protocol procedures for reporting. This is possible in a private network where the service provider can exercise control over the nodes deployed and can test these for proper behaviour. In the case of public CCN-based delivery networks, an alternative method is described below by which a publisher can be informed of its content consumption. The proposal here is that when a publisher wants to know if a certain (complex) object, e.g. a web page, is being accessed it includes a (small/invisible) object as a part of the overall webpage that is marked as something that must always be obtained from the publisher and not retrieved from any intermediate node (e.g., through Interest aggregation). This is done by using some scripting function, e.g. JavaScript, on the page that the client renders. This script will generate an Interest message for the "invisible" object with a random number appended to the message, making it unique, and therefore not aggregated en route. As these requests are unique, a good CCN implementation will not cache the pixel object returned.

Measurement of content usage is completely missing from the CCN specification. The solution presented herein provides a way to use the current specifications (specifically, a particular use of a one-way Interest message) with some additional features defined here to make it useful for real-life situations where the need to obtain a count of content served, with the "location" and time of such requests, are essential for a variety of business purposes including content consumption analytics. The solution presented herein defines a specific one-way Interest message which is sent upstream to the content publisher, confidentiality and integrity protected to serve this purpose. It defines a special field in this one-way Interest message, JustForward, that bypasses some way points in the normal processing path of an Interest message at an intermediate CCN node so that there is no needless processing of this message which isn't cached and for which no response is expected.

There is also presented herein a technique to retrieve an "invisible pixel" directly from the publisher which allows a measurement of content consumption in deployments where the CCN nodes cannot be trusted to implement the one-way Interest message for measurements defined herein, or the CP does not trust the values it receives.

The solution described herein allows the publisher of a content item to receive an accurate count of the number of requests for any content item it offers. This is done by a measurement node in an information centric network which measures the delivery of certain content objects. This allows for a publisher to know the demand for certain content within the network which is important for both technical and commercial reasons. It will be apparent to the skilled person that the exact order and content of the actions carried out in the method described herein may be altered according to the requirements of a particular set of execution parameters. Accordingly, the order in which actions are described and/ or claimed is not to be construed as a strict limitation on order in which actions are to be performed.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope The above described method may be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal Processor (DSP) or similar, causes the processor to carry out the hereinbefore described methods of requesting or sending named content items in an information centric network. Equally, the method may be embodied as a specially programmed, or hardware designed, integrated circuit which operates to carry out the method on video data loaded into the said integrated circuit. The integrated circuit may be formed as part of a general purpose computing device, such as a PC, and the like, or it may be formed as part of a more specialised device, such as a games console, mobile phone, portable computer device or hardware video encoder.

Another exemplary hardware embodiment of the present invention is that of a node in an information centric network comprising an Application Specific Integrated Circuit (ASIC). The client node may be a user apparatus. The client node may be any kind of personal computer such as a television, a smart television, a set-top box, a games- console, a home-theatre personal computer, a tablet, a smartphone, a laptop, or even a desktop PC.

Further, while examples have been given in the context of particular communications standards, these examples are not intended to be the limit of the communications standards to which the disclosed method and apparatus may be applied. For example, while specific examples have been given in the context of CCN, the principles disclosed herein can also be applied to any information centric communication network.

References

[1] CCNx Semantics:

https:/ / tools.ietf.org/html/ draft-irtf-icnrg-ccnxsemantics-02

[2] CCN Messages in TLV Format:

http:/ / tools.ietf.org/html/ draft-irtf-icnrg-ccnxmessages-02