WO2018001534A1

WO2018001534A1 - Cached content purging in an information centric network

Info

Publication number: WO2018001534A1
Application number: PCT/EP2016/071216
Authority: WO
Inventors: Nilo Mitra
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-07-01
Filing date: 2016-09-08
Publication date: 2018-01-04

Abstract

There is provided a method in a node of an information centric network, the method comprising: receiving an interest message from a node, the interest message identifying a named content object and comprising a delete flag; deleting the named content object from a local content store; checking an interest table for a record of a previous interest message identifying the named content object and comprising a delete flag, and, if no such entry is present in the interest table, then forwarding the received interest message to all interfaces, except the one by which it was received.

Description

CACHED CONTENT PURGING IN AN INFORMATION CENTRIC NETWORK

Technical field

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

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 in their Content Store (CS). 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.

Today, most content is delivered using CDNs which cache static and popular content "close" to end users to reduce latency and backbone traffic. However, there are often situations when CDNs are required to purge content that have become stale (e.g., an advertisement for a sale or promotion after the expiration date) or have become inaccurate (e.g., a breaking news item with early, incorrect information) or simply need to be silently replaced (e.g., a new version of a software binary). The current CDN technology based on HTTP offers many ways to ensure that content remains fresh by using HTTP cache control and expiration headers to invalidate cached content by providing a time after which the cache must explicitly check with the origin server to see if any replacement content is available.

A more serious situation that goes beyond invalidation of stale content is when explicit purging of content is required. A good example is when a content provider needs to take down some copyright protected content which it may have inadvertently or unknowingly served. Such instances are quite frequent with user generated content such as YouTube, where, despite best effort, songs or clips from copyrighted material are frequently inserted by end consumers into their uploaded media. In such cases, YouTube and similar services have to actively seek out and delete all copies from edge caches. (In the case of YouTube, this task is made easier because it typically has its own caches embedded deep within most ISP networks. Smaller content providers are offered interfaces by their CDN providers to delete content. The speed and granularity of deletion offered by such interfaces vary.)

There are also instances when, for purposes of security, content providers require that all copies of particular content items (e.g., a pay TV episode) be removed from all caches after playout is completed, to prevent these from being stolen and distributed illegally. ICN, especially its most popular manifestation, CCN, offers a more efficient delivery paradigm by caching content at all nodes through which a Content Object responding to an Interest for a content item traverses en route from the publisher to the requester. Such Content Objects can be marked by the publisher as "not cacheable" or provided with an expiration time after which the item is removed from the Content Store.

However, the vast majority of content items are expected to be cached if this networking paradigm is to achieve its claimed benefits. Unfortunately, there is no method by which a publisher can explicitly search an ICN/ CCN network for content items that might be stored and ask for these to be deleted. Without such a technique, it will be difficult for a content provider to respond effectively to "take down" notices from copyright holders (as described in the previous paragraph) and allow the CCN network provider to remove content items upon request.

Also, there are cases where a publisher may have published a content item with a time to live that is large, expecting that the content will not change within that period. However, it realizes that this is not a good assumption and needs to update the content. Deleting the old content and advertising a new content item with a changed time-to-live (TTL) is one valuable option. Again, content deletion is needed if the caches are not to be burdened with stale copies taking up valuable space.

Finally, there may be instances when a publisher wishes to silently replace one content item with another without the operational complexity of creating a new name for the changed content item and advertising it. An example could be a software update which a publisher decides needs an update shortly after publication. Rather than embarrass itself and annoy its users by sending out too frequent patches, it silently replaces the published patch with a newer version. Older versions previously requested and served will continue to work, but new requests will get the updated version. At some later point, the publisher can consolidate all these plus additional updates into a new version that it advertises. Summary

