WO2017207072A1

WO2017207072A1 - Improved content delivery in an information centric network

Info

Publication number: WO2017207072A1
Application number: PCT/EP2016/070861
Authority: WO
Inventors: Nilo Mitra; Börje OHLMAN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-06-03
Filing date: 2016-09-05
Publication date: 2017-12-07

Abstract

There is provided a requesting node in an information centric network, the node arranged to send a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the particular content are also requested. The node is further arranged to store the request in an interest table, and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then the request is deleted from the interest table.

Description

IMPROVED CONTENT DELIVERY IN AN

INFORMATION CENTRIC NETWORK

Technical field

The present application relates to a requesting node in an information centric network, a method for retrieving particular content, a sending node in an information centric network, a method for sending particular content, and a computer-readable medium.

Background

Information Centric Networking (ICN) is a new networking paradigm. Instead of focusing on connecting communicating endpoints (as traditional networking protocols, such as IP, do), ICN focuses on the content object that should be retrieved. In ICN, 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).

Content Centric Networking (CCN) is one approach within the ICN paradigm. A CCN standard is being developed by the Internet Research Task Force of the IETF, see, for example, the IETF internet draft 'CCNx Messages in TLV Format' dated 11 January 2016 and available from https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-01. See also 'CCNx Semantics' dated 11 January 2016 and available from

https:/ / tools.ietf.org/html/ draft-irtf-icnrg-ccnxsemantics-01. In CCN each content object is assigned a unique name by the publisher of that object. 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, based on that name, towards the source/ publisher of the object. Nodes along the path check if they have a cached copy of the object with that same name. 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 in the PIT besides the entry for this name. This is called Interest aggregation, and it prevents needless propagation upstream of the same Interest. In this way, the PIT entries for objects with the same name may form a tree in the network with receivers at the leaves.

When the Interest message reaches a server or a router having a copy of the content object (perhaps cached), the node responds to the Interest message with a Content Object message. The Content Object message has the requested content object as its payload, and is propagated backwards along the path the Interest message took. Any received Content Object message not recorded in the PIT or whose name does not match that of a pending Interest is silently dropped. 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, the Content Object message containing the content object is replicated towards each direction where the matching Interest messages came from. 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. The Content Object may be stored in the router's Content Store, so as to be able to serve future Interests for that same named object directly from the store. When the original endpoint(s) generating the Interest message(s) receive the Content Object the transaction is considered closed.

One benefit of CCN is in distributing 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, requests for Content Objects need not traverse the entire network to the source and back 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 are requesting 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.

One problem with ICN networks arises from the composite nature of modern content. Today, a typical webpage comprises an HTML file that refers to a plurality of other files such as other text files, videos, images, Javascript code, code libraries, CSS files. An average web page contains lots of such assets, and references to all these assets are embedded in the primary HTML that is first requested.

Efficiently retrieving all the content objects required to present a webpage is a problem in Information Centric Networks.

Summary

There is presented herein an arrangement whereby a request message is tagged with an 'all' flag, which allows the requesting node to signal to other nodes in the network that it wants not only just the requested content object but also all the related content objects that are required for presentation of the requested content object. This is built upon the recognition that in modern rich content environments most content that is presented to a user comprises a plurality of content objects. Accordingly, there is provided a requesting node in an information centric network, the node arranged to send a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the particular content are also requested. The node is further arranged to store the request in an interest table, and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then the request is deleted from the interest table.

The named content item may be a content object, or a data object. The information centric network may be based upon Content centric networking (CCN), Named data networking ( DN), or some other network architecture that uses information-centric networking principles.

The requesting node can set a flag in the request for content to indicate that all named content items of the particular content are required, this allows the requesting node to send fewer request messages to obtain the content, and it also means the requesting node can receive all the named content items it needs more quickly because the sending node begins sending related named content items immediately, without waiting for explicit requests for each named content item. The requested named content item may comprise a content object. The requesting node may not know whether or not other named content items are required for presentation of the requested named content item. The request indicating that all related named content items required for presentation of the content are also requested may be sent as a precaution, without explicit knowledge that such related named content items exist. The related named content item may be a content object referenced by the requested named content item relating to particular content. The related named content item may also comprise a content object.

The requesting node may further comprise a storage component for storing named content items, the requesting node arranged to store the received named content items in the storage component. The storage component may be referred to as a named content item store, or a cache for named content items.

The requesting node may be an intermediate node in an information centric network. There may be at least one intermediate node between a client node and a server node. Where the requesting node is an intermediate node, the request for content sent by the intermediate node is prompted by a request for that content received at the intermediate node by a downstream node. The downstream node may be a client node or another intermediate node. Where the requesting node is an intermediate node, the requesting node may store the received named content item. The received named content item is cached in the storage component to allow the requesting node to more quickly fulfill future requests from other downstream nodes for the same named content item.

The requesting node may be arranged to send named content items to a downstream node. The named content items are sent based upon the data maintained in the interest table. The requesting node may further comprise an output, through which the requesting node may output content. The requesting node may be a client node having a user interface and a screen speaker, video output or audio output for outputting the received content. Content is received as a plurality of named content items. Named content items are decoded, read, rendered or processed as appropriate in the client node before presentation. Presentation of the content may comprise an audio and or visual presentation. The presentation of the content may be interactive. The content may comprise software, in which case the content may not be presented but instead used at the client node for a purpose other than entertaining the user. For example, the software may be installed on the client device for subsequent use by a user.

The requesting node may be further arranged such that if a named content item received in response to the request indicates that additional named content items are to be received, then the request is not deleted from the interest table.

The requesting node may be further arranged such that if a named content item received in response to the request includes references to additional named content items, and the response indicates that the additional named content items are to be received, then the names of those additional named content items are added to the interest table.

The requesting node may be further arranged to send a further request message for the content, the further request message indicating that no more named content items of the content are wanted. Subsequent to sending a request message indicating that all named content items of the content are requested; the requesting node may determine that these named content items are no longer wanted. For example, a user may have navigated away from a webpage that had begun loading. In such a circumstance the requesting node sends a stop message for the named content item relating to particular content, which is propagated through the network and stops the flow of named content items to the requesting node. After the requesting node sends a stop message, the requesting node may delete from the storage component any named content items received in response to the request for a named content item relating to particular content; and it may also delete the request from the interest table.

