WO2014135766A1 - Procédé de traitement dans un réseau centré sur les contenus d'une demande relative a un segment de données - Google Patents

Procédé de traitement dans un réseau centré sur les contenus d'une demande relative a un segment de données Download PDF

Info

Publication number
WO2014135766A1
WO2014135766A1 PCT/FR2014/050437 FR2014050437W WO2014135766A1 WO 2014135766 A1 WO2014135766 A1 WO 2014135766A1 FR 2014050437 W FR2014050437 W FR 2014050437W WO 2014135766 A1 WO2014135766 A1 WO 2014135766A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
data segment
server
content
interface
Prior art date
Application number
PCT/FR2014/050437
Other languages
English (en)
Inventor
Bertrand Mathieu
Wei YOU
Gwendal Simon
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2014135766A1 publication Critical patent/WO2014135766A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Definitions

  • the invention lies in the field of Information Centric Networking (ICN), and more particularly relates to a technique for processing a request relating to a data segment in a communication network centered on content CCN for Content Centric Networking.
  • ICN Information Centric Networking
  • ICN networks are an alternative to current architectures, more adapted to the uses of today's Internet.
  • the current architectures are based on a fundamental principle, that of machine-to-machine communications, with two major concerns, to reach a network equipment, and maintain communications between network equipment.
  • Today's user does not care, however, about which machine provides him with the information he is looking for, or where to find the information, which interests him is the information itself.
  • ICN networks offer a new approach that focuses on content.
  • the first corresponds to a request sent on the network relating to a desired data segment, while the other corresponds to the data segment itself.
  • These two types of packets each include a data segment identifier, in particular for determining which request (s) correspond to a segment of data received.
  • the method implemented by a network routing device relies mainly on three data structures: a local cache or content store (CS for Content Store), a routing table (FIB for Forwarding Information Base), and a Pending Interest Table (PIT).
  • CS Content Store
  • FIB Forwarding Information Base
  • PIT Pending Interest Table
  • the device checks pending requests in the table if there are requests related to the same segment of data. If there are previous requests for the same data segment in the pending requests table, the interface through which the pending request was received is added to this table to all the interfaces through which requests are made. related to this data segment were received. When the pending request table does not include previous requests for that data segment, the device stores in the pending request table the identifier of the searched data segment in association with the interface through which the request is made. the desired segment of data was received. It then determines from the routing table an interface through which it transmits the request. When the searched data segment is received by the routing device, the data segment is distributed to all interfaces through which previous requests for that data segment have been received.
  • the routing table stores at least one interface for reaching an origin server storing the content.
  • the origin server is solicited in most cases, when a first request for a data segment is received. This generates routing costs for the network operator, including interconnection costs when the originating server does not belong to the network.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the invention relates to a method for processing a request for a data segment of a content in a content-centric communication network, said method comprising the following steps implemented by a data communication device. routing of the network:
  • said network further comprising at least one substitute server, separate from the origin server, connected to said device by a second interface, and storing at least a portion of the contents of a domain
  • said method comprises the following steps , prior to the sending step and conditioning said sending:
  • the verification step that another request has been sent via the second interface to the substitute server makes it possible to identify that the substitute server has not responded and therefore does not have the desired data segment. Indeed, in these content-centric networks, there are no mechanisms for a server to respond negatively to a request or to redirect the request.
  • the request being processed when a request for this data segment has already been received by the same interface, the request being processed then corresponds to a repetition of the request.
  • the request being processed is then forwarded to the origin server which has the data segment sought. Since only requests that were unable to obtain the requested data segment from a substitute server are sent to the origin server, the latter is less busy and the traffic from the origin server is decreased. The network load is also reduced, and the use of optimized bandwidth.
  • said substitute server is determined according to the domain name on which the content depends.
  • the determination of a substitute server according to a domain name allows an effective management of the contents, insofar as at the level of a routing device according to the invention it is no longer necessary to store a catalog with the full name of the contents.
  • the contents can indeed be aggregated by domain name, which makes it possible to restrict the volume of stored information. Routing by domain name is faster, which also speeds up the demand processing time, and the overall performance of the network.
  • the domain name is a piece of data that evolves little, the association between a domain name and a substitute server has a lasting validity.
  • the routing of the request to an origin server in the event of non-response of the substitute server makes it possible to secure the processing of the requests, when the content is not memorized by the substitute server.
  • the identification of a domain name in the content name of the request relating to a data segment is sufficient to determine a substitute server to which to route the request.
  • the processing method further comprises on receiving said data segment the following steps: obtaining at least one interface via which a request has been received relating to said data segment, associated with a pending request sent via an interface making it possible to reach a server belonging to the group comprising the original server and alternate server;
  • the distribution of the content on all the interfaces through which requests relating to the data segment have been received has the advantage of taking into account all the requests processed by the routing device, associated with routing as well. to a substitute server than to an origin server.
  • the processing method further comprises a step of receiving a publication sent by the substitute server, of at least one domain name for which it stores a part of the contents.
  • the reception of a publication sent by the substitute server makes it possible to indicate to a routing device according to the invention which alternate servers may be requested during a request for content. It also allows a replacement server newly installed in the network to be known automatically to the routing devices according to the invention belonging to the network. Alternate server management by domain name also allows the provision of network resources adapted to the popularity of the domain name. For example, a domain name such as "youtube.com", whose content is particularly popular, will have several dedicated substitutes sized to handle a large number of requests.
  • the publishing mechanism also allows a routing device to differentiate routing data relating to the alternate server from that relating to the originating server.
  • the invention proposes a device for routing a request relating to a data segment of a content in a communication network centered on the contents, comprising:
  • a sending module arranged to send said request via at least one first interface making it possible to reach at least one origin server storing said content, when no previous request relating to said data segment n ' is pending;
  • a verification module arranged to verify that another request relating to the segment has been sent via a second interface making it possible to reach said substitute server and is pending, and that a previous request relating to said segment, associated with the other pending application and said request being processed have been received via the same interface.
  • the routing device further comprises a module for receiving a publication, arranged to receive a publication issued by the substitute server, of at least one domain name for which said server stores a part of the contents. .
  • the invention also relates to a content-centric communication network comprising at least one routing device according to the second aspect, said network further comprising at least one substitute server, distinct from the origin server, and storing at least a portion of the contents of a domain.
  • a content-centric communication network with a substitute server can take advantage of the known benefits of a cache within such a network: freeing up network resources, better use of bandwidth, faster retrieval of content popular, etc.
  • the routing device has the advantage of being integrated in a mixed network comprising both routing devices known from the state of the art and routing devices according to the invention. No major modification of the infrastructures is required, and the deployment of routing devices according to the invention, in a communication network centered on the existing contents is easy. Thanks to the invention it is therefore possible to simply add cache functionality to an existing content-centric network architecture.
  • said at least one substitute server of the communication network comprises a publication module, arranged to publish at least one domain name for which it stores a part of the contents.
  • the invention also relates to a program for a routing device according to the second aspect, comprising program code instructions for controlling the execution of the steps of the method described above, when said program is executed by said device and a support of recordable by a routing device on which a program for a routing device is recorded.
  • FIG. 1 represents a communication network centered on information
  • FIG. 2 shows a routing device according to a particular embodiment
  • FIGS. 3a and 3b show steps of the method of processing a data packet according to a particular embodiment
  • FIGS. 4a-h illustrate the implementation of the steps of the method in a particular scenario.
  • FIG. 1 represents an information-centric communication network 1 enabling client entities 108a-b to access content.
  • the network is organized as a mesh network.
  • Each client entity 108a-b is connected to the network 10 of a network operator, enabling it to send a request for a content, and to receive this content from a device of the network 1.
  • These contents, videos, music, page Internet, for example are exchanged on the network in the form of data segments.
  • Content consists of either a single segment of data (the segment is in this case representative of the content as a whole), or several segments of data (chunk in English).
  • Content is associated in the network organization with a domain name.
  • a content identifier is organized as follows:
  • a name in the organization for example "stream / news /../ videol / versionl”.
  • a segment of data belonging to the content is identified by the identifier of the content and information relating to the segment number.
  • the data segment is identified by "/youtube.com/stream/news/../videol/versionl/segmentl”.
  • the requested data segment can be obtained from an origin server 106a-c, a substitute server 102a-c, a routing device as described by Van Jacobson et al. 104a-d, a routing device 20a-b, or from any other device of the network 1 capable of storing this segment of data.
  • the original servers 106a-c are used by the content providers to make their content available on the network 1. They are often located outside the network 10 of the network operator.
  • the network operator may also be content provider, and have its own original servers in its network (case of the original server 106a which belongs to the network 10). Because of their frequent location outside the network of the network operator, these servers are generally far from the client entities. This distance can generate significant interconnection costs.
  • Substitute servers 102a-c are used by network operators to cache content, storing at least a portion of the contents of a domain name. More precisely, they make it possible to store locally and temporarily contents requested by a client entity 108a-b, in order to transmit them later to other client entities. Substitute servers 102a-c are dedicated to this content caching function, and do not have an aggregation and transmission of requests function. In particular, they are distinguished from a local cache memory of a routing device 20a-b or 104a-d, especially in terms of memory capacity and use. Unlike a local cache that has limited capabilities for storing only a few segments of data, alternate servers 102a-c are used to replicate entire contents of one or more origin servers.
  • the alternative servers 102a-c are generally placed closer to the 108a-b client entities in order to reduce the access time to the desired content.
  • a routing device does not publish a catalog of data segments stored in its local cache. The latter is therefore not addressable.
  • the routing devices 104a-d make it possible to route a request relating to a data segment to an origin server storing this data segment, and then forward it to the client entities that requested it.
  • the routing carried out is a routing by name, described by Van Jacobson et al. in the aforementioned "Networking Named Content" document, which relies primarily on three data structures: a content store, a request routing table, and a pending request table.
  • a device 104a-d receives a request, it first checks whether it stores the desired data segment in its content store, and returns it if it is, to the interface through which it has reached Requirement.
  • the device 104a-d verifies that there is no request for the data segment that has already been received by the device, and for which the data segment has not yet been received. Such a request is called a "pending application". More precisely, it is a pending request to an origin server. If such a pending request exists, the pending request is not redirected. If no pending request is stored in the pending requests table of the device 104a-d, the request for the data segment is sent to an origin server 106a-c, and itself becomes pending until it receives the request. segment of data sought. When the device 104a-d receives the desired data segment, the latter is simply distributed to the interfaces of the device 104a-d through which requests relating to the data segment have been received.
  • Network 10 of the network operator also includes routing devices 20a-b. These routing devices 20a-b, unlike the routing devices 104a-d, make it possible to route a request to origin servers 106a-c, but also to alternative servers 102a-c.
  • the routing devices 20a-b are directly connected to one or more substitutes 102a-c.
  • the routing devices 20a-b direct the request relating to a data segment in priority to the substitute server when possible.
  • a routing device 20a-b uses two data structures in addition to the three data structures previously described: a cache routing table and a hidden request table.
  • a device 20a-b When a device 20a-b receives a request, it first verifies whether its local cache memory stores the desired data segment and returns it, if any, to the interface through which it has received the request. In the opposite case, the device 20a-b checks whether the data segment is attached to a domain of which at least part of the contents is stored by a substitute server 102a-c. If this is the case, it then checks whether there is a pending request to this substitute server 102a-c, relative to the sought data segment. If such a request exists, the current request for the data segment, if received through a new interface, is not forwarded.
  • the routing device 20a-b returns the request to a server d. origin 106a-c.
  • the device 20a-b thus makes it possible to send back a request relating to a segment for which no substitute server 102a-c has responded, to an origin server 106a-c.
  • the request is then treated in the same way as it would have been by a routing device 104a-d.
  • Substitute servers 102a-c are also directly connected with the routing devices 20a-b.
  • Figure 2 shows a routing device 20 according to a particular embodiment. It includes:
  • a transmission / reception module 200 arranged to receive and transmit a data packet on the network, the data packet possibly being a request relating to a data segment, or a data segment;
  • a processing module 202 arranged to process a data packet, the data packet possibly being a request relating to a data segment or a data segment;
  • a first table 210 called the Forwarding Information Base (FIB) routing table, arranged to store request routing data relating to data segments according to the identifiers of the data segments, more specifically a list of interface identifiers through which an origin server 106a-c is reached, in association with a data segment identifier.
  • FIB Forwarding Information Base
  • a second table 214 called the PIT pending table, for "Pending Interest Table", arranged to store a list of interfaces through which a or requests for a data segment of a content have been received until that data segment has been received in response. These are pending requests to an origin server 106a-c;
  • a module for receiving a publication 204 arranged to receive a publication sent by a substitute server 102a-c, of at least one domain name for which the substitute server 102a-c stores at least part of the contents;
  • a third table 208 called the cache forwarding table, referred to as the CFT cache routing table, arranged to store request routing data relating to data segments to substitute servers 102a-c, more specifically a list of interface identifiers for reaching a substitute server 102a-c, in association with a domain name;
  • a fourth table 212 called the Pending Cached Interest Table, which is designed to store a list of interfaces through which one or more requests relating to a data segment of a content have received, the first of these requests having been sent to a substitute server 102a-c, as long as this data segment was not received in response. These are pending requests to a substitute server 102a-c.
  • the storage means 206 are for example a memory zone, a buffer zone (or “buffer”) or an external hard disk.
  • the processing module 202 comprises a verification sub-module 216, arranged to check whether a request relating to the data segment of the request being processed has already been sent to a substitute server 102a-c, and if two previous requests have received via a single interface. In another embodiment, it may be an independent module.
  • the device 20 does not include a module for receiving a publication 204.
  • the routing data of the CFT table are in this case locally filled.
  • Such a routing device may be a network router, a network access gateway, access multiplexer equipment.
  • the client entity 108a wishes to obtain a data segment of a content.
  • the client entity 108a transmits an IntP request for "Interest Packet" relating to this data segment.
  • FIG. 3a describes the steps of the method of processing a data segment that are implemented by the routing device 20 to process a packet carrying a request.
  • the routing device 20 receives the request IntP and determines whether it has the requested data segment in its content store 206. For this, it proceeds for example by comparison of the CN identifier of the segment of data of the IntP request with the identifiers of the segments stored in its content store 206.
  • the requested segment is present in the content store 206 of the device 20, it is transmitted, in a step E2, to the interface through which the IntP request has been received.
  • the device 20 then waits for a next request or for a next data segment to be processed.
  • the routing device 20 determines a DN domain name from the CN identifier of the data segment. From this DN domain name, the routing device 20 then determines in a step E4, whether there exists in the CFT cache routing table 208, a list of interfaces directly connected to one or more proxy servers, and associated with this DN domain name. If the DN domain name is not found in the CFT 208 table, it means that there are no known alternative servers of the device 20 storing at least a portion of the contents of this domain. In this case, the device 20 goes to a step El 1, and executes the routing method 30a known from the state of the art as described by Van Jacobson et al., In the previously cited document.
  • the device 20 checks in a step E5, if a previous request relating to the same data segment has already been sent to a substitute server 102a-c. For this purpose, it checks in particular whether the pending hidden requests table PCIT 212 stores the CN identifier of the searched data segment.
  • the device 20 then stores, in a step E12, the CN identifier of the data segment in the PCIT table 212, in association with the interface F by which the IntP request relating to the data segment has been received. This allows the device 20 to mark the IntP request as being pending to one or more alternate servers 102a-c.
  • the request IntP is then sent to a substitute server (s) 102a-c, via the associated interface (s) in the CFT 208 to the DN domain name obtained ( s) at step E4. Processing of the packet carrying the request for the data segment is then completed, and the device waits for reception of a packet of data.
  • step E5 the CN of the searched segment is stored in the PCIT 212
  • the device 20 checks in a step E6, if an LF list of interfaces associated with the CN identifier of the data segment of the IntP request is stored in the PCIT 212 table.
  • the absence of an interfaces LF list associated with the CN identifier indicates to the device 20 that at least two previous requests relating to the searched data segment have been received by through the same interface, an earlier request having been sent to a substitute server 102a-c.
  • the device 20 then goes to step El i to process the IntP request according to the routing method 30a known from the state of the art, described above. Thus, in this case, the IntP request is routed to one or more origin servers 106a-c.
  • step E6 an interface list LF associated with the CN identifier of the data segment of the IntP request having been obtained, one or more previous requests relating to the same data segment were received by the user. intermediate two-to-two interfaces, and that the first of these previous requests has been sent to a substitute server 102a-c.
  • step E7 the device 20 verifies that the interface F by which the IntP request has been received does not belong to the list LF associated with the CN identifier of the data segment searched in the PCIT 212 table.
  • the PCIT table 212 is updated in a step E8, in order to add the interface F to the list LF of the interfaces associated with the identifier CN of the searched data segment. This allows, upon receipt of the desired data segment, to distribute it to all the interfaces through which a request for this desired data segment has been received. Processing of the request packet relating to the data segment is then completed, and the device waits to receive a new data packet.
  • step E7 the interface F through which the IntP request being processed has been received belongs to the list of interfaces obtained in step E6, this means that the substitute server 102a -c did not respond to the pending request stored in the PCIT 212 table.
  • the IntP request is routed to an origin server 106a-c.
  • the packet carrying the IntP request is sent to the routing method 30b adapted to the routing method 30a known from the state of the art.
  • This adaptation consists in adding a step E9 of storing the list of interfaces LF in the table PIT 214 in association with the identifier CN of the searched data segment, and deleting this list LF of the table PCIT 212.
  • the list of interfaces LF is stored in the table PIT 214, after the device 20a-b has verified that there is no pending request to an origin server 106a-c relating to the data segment sought. (step El i). The request is thus sent back to an origin server 106a-c.
  • Step E6 allows indeed, as previously described, to redirect a request with a list of empty interfaces directly to the method 30a known from the state of the art.
  • steps E12 and E13 are implemented successively. In another embodiment, step E13 is implemented before step E1. In yet another embodiment, steps E12 and E1 are executed in parallel.
  • the IntP request is processed at the end of the steps E2, E8, E13, as well as after the routing processes 30a and 30b.
  • the processing method proceeds to a waiting step of receiving a data packet.
  • FIG. 3b describes, for its part, the steps of the method implemented to process a data segment received via an interface f.
  • a step F1 the routing device 20 receives a data segment DatP via the interface f, and determines whether the segment DatP comes from a substitute server 102a-c. For this it verifies that the DatP segment has been received via an interface directly connected to a substitute server 102a-c. If this is the case, the routing device 20 proceeds to a step F2b, in which it checks whether the CN identifier of the received data segment is stored in the PCIT 212 table. If the CN identifier is not in the PCIT 212, the received data segment does not correspond to any pending request for the device 20, and it is ignored.
  • a request for this data segment is pending.
  • the interfaces associated with the CN identifier of the data segment, through which previous requests were received, are obtained from the PCIT 212 table.
  • the absence of interfaces associated with the CN identifier indicates at least one previous request has been sent to a substitute server 102a-c, but the latter having responded late, another request has meanwhile been sent to a separate network device of a substitute server 102a-c.
  • the identifier CN is then deleted from the PCIT 212 table. This makes it possible to route a next request relating to the data segment to a substitute server 102a-c (step E5).
  • the data segment being processed is ignored. It is emphasized here that upon receipt of the data segment in response to the other request sent in the meantime to a separate network device of a substitute server 102a-c, the data segment is routed to the stored interface (s). in the PIT table 214, in which the interface or interfaces stored in the PCIT 212 have been stored. Thus, ignoring the data segment is of no consequence to client entities 108a-b.
  • the pending request for the data segment is then deleted from the PCIT 212 in a step F5b.
  • step F6 the data segment is sent via the interfaces obtained in step F3b.
  • This shipment is managed, as a non-limiting example, by a queue associated with each interface, in which are stored the data segments waiting to be sent.
  • the routing device 20 then returns to awaiting reception of a data packet.
  • step F2a the device 20 checks whether the CN identifier of the received data segment is contained in the PIT 214 table. If the CN identifier is not in the PIT 214 table, the received data segment does not correspond to any pending request and is ignored. If the CN identifier is in the PIT 214 table, a request for this data segment being pending, in a step F3a, the interfaces associated with the CN identifier of the data segment are obtained from the PIT table 214. .
  • the pending request for the data segment is then deleted from the PIT table 214 in a step F5a.
  • the PCIT 212 always stores the identifier of the searched data segment. This makes it possible to determine for the processing of a next request for the data segment, that before being sent to an origin server 106a-c, an earlier request for this data segment has been sent to a server substitute 102a-c who did not answer.
  • the PCIT table is not updated, so that in a future request for this content, the latter is directly directed to an origin server 106a-c.
  • the data segment is sent to step F6 via the interfaces obtained in step F3a.
  • the data segment DatP is processed after the steps F2b, F3b, F2a and F6.
  • the routing device 20 then returns to awaiting reception of a data packet.
  • step F1 is not provided.
  • the presence of pending requests is then systematically verified in both PCIT and PIT tables.
  • two tables of pending requests are used: the table of pending requests to a substitute server (PCIT table 212), and the table of pending requests to an origin server (PIT table 214).
  • PCIT table 212 the table of pending requests to a substitute server
  • PIT table 214 the table of pending requests to an origin server
  • this table also stores in association with the identifier of the data segment if the request is pending to a substitute server or an origin server.
  • a refreshing mechanism of the PCIT table 212 is realized, by way of non-limiting example, by the deletion at regular intervals (every five hours for example) of all the entries of the PCIT table 212 relating to a data segment for which the data segment was not received. This makes it possible to take into account the evolutions relating to the contents memorized by the alternative servers 102a-c.
  • a substitute server 102a-c is indeed likely to memorize a content that it did not memorize before, and therefore sending a data segment in response to a request for a data segment of that content.
  • Such a content-centric network can also interwork with a Content Delivery Network (CDN) content distribution network integrating substitutable servers addressable by their Internet Protocol (IP) address.
  • CDN Content Delivery Network
  • IP Internet Protocol
  • the direct connection between a content-based network routing device and a substitute server is effected for example via a gateway, arranged to translate an IP addressing into an addressing by name and reciprocally.
  • FIGS. 4b-h represent the contents of the tables CFT 208, FIB 210, PCIT 212 and PIT 214, of a device of FIG. routing during the execution of different process steps, for a particular scenario shown in Figure 4a.
  • the routing device 20 has four interfaces il, i2, i3 and i4. It is interfaced with the client entity 401 via the interface it, with the client entity 402 via the interface i2, with a substitute server 403 via the interface i3.
  • the interface i4 also allows it to reach an origin server 404.
  • the requests D1 and D3 are issued by the client entity 401, and the request D2 by the client entity 402.
  • the CFT and FIB tables are each filled with a routing rule.
  • the CFT table indicates that any request for content belonging to the "youtube.com” domain must be routed through the i3 interface ( Figure 4b).
  • the FIB table indicates that a request for "/youtube.com/stream/news/../videol/versionl” content must be routed through the i4 interface ( Figure 4c).
  • the PIT and PCIT tables are empty.
  • the client entity 401 sends a request D1 relating to the data segment "/youtube.com/stream/news/../videol/versionl/segmentl". It is received by the device 20 via the interface 11.
  • the identifier of the requested data segment indicates that the content to which the desired data segment belongs is attached to the domain "youtube.com”.
  • the CFT table has a routing rule for this domain (step E4).
  • the request D1 is sent to the substitute server 403 via the interface i3 associated with the domain name in the table CFT (step E13). This request is pending to the alternate server 403 until the data segment has been received by the device 20.
  • the identifier of the data segment associated with the interface through which the request has been received D1 is stored (step E1) in the PCIT table (FIG. 4d).
  • the client entity 402 in turn sends a request D2 relating to the same data segment "/youtube.com/stream/news/../videol/versionl/segmentl".
  • This request is received by the device 20 via the interface i2.
  • the PCIT table indicates that a request for the same data segment has already been received.
  • the PCIT table is then updated in order to memorize the interface i2 through which the second request D2 has been received (FIG. 4e). At this stage, the PIT table has still not been modified (Figure 4g).
  • a third request D3 always relating to the same data segment
  • the D3 request is received through the same interface as the D1 request.
  • This interface belongs to the list of associated interfaces in the PCIT table with the pending request to the substitute server 403 (step E7). It is therefore a repetition of the request on the same interface.
  • the substitute server 403 has therefore not responded to the request D1.
  • the request is then routed to the origin server 404, according to the routing rule stored in the FIB table (FIG. 4c).
  • the list of interfaces associated with the identifier of the data segment in the PCIT table is erased from this table (FIG. 4f), and is then stored in the PIT table (FIG. 4h).
  • the PCIT table stores the identifier of the data segment without associated interface identifier. This makes it possible to identify that a request sent to the substitute server 403 has remained unanswered. Thus a next request relating to the data segment "/youtube.com/stream/news/../videol/versionl/segmentl", is directly routed to the original server 404.
  • module may correspond in this document to both a software component, a hardware component or a set of hardware and / or software components, capable of implementing a function or a set of functions, as described above for the module concerned.
  • a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software.
  • Such a software component is stored in memory and then loaded and executed by a data processor of a physical entity and is able to access the hardware resources of this physical entity (memories, recording media, communication buses, electronic cards of a physical entity). input / output, user interfaces, etc.).
  • a material component corresponds to any element of a material set (or hardware). It may be a programmable hardware component or not, with or without an integrated processor for running software. This is for example an integrated circuit, a smart card, an electronic card for executing a firmware, etc.
  • the modules 200, 202, 204 are arranged to implement the previously described method. These are preferably software modules comprising software instructions for executing the steps of the method described above, implemented by the protection device.
  • the invention therefore also relates to: a program for a routing device, comprising program code instructions for controlling the execution of the steps of the method described above, when said program is executed by said device;
  • a recording medium readable by a routing device on which the program for a routing device is recorded.
  • the software modules can be stored in or transmitted by a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as an electrical signal, optical or radio, or a telecommunications network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procédé de traitement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus, comprenant au moins un serveur substitut, distinct du serveur d'origine, connecté au dispositif par une interface, et mémorisant au moins une partie des contenus d'un domaine, ledit procédé comprenant les étapes suivantes mises en œuvre par un dispositif d'acheminement : - vérification qu'une autre demande relative au segment est pendante vers le serveur substitut, et qu'une demande antérieure relative au segment, associée à l'autre demande pendante et la demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface; - envoi de la demande par l'intermédiaire d'au moins une interface permettant d'atteindre au moins un serveur d'origine mémorisant le contenu, lorsqu'aucune demande antérieure relative au segment de données n'est pendante vers un serveur d'origine.