The solution proposed herein defines a new field in a one-way Interest message which indicates that the content item identified by the name should be deleted. This Interest message, made one-way by setting its Lifetime field to zero, is sent in the reverse direction from usual requests for content— that is, it is sent from the publisher of that content item into an ICN/ CCN network. This flag with the value "delete" causes the invocation of an alternative (compared to the normal) processing path through a CCN node, by which the Content Store is searched for the named content item, which, if found, is deleted. The message is then forwarded (not routed) on all outgoing interfaces at that node except the one over which it was received. The process is repeated at every node which receives such a message. A procedure is defined to ensure that the changes to normal CCN processing are minimized, and that needless messages are not sent through the network. By following the procedures outlined below, all nodes are reached and the content item purged from each node's cache. While not strictly necessary compared to the most important use case described above, the solution also offers the opportunity to replace one content item with another with the same name at a cache. This is done by using the same procedure as above but with this new flag taking the value "delete and replace". The payload of this Interest message contains either the replacement content object or a link to the replacement content object, which must be retrieved and cached as replacement of the deleted object. This might be useful for example when a publisher wishes to silently replace one piece of content with another without the operational complexity of creating a new named object and advertising it.

Accordingly, there is provided a method in a node of an information centric network, the method comprising: receiving an interest message from a node, the interest message identifying a named content object and comprising a delete flag; deleting the named content object from a local content store if present therein; checking an interest table for a record of a previous interest message identifying the named content object and comprising a delete flag, and, if no such entry is present in the interest table, then forwarding the received interest message to all interfaces, except the one by which it was received. By keeping a record of received interest messages comprising delete flags, the node of an information centric network is able to disseminate a message with a delete flag to connected nodes, without undue propagation and repetition, thus limiting signaling overhead. Importantly, this mechanism allows a content publisher to update a content object and remove old versions of that content object from nodes within the information centric network.

The method may further comprising checking if the named content object in the received interest message is present in the local content store, and deleting the named content object from the local content store only if it is present.

The received interest message may also contain a selector field, wherein the method further comprises checking that the selector field matches that of the stored named content object before deleting that stored named content object from the local content store. Such a selector field may be the Content Object Hash Restriction, whereby the hash of the received Content Object must match the hash provided in the Interest message. Alternatively, the selector field may comprise the KeylD, whereby the KeylD is the public key of the publisher used to validate the signature of the received content object. The method may further comprise storing the selector fields, if present, in the interest table for an Interest and subsequently checking that the received content object meets the conditions set by the selector fields.

If the interest table does have a record of a previous interest message identifying the named content object and comprising a delete flag, then the method may comprise adding the interface upon which the received interest message was received to that record in the interest table. If the node has already received an interest message naming the content object and including a delete flag, the interest message is not propagated onwards, but a record of the node from which the interest message was received is added to the interest table.

The received interest message comprises a delete and replace flag, wherein the payload of the received interest message comprises a link to an updated content object, and wherein the method further comprises sending an interest message for an updated content object to replace the deleted content object. Typically, a content object must be removed because a new and updated version is available. If the content object was cached at the node, then it is likely that the updated version will be requested again, and that request can be anticipated by replacing the old content object with the updated version. The method may further comprise checking if the named content object in the received interest message is present in the local content store and sending an interest message for an updated content object to replace the deleted content object only if it is present. If the content object was not present in the local content store, then a replacement is unlikely to be required.

The method may further comprise receiving an updated content object and storing it in the local content store. The received interest message may comprise a delete and replace flag, and wherein the payload of the received interest message comprises an updated content object to replace the deleted content object, and wherein the method further comprises: storing the updated content object in the local content store.

The method may further comprise checking if the named content object is present in the local content store and deleting the named content object from the local content store only if it is present. The method may further comprise checking if the named content object in the received interest message is present in the local content store and storing the updated content object in the local content store only if it is present.

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 interface for receiving an interest message from another node, the interest message identifying a named content object and comprising a delete flag; a local content store where content objects are stored; a processor arranged to delete the named content object from the local content store. The node further comprises an interest table which is checked for a record of a previous interest message identifying the named content object and comprising a delete flag, and, if no such entry is present in the interest table, then forwarding the received interest message to all interfaces, except the one by which it was received.