A named content item may comprise a content object and a request may identify the content object that is requested.

There is further provided an apparatus in an information centric network, the apparatus comprising a processor and a memory, said memory containing instructions executable by said processor whereby said apparatus is operative to send a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the particular content are also requested. The apparatus is further operative to store the request in an interest table, and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then the request is deleted from the interest table.

There is further provided a method for retrieving particular content, the method comprising, in a node of an information centric network sending a request for a named content item relating to the particular content, the request indicating that all related named content items required for presentation of the content are also requested. The method further comprises storing the request in an interest table and receiving a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then deleting the request from the interest table. The method may further comprise storing the received named content items in a storage component.

The method may further comprise adding to the interest table the names of the plurality of named content items to be received, sent in response to a request for a named content item relating to a particular content.

The method for requesting a named content item relating to particular content may be performed in a requesting node, an intermediate node, or in a client node. In an information centric network, there may be at least one intermediate node between a client node and a server node. Where the requesting node is an intermediate node, the request for a named content item relating to particular content sent by the intermediate node is prompted by a request for that named content item received at the intermediate node from a downstream node. The downstream node may be a client node or another intermediate node. Where the method for requesting a named content item is performed in an intermediate node, the method may further comprise storing any received named content items. Any received named content items are thus cached to allow the requesting node to more quickly fulfill future requests from other downstream nodes for the same named content item. The method may further comprise sending received named content items to a downstream node. The named content items are sent based upon the data maintained in the interest table. The node of an information centric network may be a client node, and the method may further comprise outputting the particular content through an output of the node. The output may comprise a screen speaker, video output or audio output for outputting the received content. Presentation of the content may comprise an audio and or visual presentation. The content may comprise software, which may be installed on the client device for subsequent use.

The method may further comprise not deleting the request from the interest table if a named content item received in response to the request indicates that additional named content items are to be received.

The method may further comprise, upon receipt of a named content item that includes references to additional named content items, adding to the interest table the names of the additional named content items that are to be received in response to the request for a named content item relating to a particular content.

The method may further comprise sending a further request message for the named content item relating to particular content, the further request message indicating that no more related named content items required for presentation of the content are wanted. The further request message may also indicate that the requested named content item relating to particular content is no longer wanted.

There is further provided a sending node in an information centric network, the node arranged to receive a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the content are also requested. The node is further arranged to send the named content item containing the list of names of each related content item and to subsequently send each related named content item in response to such a request, wherein each sent named content item indicates that additional named content items will be sent, except for the last sent named content item sent in reply to the request, which is returned with an indication that no additional named content items will be sent.

When the sending node receives an appropriately flagged request it begins sending all named content items related to the requested content. This means the sending node has to process fewer request messages. It also allows the sending node to begin sending related named content item objects immediately, without waiting for explicit requests for each related named content item. The requested named content item may comprise a content object. The related named content items may be content objects referenced by the requested named content item.

The sending node may further comprise a storage component, the sending node arranged to consult the storage component to verify if a required named content item is cached therein. If the requested named content item is not cached, then the sending node propagates the request to another node in the information centric network. If the required named content item is cached, then the named content item is retrieved from the cache and sent in reply to the request, and the request is not propagated further. The storage component will also be checked for any related named content items required for presentation of the requested named content item, and the sending node is further arranged to additionally retrieve the related named content items from the storage component and send these in response to the request.

The sending node may be further arranged to receive a further request message for the particular content, the further request message indicating that no more named content items of the content are wanted, and in response thereto the sending node stops sending named content items of the content in response to the request for content. Subsequent to sending a request message indicating that all named content items of the content are requested; the requesting node may determine that these named content items are no longer wanted. For example, a user may have navigated away from a web page that had begun loading. In such a circumstance the requesting node sends a stop message for the named content item relating to particular content, which is propagated through the network and stops the flow of named content items to the requesting node. Upon receipt of the stop message, the sending node stops sending the named content item and any related named content items to the requesting node.

The sending node may be further arranged to request and receive content. The sending node may comprise an intermediate node in an information centric network. The sending node receives requests from downstream nodes. Any named content item requested that the sending node does not have cached causes the sending node to send a request message to an upstream node. The sending node may comprise a content server, in which case upon receipt of a request for a named content item that the content server does not have stored, the content server may send an error message in reply.

There is further provided an apparatus in an information centric network, the apparatus comprising a processor and a memory, said memory containing instructions executable by said processor whereby said apparatus is operative to receive a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the content are also requested. The apparatus is further arranged to send the named content item and each related named content item in response to such a request, wherein each sent named content item indicates that additional named content items will be sent, except for the last sent named content item sent in reply to the request, which is returned with an indication that no additional named content items will be sent.

There is further provided a method for sending particular content in a node of an information centric network, the method comprising receiving a request for a named content item relating to the content, the request indicating that all related named content items required for presentation of the content are also requested. The method further comprises sending the named content item and each related named content item in response to such a request, wherein each sent named content item indicates that additional named content items will be sent, except for the last sent named content item sent in reply to the request, which is returned with an indication that no additional named content items will be sent. The requested named content item may comprise a content object. The related named content item required for presentation of the content may be a content object referenced by the requested named content item. The method may further comprise consulting a storage component to verify if a required named content item is cached therein.

The method may further comprise receiving a further request message indicating that no more named content items required for presentation of the content are wanted, and in response thereto sending no more named content items of the particular content in response to the request for content. Subsequent to sending a request message indicating that all named content items of the content are requested, the requesting node may determine that these named content items are no longer wanted. For example, a user may have navigated away from a web page that had begun loading. In such a circumstance the requesting node sends a stop message for the named content item relating to particular content, which is propagated through the network and stops the flow of named content items to the requesting node. Upon receipt of the stop message, the sending node stops sending the named content item and any related named content items to the requesting node.