Description

Procédé de traitement dans un réseau centré sur les contenus d'une demande relative à un segment de données
L'invention se situe dans le domaine des réseaux de communication centrés sur les informations (en anglais ICN pour Information Centric Networking), et concerne plus particulièrement une technique de traitement d'une demande relative à un segment de données dans un réseau de communication centré sur les contenus (en anglais CCN pour Content Centric Networking).
Les réseaux ICN se veulent une alternative aux architectures actuelles, plus adaptée aux usages de l'Internet d'aujourd'hui. Les architectures actuelles reposent en effet sur un principe fondamental, celui de communications de machine à machine, avec deux préoccupations majeures, atteindre un équipement du réseau, et maintenir les communications entre des équipements du réseau. L'utilisateur d'aujourd'hui se soucie cependant peu de savoir quelle machine lui fournit l'information recherchée, ou de savoir où trouver l'information, ce qui l'intéresse est bien l'information elle-même. En réponse à cette tendance, les réseaux ICN proposent une nouvelle approche qui se focalise sur les contenus.
Le document intitulé « Networking Named Content », de Van Jacobson et al. publié en 2009 dans les actes de la conférence CoNEXT'09, décrit un nouveau modèle d'architecture ICN, plus précisément un réseau CCN (CCN pour Content Centric Networking), dans lequel un contenu est obtenu par son nom. Il propose de remplacer l'actuel adressage par équipement réseau (permettant d'identifier un équipement dans le réseau par son adresse IP) par un adressage par nom de contenu. Dans cette nouvelle architecture centrée sur les contenus, deux fonctions principales doivent être rendues : proposer l'information, et obtenir l'information. Pour cela, deux types de paquets de données sont définis, une demande relative à un segment de données d'un contenu {Interest packet) et un segment de données (Data packet). Le premier correspond à une demande émise sur le réseau relative à un segment de données recherché, tandis que l'autre correspond au segment de données lui-même. Ces deux types de paquets comportent chacun un identifiant de segment de données permettant notamment de déterminer à quelle(s) demande(s) correspond un segment de données reçu. Le procédé mis en œuvre par un dispositif d'acheminement du réseau repose principalement sur trois structures de données : une mémoire cache locale ou magasin de contenus (CS pour Content Store), une table d'acheminement (FIB pour Forwarding Information Base), et une table des demandes pendantes (PIT pour Pending Interest Table). Sur réception par l'intermédiaire d'une interface d'une demande relative à un segment de données, le dispositif d'acheminement du réseau vérifie s'il dispose de ce segment de données dans sa mémoire cache locale. Si tel est le cas, le segment de données recherché est envoyé vers l'interface par l'intermédiaire de laquelle la demande est parvenue au dispositif. Dans le cas contraire, le dispositif vérifie dans la table des demandes pendantes s'il existe des demandes antérieures relatives au même segment de données. En cas d'existence de demandes antérieures pour le même segment de données dans la table des demandes pendantes, l'interface par laquelle a été reçue la demande en cours de traitement est ajoutée dans cette table à l'ensemble des interfaces par lesquelles des demandes relatives à ce segment de données ont été reçues. Lorsque la table des demandes pendantes ne comprend pas de demandes antérieures relatives à ce segment de données, le dispositif mémorise dans la table des demandes pendantes l'identifiant du segment de données recherché en association avec l'interface par l'intermédiaire de laquelle la demande relative au segment de données recherché a été reçue. Il détermine ensuite à partir de la table d'acheminement une interface par l'intermédiaire de laquelle il transmet la demande. Lorsque le segment de données recherché est reçu par le dispositif d'acheminement, le segment de données est distribué à l'ensemble des interfaces par lesquelles des demandes antérieures relatives à ce segment de données ont été reçues.
Telle que prévue dans ce procédé, la table d'acheminement mémorise au moins une interface permettant d'atteindre un serveur d'origine mémorisant le contenu. Ainsi, le serveur d'origine est sollicité dans la plupart des cas, lorsqu'une première demande relative à un segment de données est reçue. Ceci engendre des coûts d'acheminement pour l'opérateur du réseau, notamment des coûts d'interconnexion lorsque le serveur d'origine n'appartient pas au réseau.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Selon un premier aspect, l'invention concerne un procédé de traitement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus, ledit procédé comprenant les étapes suivantes mises en œuvre par un dispositif d' acheminement du réseau :
- envoi de ladite demande par l'intermédiaire d'au moins une première interface permettant d'atteindre au moins un serveur d'origine mémorisant ledit contenu, lorsqu' aucune demande antérieure relative audit segment de données n'est pendante ;
caractérisé en ce que, ledit réseau comprenant en outre au moins un serveur substitut, distinct du serveur d'origine, connecté audit dispositif par une deuxième interface, et mémorisant au moins une partie des contenus d'un domaine, ledit procédé comprend les étapes suivantes, préalablement à l'étape d'envoi et conditionnant ledit envoi :
- vérification qu'une autre demande relative au segment a été envoyée par l'intermédiaire de ladite deuxième interface et est pendante, et qu'une demande antérieure relative audit segment, associée à l'autre demande pendante et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface.
II est connu pour un opérateur d'introduire dans son réseau des serveurs substituts. Ces serveurs substituts sont agencés pour mémoriser certains contenus, par exemple des contenus populaires. Ces serveurs substituts permettent de ne pas solliciter les serveurs d'origine et ainsi de diminuer les coûts d'acheminement. Il est ici souligné que ces serveurs substituts sont distincts des mémoires caches des dispositifs d'acheminement. Lorsqu'une demande relative à un segment de données est transmise sur l'interface par l'intermédiaire de laquelle le dispositif d'acheminement est connecté au serveur substitut, elle n'est pas traitée par d'autres dispositifs d'acheminement situés sur un chemin à destination du serveur d'origine. Il ne s'agit donc pas selon l'invention de solliciter les mémoires caches des dispositifs d'acheminement mais bien de permettre le fonctionnement de serveurs substituts prévus par exemple pour un réseau de distribution de contenus de type CDN. L'étape de vérification qu'une autre demande a été envoyée par l'intermédiaire de la deuxième interface vers le serveur substitut permet d'identifier que le serveur substitut n'a pas répondu et ne dispose donc pas du segment de données recherché. En effet, il n'existe pas dans ces réseaux centrés sur les contenus de mécanismes permettant à un serveur de répondre négativement à une demande, ni de rediriger la demande. De plus, lorsqu'une demande relative à ce segment de données a déjà été reçue par la même interface, la demande en cours de traitement correspond alors à une répétition de la demande. La demande en cours de traitement est alors acheminée vers le serveur d'origine qui dispose, lui, du segment de données recherché. Du fait que seules les demandes qui n'ont pu obtenir le segment de données recherché à partir d'un serveur substitut sont envoyées vers le serveur d'origine, ce dernier est moins sollicité et le trafic en provenance du serveur d'origine est de fait diminué. La charge réseau s'en trouve également diminuée, et l'utilisation de la bande passante optimisée.
Selon une caractéristique particulière du procédé de traitement, pour envoyer ladite autre demande, ledit serveur substitut est déterminé en fonction du nom de domaine duquel dépend le contenu.
La détermination d'un serveur substitut en fonction d'un nom de domaine permet une gestion efficace des contenus, dans la mesure où au niveau d'un dispositif d'acheminement selon l'invention il n'est plus nécessaire de mémoriser un catalogue avec le nom complet des contenus. Les contenus peuvent en effet être agrégés par nom de domaine, ce qui permet de restreindre le volume d'informations mémorisées. L'acheminement par nom de domaine est plus rapide, ce qui accélère également le temps de traitement de la demande, et les performances globales du réseau. Par ailleurs le nom de domaine étant une donnée qui évolue peu, l'association entre un nom de domaine et un serveur substitut possède une validité durable. En outre, l'acheminement de la demande vers un serveur d'origine en cas de non réponse du serveur substitut, permet de sécuriser le traitement des demandes, lorsque le contenu n'est pas mémorisé par le serveur substitut. L'identification d'un nom de domaine dans le nom de contenu de la demande relative à un segment de données suffit en effet à déterminer un serveur substitut vers lequel acheminer la demande.
Selon une autre caractéristique particulière, le procédé de traitement comprend en outre sur réception dudit segment de données les étapes suivantes : - obtention d'au moins une interface par l'intermédiaire de laquelle a été reçue une demande relative audit segment de données, associée à une demande pendante envoyée par l'intermédiaire d'une interface permettant d'atteindre un serveur appartenant au groupe comprenant le serveur d'origine et le serveur substitut ;
- envoi dudit segment de données par l'intermédiaire de ladite au moins une interface obtenue.
La distribution du contenu sur l'ensemble des interfaces par lesquelles des demandes relatives au segment de données ont été reçues, présente l'avantage de prendre en compte l'ensemble des demandes traitées par le dispositif d'acheminement, associées à des acheminements aussi bien vers un serveur substitut que vers un serveur d'origine.
Selon une autre caractéristique particulière, le procédé de traitement comprend en outre une étape de réception d'une publication émise par le serveur substitut, d'au moins un nom de domaine pour lequel il mémorise une partie des contenus.
La réception d'une publication émise par le serveur substitut permet d'indiquer à un dispositif d'acheminement selon l'invention, quels sont les serveurs substituts qui peuvent être sollicités lors d'une demande de contenu. Elle permet en outre à un serveur substitut nouvellement installé dans le réseau de se faire connaître automatiquement auprès des dispositifs d'acheminement selon l'invention appartenant au réseau. Une gestion des serveurs substituts par nom de domaine permet par ailleurs d'octroyer des ressources réseaux adaptées à la popularité du nom de domaine. Par exemple un nom de domaine comme « youtube.com », dont les contenus sont particulièrement populaires, disposera de plusieurs serveurs substituts dédiés et dimensionnés pour traiter un nombre important de demandes. Dans un mode de réalisation, le mécanisme de publication permet également à un dispositif d'acheminement de différencier les données d'acheminement relatives au serveur substitut de celles relatives au serveur d'origine.
Selon un deuxième aspect, l'invention propose un dispositif d'acheminement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus, comprenant :
- un module d'envoi, agencé pour envoyer ladite demande par l'intermédiaire d'au moins une première interface permettant d'atteindre au moins un serveur d'origine mémorisant ledit contenu, lorsqu'aucune demande antérieure relative audit segment de données n'est pendante ;
- un module de vérification, agencé pour vérifier qu'une autre demande relative au segment a été envoyée par l'intermédiaire d'une deuxième interface permettant d'atteindre ledit serveur substitut et est pendante, et qu'une demande antérieure relative audit segment, associée à l'autre demande pendante et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface.
Les avantages énoncés pour le procédé de traitement d'une demande relative à un segment de données selon le premier aspect sont transposables directement au dispositif d' acheminement selon le deuxième aspect. Selon une caractéristique particulière, le dispositif d' acheminement comprend en outre un module de réception d'une publication, agencé pour recevoir une publication émise par le serveur substitut, d'au moins un nom de domaine pour lequel ledit serveur mémorise une partie des contenus.
Selon un troisième aspect, l'invention concerne également un réseau de communication centré sur les contenus comprenant au moins un dispositif d'acheminement selon le deuxième aspect, ledit réseau comprenant en outre au moins un serveur substitut, distinct du serveur d'origine, et mémorisant au moins une partie des contenus d'un domaine.
Un réseau de communication centré sur les contenus comprenant un serveur substitut permet de tirer parti des avantages connus d'un cache au sein d'un tel réseau : libération de ressources réseau, meilleure utilisation de la bande passante, récupération plus rapide d'un contenu populaire, etc. En outre le dispositif d'acheminement présente l'avantage de pouvoir être intégré dans un réseau mixte comprenant à la fois des dispositifs d'acheminement connus de l'état de la technique et des dispositifs d'acheminement selon l'invention. Aucune modification lourde des infrastructures n'est requise, et le déploiement de dispositifs d'acheminement selon l'invention, au sein d'un réseau de communication centré sur les contenus existant est aisé. Grâce à l'invention il est donc possible d'ajouter simplement des fonctionnalités de cache à une architecture réseau centrée sur les contenus existante.
Selon une caractéristique particulière, ledit au moins un serveur substitut du réseau de communication selon le troisième aspect, comprend un module de publication, agencé pour publier au moins un nom de domaine pour lequel il mémorise une partie des contenus.
Les avantages présentés pour l'une quelconque des caractéristiques particulières selon le premier aspect sont directement transposables au réseau de communication selon le troisième aspect.
L'invention concerne également un programme pour un dispositif d'acheminement selon le deuxième aspect, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit dispositif et un support d'enregistrement lisible par un dispositif d'acheminement sur lequel est enregistré un programme pour un dispositif d'acheminement.
L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels :
- la figure 1 représente un réseau de communication centré sur l'information ;
- la figure 2 représente un dispositif d'acheminement selon un mode particulier de réalisation ;
- les figures 3a et 3b représentent des étapes du procédé de traitement d'un paquet de données selon un mode particulier de réalisation ;
- les figures 4a-h illustrent la mise en œuvre des étapes du procédé dans un scénario particulier. La figure 1 représente un réseau de communication centré sur l'information 1 permettant à des entités clientes 108a-b d'accéder à des contenus. Tels que représentés sur la figure 1, le réseau est organisé sous la forme d'un réseau maillé. Il n'existe cependant pas de caractère limitatif quant à la topologie du réseau 1 adoptée. Chaque entité cliente 108a-b est reliée au réseau 10 d'un opérateur de réseaux, lui permettant d'envoyer une demande relative à un contenu, et de recevoir ce contenu depuis un équipement du réseau 1. Ces contenus, vidéos, musique, page internet, par exemple, sont échangés sur le réseau sous la forme de segments de données. Un contenu est constitué soit d'un unique segment de données (le segment est dans ce cas représentatif du contenu dans son ensemble), ou de plusieurs segments de données (chunk en anglais). Un contenu est associé dans l'organisation du réseau à un nom de domaine. A titre d'exemple non limitatif, un identifiant de contenu est organisé de la façon suivante :
- un préfixe ou information relative à un nom de domaine, correspondant à un nom acheminable ou routable, par exemple « youtube.com »,
un nom dans l'organisation, par exemple « stream/news/../ videol/versionl».
Un segment de données appartenant au contenu est identifié par l'identifiant du contenu et une information relative au numéro de segment.
Selon cet exemple, le segment de données est identifié par « /youtube.com/stream/news/../videol/versionl/segmentl».
Le segment de données demandé peut être obtenu depuis un serveur d'origine 106a-c, un serveur substitut 102a-c, un dispositif d'acheminement tel que décrit par Van Jacobson et al. 104a- d, un dispositif d'acheminement 20a-b, ou depuis tout autre dispositif du réseau 1 susceptible de mémoriser ce segment de données.
Les serveurs d'origine 106a-c, sont utilisés par les fournisseurs de contenus pour mettre leurs contenus à disposition sur le réseau 1. Ils sont souvent localisés en dehors du réseau 10 de l'opérateur de réseaux. L'opérateur de réseaux peut également être fournisseur de contenus, et disposer de ses propres serveurs d'origine dans son réseau (cas du serveur d'origine 106a qui appartient au réseau 10). En raison de leur fréquente localisation en dehors du réseau propre à l'opérateur de réseaux, ces serveurs sont généralement éloignés des entités clientes. Cet éloignement peut générer des coûts d'interconnexion importants.
Les serveurs substituts 102a-c sont utilisés par les opérateurs de réseaux pour mettre en cache des contenus, en mémorisant au moins une partie des contenus d'un nom de domaine. Plus précisément ils permettent de mémoriser localement et temporairement des contenus demandés par une entité cliente 108a-b, afin de les transmettre ultérieurement à d'autres entités clientes. Les serveurs substituts 102a-c sont dédiés à cette fonction de mise en cache des contenus, et ne disposent pas de fonction d'agrégation et de transmission des demandes. Ils sont en particulier à distinguer d'une mémoire cache locale d'un dispositif d'acheminement 20a-b ou 104a-d, notamment en terme de capacité de mémorisation et d'utilisation. Contrairement à une mémoire cache locale qui dispose de capacités limitées ne permettant de mémoriser que quelques segments de données, les serveurs substituts 102a-c sont utilisés pour répliquer des contenus entiers d'un ou plusieurs serveurs d'origine. Ils permettent en particulier, en fonction du nombre de serveurs déployés et de leur localisation dans le réseau de réduire les congestions réseau au niveau des serveurs d'origine. Ces derniers peuvent en effet faire l'objet d'un nombre très important de sollicitations en lien direct avec la popularité des contenus qu'ils mémorisent. En outre, les serveurs substituts 102a-c sont généralement placés au plus près des entités clientes 108a-b afin de réduire les délais d'accès au contenu recherché. De plus, un dispositif d'acheminement ne publie pas de catalogue des segments de données mémorisé dans sa mémoire cache locale. Cette dernière n'est donc pas adressable.
Les dispositifs d'acheminement 104a-d permettent d'acheminer une demande relative à un segment de données vers un serveur d'origine mémorisant ce segment de données, puis de l'acheminer ensuite aux entités clientes qui l'ont demandé. L'acheminement réalisé est un acheminement par nom, décrit par Van Jacobson et al. dans le document « Networking Named Content » mentionné précédemment, qui repose principalement sur trois structures de données : un magasin de contenus, une table d'acheminement des demandes, et une table des demandes pendantes. Lorsqu'un dispositif 104a-d reçoit une demande, il vérifie dans un premier temps s'il mémorise le segment de données recherché dans son magasin de contenus, et le renvoie si tel est le cas, vers l'interface par laquelle lui est parvenue la demande. Dans le cas contraire, le dispositif 104a-d vérifie qu'il n'existe pas de demande relative au segment de données qui ait déjà été reçue par le dispositif, et pour laquelle le segment de données n'a pas encore été reçu. Une telle demande est appelée « demande pendante ». Plus précisément, il s'agit d'une demande pendante vers un serveur d'origine. Si une telle demande pendante existe, la demande en cours n'est pas réacheminée. Si aucune demande pendante n'est mémorisée dans la table des demandes pendantes du dispositif 104a-d, la demande relative au segment de données est envoyée vers un serveur d'origine 106a-c, et devient elle-même pendante jusqu'à réception du segment de données recherché. Lorsque le dispositif 104a-d reçoit le segment de données recherché, ce dernier est simplement distribué aux interfaces du dispositif 104a-d par lesquelles des demandes relatives au segment de données ont été reçues.
Le réseau 10 de l'opérateur de réseaux, comprend également des dispositifs d'acheminement 20a-b. Ces dispositifs d'acheminement 20a-b, à la différence des dispositifs d'acheminement 104a-d, permettent d'acheminer une demande vers des serveurs d'origine 106a-c, mais également vers des serveurs substituts 102a-c. Les dispositifs d'acheminements 20a-b sont directement connectés à un ou des serveurs substituts 102a-c. Les dispositifs d'acheminements 20a- b orientent la demande relative à un segment de données en priorité vers le serveur substitut lorsque cela est possible. Pour cela un dispositif d'acheminement 20a-b, utilise deux structures de données particulières en complément des trois structures de données décrites précédemment : une table d'acheminement cache et une table de demandes cachées. Lorsqu'un dispositif 20a-b reçoit une demande, il vérifie dans un premier temps si sa mémoire cache locale mémorise le segment de données recherché et le renvoie, si tel est le cas, vers l'interface par laquelle lui est parvenue la demande. Dans le cas contraire, le dispositif 20a-b vérifie si le segment de données est attaché à un domaine dont au moins une partie des contenus est mémorisée par un serveur substitut 102a-c. Si tel est le cas, il vérifie ensuite s'il existe une demande pendante vers ce serveur substitut 102a-c, relative au segment de données recherché. Si une telle demande existe, la demande en cours relative au segment de données, si elle est reçue par l'intermédiaire d'une nouvelle interface, n'est pas réacheminée. En revanche si l'interface par laquelle est reçue la demande en cours est identique à l'une des interfaces associées à la demande pendante vers un serveur substitut 102a-c, le dispositif d'acheminement 20a-b renvoie la demande vers un serveur d'origine 106a-c. Le dispositif 20a-b permet donc de renvoyer une demande relative à un segment pour laquelle aucun serveur substitut 102a-c n'a répondu, vers un serveur d'origine 106a-c. La demande est alors traitée de la même manière qu'elle l'aurait été par un dispositif d'acheminement 104a-d. Les serveurs substituts 102a-c sont en outre directement connectés avec les dispositifs d'acheminement 20a-b. Ceci permet d'éviter qu'une demande lors de son envoi vers un serveur substitut 102a-c par un dispositif d'acheminement 20a-b, soit aussi envoyée sur un chemin du réseau permettant d'atteindre un serveur d'origine 106a-c. Lorsqu'un serveur substitut 102a-c mémorise le contenu, cela permet également de le délivrer plus rapidement à une entité cliente 108a-b.
La figure 2 représente un dispositif d'acheminement 20 selon un mode particulier de réalisation. Il comprend notamment :
- un module d'émission / réception 200, agencé pour recevoir et émettre un paquet de données sur le réseau, le paquet de données pouvant être une demande relative à un segment de données, ou un segment de données ;
- un module de traitement 202, agencé pour traiter un paquet de données, le paquet de données pouvant notamment être une demande relative à un segment de données ou un segment de données ;
- des moyens de mémorisation 206 ou mémoire cache locale, également appelés magasin de contenus ou « Content Store », agencés pour mémoriser des segments de données ;
- une première table 210, appelée table d'acheminement des demandes FIB, pour « Forwarding Information Base », agencée pour mémoriser des données d'acheminement des demandes relatives à des segments de données en fonction des identifiants des segments de données, plus précisément une liste d'identifiants d'interface par l'intermédiaire desquelles un serveur d'origine 106a-c est atteint, en association avec un identifiant de segment de données.
- une deuxième table 214, appelée table des demandes pendantes PIT, pour « Pending Interest Table », agencée pour mémoriser une liste d'interfaces par l'intermédiaire desquelles une ou des demandes relatives à un segment de données d'un contenu ont été reçues, tant que ce segment de données n'a pas été reçu en réponse. Il s'agit des demandes pendantes vers un serveur d'origine 106a-c ;
- un module de réception d'une publication 204, agencé pour recevoir une publication émise par un serveur substitut 102a-c, d'au moins un nom de domaine pour lequel le serveur substitut 102a-c mémorise au moins une partie des contenus ;
- une troisième table 208, appelée table d'acheminement cache CFT, pour « Cache Forwarding Table », agencée pour mémoriser des données d' acheminement des demandes relatives à des segments de données vers des serveurs substituts 102a-c, plus précisément une liste d'identifiants d'interface permettant d'atteindre un serveur substitut 102a-c, en association avec un nom de domaine ;
- une quatrième table 212, appelée table des demandes cachées pendantes PCIT, pour « Pending Cached Interest Table », agencée pour mémoriser une liste d'interfaces par l'intermédiaire desquelles une ou des demandes relatives à un segment de données d'un contenu ont été reçues, la première de ces demandes ayant été envoyée vers un serveur substitut 102a-c, tant que ce segment de données n'a pas été reçu en réponse. Il s'agit des demandes pendantes vers un serveur substitut 102a-c.
Les moyens de mémorisation 206 sont par exemple une zone mémoire, une zone tampon (ou « buffer ») ou bien encore un disque dur externe.
Le module de traitement 202 comporte un sous-module de vérification 216, agencé pour vérifier si une demande relative au segment de données de la demande en cours de traitement a déjà été envoyée vers un serveur substitut 102a-c, et si deux demandes antérieures ont été reçues par l'intermédiaire d'une même interface. Dans un autre mode de réalisation il peut s'agir d'un module indépendant.
Dans un autre mode de réalisation, le dispositif 20 ne comprend pas de module de réception d'une publication 204. Les données d'acheminement de la table CFT sont dans ce cas renseignées localement.
Un tel dispositif d'acheminement peut être un routeur du réseau, une passerelle d'accès au réseau, un équipement multiplexeur d'accès.
Nous allons maintenant décrire le procédé de traitement d'un paquet de données, tel qu'il est mis en œuvre par le dispositif d'acheminement 20, en relation avec les figures 3a et 3b.
On se place dans le cas particulier où l'entité cliente 108a souhaite obtenir un segment de données d'un contenu. L'entité cliente 108a transmet une demande IntP, pour « Interest Packet », relative à ce segment de données.
La figure 3a décrit les étapes du procédé de traitement d'un segment de données qui sont mises en œuvre par le dispositif d'acheminement 20 pour traiter un paquet portant une demande
IntP relative à un segment de données. Dans une étape El, le dispositif d'acheminement 20 reçoit la demande IntP et détermine s'il dispose du segment de données demandé dans son magasin de contenus 206. Pour cela, il procède par exemple par comparaison de l'identifiant CN du segment de données de la demande IntP avec les identifiants des segments mémorisés dans son magasin de contenus 206.
Si le segment demandé est présent dans le magasin de contenu 206 du dispositif 20, il est transmis, dans une étape E2, vers l'interface par l'intermédiaire de laquelle la demande IntP a été reçue. Le dispositif 20 se met ensuite en attente d'une prochaine demande où d'un prochain segment de données à traiter.
Dans le cas contraire, c'est-à-dire lorsque le segment de données recherché n'est pas mémorisé dans le magasin de contenus 206, dans une étape E3, le dispositif d'acheminement 20 détermine un nom de domaine DN à partir de l'identifiant CN du segment de données. A partir de ce nom de domaine DN, le dispositif d'acheminement 20 détermine ensuite dans une étape E4, s'il existe dans la table d'acheminement cache CFT 208, une liste d'interfaces directement connectées à un ou plusieurs serveurs substituts, et associée à ce nom de domaine DN. Si le nom de domaine DN n'est pas trouvé dans la table CFT 208, cela signifie qu'il n'existe pas de serveurs substituts connus du dispositif 20 mémorisant au moins une partie des contenus de ce domaine. Dans ce cas, le dispositif 20 passe à une étape El 1, et exécute le procédé d'acheminement 30a connu de l'état de la technique tel que décrit par Van Jacobson et al., dans le document précédemment cité.
Si le nom de domaine DN est trouvé dans la table CFT 208, le dispositif 20 vérifie ensuite dans une étape E5, si une demande antérieure relative au même segment de données a déjà été envoyée vers un serveur substitut 102a-c. Pour cela il vérifie en particulier si la table des demandes cachées pendantes PCIT 212 mémorise l'identifiant CN du segment de données recherché.
Si l'identifiant du segment de données recherché n'est pas dans la table PCIT 212, aucune demande relative à ce segment de données n'a encore été envoyée vers ce serveur substitut 102a-c susceptible de mémoriser le segment de données recherché. Le dispositif 20 mémorise alors, dans une étape E12, l'identifiant CN du segment de données dans la table PCIT 212, en association avec l'interface F par laquelle la demande IntP relative au segment de données a été reçue. Ceci permet au dispositif 20 de marquer la demande IntP comme étant pendante vers un ou des serveurs substituts 102a-c. Dans une étape E13, la demande IntP est ensuite envoyée à un/des serveur(s) substitut(s) 102a-c, par l'intermédiaire de la ou des interfaces associées dans la table CFT 208 au nom de domaine DN, obtenue(s) à l'étape E4. Le traitement du paquet portant la demande relative au segment de données est alors terminé, et le dispositif se met en attente de réception d'un paquet de données.
Dans le cas où, à l'étape E5, l'identifiant CN du segment recherché est mémorisé dans la table PCIT 212, cela signifie qu'une demande antérieure, distincte de la demande IntP, a déjà été reçue du dispositif 20 et est pendante vers un serveur substitut 102a-c. Le dispositif 20 vérifie alors dans une étape E6, si une liste LF d'interfaces associées à l'identifiant CN du segment de données de la demande IntP est mémorisée dans la table PCIT 212. L'absence d'une liste LF d'interfaces associée à l'identifiant CN indique au dispositif 20 qu'au moins deux demandes antérieures relatives au segment de données recherché ont été reçues par l'intermédiaire d'une même interface, une demande antérieure ayant été envoyée vers un serveur substitut 102a-c. Ceci permet d'identifier une absence de réponse du serveur substitut 102a-c. Cette absence de réponse peut être due à des raisons techniques, mais également au fait que le serveur substitut ne dispose pas du segment de données recherché. Le dispositif 20 passe alors à l'étape El i afin de traiter la demande IntP selon le procédé d'acheminement 30a connu de l'état de la technique, décrit précédemment. Ainsi, dans ce cas, la demande IntP est acheminée vers un ou plusieurs serveurs d'origine 106a-c.
On rappelle qu'à l'étape E6, une liste LF d'interfaces associée à l'identifiant CN du segment de données de la demande IntP ayant été obtenue, une ou plusieurs demandes antérieures relatives au même segment de données ont été reçues par l'intermédiaire d'interfaces deux à deux distinctes, et que la première de ces demandes antérieures a été envoyée vers un serveur substitut 102a-c. Dans une étape E7, le dispositif 20 vérifie que l'interface F par laquelle a été reçue la demande IntP n'appartient pas à la liste LF associée à l'identifiant CN du segment de données recherché dans la table PCIT 212. Si tel est le cas, la table PCIT 212 est mise à jour dans une étape E8, afin d'ajouter l'interface F à la liste LF des interfaces associée à l'identifiant CN du segment de données recherché. Ceci permet, à réception du segment de données recherché, de le distribuer à l'ensemble des interfaces par lesquelles une demande relative à ce segment de données recherché a été reçue. Le traitement du paquet portant la demande relative au segment de données est alors terminé, et le dispositif se met en attente de réception d'un nouveau paquet de données.
Si, lors de l'étape E7, l'interface F par l'intermédiaire de laquelle a été reçue la demande IntP en cours de traitement, appartient à la liste des interfaces obtenue à l'étape E6, cela signifie que le serveur substitut 102a-c n'a pas répondu à la demande pendante mémorisée dans la table PCIT 212. Dans ce cas, la demande IntP est acheminée vers un serveur d'origine 106a-c. Pour cela, le paquet portant la demande IntP est envoyé vers le procédé d'acheminement 30b adapté du procédé d'acheminement 30a connu de l'état de la technique. Cette adaptation consiste en l'ajout d'une étape E9 de mémorisation de la liste d'interfaces LF dans la table PIT 214 en association avec l'identifiant CN du segment de données recherché, et de suppression de cette liste LF de la table PCIT 212. La liste d'interfaces LF est mémorisée dans la table PIT 214, après que le dispositif 20a-b ait vérifié qu'il n'existe pas de demande pendante vers un serveur d'origine 106a-c relative au segment de données recherché (étape El i). La demande est ainsi renvoyée vers un serveur d'origine 106a-c.
La suppression de la liste LF d'interfaces associée à l'identifiant CN du segment de données dans la table PCIT 212 permet par ailleurs, de ne pas solliciter inutilement la table PCIT 212, lors d'une prochaine demande relative au segment de données (étape E6). L'étape E6 permet en effet comme décrit précédemment de réorienter une demande avec une liste d'interfaces vide directement vers le procédé 30a connu de l'état de la technique.
Dans le mode de réalisation décrit, les étapes E12 et E13 sont mises en œuvre successivement. Dans un autre mode de réalisation, l'étape E13 est mise en œuvre avant l'étape El 2. Dans encore un autre mode de réalisation, les étapes E12 et El 3 sont exécutées en parallèle.
La demande IntP est traitée à l'issue des étapes E2, E8, E13, ainsi qu'à l'issue des procédés d'acheminement 30a et 30b. Le procédé de traitement passe à une étape d'attente de réception d'un paquet de données.
La figure 3b décrit, quant à elle, les étapes du procédé mises en œuvre pour traiter un segment de données reçu par l'intermédiaire d'une interface f.
Dans une étape Fl, le dispositif d'acheminement 20 reçoit un segment de données DatP par l'intermédiaire de l'interface f, et détermine si le segment DatP provient d'un serveur substitut 102a-c. Pour cela il vérifie que le segment DatP a été reçu par l'intermédiaire d'une interface directement connectée à un serveur substitut 102a-c. Si tel est le cas, le dispositif d'acheminement 20 passe à une étape F2b, dans laquelle il vérifie si l'identifiant CN du segment de données reçu est mémorisé dans la table PCIT 212. Si l'identifiant CN ne se trouve pas dans la table PCIT 212, le segment de données reçu ne correspond à aucune demande pendante pour le dispositif 20, et il est ignoré.
Si l'identifiant CN se trouve dans la table PCIT 212, une demande relative à ce segment de données est pendante. Dans une étape F3b, les interfaces associées à l'identifiant CN du segment de données, par lesquelles ont été reçues des demandes antérieures, sont obtenues à partir de la table PCIT 212. L'absence d'interfaces associées à l'identifiant CN indique qu'au moins une demande antérieure a été envoyée vers un serveur substitut 102a-c, mais que ce dernier ayant répondu tardivement, une autre demande a entre-temps été envoyée vers un dispositif du réseau distinct d'un serveur substitut 102a-c. Dans une étape F3c, l'identifiant CN est ensuite supprimé de la table PCIT 212. Ceci permet d'acheminer une prochaine demande relative au segment de données vers un serveur substitut 102a-c (étape E5). Le segment de données en cours de traitement est quant à lui ignoré. On souligne ici que lors de la réception du segment de données en réponse à l'autre demande envoyée entre-temps vers un dispositif du réseau distinct d'un serveur substitut 102a-c, le segment de données est acheminé vers la ou les interfaces mémorisées dans la table PIT 214, dans laquelle la ou les interfaces mémorisées dans la table PCIT 212 ont été mémorisées. Ainsi, le fait d'ignorer le segment de données est sans conséquence vis-à-vis des entités clientes 108a-b.
La demande pendante relative au segment de données est ensuite supprimée de la table PCIT 212 dans une étape F5b.
Dans une étape F6, le segment de données est envoyé par l'intermédiaire des interfaces obtenues à l'étape F3b. Cet envoi est géré, à titre d'exemple non limitatif, par une file d'attente associée à chaque interface, dans laquelle sont mémorisés les segments de données en attente d'envoi.
Le dispositif d'acheminement 20 repasse ensuite en attente de réception d'un paquet de données.
Si le segment de données DatP reçu par le dispositif d' acheminement 20 ne provient pas d'un serveur substitut (étape Fl), dans une étape F2a, le dispositif 20 vérifie si l'identifiant CN du segment de données reçu est contenu dans la table PIT 214. Si l'identifiant CN ne se trouve pas dans la table PIT 214, le segment de données reçu ne correspond à aucune demande pendante et il est ignoré. Si l'identifiant CN se trouve dans la table PIT 214, une demande relative à ce segment de données étant pendante, dans une étape F3a, les interfaces associées à l'identifiant CN du segment de données sont obtenues à partir de la table PIT 214.
La demande pendante relative au segment de données est ensuite supprimée de la table PIT 214 dans une étape F5a. On notera que dans cette étape, seule la table PIT 214 est mise à jour. La table PCIT 212 mémorise toujours l'identifiant du segment de données recherché. Cela permet de déterminer pour le traitement d'une prochaine demande relative au segment de données, qu'avant d'avoir été envoyée vers un serveur d'origine 106a-c, une demande antérieure pour ce segment de données a été envoyée vers un serveur substitut 102a-c qui n'a pas répondu. La table PCIT n'est donc pas mise à jour, afin que lors d'une prochaine demande relative à ce contenu, cette dernière soit directement orientée vers un serveur d'origine 106a-c.
Le segment de données est envoyé à l'étape F6 par l'intermédiaire des interfaces obtenues à l'étape F3a.
Le segment de données DatP est traité à l'issue des étapes F2b, F3b, F2a et F6. Le dispositif d'acheminement 20 repasse ensuite en attente de réception d'un paquet de données.
Dans un autre mode de réalisation, l'étape Fl n'est pas prévue. La présence de demandes pendantes est alors systématiquement vérifiée dans les deux tables PCIT et PIT.
Dans le mode de réalisation décrit précédemment, deux tables des demandes pendantes sont utilisées : la table des demandes pendantes vers un serveur substitut (table PCIT 212), et celle des demandes pendantes vers un serveur d'origine (table PIT 214). Dans un autre mode de réalisation, une seule table de demandes pendantes est prévue. Dans ce cas, cette table mémorise également en association avec l'identifiant du segment de données si la demande est pendante vers un serveur substitut ou un serveur d'origine.
Par ailleurs, un mécanisme de rafraîchissement de la table PCIT 212 est réalisé, à titre d'exemple non limitatif, par la suppression à intervalle régulier (toutes les cinq heures par exemple), de toutes les entrées de la table PCIT 212 relatives à un segment de données pour lesquelles le segment de données n'a pas été reçu. Ceci permet de prendre en compte les évolutions relatives aux contenus mémorisés par les serveurs substituts 102a-c. Un serveur substitut 102a-c est en effet susceptible de mémoriser un contenu qu'il ne mémorisait pas auparavant, et donc d'envoyer un segment de données en réponse à une demande relative à un segment de données de ce contenu.
Un tel réseau centré sur les contenus peut également interfonctionner avec un réseau de distribution de contenus de type CDN (Content Delivery Network) intégrant des serveurs substituts adressables par leur adresse IP (Internet Protocol). Dans ce dernier cas, la connexion directe entre un dispositif d'acheminement du réseau centré sur les contenus et un serveur substitut s'effectue par exemple par l'intermédiaire d'une passerelle, agencée pour traduire un adressage IP en un adressage par nom et réciproquement.
A titre d'illustration du fonctionnement du procédé de traitement d'une demande relative à un segment de données, les figures 4b-h, représentent le contenu des tables CFT 208, FIB 210, PCIT 212 et PIT 214, d'un dispositif d'acheminement 20 au cours de l'exécution de différentes étapes du procédé, pour un scénario particulier représenté à la figure 4a. Dans ce scénario le dispositif d'acheminement 20 a quatre interfaces il, i2, i3 et i4. Il est interfacé avec l'entité cliente 401 par l'intermédiaire de l'interface il, avec l'entité cliente 402 par l'intermédiaire de l'interface i2, avec un serveur substitut 403 par l'intermédiaire de l'interface i3. L'interface i4 lui permet en outre d'atteindre un serveur d'origine 404. A titre illustratif, on se place dans le cas particulier où trois demandes Dl, D2 et D3 relatives à un même segment de données sont émises successivement. Les demandes Dl et D3 sont émises par l'entité cliente 401, et la demande D2 par l'entité cliente 402.
A l'initialisation, les tables CFT et FIB sont chacune renseignées avec une règle d'acheminement. La table CFT indique que toute demande relative à un contenu appartenant au domaine « youtube.com » doit être acheminée par l'intermédiaire de l'interface i3 (figure 4b). La table FIB indique qu'une demande pour le contenu « /youtube.com/stream/news/../videol/versionl » doit être acheminée par l'intermédiaire de l'interface i4 (figure 4c). Les tables PIT et PCIT sont quant à elles vides.
L'entité cliente 401 envoie une demande Dl relative au segment de données « /youtube.com/stream/news/../videol/versionl/segmentl ». Elle est reçue par le dispositif 20 par l'intermédiaire de l'interface il. L'identifiant du segment de données demandé indique que le contenu auquel appartient le segment de données recherché est attaché au domaine « youtube.com ». La table CFT comporte une règle d'acheminement pour ce domaine (étape E4). La demande Dl est donc envoyée vers le serveur substitut 403 par l'intermédiaire de l'interface i3 associée au nom de domaine dans la table CFT (étape E13). Cette demande est pendante vers le serveur substitut 403 tant que le segment de données n'a pas été reçu par le dispositif 20. L'identifiant du segment de données associé à l'interface il par l'intermédiaire de laquelle a été reçue la demande Dl est mémorisé (étape El 2) dans la table PCIT (figure 4d).
L'entité cliente 402 émet à son tour une demande D2 relative au même segment de données « /youtube.com/stream/news/../videol/versionl/segmentl ». Cette demande est reçue par le dispositif 20 par l'intermédiaire de l'interface i2. La table PCIT indique qu'une demande pour le même segment de données a déjà été reçue. La table PCIT est alors mise à jour afin de mémoriser l'interface i2 par l'intermédiaire de laquelle la seconde demande D2 a été reçue (figure 4e). A ce stade la table PIT n'a toujours pas été modifiée (figure 4g).
Une troisième demande D3 toujours relative au même segment de données
« /youtube.com/stream/news/../videol/versionl/segmentl » est maintenant émise par l'entité cliente 401. La demande D3 est reçue par l'intermédiaire de la même interface il que la demande Dl. Cette interface il appartient à la liste des interfaces associées dans la table PCIT à la demande pendante vers le serveur substitut 403 (étape E7). Il s'agit donc d'une répétition de la demande sur la même interface. Le serveur substitut 403 n'a donc pas répondu à la demande Dl. La demande est alors acheminée vers le serveur d'origine 404, selon la règle d'acheminement mémorisée dans la table FIB (figure 4c). La liste d'interfaces associée à l'identifiant du segment de données dans la table PCIT est effacée de cette table (figure 4f), puis est mémorisée dans la table PIT (figure 4h).
La table PCIT mémorise l'identifiant du segment de données sans identifiant d'interface associé. Cela permet d'identifier qu'une demande envoyée au serveur substitut 403 est restée sans réponse. Ainsi une prochaine demande relative au segment de données « /youtube.com/stream/news/../videol/versionl/segmentl », est directement acheminée vers le serveur d'origine 404.
L'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Dans un mode de réalisation particulier, les modules 200, 202, 204 sont agencés pour mettre en œuvre le procédé précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé précédemment décrit, mises en œuvre par le dispositif de protection. L'invention concerne donc aussi : - un programme pour un dispositif d'acheminement, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit dispositif ;
- un support d'enregistrement lisible par un dispositif d'acheminement sur lequel est enregistré le programme pour un dispositif d'acheminement.
Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.

Claims

REVENDICATIONS
1. Procédé de traitement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus (1), ledit procédé comprenant les étapes suivantes mises en œuvre par un dispositif d'acheminement (20a-b) du réseau (1):
- envoi (30b) de ladite demande par l'intermédiaire d'au moins une première interface permettant d'atteindre au moins un serveur d'origine (106a-c) mémorisant ledit contenu, lorsqu'aucune demande antérieure relative audit segment de données n'est pendante ;
caractérisé en ce que, ledit réseau (1) comprenant en outre au moins un serveur substitut (102a-c), distinct du serveur d'origine (106a-c), connecté audit dispositif (20a-b) par une deuxième interface, et mémorisant au moins une partie des contenus d'un domaine, ledit procédé comprend les étapes suivantes, préalablement à l'étape d'envoi et conditionnant ledit envoi :
- vérification (E6) qu'une autre demande relative au segment a été envoyée par l'intermédiaire de ladite deuxième interface et est pendante ; et
- vérification (E7) qu'une demande reçue antérieurement relative audit segment, associée à l'autre demande pendante envoyée par l'intermédiaire de la deuxième interface, et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface.
2. Procédé de traitement selon la revendication 1 , dans lequel pour envoyer ladite autre demande, ledit serveur substitut (102a-c) est déterminé en fonction du nom de domaine duquel dépend le contenu.
3. Procédé de traitement selon la revendication 1, comprenant en outre sur réception dudit segment de données les étapes suivantes :
- obtention (F3a, F3b) d'au moins une interface par l'intermédiaire de laquelle a été reçue une demande relative audit segment de données, associée à une demande pendante envoyée par l'intermédiaire d'une interface permettant d'atteindre un serveur appartenant au groupe comprenant le serveur d'origine et le serveur substitut ;
- envoi (F6) dudit segment de données par l'intermédiaire de ladite au moins une interface obtenue.
4. Procédé de traitement selon la revendication 2, comprenant en outre une étape de réception d'une publication émise par le serveur substitut (102a-c), d'au moins un nom de domaine pour lequel il mémorise une partie des contenus.
5. Dispositif d'acheminement (20) d'une demande relative à un segment de données d'un contenu dans un réseau de communication (1) centré sur les contenus, comprenant : - un module d'envoi (200), agencé pour envoyer ladite demande par l'intermédiaire d'au moins une interface permettant d'atteindre au moins un serveur d'origine (106a-c) mémorisant ledit contenu, lorsqu'aucune demande antérieure relative audit segment de données n'est pendante ;
- un module de vérification (216), agencé pour vérifier qu'une autre demande relative au segment a été envoyée par l'intermédiaire d'une interface permettant d'atteindre un serveur substitut (102a-c) et est pendante, et qu'une demande reçue antérieurement relative audit segment, et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface.
6. Dispositif d'acheminement (20) selon la revendication 5, comprenant en outre un module de réception (204) d'une publication, agencé pour recevoir une publication émise par le serveur substitut (102a-c), d'au moins un nom de domaine pour lequel ledit serveur (102a-c) mémorise une partie des contenus.
7. Réseau de communication centré sur les contenus (1) comprenant au moins un dispositif d'acheminement (20a-b) selon la revendication 5, ledit réseau (1) comprenant en outre au moins un serveur substitut (102a-c), distinct du serveur d'origine (106a-c), et mémorisant au moins une partie des contenus d'un domaine.
8. Réseau de communication (1) selon la revendication 7, dans lequel ledit au moins un serveur substitut (102a-c) comprend un module de publication, agencé pour publier au moins un nom de domaine pour lequel il mémorise une partie des contenus.
9. Programme pour un dispositif d'acheminement (20a-b) selon la revendication 5 ou 6, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé selon l'une des revendications 1 à 4, lorsque ledit programme est exécuté par ledit dispositif.
10. Support d'enregistrement lisible par un dispositif d'acheminement (20a-b) sur lequel est enregistré le programme selon la revendication 9.
PCT/FR2014/050437 2013-03-08 2014-02-27 Procédé de traitement dans un réseau centré sur les contenus d'une demande relative a un segment de données WO2014135766A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1352113A FR3003111A1 (fr) 2013-03-08 2013-03-08 Procede de traitement dans un reseau centre sur les contenus d'une demande relative a un segment de donnees
FR1352113 2013-03-08

Publications (1)

Publication Number Publication Date
WO2014135766A1 true WO2014135766A1 (fr) 2014-09-12

Family

ID=48521278

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2014/050437 WO2014135766A1 (fr) 2013-03-08 2014-02-27 Procédé de traitement dans un réseau centré sur les contenus d'une demande relative a un segment de données

Country Status (2)

Country Link
FR (1) FR3003111A1 (fr)
WO (1) WO2014135766A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2214357A1 (fr) * 2009-01-30 2010-08-04 Palo Alto Research Center Incorporated Système de transfert d'un paquet avec un identificateur à longueur variable structurée hiérarchiquement
EP2466786A1 (fr) * 2010-12-16 2012-06-20 Palo Alto Research Center Incorporated Récupération de contenu éco-énergétique dans les réseaux centraux de contenu

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2214357A1 (fr) * 2009-01-30 2010-08-04 Palo Alto Research Center Incorporated Système de transfert d'un paquet avec un identificateur à longueur variable structurée hiérarchiquement
EP2466786A1 (fr) * 2010-12-16 2012-06-20 Palo Alto Research Center Incorporated Récupération de contenu éco-énergétique dans les réseaux centraux de contenu

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
BEBEN A ET AL: "Content Aware Network Based on Virtual Infrastructure", SOFTWARE ENGINEERING, ARTIFICIAL INTELLIGENCE, NETWORKING AND PARALLEL&DISTRIBUTED COMPUTING (SNPD), 2012 13TH ACIS INTERNATIONAL CONFERENCE ON, IEEE, 8 August 2012 (2012-08-08), pages 643 - 648, XP032236375, ISBN: 978-1-4673-2120-4, DOI: 10.1109/SNPD.2012.68 *
JANAKA WIJEKOON ET AL: "SoR based request routing for future CDN", APPLICATION OF INFORMATION AND COMMUNICATION TECHNOLOGIES (AICT), 2012 6TH INTERNATIONAL CONFERENCE ON, IEEE, 17 October 2012 (2012-10-17), pages 1 - 5, XP032293884, ISBN: 978-1-4673-1739-9, DOI: 10.1109/ICAICT.2012.6398497 *
MOHAMED DIALLO ET AL: "Leveraging Caching for Internet-Scale Content-Based Publish/Subscribe Networks", ICC 2011 - 2011 IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS - 5-9 JUNE 2011 - KYOTO, JAPAN, IEEE, PISCATAWAY, NJ, USA, 5 June 2011 (2011-06-05), pages 1 - 5, XP031908428, ISBN: 978-1-61284-232-5, DOI: 10.1109/ICC.2011.5962666 *
VAN JACOBSON ET AL., NETWORKING NAMED CONTENT
VAN JACOBSON ET AL.: "Networking Named Content", ACTES DE LA CONFÉRENCE CONEXT'09, 2009
VASILIS SOURLAS ET AL: "Effective cache management and performance limits in information-centric networks", COMPUTING, NETWORKING AND COMMUNICATIONS (ICNC), 2013 INTERNATIONAL CONFERENCE ON, IEEE, 28 January 2013 (2013-01-28), pages 955 - 960, XP032377030, ISBN: 978-1-4673-5287-1, DOI: 10.1109/ICCNC.2013.6504219 *

Also Published As

Publication number Publication date
FR3003111A1 (fr) 2014-09-12

Similar Documents

Publication Publication Date Title
EP2687001B1 (fr) Technique de communication dans un reseau de communication avec acheminement par nom
US8880698B2 (en) Storage of content data in a peer-to-peer network
US20060064476A1 (en) Advanced content and data distribution techniques
FR2870022A1 (fr) Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
US10367871B2 (en) System and method for all-in-one content stream in content-centric networks
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
EP2988512B1 (fr) Système et procédé pour flux de contenu tout-en-un reproductible
EP2966834B1 (fr) Système et procédé d'auto-amorçage de contenu sécurisé parallèle dans des réseaux tournés vers le contenu
EP2695363B1 (fr) Technique de communication entre des reseaux de distribution de contenus numeriques
EP2936783B1 (fr) Technique de communication dans un réseau de communication centré sur les informations
FR2979509A1 (fr) Procede et serveur pour le suivi des utilisateurs au cours de leur navigation dans un reseau de communication
WO2016102871A1 (fr) Système de génération d'une fonction réseau virtualisée
FR2928800A1 (fr) Procede de gestion de requetes d'obtention d'identifiants de pairs en vue d'acceder en mode p2p a des contenus qu'ils stockent, et dispositif de gestion et equipement de reseau associes.
EP3646196B1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
EP2856719B1 (fr) Technique de communication dans un réseau de communication centré sur les informations
FR3028373A1 (fr) Delegation d'intermediation sur un echange de donnees chiffrees.
WO2014135766A1 (fr) Procédé de traitement dans un réseau centré sur les contenus d'une demande relative a un segment de données
EP3149918B1 (fr) Téléchargement de contenu et mise a disposition de réseaux
CN103685367A (zh) 离线下载系统和方法
FR2995487A1 (fr) Technique de traitement d'une requete de distribution de contenu
EP2692117B1 (fr) Substitution d'un ou plusieurs serveurs de contenus par un serveur de substitution
FR2988544A1 (fr) Selection d'une entite de reseau pour la fourniture d'un contenu numerique
FR3052620A1 (fr) Procede de gestion de l'acces a des contenus numeriques via une passerelle domestique
FR3024315A1 (fr) Systeme et procede de mise a disposition de fichiers informatiques.
FR2966310A1 (fr) Decouverte de services web dans un reseau local

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14713516

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14713516

Country of ref document: EP

Kind code of ref document: A1