By keeping a record of received interest messages comprising delete flags, the node of an information centric network is able to disseminate a message with a delete flag to connected nodes, without undue propagation and repetition, thus limiting signaling overhead. Importantly, this mechanism allows a content publisher to update a content object and remove old versions of that content object from nodes within the information centric network. The received interest message may also contain a selector field, wherein the processor is further arranged to check that the selector field matches that of the stored named content object before deleting that stored named content object from the local content store. Such a selector field may be the Content Object Hash Restriction, whereby the hash of the received Content Object must match the hash provided in the Interest message. Alternatively, the selector field may comprise the KeylD, whereby the KeylD is the public key of the publisher used to validate the signature of the received content object. The node may be further arranged to store the selector fields, if present, in the interest table for an Interest and subsequently checking that the received content object meets the conditions set by the selector fields. If the interest table does have a record of a previous interest message identifying the named content object and comprising a delete flag, then the node may add the interface upon which the received interest message was received to that record in the interest table.

The received interest message may comprise a delete and replace flag, wherein the payload of the received interest message comprises a link to an updated content object, and which additionally causes the node to send an interest message for an updated content object to replace the deleted content object.

The processor is further arranged to check if the named content object is present in the local content store and to sending an interest message for an updated content object to replace the deleted content object only if it is present. The node may be further arranged to receive an updated content object and store it in the local content store.

The received interest message may comprise a delete and replace flag, and wherein the payload of the received interest message comprises an updated content object to replace the deleted content object, and wherein the local content store is arranged to store the updated content object. The processor may be further arranged to check if the named content object is present in the local content store and the local content store may be arranged to store the updated content object only if the named content object is present.

The processor may be arranged to check if the named content object is present in the local content store and the local content store may be arranged to delete the named content object from the local content store only if it is present.

The described mechanism adds a very important feature to the CCN protocol. The ability to purge content explicitly from caches is important for many reasons, both legal and business. Without this feature, CCN would not be very useful in real-life

applications. The solution makes changes to the CCN Interest message and its handling. It requires no major changes to the message's syntax or semantics and offers a clean and elegant solution to the problems described hereinbefore. The solution is even better than that offered by many CDNs, many of whom offer bulk deletion of all cached content and not the fine-grained, granular control as offered by this solution.

Brief description of the dr wings

A method and apparatus for content purging in an information centric network will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a new interest message;

Figure 2 shows a method in a node that receives the new interest message;

Figure 3 shows an example of a CCN network;

Figure 4 illustrates a method in a node of an information centric network;

Figure 5 illustrates another method in a node of an information network;

Figure 6 illustrates a further method in a node of an information centric network; and

Figure 7 illustrates a node in an information centric network.

Detailed description

The method described herein requires that an Interest message is sent from the publisher of a content item that it wishes to delete that content item from all caches in the information centric network to which it is attached. Figure 1 shows an Interest message 100 which facilitates the delete function.

The interest message of Figure 1 comprises a name field 110, a Fields field 120, and a payload field 130. The Name field 110 takes the value '/com/youtube/HqHB8FE5wrk', this identifies the named content item that should be deleted from all Content Stores at CCN nodes in the CCN network to which this publisher originally offered the named content item. One of the Fields 120 is a new field named 'Action'. The semantics of the values this field can take are as follows:

• Action=delete: this means that the object identified by the name in the Interest message (including an exact match on any other selectors such as a Content Object Hash Restriction field if indicated in the PIT for the original content object) should be deleted, if present, from the Content Store at any node where this message is received.

• Action=delete and replace: this means that the object identified by the name in the Interest message, if present in the local content store, should be replaced by either:

the content object provided in the Payload of the Interest message; or - the content object for which a LINK type of content object (defined in

reference [1]) is included in the Payload of the interest message. The LINK content object identifies the named object which should be retrieved as the replacement of the deleted object and stored with the original name.

• Other values for Action are left for future use.

The lifetime field of this Interest should be set to zero to indicate that this is a one-way message for which no Content Object is expected in response. The current CCN protocol suggests that no record need be maintained in the node's Pending Interest Table for such a message. However, this invention requires that this restriction be removed for this particular type of Interest message. As we shall show below, a PIT entry for this one- way message should be recorded so that a second message requesting the delete operation on the same named content is not forwarded. The entry in the PIT can be removed after some operationally specified time when it is clear that the delete operations have permeated throughout the network. Figure 2 shows the actions taken at a node on receiving an Interest message as defined above.