The node may be referred to as a sending node but may be further arranged to request and receive content. The sending node may comprise an intermediate node in an information centric network. The sending node receives requests from downstream nodes. Any named content item requested that the sending node does not have cached causes the sending node to send a request message to an upstream node. The sending node may comprise a content server, in which case upon receipt of a request for a named content item that the content server does not have stored, the content server may send an error message in reply.

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 computer-readable storage medium, storing instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined herein. The computer program product may be in the form of a non- volatile memory or volatile memory, e.g. an EEPROM (Electrically Erasable Programmable Read-only Memory), a flash memory, a disk drive or a RAM (Random- access memory).

There is further provided a user terminal comprising a processor and memory, said memory containing instructions executable by said processor whereby said user terminal is operative to send a request for a named content item relating to a particular content in an information centric network, the request indicating that all related named content items required for presentation of the particular content are also requested. The user terminal is further operative to store the request in an interest table and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then deleting the request from the interest table.

The user terminal is further operative to adding to the interest table the names of the plurality of named content items to be received, sent in response to a request for a named content item relating to a particular content. If a named content item received in response to the request includes references to additional named content items, and the response indicates the additional named content items are to be received, then the user terminal is operative to add the names of those additional named content items to the interest table.

There is further provided a user terminal comprising an antenna, display, transceiver, processor and memory, said memory containing instructions executable by said processor whereby said user terminal is operative to send a request for a named content item relating to a particular content in an information centric network, the request indicating that all related named content items required for presentation of the particular content are also requested. The user terminal is further operative to store the request in an interest table and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then deleting the request from the interest table.

Brief description of the dr wings

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

Figure 1 is a signaling diagram showing the behaviour of nodes operating

according to the known CCN protocol;

Figure 2 shows an alternative perspective of how known Information Centric

Networks operate;

Figure 3 is a signaling diagram illustrating modified messages as presented herein;

Figure 4 is a signaling diagram illustrating a stop message as presented herein; Figure 5 shows a requesting node;

Figure 6 illustrates a method for retrieving particular content;

Figure 7 illustrates an extension of the method of figure 6;

Figure 8 shows a sending node;

Figure 9 illustrates a method for sending particular content;

Figure 10 illustrates how a stop message is handled by the sending node; and Figure 11 is a signaling diagram illustrating a system incorporating the messages presented herein.

Detailed description

A node in an information centric network as presented herein can request all subcomponents of a piece of content. Hence, instead of waiting for the client to discover references to these resources, it is much more efficient if the server, when requested to do so by the client, were to just send all of them directly and immediately in response to the first request related to a particular piece of content.

A Content Centric Network (CCN) is one example of an Information Centric Network (ICN). In the current CCN protocol, the requester of the content does not know a priori that the content might be composed of multiple content objects, each content object comprising a part that makes up the whole content. The parts could just be similar types of chunks of a large object (e.g., segments of a video file) or different types of objects (e.g., components of a web page). A naive use of CCN typically causes an initial Interest message for a first content object to be sent. This first content object relates to a particular piece of content that may be complex and composed of a plurality of content objects. The first content object will comprise a manifest identifying the content objects that are the component pieces of the content required for presenting the content. Each of the referenced component pieces may themselves be composed of several "sub- pieces", such as chunks of a video file embedded in the web page. In this naive use of CCN, the receiver must make individual requests for every single content object using separate Interest messages.

To understand the method and apparatus presented herein, it is important to contrast these with the current behaviour of the CCN protocol when retrieving composite objects such as a web page or a large object (chunked for delivery). Figure 1 is a signaling diagram shows the existing behaviour of nodes operating according to the CCN protocol. A requesting node 110 discovers the object by name and requests it via an Interest message 120. Here, only two nodes are shown, in practice a request would likely pass through several intermediate nodes (routers) before arriving at either an intermediate node that has the required content object cached or an origin server. Furthermore, this figure does not show certain details present in an Interest message such as metadata and validator parameters defined in 'CCNx Semantics' dated 11 January 2016 and available from https:/ / tools.ietf.org/html/ draft-irtf-icnrg-ccnxsemantics-01.

The content object which comprises the index file is returned 122 to the requesting node 110. Each of the sub-components required for presentation of the required content is identified by its name in the index file. These are, for instance, text blocks such as CI, C2, C3, as well as a style sheet (style.css) and an image file (logo.jpg). Each of these component content objects is then requested separately using its name in an Interest message and the corresponding object returned in reply. For example, request message 124 requests the content object CI and this is returned as a content object 126 with payload comprising the text block CI. Similarly, content object C2 is requested with request message 128, and this is returned by the sending node 190 as a subsequent content object 130. Similar requests and responses are made for content objects C3 and style.css. Finally, the content object logo.jpg is requested by the request node 110 in request message 132 and returned as a further content object 134. Upon receipt of all the content objects listed in the index file the requesting node 110 is able to present the content to which the index file 122 relates.

Figure 2 shows an alternative perspective of how known Information Centric Networks operate. Two client nodes 110 and 111 each request the same content object from a server 190. A plurality of intermediate nodes 181, 182, 183, 184, 185, and 186 are cross connected to form an information centric network (ICN). Each intermediate node 181, 182, 183, 184, 185, and 186 is a router. Client node 110 connects to the ICN via node 181 and client node 111 connects to the ICN via node 183. Server 190 can communicate with the ICN via one of the intermediate nodes 185.

Client node 110 identifies it requires content object B, and sends a request message 120 for such to intermediate node 181. Intermediate node 181 does not have content object B stored locally so it sends a request message 122 for content object B towards a server where it expects the object to be stored, intermediate node 185. Intermediate node 185 does not have content object B stored locally so it sends a request message 124 for content object B to the server 190 where it expects the object to be stored. Server 190 responds with content object B 126 which is sent to intermediate node 185.

Intermediate node 185 receives content object B 126, stores a copy locally, and sends content object B 128 to intermediate node 181. Intermediate node 181 receives content object B 128, stores a copy locally, and sends content object B 130 to the requesting client node 110.

Subsequently, client node 111 identifies it also requires content object B, and so it sends a request message 132 for such to intermediate node 183. Intermediate node 183 does not have content object B stored locally so it sends a request message 134 for content object B towards a server where it expects the object to be stored, intermediate node 185. Intermediate node 185 does have content object B stored locally; this is as a result of the prior request chain originating from client node 110. Intermediate node 185 retrieves content object B from local storage, and sends content object B 136 to intermediate node 183. Intermediate node 183 receives content object B 136, stores a copy locally, and sends content object B 138 to the requesting client node 111. In a much larger network the above method would result in popular content being cached in intermediate nodes closer to the client nodes, merely as a result of it being previously requested by at least one client node. However, from both figures 1 and 2, it is apparent that each content object must be explicitly requested by the requesting node, which may be a client node or an intermediate node. This is an inefficient use of network resources for complex content comprising multiple content objects.

The solution presented herein uses an optimization feature applied to the CCN protocol whereby an Interest message can indicate that it wishes to receive all the referenced components related to a requested content object without explicitly requesting each referenced component. A content object is determined to be related to a requested content object if they are both required for presentation of a particular piece of content. This is done by introducing a new parameter in the Interest message. This new parameter is stored in the Pending Interest Table (PIT) of the requesting node and any intermediate node along with the associated Interest.

On receipt of such a flagged Interest, the source/ publisher "pushes" all component objects associated with the requested content along the reverse path of the flagged Interest. The first Component Object flagged as "next" includes a list of all the remaining components associated with the requested content. Each of the names for these components is stored along with the original Interest in the PIT of each intermediate node and the requesting node. Each of these components is sent sequentially in Content Objects flagged as "next". PIT entries created by such an Interest message are not removed when a corresponding Content Object message arrives, so long as these are identified as "next". The last component sent is flagged "last" by the source/ publisher to allow the PIT entry at intermediate CCN routers to be flushed after this component object is sent. Following CCN practice, received Content Objects are stored in Content Stores at intermediate CCN routers and may be served from there for subsequent Interests for the same named content object. Figure 3 is a signaling diagram illustrating messages modified according to the present disclosure. An Interest message has an optional parameter called "send" and associated with which is a value "all", "next", "last" or "stop". An Interest message with the parameter "send" set to value "all" indicates that components of any composite object be sent without any explicit solicitation for each.

A requesting node 310 discovers an object by name and requests that object via an Interest message 320. Interest message 320 includes the send parameter which takes the value "all". The requested object 322 happens to be the top-level HTML index file and this is returned to the requesting node 310. Each of the sub-components required for presentation of the required content is identified by its name in the index file sent as payload of the requested object 322 with this "send" parameter set to the value "next". Because the Interest message 320 is marked "send=all", the sending node 390 understands that it should return not only the requested content object 322 but also any content objects referenced therein and required for presentation of the requested content. So, the sending node 390 sends each of these component content objects to the requesting node 310. Each of the components of the composite object are returned in successive Content Objects, with this "send" parameter set to the value "next", and with the final one set to "last".

The sending node 390 replies with the originally requested content object, the top-level HTML index file 322, followed by content object CI 326, Content Object C2 330, Content Object C3 (not shown), Content Object style.css 333, and content Object logo.jpg 334. Upon receipt of all the content objects listed in the top-level HTML index file the requesting node 310 is able to present the content to which the index file 322 relates. Note that each sent Content Object includes the send parameter which takes the value "next" indicating that a further Content Object will be sent, except for the final Content Object 334 containing logo.jpg, which has the send parameter set to "last" indicating to the requesting node 310 that no more Content Objects will be returned in response to the Interest message 320.

With a small extension of the CCN protocol we allow all the components associated with a Content Object to be retrieved with a single Interest message. Thus, a request for a web page, for example, allows all the assets associated with the page to be pushed to the requester, without requiring the latter to discover these and explicitly request each one.

However, the usefulness of this invention is not limited to web pages. Video content stored in a mezzanine format can be chunked and sent efficiently to a downstream node upon a single request, avoiding multiple network messages and consequent delays. This scenario for use in video delivery is described further below.

The send parameter may also take the value "stop". A node may forward an Interest message on the outbound path for the same content with a flag set to "stop" in case it cannot or does not wish to handle any further incoming components. This would be useful if, for example, the requesting node no longer had a need for the incoming components or if the requesting node believes that an upstream node sending Content Objects is ill-behaved.

Figure 4 is a signaling diagram illustrating a stop message. This demonstrates how a requesting node 410 can interrupt the delivery of a set of Content Objects. This could arise because the user has abandoned the page, or the requested video object is no longer needed at the requesting node 410. At any point before a Content Object with the "send" parameter set to "last" is received, the requesting node can send an Interest for the same named object with the "send" parameter set to "stop". Good housekeeping requires that the receiver responds with an Interes Return message with an appropriate return code, which could be a meaningful description such as "requester initiated" or similar.

The requesting node 410 requests a content object using an Interest message 420, which includes the send parameter set to "all". The requested object 420 happens to be a top level HTML index file and this is returned 422 to the requesting node 410, that returned content object includes the send parameter with value set to "next". Because the interest message 420 is marked with "send=all", the sending node 490 understands that it should return not only the requested content object 422 but also any content objects referenced therein and required for presentation of the requested content. So, the sending node 490 sends each of these component content objects to the requesting node 410. Each of the components of the composite object are returned in successive Content Objects, with this "send" parameter set to the value "next", and with the final one would be set to "last". However, before the final content object is received by requesting node 410, the requesting node 410 sends an interest message 431 for the originally requested content object but with the send parameter taking a value "stop". Upon receipt of the message 431 the sending node 490 ceases sending content objects relating to the original request 420 and instead sends in response an InterestReturn message 434 confirming receipt of the stop request with a return code set to the value "requester initiated".

The send parameter is a new field added to an Interest message with name "send" and which can take the following values:

• "all": used by the originator of the Interest to indicate that all components associated with the content object should be sent without waiting for an explicit Interest for each.

• "next": used in a Content Object message to indicate that this is one of several Content Objects associated with the named Interest.

• "last": used in a Content Object message to indicate that this is the last of the Content Objects associated with the named Interest.

• "stop": used by the originator of the Interest to indicate that it does not wish to receive any more Content Objects associated with the named content item relating to particular content.

The originator of the Interest message will typically set this new parameter to "all" for most (perhaps all) requests. A server acting as a source or publisher of content that understands this parameter will act on it by sending the component parts of the requested content in separate Content Objects, with each having this parameter set to