When a node operating according to the method of Figure 2 receives an Interest message with the new field Action with value "delete", the Content Store is consulted 210 to see if a content item is present therein which matches the name of the received Interest including an exact match on any selectors such as a Content Object Hash Restriction field if indicated as present for the original content object. If there is an exact match of all the relevant fields, the object is deleted 220 from the CS. However, for the case of a received one-way Interest message with this new Action field set to "delete", the processing continues and the Pending Interest Table (PIT) is consulted 230 to see if there is present information about a previous Interest with the same name and with this new action field set to "delete".

· If yes, the incoming interface on which this Interest is received is added 240 to the PIT entry against this name and further processing stops.

• If no, the incoming interface on which this Interest is received is added 240 to the PIT entry against this name and the processing continues 250. Processing continues by way of the Interest sent 250 to the FIB for onward routing.

However, rather than route this message based on its name, this special type of Interest (with the new Action field set to "delete") is forwarded {not routed) on all interfaces at this node except the one over which this Interest was received. Thus, any content item with the appropriate match is deleted from the CS and the delete message (i.e., the Interest with Action field set to "delete") is propagated on all interfaces except the one over which it was originally received. Where the incoming interface on which the Interest is received is added 240 to the PIT entry against this name and then further processing stops ensures that the reception over any interface of another delete (Interest) message for the same content object does not propagate further, thereby preventing an explosion of unnecessary repeated delete messages from this node.

The utility of the above procedures are best explained with reference to an example CCN network 300 as shown in Figure 3. In Figure 3, the same Interest message (with the Action field set to "delete") is labeled A, B, C, etc. for clarity and ease of explanation in what follows. The CCN network 300 comprises a content provider 310, a plurality of CCN nodes 320, and a plurality of client nodes 350.

Looking from right to left of Figure 3, a Content Provider (CP) 310 wishes to delete a particular named content item that it previously published, and which has, over the course of time, presumably been stored at many (perhaps all) caches in the CCN nodes 320 of the network owing to client requests.

It sends an Interest message A, with the Action field set to "delete" as described above, over its interface to the CCN network 300. The rules described hereinbefore requires that Node CCN7 deletes the item from its cache (it would obviously have cached this) while forwarding the message on its other interfaces F2 and F3, as messages C and B respectively. The interfaces over which the message has been sent and received are recorded in its PIT.

Similarly, on receipt of the same Interest message, now labeled B for clarity, CCN5 deletes the content item if found in its cache and forwards the Interest on all interfaces Fl and F3 except the one, F2, over which it received the special (delete) Interest. The interfaces over which the message has been sent and received are recorded in its PIT. There is a similar explanation for the behavior of CCN6 on receiving the same Interest message, labeled C for clarity.

A further explanation is needed for messages E and D exchanged between CCN5 and CCN6, respectively, related to potential race conditions. (A similar explanation holds for messages K and L or G and I.) CCN5 forwards message E to CCN6, making an entry in its PIT showing that the Interest was forwarded on interface F3. CCN6 records in its PIT the reception of this Interest on its interface F2. Thus, no Interest (message D) is forwarded on interface F2 at CCN6. However, there might be a race condition if message E were not received until well after message C was processed at CCN6, in which case message D might well have been sent over interface F2 and node CCN6. The reception of message D at CCN5 causes it not be forwarded, because the PIT shows that an Interest with this name was already forwarded from this interface. The point is that the processing rules ensure that every attempt is made to avoid needless forwarding of this special Interest message between nodes thereby avoiding an explosion in the number of such messages which, if unchecked, could be a vector for a denial of service attack.

Note that the end user nodes, such as those connected to CCN1, CCN3 and CCN5, are not shown in this deployment as being CCN capable. This is because their interface to the CCN network is probably proxied by an HTTP-to-CCN gateway (not shown), which is a likely deployment option. Thus, the special Interest message stops at nodes CCN1 and CCN3 as there are no remaining interfaces over which the Interest can be further forwarded/ propagated. Note also that no attempt is made to remove content from the end consumer's browser caches. Note that the above processing and forwarding rules apply equally to the case where the Interest has the new flag set to the value "delete and replace". The only difference is that the replacement content object is either carried in the payload field of this special Interest message and, as above, silently replaces the existing matching content object in the content store or the payload contain a LINK object which requires that node to send an Interest to retrieve the replacement content object identified by the name in the link and replace the deleted object with the one retrieved.