"next" except for the last Component Object where it is set to "last". A server that does not understand this new protocol parameter will respond, as in current practice, with just the first content object, which will likely be a manifest or index file identifying the component parts.

CCN routers receiving the Interest with this parameter set will store it in the Pending Interest Table alongside the ingress route to which this Interest pertains. The router will also store the names of the component objects associated with the request for this composite object as received in the first component, the index file. All entries for this Interest are only removed when a Content Object with the "send" parameter value set to "last" is received.

Content Objects with the new parameter may be cached in the Content Store at intermediate nodes. The cached components of a named composite object are considered complete only if a Content Object with the "send" parameter set to "last" is included in the collection. In such a case, a new Interest message with the "send" parameter set to "all" may be served from this cache, without forwarding the Interest upstream. If the collection of components associated with a composite object at a Content Store does not include one with the "send" parameter set to "last", it is optional to send the currently cached components in anticipation of receiving further components associated with this named object, including the "last" one.

If the "last" component has not been received in a pre-defined (reasonable) amount of time, an intermediate CCN router may assume that there is an error condition in upstream nodes preventing delivery, and therefore may send an InterestReturn message to the downstream node with a suitably descriptive error code (e.g., "timeout").

Interests received for the same named content object but without this new parameter require a separate entry in the pending interest table (PIT). The PIT entry for an Interest includes its ingress and egress interface information, along with other things such as the name of the content object. If a CCN router receives an Interest with the "send" parameter set to "stop", it must forward it along the same path as the original Interest making use of the egress information in the PIT for that request. As the InterestReturn message is 1-hop by nature, an intermediate node that receives an InterestReturn may propagate its own InterestReturn to previous hops as indicated in the reverse path of a PIT entry.

The reception of an Interest message with a "send" parameter set to "stop" may cause any Content Store to flush any incomplete collection of component Content Objects associated with a named content object, i.e., those that do not have a Content Object with the "send" parameter set to "last". As mentioned previously, the described solution may also apply to the delivery of video segments. The solution described herein can be used for efficient delivery of video through a core network of ICN/ CCN routers that connects the video head end to local or edge servers in a cable or telco service provider network, the edge servers being the nodes from which end customers are served. Typically, video is delivered to client nodes using adaptive bitrate streaming, but a single high quality bit rate can be distributed to the edge servers which transcode the video to generate the different bitrate versions. The solution described herein is most easily applied to the delivery of video to the edge servers.

Video content is created in the video head ends in the so-called "mezzanine" format, which is a lightly compressed version of the original that is suitable for making many different compressed versions. The file is compressed slightly to make it compact enough for efficient delivery, but not compressed to the point that prevents it from being further modified for serving different device types, new encoding schemes, different package formats etc.

The solution described herein can be used to send the chunks of mezzanine format video (stream or file) through the CCN network, at the request of (i.e., expression of Interest by) each edge node. Each chunk need not be requested separately and efficiency of delivery is achieved. As more edge servers make the request, content chunks get served from intermediate nodes whose caches are populated. Thus, very efficient delivery of a mezzanine formatted video file is achieved without each edge server requesting it through unicast from a video head end, and there are no operational overheads or complexity of joining an IP multicast tree.

The edge servers can further process the received mezzanine file to create various representations suitable for adaptive bitrate streaming. These are packaged into the different adaptive streaming formats (Apple's HLS, Adobe's HDS, Microsoft

SmoothStreaming etc.).

Of course, it would be possible to also create such representations/ formats at the video head end and retrieve these using the CCN-based core network, but the preference nowadays is for the decision on what representations to create and what format to package these in to be made closer to the end user and just-in-time depending on the requesting device type (an Apple device or Android, say), the type of last mile networks available (e.g., DSL vs FTTH) etc. This reduces the load in the core network, simplifies the video head ends by reducing the need to store needless, under-utilised representations, and allows the edge servers to use cheaper, software-based, just-in-time techniques to create the necessary

representations/ formats. A requesting node 500 is illustrated in figure 5. The requesting node 500 comprises a receiver 510 a processor 520, a memory 525, a storage component 530, a sender 540, and optionally an output 550. Output 550 only features on requesting nodes 500 that are also client nodes. The processor 520 is connected to receiver 510, memory 525, sender 540, storage component 530, and output 550. The processor 520 is arranged to receive instructions which, when executed, causes the processor 520 to carry out the above described method. The instructions may be stored on the memory 525. The receiver 510 is arranged to receive requests for named content items. The sender 540 is arranged to send named content items in response to requests. The storage component 530 is arranged to store named content items and may be referred to as a named content item store, or a cache for named content items.

The requesting node 500 operates in an information centric network, and the requesting node 500 arranged to send a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the particular content are also requested. The node is further arranged to store the request in an interest table, the interest table maintained in memory 525. The node 500 is further arranged to receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then the request is deleted from the interest table. The node is further arranged to store the names of the components associated with the composite object represented by the original request in the interest table, the interest table maintained in memory 525. The named content item may be a content object, or a data object. The information centric network may be based upon Content centric networking (CCN), Named data networking ( DN), or some other network architecture that uses information-centric networking principles.

The requesting node can set a flag in the request for content to indicate that all named content items of the particular content are required, this allows the requesting node to send fewer request messages to obtain the content, and it also means the requesting node can receive all the named content items it needs more quickly because the sending node begins sending related named content items immediately, without waiting for explicit requests for each named content item.

The requested named content item may comprise a content object. The requesting node may not know whether or not other named content items are required for presentation of the requested named content item. The request indicating that all related named content items required for presentation of the content are also requested may be sent as a precaution, without explicit knowledge that such related named content items exist. The related named content item may be a content object referenced by the requested named content item relating to particular content. The related named content item may also comprise a content object.

The requesting node may further comprise a storage component 530 for storing named content items. The requesting node 500 is arranged to store the received named content items in the storage component 530.

The requesting node may be an intermediate node in an information centric network. There may be at least one intermediate node between a client node and a server node. Where the requesting node is an intermediate node, the request for content sent by the intermediate node is prompted by a request for that content received at the intermediate node from a downstream node. The downstream node may be a client node or another intermediate node. Where the requesting node is an intermediate node, the requesting node may store the received named content item. The received named content item is cached in the storage component to allow the requesting node to more quickly fulfill future requests from other downstream nodes for the same named content item. The requesting node may be arranged to send named content items to a downstream node. The named content items are sent based upon the data maintained in the interest table.

The requesting node may further comprise an output, through which the requesting node may output content. The requesting node may be a client node having a user interface and a screen speaker, video output or audio output for outputting the received content. Content is received as a plurality of named content items. Named content items are decoded, read, rendered or processed as appropriate in the client node before presentation. Presentation of the content may comprise an audio and or visual presentation. The presentation of the content may be interactive. The content may comprise software, which may be installed on the client device for subsequent use. The requesting node may be further arranged such that if a named content item received in response to the request indicates that additional named content items are to be received, then the request is not deleted from the interest table. The requesting node may be further arranged such that if a named content item received in response to the request indicates the names of named content items to be additionally received, then the names of those content items are added to the interest table.

The requesting node may be further arranged to send a further request message for the content, the further request message indicating that no more named content items of the content are wanted. Subsequent to sending a request message indicating that all named content items of the content are requested, the requesting node may determine that these named content items are no longer wanted. For example, a user may have navigated away from a web page that had begun loading. In such a circumstance the requesting node sends a stop message for the named content item relating to particular content, which is propagated through the network and stops the flow of named content items to the requesting node. After the requesting node sends a stop message, the requesting node may delete from the storage component any named content items received in response to the request for a named content item relating to particular content; and it may also delete the request from the interest table. A named content item may comprise a content object and a request may identify the content object that is requested.

There is further provided an apparatus 500 in an information centric network, the apparatus comprising a processor 520 and a memory 525, said memory 525 containing instructions executable by said processor 520 whereby said apparatus is operative to send a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the particular content are also requested. The apparatus 500 is further operative to store the request in an interest table, and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then the request is deleted from the interest table. Figure 6 shows a method for retrieving particular content, the method comprising, in a node of an information centric network sending 610 a request for a named content item relating to the particular content, the request indicating that all related named content items required for presentation of the content are also requested. The method further comprises storing 620 the request in an interest table and receiving 622 a first content item. The first content item contains the names of a plurality of referenced content items and the names of these referenced content items are stored 624 in the interest table. Subsequently, a plurality of referenced content items are received 630. After each named content item is received 630, a determination 640 is made as to whether the received named content item indicates that no more additional named content items are to be received in response to the request 610. If not, then the process waits for the next named content item to be received 630. But if a received named content item does indicate it is the last named content item, then the request 610 is deleted 650 from the interest table. The method may further comprise storing the received named content items in a storage component.

The method for requesting a named content item relating to particular content may be performed in a requesting node, an intermediate node, or in a client node. In an information centric network, there may be at least one intermediate node between a client node and a server node. Where the requesting node is an intermediate node, the request for a named content item relating to particular content sent by the intermediate node is prompted by a request for that named content item received at the intermediate node from a downstream node. The downstream node may be a client node or another intermediate node. Where the method for requesting a named content item is performed in an intermediate node, the method may further comprise storing any received named content items. Any received named content items are thus cached to allow the requesting node to more quickly fulfill future requests from other downstream nodes for the same named content item. The method may further comprise sending received named content items to a downstream node. The named content items are sent based upon the data maintained in the interest table at a node.

The node of an information centric network may be a client node, and the method may further comprise outputting the particular content through an output of the node. The output may comprise a screen speaker, video output or audio output for outputting the received content. Presentation of the content may comprise an audio and or visual presentation. The content may comprise software, which may be installed on the client device for subsequent use.

The method may further comprise not deleting the request from the interest table maintained at a node if a named content item received in response to the request indicates that additional named content items are to be received. Figure 7 illustrates an extension of the above described method wherein after sending 710 a request for a named content item relating to the particular content, the request indicating that all related named content items required for presentation of the content are also requested, and this request being stored 720 in an interest table, the method may further comprise determining 760 that the requested named content items are no longer wanted. As a result of making such a determination, the method comprises sending 770 a further request message for the named content item relating to particular content, the further request message indicating that no more related named content items required for presentation of the content are wanted. The method illustrated in figure 7 further comprises deleting 780 the copy of the request from the interest table. If the determination 760 that the content is no longer wanted occurs after the first content item is received, then the method additionally comprises deleting the stored names of referenced components from the interest table. Additionally, any received content items related to the request and that have been stored may be deleted from storage.

There is further provided a sending node in an information centric network, the node arranged to receive a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the content are also requested. The node is further arranged to send the named content item and each related named content item in response to such a request, wherein each sent named content item indicates that additional named content items will be sent, except for the last sent named content item sent in reply to the request, which is returned with an indication that no additional named content items will be sent.

A sending node 800 is illustrated in figure 8. The sending node 800 comprises a receiver 810 a processor 820, a memory 825, a storage component 830, and a sender 840. The processor 820 is connected to receiver 810, memory 825, sender 840, and storage component 830. The processor 820 is arranged to receive instructions which, when executed, causes the processor 820 to carry out the above described method. The instructions may be stored on the memory 825. The receiver 810 is arranged to receive requests for named content items. The sender 840 is arranged to send named content items in response to requests. The storage component 830 is arranged to store named content items.

When the sending node receives an appropriately flagged request it begins sending all named content items related to the requested content. The first of such named content items identifies by name all the named component items that are related to the requested content. This means the sending node has to process fewer request messages. It also allows the sending node to begin sending related named content item objects immediately, without waiting for explicit requests for each related named content item. The requested named content item may comprise a content object. The related named content items may be content objects referenced by the requested named content item.