Active purging of content for the CCN content stores is completely missing from the CCN specification of reference [1]. This invention describes a way to use the current specifications (specifically, a particular use of a one-way Interest message) with an additional field and some special processing rules defined here to offer a simple and direct way to delete all cache entries associated with a specific named content item. While not the most common use case, the solution described herein provides a straightforward way to replace a content item with another of the same name using the "delete and replace" option.

Figure 4 illustrates a method in a node of an information centric network, the method comprising: receiving 410 an interest message from a node, the interest message identifying a named content object and comprising a delete flag; deleting 420 the named content object from a local content store if present therein; checking 430 an interest table for a record of a previous interest message identifying the named content object and comprising a delete flag, and, if no such entry is present in the interest table, then recording this Interest XXX and forwarding 440 the received interest message to all interfaces, except the one by which it was received.

By keeping a record of received interest messages comprising delete flags, the node of an information centric network is able to disseminate a message with a delete flag to connected nodes, without undue propagation and repetition, thus limiting signaling overhead. Importantly, this mechanism allows a content publisher to update a content object and remove old versions of that content object from nodes within the information centric network. The method may further comprising checking if the named content object in the received interest message is present in the local content store, and deleting the named content object from the local content store only if it is present. The received interest message may also contain a selector field, wherein the method further comprises checking that the selector field matches that of the stored named content object before deleting that stored named content object from the local content store. Such a selector field may be the Content Object Hash Restriction, whereby the hash of the received Content Object must match the hash provided in the Interest message. Alternatively, the selector field may comprise the KeylD, whereby the KeylD is the public key of the publisher used to validate the signature of the received content object. The method may further comprise storing the selector fields, if present, in the interest table for an Interest and subsequently checking that the received content object meets the conditions set by the selector fields.

Figure 5 illustrates another method in a node of an information network. The method of Figure 5 is similar to Figure 4. The difference is that if at step 430 (here 530), it is determined that the interest table does have a record of a previous interest message identifying the named content object and comprising a delete flag, then the method comprises adding 550 the interface upon which the received interest message was received to that record in the interest table. If the node has already received an interest message naming the content object and including a delete flag, the interest message is not propagated onwards, but a record of the node from which the interest message was received is added to the interest table.

The method may further comprising checking if the named content object in the received interest message is present in the local content store, and deleting the named content object from the local content store only if it is present. Figure 6 illustrates a further method in a node of an information centric network. Here, the received interest message 610 comprises a delete and replace flag, wherein the payload of the received interest message comprises a link to an updated content object. The method comprises checking 615 the local content store for the named content object, and if the content store does have the content object, then deleting the named content object 620, and sending 660 an interest message for an updated content object to replace the deleted content object. Typically, a content object must be removed because a new and updated version is available. If the content object was cached at the node, then it is likely that the updated version will be requested again, and that request can be anticipated by replacing the old content object with the updated version.

The method may further comprise checking if the named content object in the received interest message is present in the local content store and sending an interest message for an updated content object to replace the deleted content object only if it is present. If the content object was not present in the local content store, then a replacement is unlikely to be required.

The method may further comprise checking if the named content object in the received interest message is present in the local content store and storing the updated content object in the local content store only if it is present. The method may further comprise checking if the named content object is present in the local content store and deleting the named content object from the local content store only if it is present. 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 comprises: an interface 710 for receiving an interest message from another node, the interest message identifying a named content object and comprising a delete flag; a local content store 730 where content objects are stored; a processor 720 arranged to delete the named content object from the local content store. The node further comprises an interest table 740 which is checked for a record of a previous interest message identifying the named content object and comprising a delete flag, and, if no such entry is present in the interest table, then forwarding the received interest message to all interfaces, except the one by which it was received. The processor 720 is arranged to receive instructions which, when executed, causes the processor 720 to carry out the above described method. The instructions may be stored on a memory 725.

By keeping a record of received interest messages comprising delete flags, the node of an information centric network is able to disseminate a message with a delete flag to connected nodes, without undue propagation and repetition, thus limiting signaling overhead. Importantly, this mechanism allows a content publisher to update a content object and remove old versions of that content object from nodes within the information centric network.