The sending node may further comprise a storage component 830, the sending node arranged to consult the storage component to verify if a required named content item is cached therein. If the requested named content item is not cached, then the sending node propagates the request to another node in the information centric network. If the required named content item is cached, then the named content item is retrieved from the cache and sent in reply to the request, and the request is not propagated further. The storage component 830 will also be checked for any related named content items required for presentation of the requested named content item, and the sending node is further arranged to additionally retrieve the related named content items from the storage component 830 and send these in response to the request. The sending node may be further arranged to receive a further request message for the particular content, the further request message indicating that no more named content items of the content are wanted, and in response thereto the sending node stops sending named content items of the content in response to the request for content. Subsequent to sending a request message indicating that all named content items of the content are requested; the requesting node may determine that these named content items are no longer wanted. For example, a user may have navigated away from a web page that had begun loading. In such a circumstance the requesting node sends a stop message for the named content item relating to particular content, which is propagated through the network and stops the flow of named content items to the requesting node. Upon receipt of the stop message, the sending node stops sending the named content item and any related named content items to the requesting node.

The sending node may be further arranged to request and receive content. The sending node may comprise an intermediate node in an information centric network. The sending node receives requests from downstream nodes. Any named content item requested that the sending node does not have cached causes the sending node to send a request message to an upstream node. The sending node may comprise a content server, in which case upon receipt of a request for a named content item that the content server does not have stored, the content server may send an error message in reply. There is further provided an apparatus in an information centric network, the apparatus comprising a processor and a memory, said memory containing instructions executable by said processor whereby said apparatus is operative to receive a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the content are also requested. The apparatus is further arranged to send the named content item and each related named content item in response to such a request, wherein each sent named content item indicates that additional named content items will be sent, except for the last sent named content item sent in reply to the request, which is returned with an indication that no additional named content items will be sent. The first of such named content items identifies by name all the named component items that are related to the requested content.

Figure 9 illustrates a method for sending particular content in a node of an information centric network. The method comprising receiving 910 a request for a named content item relating to the content, the request indicating that all related named content items required for presentation of the content are also requested. The method further comprises sending 920, 922 the named content item and each related named content item in response to such a request, wherein each sent named content item 920, 922 indicates that additional named content items will be sent, except for the last sent named content item 930 sent in reply to the request, which is returned with an indication that no additional named content items will be sent. The first 920 of such named content items identifies by name all the named component items that are related to the requested content 910. The requested named content item may comprise a content object. The related named content item required for presentation of the content may be a content object referenced by the requested named content item. The method may further comprise consulting a storage component to verify if a required named content item is cached therein. Figure 10 illustrates how a stop message is handled by the sending node. After receiving 1010 a request message for a plurality of related named content items, and the sending node begins sending 1020 the sending node receives 1040 a further request message indicating that no more named content items required for presentation of the content are wanted, and in response thereto the sending node stops 1050 sending any more named content items of the particular content in response to the request for content initially received 1010. The sending node may then send an InterestReturn message to the requesting node with a return code taking the value "requester initiated". Subsequent to sending a request message indicating that all named content items of the content are requested, the requesting node may determine that these named content items are no longer wanted. For example, a user may have navigated away from a web page that had begun loading. In such a circumstance the requesting node sends a stop message for the named content item relating to particular content, which is propagated through the network and stops the flow of named content items to the requesting node. Upon receipt of the stop message, the sending node stops sending the named content item and any related named content items to the requesting 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 computer-readable storage medium, storing instructions, which, when executed by computer logic, causes said computer logic to carry out any of the methods defined herein. The computer program product may be in the form of a non- volatile memory or volatile memory, e.g. an EEPROM (Electrically Erasable Programmable Read-only Memory), a flash memory, a disk drive or a RAM (Random- access memory).

A user terminal comprising a processor and memory, said memory containing instructions executable by said processor whereby said user terminal is operative to send a request for a named content item relating to a particular content in an information centric network, the request indicating that all related named content items required for presentation of the particular content are also requested. The user terminal is further operative to store the request in an interest table and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then deleting the request from the interest table.

The user terminal is further operative to adding to the interest table the names of the plurality of named content items to be received, sent in response to a request for a named content item relating to a particular content. If a named content item received in response to the request includes references to additional named content items, and the response indicates that the additional named content items are to be received, then the user terminal is operative to add the names of those additional named content items to the interest table.

A user terminal comprising an antenna, display, transceiver, processor and memory, said memory containing instructions executable by said processor whereby said user terminal is operative to send a request for a named content item relating to a particular content in an information centric network, the request indicating that all related named content items required for presentation of the particular content are also requested. The user terminal is further operative to store the request in an interest table and receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then deleting the request from the interest table.

The user terminal is further operative to adding to the interest table the names of the plurality of named content items to be received, sent in response to a request for a named content item relating to a particular content. If a named content item received in response to the request includes references to additional named content items, and the response indicates the additional named content items are to be received, then the user terminal is operative to add the names of those additional named content items to the interest table. Figure 11 is a signaling diagram illustrating a system incorporating the arrangements described herein including a send parameter. The system comprises a client node 1110, an intermediate node 1150, and server 1190. Client node 1110 includes a Pending Interest Table (PIT) 1114. Intermediate node 1150 includes a storage component 1152 and a Pending Interest Table (PIT) 1154. Server 1190 includes a storage component 1192.

Client node 1110 sends a request 1120 for named object B to intermediate node 1150, the request 1120 having the send parameter taking value "all". Client 1110 records an entry 1121 for object 'B' in PIT 1114. Upon receipt of the request intermediate node 1150 checks 1122 its local cache (storage component 1152) to see if object B is stored. Object B and its related components are cached at intermediate node 1150 and so object B is returned 1124 to the client node 1110. The return message 1124 that includes object B is tagged with a send parameter taking value "next", to signify that additional components will follow. Object B includes references to two other objects: B₂ and B₃. Upon receipt of object B, client 1110 reads these references and adds 1125 the names B₂ and B₃ to its PIT 1114. Subsequently, intermediate node 1150 sends objects B₂ 1126 and B₃ 1128. These are received by the client node 1110; B₃ is tagged with a send parameter of "last" indicating that no further components will be sent. Client node 1110 then deletes the entries for object B, B2 and B3 from the PIT 1114 because the delivery of the composite object is complete. The management of the PIT 1114 may be handled in another way, for example the PIT entry of object B may be deleted after object B is received but before referenced objects B₂ and B₃ are received. Later, client node 1110 determines it requires named object E. Client node 1110 sends a request 1160 for object E to intermediate node 1150, the request having the send parameter taking value "all". Upon receipt of the request intermediate node 1150 checks 1162 its local cache (storage component 1152) to see if object E is stored. Object E is not stored there so intermediate node 1150 sends 1164 a request for object E to server 1190, and records 1166 the Interest message in its Pending Interest Table 1154. Server 1190 has Object E stored in its storage component 1192 and so object E is returned 1168 to the intermediate node 1150. The return message 1168 that includes object E is tagged with a send parameter taking value "next", to signify that additional components will follow. Object E includes references to two other objects: E₂ and E₃. Upon receipt of object E, intermediate node 1150 reads these references and adds 1170 the names E₂ and E₃ to its PIT 1154. Upon receipt of object E the intermediate node 1150 checks its Pending Interest Table 1154 to see which node had requested object E; client node 1110 is identified as waiting for object E and any related components so object E is sent 1172 by the intermediate node 1150 to the client node 1110. On receipt of Object E 1172, the client node 1110 reads the references to E₂ and E₃ and stores 1174 these names in its PITH 14.