The received interest message may also contain a selector field, wherein the processor is further arranged to check that the selector field matches that of the stored named content object before deleting that stored named content object from the local content store. Such a selector field may be the Content Object Hash Restriction, whereby the hash of the received Content Object must match the hash provided in the Interest message. Alternatively, the selector field may comprise the KeylD, whereby the KeylD is the public key of the publisher used to validate the signature of the received content object. The node may be further arranged to store the selector fields, if present, in the interest table for an Interest and subsequently checking that the received content object meets the conditions set by the selector fields.

If the interest table does have a record of a previous interest message identifying the named content object and comprising a delete flag, then the node may add the interface upon which the received interest message was received to that record in the interest table.

The solution described herein allows the publisher of a content item to delete that content item from the cache of nodes within an information centric network. This is done by sending a new interest message into the information centric network, whereby each node therein receives the interest message and deletes the identified content item. In an alternative the solution allows for the content item to be replaced. This allows for a publisher to quickly take-down a content item when necessary, 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

Claims

1. A method in a node of an information centric network, the method comprising: receiving an interest message via an interface with another node, the interest message identifying a named content object and comprising a delete flag;

deleting the named content object from a local content store;

checking an interest table for a record of a previous interest message identifying the named content object and comprising a delete flag, and, if no such entry is present in the interest table, then forwarding the received interest message to all interfaces, except the one by which it was received.

2. The method of claim 1 , wherein if the interest table does have a record of a previous interest message identifying the named content object and comprising a delete flag, then adding the interface upon which the received interest message was received to that record in the interest table.

3. The method of any preceding claim, wherein the received interest message comprises a delete and replace flag, wherein the payload of the received interest message comprises a link to an updated content object, and wherein the method further comprises:

sending an interest message for an updated content object to replace the deleted content object.

4. The method of claim 3, further comprising checking if the named content object in the received interest message is present in the local content store and sending an interest message for an updated content object to replace the deleted content object only if it is present.

5. The method of claim 3 or 4, further comprising receiving an updated content object and storing it in the local content store.

6. The method of claim 1 or 2, wherein the received interest message comprises a delete and replace flag, and wherein the payload of the received interest message comprises an updated content object to replace the deleted content object, and wherein the method further comprises:

storing the updated content object in the local content store.

7. The method of claim 6, further comprising checking if the named content object in the received interest message is present in the local content store and storing the updated content object in the local content store only if it is present.

8. The method of any preceding claim, further comprising checking if the named content object is present in the local content store and deleting the named content object from the local content store only if it is present.

9. A computer-readable medium, carrying instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined by claims 1 to 8.

10. A node in an information centric network, the node comprising:

an interface for receiving an interest message from another node, the interest message identifying a named content object and comprising a delete flag;

a local content store where content objects are stored;

a processor arranged to delete the named content object from the local content store; and

an interest table which is checked for a record of a previous interest message identifying the named content object and comprising a delete flag, and, if no such entry is present in the interest table, then forwarding the received interest message to all interfaces, except the one by which it was received.

11. The node of claim 10, wherein if the interest table does have a record of a previous interest message identifying the named content object and comprising a delete flag, then adding the interface upon which the received interest message was received to that record in the interest table.

12. The node of claim 10 or 11, wherein the received interest message comprises a delete and replace flag, wherein the payload of the received interest message comprises a link to an updated content object, and which additionally causes the node to send an interest message for an updated content object to replace the deleted content object.

13. The node of claim 12, wherein the processor is further arranged to check if the named content object is present in the local content store and to sending an interest message for an updated content object to replace the deleted content object only if it is present.

14. The node of claim 12 or 13, further arranged to receive an updated content object and store it in the local content store.

15. The node of claim 10 or 11, wherein the received interest message comprises a delete and replace flag, and wherein the payload of the received interest message comprises an updated content object to replace the deleted content object, and wherein the local content store is arranged to store the updated content object.

16. The node of claim 15, wherein the processor is further arranged to check if the named content object is present in the local content store and the local content store is arranged to store the updated content object only if the named content object is present.

17. The node of any of claims 10 to 16, wherein the processor is arranged to check if the named content object is present in the local content store and the local content store is arranged to delete the named content object from the local content store only if it is present.