Subsequently, server 1190 sends objects E₂ 1176 and E₃ 1180. These are received by the intermediate node 1150. Upon receipt of these objects the intermediate node 1150 checks its Pending Interest Table 1154 to see which node had requested object E and any related components; client node 1110 is identified as waiting for any components related to object E and so objects E₂ and E₃ are sent 1178, 1182 by the intermediate node 1150 to the client node 1110. E₃ is tagged in message 1180 and 1182 with a send parameter of "last" indicating that no further components will be sent. The entries for object E, E2 and E3 are now deleted from the PIT 1154 as the delivery of the composite object is complete. However, the management of the PIT 1154 may be handled in another way, for example the PIT entry of object E may be deleted after object E is received but before referenced objects E₂ and E₃ are received.

Here the client node 1110 acts only as a requesting node. The server 1190 acts only as a sending node. Intermediate node 1150 acts as both a requesting node and a sending node. The server 1190 is upstream of the intermediate node 1150, which in turn is upstream of the client node 1110. The client node 1110 is downstream of the intermediate node 1150 and both are downstream of the server 1190.

The solution allows multiple Content Object messages (each representing components of a composite content object) to be sent in response to a single Interest message. This allows greater network efficiency than current practice where each component has to be solicited individually.

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 the 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 content centric communication network.

References

'CCNx Messages in TLV Format', IETF internet draft dated 11 January 2016 https:/ / tools.ietf.org/html/ draft-irtf-icnrg-ccnxmessages-01

'CCNx Semantics', IETF internet draft dated 11 January 2016

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

Claims

1. A requesting node in an information centric network, the node arranged to: send a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the particular content are also requested;

store the request in an interest table;

receive a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then the request is deleted from the interest table.

2. The requesting node of claim 1 , further comprising a storage component for storing named content items, the requesting node arranged to store the received named content items in the storage component.

3. The requesting node of any preceding claim, further arranged to send named content items to a downstream node.

4. The requesting node of claim 1, wherein the requesting node further comprises an output, and wherein the requesting node is arranged to output content through the output.

5. The requesting node of any preceding claim, further arranged such that if a named content item received in response to the request indicates that additional named content items are to be received, then the request is not deleted from the interest table.

6. The requesting node of any preceding claim, further arranged to send a further request message for the content, the further request message indicating that no more named content items of the content are wanted.

7. The requesting node of any preceding claim wherein a named content item is a content object and a request identifies the content object that is requested.

8. A method for retrieving particular content, the method comprising, in a node of an information centric network:

sending a request for a named content item relating to the particular content, the request indicating that all related named content items required for presentation of the content are also requested;

storing the request in an interest table;

receiving a plurality of named content items in response to the request, and upon receipt of a named content item that indicates that no more additional named content items are to be received in response to the request, then deleting the request from the interest table.

9. The method of claim 8, further comprising storing the received named content items in a storage component.

10. The method of claim 8 or 9, further comprising sending received named content items to a downstream node.

11. The method of any of claims 8 to 10, wherein the node of an information centric network is a client node, and wherein the method further comprises outputting the particular content through an output of the node.

12. The method of any of claims 8 to 11, further comprising not deleting the request from the interest table if a named content item received in response to the request indicates that additional named content items are to be received.

13. The method of any of claims 8 to 12, further comprising sending a further request message for the named content item relating to particular content, the further request message indicating that no more related named content items required for presentation of the content are wanted.

14. The method of any of claims 8 to 13, wherein a named content item is a content object and a request identifies the content object that is requested.

15. 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 8 to 14.

16. A sending node in an information centric network, the node arranged to:

receive a request for a named content item relating to particular content, the request indicating that all related named content items required for presentation of the content are also requested;

send the named content item and each related named content item in response to such a request, wherein each sent named content item indicates that additional named content items will be sent, except for the last sent named content item sent in reply to the request, which is returned with an indication that no additional named content items will be sent.

17. The sending node of claim 16, further comprising a storage component, the sending node arranged to consult the storage component to verify if a required named content item is cached therein.

18. The sending node of claim 16 or 17, further arranged to receive a further request message for the particular content, the further request message indicating that no more named content items of the content are wanted, and in response thereto the sending node stops sending named content items of the content in response to the request for content.

19. The sending node of any of claims 16 to 18, wherein a named content item is a content object and a request message identifies a content object that is requested.

20. The sending node of any of claims 16 to 19, further arranged to request and receive content.

21. A method for sending particular content in a node of an information centric network, the method comprising:

receiving a request for a named content item relating to the content, the request indicating that all related named content items required for presentation of the content are also requested; sending the named content item and each related named content item in response to such a request, wherein each sent named content item indicates that additional named content items will be sent, except for the last sent named content item sent in reply to the request, which is returned with an indication that no additional named content items will be sent.

22. The method of claim 21, further comprising consulting a storage component to verify if a required named content item is cached therein.

23. The method of claim 21 or 22, further comprising receiving a further request message indicating that no more named content items required for presentation of the content are wanted, and in response thereto sending no more named content items of the particular content in response to the request for content.

24. The method of any of claims 21 to 23, wherein a named content item is a content object and a request message identifies a content object that is requested.

25. The method of any of claims 21 to 24, wherein the node is further arranged to request and receive content.

26. 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 21 to 25.