EP1647125A1 - Description de contenu de paquets dans un reseau de communication par paquets - Google Patents

Description de contenu de paquets dans un reseau de communication par paquets

Info

Publication number
EP1647125A1
EP1647125A1 EP04767614A EP04767614A EP1647125A1 EP 1647125 A1 EP1647125 A1 EP 1647125A1 EP 04767614 A EP04767614 A EP 04767614A EP 04767614 A EP04767614 A EP 04767614A EP 1647125 A1 EP1647125 A1 EP 1647125A1
Authority
EP
European Patent Office
Prior art keywords
packet
data
identifier
description
information
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP04767614A
Other languages
German (de)
English (en)
Inventor
Olivier Le Moigne
Olivier Marce
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel CIT SA
Alcatel SA
Alcatel Lucent SAS
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 Alcatel CIT SA, Alcatel SA, Alcatel Lucent SAS filed Critical Alcatel CIT SA
Publication of EP1647125A1 publication Critical patent/EP1647125A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25

Definitions

  • the invention relates to packet communication networks implementing protocols organized in layers as standardized in the OSI (“Open System Interconnection”) reference model defined by the International Organization for Standardization, known as ISO or which may be assimilate it. More particularly, the invention relates to a method of operating a node of a packet communication network, in particular an IP router. It also relates to a data packet for a packet communication network and a data packet generator for a packet communication network. Optimizing the transmission of packets transmitted in a packet communication network such as a network using IP (from the English "Internet Protocol”) is based on the specific processing of packets at the level of network nodes depending on their content. In the case of an IP protocol network, the nodes are traditionally called routers.
  • OSI Open System Interconnection
  • the mechanisms of quality of service or QoS in networks include a differentiated treatment of packets transmitted on the network, according to parameters such as the sender, the recipient or the type of data contained in the packet.
  • Network nodes process packets based on these parameters, for example by assigning routing, bandwidth, priority, or any other suitable characteristic.
  • Quality of service is in particular essential to guarantee the transmission under good conditions of packets containing voice or video, in particular in the case of voice over IP or video over IP. It is therefore necessary to be able to determine these parameters in order to manage packet flows correctly and efficiently.
  • There are software such as PacketShaper TM from the American company
  • the router makes this estimate of the type of data contained in the packet by examining the packets to determine the protocols used in the part of the packets corresponding to the OSI layers 5 to 7 (i.e. layers 5 to 7 of the OSI reference).
  • the router can in particular determine that the protocol used is FTP (from the English “File Transfer Protocol”) or HTTP (from the English “Hypertext Transfer Protocol”).
  • the router possibly examines the other parts of the packet to determine the type of data contained in the packet, for example by recognizing the signature of an application or of a type of data present among the data in the body of the packet (called "paylaod").
  • the router assumes that the packet belongs to a predefined processing category according to the recognized protocol as well as any recognized signature.
  • the packet is then classified in the predefined category, and the router applies the treatments corresponding to this category to it.
  • This method has drawbacks, however.
  • the protocol is not recognized by an router that is not updated. The router can therefore no longer assume the content of such a data packet.
  • the router can then no longer manage the quality of service according to the content of a packet.
  • the same protocol can be used for different types of data.
  • the HTTP protocol is used both for the transport of interactive content and for the transfer of static files, and only allows information to be transported on the data which is transported in a sequence of packets (typically a TCP stream) and not by a single package.
  • the router cannot precisely determine the type of data solely according to the transmission protocol used.
  • the router is therefore not always able to correctly recognize the type of data contained in the packets.
  • the quality of service is therefore not optimal since the different types of data may require different technical requirements.
  • Another possibility for supplying the parameters useful to the routers would consist in using a known signaling protocol which is provided for supplying information of this type.
  • SIP protocol from the English “Session Initiation Protocol” which makes it possible to send messages containing the type of data transported in a packet flow.
  • this solution has drawbacks because the messages are sent from a sending network element to a receiving network element and are not designed to facilitate their interpretation by routers.
  • the subject of the invention is therefore a method of operating a node of a packet communication network, in particular an IP router, comprising the steps of: a) reception by the node of a packet from the network ; b) reception by the node of information independent of the protocols of the OSI layers 5 to 7 of the packet and concerning at least one of the following characteristics: ' "- the type of data transported in the packet, - the source of transmission data transported in the packet other than the network address of the source of transmission of the packet, and - the recipient of the data transported in the packet other than the network address of the source of transmission of the packet; c) processing of the packet by the node according to said description It is even more advantageous that the information received in step b) is independent of the protocols of the OSI layers 4 to 7 of the packet.
  • said information is contained in the packet, step b) comprising the reading of said information in the packet by the node.
  • Said information can in particular be contained in the header to the protocol of the OSI layer 3 of the packet, step b) then comprising the reading by the node of said information in the header to the protocol of the OSI layer 3 of the package.
  • the packet contains an identifier of said information, step a) comprising the reading of the identifier by the node.
  • the identifier can in particular be contained in the header to the protocol of the OSI layer 3 of the packet, step a) comprising the reading by the node of the identifier in the header to the protocol of the OSI layer. 3 of the package.
  • step b) comprises the reception by the node of another packet from the network, said other packet containing said information.
  • Said information can in particular be contained in the protocol header of the OSI layer 3 of said other packet, step b) then comprising the reading by the node of said information in the header to the protocol of the OSI layer 3 of said other package.
  • the method according to said information can be contained in the body according to the protocol of the OSI layer 3 of said other packet, step b) then comprising the reading by the node of said information in the body according to the protocol of the OSI layer. 3 of said other package.
  • said other packet also contains the identifier, step b) also comprising the reading by the node of the identifier in said other packet.
  • the identifier can in particular be contained in the protocol header of the OSI layer 3 of said other packet in which case step b) comprises the reading by the node of the identifier in the protocol header of the OSI 3 layer of said other package.
  • the method can also advantageously include, after step b), a step of sending by the node to a database, the identifier and said information.
  • the method comprises, after step a) and before step b), a step of interrogation by the node of a database with the identifier.
  • the invention also proposes a data packet for a packet communication network, comprising information independent of the protocols of the OSI layers 5 to 7 of the packet and concerning at least one of the following characteristics: - the type of data transported in the packet, - the source of transmission of the data transported in the packet other than the network address from the source of transmission of the packet, and - the recipient of the data transported in the packet other than the network address of the source of transmission of the packet.
  • said information is contained in the protocol header of the OSI layer 3 of the packet.
  • the packet is in the IP protocol, said information being contained in the IP header.
  • FIG. 1 a schematic representation an example of a transmission network in which the invention is implemented;
  • FIG. 2 a structure of a data packet containing a description of data;
  • FIG. 3 a structure of a data packet containing a data description identifier;
  • FIG. 4a a structure of a data packet containing both a data identifier and a data description in the header of the packet;
  • FIG. 1 a schematic representation an example of a transmission network in which the invention is implemented
  • FIG. 2 a structure of a data packet containing a description of data
  • FIG. 3 a structure of a data packet containing a data description identifier
  • FIG. 4a a structure of a data packet containing both a data identifier and a data description in the header of the packet;
  • FIG. 1 a schematic representation an example of a transmission network in which the invention is implemented
  • FIG. 2 a structure of a data packet containing a description of data
  • FIG. 3 a structure of a data packet
  • FIG. 4b a structure of a data packet containing a data description identifier placed in the header of the packet and a data description placed in the body of the packet;
  • FIG. 5 a structure of a data packet containing a description of data in the body of the packet.
  • the operating method of a node of a packet communication network comprises the steps of: ⁇ ) reception by the node of a packet from the network; b) reception by the node of information independent of the protocols of the OSI layers 5 to 7 of the packet and concerning at least one of the following characteristics: - the type of data transported in the packet, the source of transmission of the transported data in the packet other than the network address of the source of transmission of the packet, and the recipient of the data transported in the packet other than the network address of the source of transmission of the packet; c) processing of the packet by the node according to said description.
  • the time order of steps a) and b) is indifferent. In other words, step a) can be after or before step b).
  • Steps a) and b) can also be concomitant, in particular in the case where said information is contained in the packet itself. It will be understood that said information can relate only to any one of the characteristics indicated in step b), or any two of them or even all three. They may also include other information concerning for example the processing to be carried out by the node on the packets. The fact that said information is supplied to the node therefore allows the latter to process the packet - for example to choose a path in the network - as a function of said information. In other words, the processing of the packet no longer depends solely on the information conventionally contained in the packet for this purpose such as the network address of the source of the packet and the network address of the final recipient of the packet.
  • the node can read and understand said information without knowing these protocols. In other words, the node is able to process the packet according to said information without knowing the protocols of layers 5 to 7. It is even more advantageous that said information is independent of the protocol of the layer OSI 4 used in the packet, which allows the node to process the packet based on this information regardless of this protocol. Indeed, a network node may not be able to analyze the corresponding layer of packets that it receives or it is undesirable that it should be able to do so for reasons of speed of processing. Said information is advantageously written according to a code or language that the node is capable of understanding. This code or language can always be the same whatever the package concerned.
  • said information can be included in the package itself. This makes it possible to send said information simply and reliably to the network node to process the corresponding data packet. It is advantageous that said information is completely contained in the packet concerned by the information because it acts in a simple way to ensure that the node always receives said information for each of the packets. If, on the contrary, said information was distributed in several packets, the node must reconstitute it from the plurality of packets by scheduling them adequately, which makes the operation more complex. In addition, the node may be unable to reconstruct the information if it does not receive one of them, for example in the event of a change in the routing path in the network.
  • each packet may simply contain - instead of said information an identifier of said information, the identifier being independent of the protocols of the OSI layers 5 to 7, or even of the OSI layers 4 to 7, used in the packet.
  • the node determines said information which corresponds to the identifier for processing each packet as a function of said information.
  • Said information can be supplied to the node by various means such as by a packet which contains it or by a database which it interrogates.
  • the invention is particularly suitable for being implemented in an IP protocol network (which corresponds to the OSI layer 3).
  • FIG. 1 schematically represents an example of a packet communication network 1, in this case a network with the IP protocol.
  • the network
  • I comprises a terminal 2 sending data packets via a subnet 3 to a final recipient, not shown.
  • the subnetwork 3 is provided with routers 4 to 7 providing several routing paths to the data packets through the subnet 3.
  • the terminal 2 comprises a generator 8 of data packets which can be of any known type, for example. example a software application for voice or video transmission over IP.
  • the generator 8 generates IP protocol data packets which are sent to the final recipient through the subnet 3 thanks to an appropriate interface 9 of the terminal 2.
  • FIG. 2 shows the structure of a packet 10 comprising an IP header
  • the header 1 1 includes a description 1 3 of the useful data contained in the body 1 2 of the package.
  • the body 12 contains the useful data to be transmitted to the final recipient of the packet and which may be in the format of a protocol of an OSI layer higher than the IP layer, the latter being a protocol corresponding to the OSI layer 3.
  • the body 1 2 can conventionally contain a header to a protocol corresponding to the OSI 4 layer (known as the transport layer) such as TCP (from the English “Transmission Control Protocol”) or UDP (from the English “User Datagram Protocol”) encapsulating the useful data to be transmitted to the recipient of the packet.
  • TCP from the English “Transmission Control Protocol”
  • UDP from the English “User Datagram Protocol
  • the data is in the format of a protocol of the application layer of the IP model which corresponds to the OSI layers 5 to 7 as mentioned above.
  • This data can for example be voice over IP or video over IP.
  • the routers 4 to 7 are provided for reading the description of data 13 placed in the IP header 1 1 of the packets they receive and processing each packet according to the description 1 3 contained in its IP header.
  • the fact that the data description 13 is placed in the IP header of the packet 10 is advantageous since the router can read it by analyzing only the IP header 1-1 of the packet.
  • a router is conventionally capable of analyzing IP headers. On the contrary, it does not need to process the body 1 2 of the package.
  • the router does not need to know the protocol or protocols of the OSI layers 4 to 7 which are possibly used in the body 12 of the packet. Consequently, it is avoided that the router has to do processing on the data in the body 12 of the packet and in particular on the useful data transported, the router not being intended to carry out this type of processing.
  • the router is able to process the data description 13 whatever the protocol or protocols of the OSI layers 4 to 7 used in the body 12 of the packet.
  • the complete description 13 being contained in the packet to be processed, the router does not need to reconstitute the description beforehand by reading several different packets that it reorders before it can process a packet according to the data description.
  • This embodiment is particularly suitable for being implemented with IPv au protocol packets because such a packet has a header 1 1 of sufficient size to include a description of data.
  • the data description 1 3 can in particular be placed in a header extension (called “extension header” in English) of the IPv ⁇ header, for example a header extension of the type says "Hop-by-Hop Options".
  • this embodiment can also be implemented with IPv4 protocol packets, for example by entering the data description 1 3 in an option of the header 1 1.
  • the data description 13 in the case cited where the data description 13 is placed in a header extension, it can for example be a predetermined code placed in the header extension immediately following of its own header. Under IPv4, in the case cited where the data description 13 is placed in a header option, it can in particular be the byte coding the type of option.
  • the router can be configured by a routing manager 20 (called in English “Policy Decision Point” or PDP) for example via the IP network itself .
  • PDP Policy Decision Point
  • each packet 1 0 is processed by the routers according to the data description 13 which is placed in this packet.
  • an identifier of the data description is placed in the IP packet sent by the terminal 2. More precisely, an identifier placed in a data packet corresponds to a description of the useful data transported in the packet containing this ID. Again, the identifier can advantageously be included in the IP header of the packet.
  • FIG. 3 illustrates the structure of such a packet 1 0a with an identifier 14 of the data description which is placed in the IP header 1 1, the body (or “payload”) of the packet being referenced 1 2.
  • the identifier can for example be placed in a header extension or an option respectively in a similar manner to that described for the description of data 1 3 in the first embodiment. Furthermore, it is advantageous to have information in the header 11 of the packet indicating to the router that it contains an identifier 14. Under IPv4 or IPv ⁇ , this can be implemented in a similar manner to the examples. data for the indication of the presence of the data description 1 3 in the first embodiment.
  • the routers 4 to 7 can be provided to read the identifier 14 in the IP headers 1 1 of the packets they receive and determine the description of data which corresponds to the identifier 14. Then, the router processes the packet according to the data description corresponding to the identifier 14 contained in its IP header 11.
  • This embodiment is advantageous compared to the previous one insofar as the size of the identifier 14 can be less compared to the description of the data, which therefore leaves more space available in the packets for the data useful to be transported.
  • An advantageous way is to send an IP packet containing both the identifier 14 and the description of data corresponding to the network over the network. identifier 14. This packet is preferably sent along the path through the network which will be used subsequently by the packets 10a containing the identifier 14 without the data description. Thus, the data description is made available to the routers affected by this packet flow.
  • FIG. 4a illustrates an example of the structure of such a packet, referenced 15a, in which the identifier 14 and the data description 13 corresponding to the identifier 14 are both placed in the IP header of the packet 1 5a.
  • the body 1 2 of the package can contain useful data.
  • the identifier 14 can for example be placed in a header extension and the description 13 in another header extension.
  • the identifier 14 and the description 13 may be placed in the same header extension.
  • the identifier 14 can for example be placed in a header option and the description 13 in another header option.
  • the identifier 14 and the description 13 may be placed in the same header option.
  • FIG. 4b illustrates another example of the structure of such a packet, referenced 1 5b, in which the identifier 1 4 is placed in the IP header 1 1 and the data description 1 3 corresponding to the identifier 14 is placed in the body 1 2 of the package.
  • the rest of the space available in the body 1 2 of the package can contain data helpful.
  • the identifier 14 can for example be placed in a header extension.
  • the description 1 3 can be placed at a predetermined location in the body 1 2 of the package.
  • the identifier 14 can for example be placed in a header option.
  • the description 13 can also be placed at a predetermined location in the body 12 of the package.
  • the packet structure of FIG. 4b is particularly suitable for the case where the size of the description 1 3 is too large to be contained in the IP header 1 1. Furthermore, it is advantageous to have information in the header 1 1 of the packet indicating to the router the fact that it contains both an identifier 14 and a description 13. Under IPv4 or IPv ⁇ , this can be set implemented similarly to the examples given for indicating the presence of the data description 1 3 in the first embodiment. When the router receives such a packet containing both the identifier 14 and the description 15, it reads the latter. The router can then process this packet 1 5 as a function of the description 13. Furthermore, the router keeps in memory the identifier 14 and the corresponding description 13.
  • the router when the router subsequently receives packets of type 10a containing the identifier 14, it processes these packets according to the description 13 corresponding to the identifier 14 previously stored.
  • the routers provide the description of data corresponding to an identifier by sending an IP packet containing both the identifier 14 and the corresponding data description 13, it is preferable to ensure that this packet takes the same path through the network as the subsequent packets including the identifier 14.
  • the routers may be provided to apply the same routing to all the packets comprising the same identifier 14, whether it also includes the description 13 or not.
  • a packet containing both the identifier 14 and the description 1 3 can be sent only once before other packets of the type 1 0a stream including the identifier 14 without the description 13. But it is more advantageous to send a packet containing both the identifier 14 and the description 1 3 regularly, for example each time after a certain number of packets of the type 10a have been sent. Thus, a router which accidentally lost from its memory the data description 1 3 corresponding to the identifier 14 can put it back in memory.
  • the router updates its memory with the data description 13 for the identifier 14 concerned each time it receives such a packet. It can also be provided that the router uses the description 13 which it has in memory for a given identifier 14 only for a predetermined period of time since the reception of the last packet containing both this identifier 14 and this description 13. This expiration duration is preferably defined to be greater than the time separating a packet containing both the identifier 14 and the description 1 3 of the next packet also containing both the identifier 14 and the description 1 3 for the same flow of packets.
  • the router when it receives a packet 10a, the router reads the identifier 14 contained in the package. It then interrogates the database 21 with this identifier 14 and the database 21 returns the corresponding data description 13 to it. The router then processes the packet according to the data description 1 3 provided by the database 21. In addition, the router can store in memory the identifier 14 and the corresponding description 1 3. In this case, when the router subsequently receives packets of type 10a containing the same identifier 14, it processes these packets according to the description 1 3 corresponding previously. stored. In other words, the router verifies if it does not already have in memory a description 13 associated with the identifier 14 read in the packet and interrogates the database 21 only if the verification is negative.
  • the processing of subsequent packets is faster since it does not waste the time associated with querying the database 21.
  • the use of the database 21 is advantageous because a router always has the possibility of knowing the description 1 3 for any identifier even if the path followed by the different packets varies or even if the description 1 3 corresponding to an identifier 14 is accidentally erased in the router memory.
  • the terminal 2 can send an IP packet containing both the identifier 14 and the corresponding description 13 to the database 21 -
  • the database 21 acknowledges receipt of the terminal 2 by a return message. After receipt of the acknowledgment, the terminal 2 sends the IP packets with the useful data and comprising the identifier 14 to the final recipient.
  • the use of the database 21 and the method described above are combined to make available to the routers the description of data corresponding to an identifier 14 which includes sending over the network of an IP packet containing both the identifier 14 and the corresponding data description.
  • All the description made regarding the sending of a packet containing both an identifier 14 and the corresponding data description 13 to make available to routers said description 13 is applicable here with the following additional explanations.
  • a router receives such a packet containing both the identifier 14 and the corresponding description 1 3, it reads the latter.
  • the router sends to the database 21 the identifier 14 and the description 13, which ensures the updating of the database 21. Furthermore, the router processes this packet according to the description 13.
  • the router can advantageously keep in memory the identifier 1 4 and the corresponding description 1 3.
  • the router when the router subsequently receives packets of type 10a containing the identifier 14, it processes these packets according to the description 13 corresponding to the identifier 14 previously stored. But it can happen that a router does not have in memory the description 1 3 corresponding to an identifier 14 contained in a packet of type 10a. This may be the case because the router accidentally lost it from its memory or because it did not receive the packet containing both the identifier 14 and the corresponding description 1 3. This latter situation can in particular arise when the routers have changed the routing path after the sending of the packet containing both the identifier 14 and the corresponding description 13. In this case, the router interrogates the database 21 with the identifier 14.
  • the database 21 provides it with the corresponding description 13.
  • the router then processes the packet according to the description 13 provided and stores it for the processing of packets received subsequently and having the same identifier 14.
  • a router can be configured by a routing manager 20 (called in English “Policy Decision Point” or PDP), for example via the IP network itself, to define the processing operations to be performed on a packet 10a by the router as a function of the data description 13 which corresponds thereto.
  • the database 21 can possibly be part of the routing manager 20.
  • it can confine itself to processing - in particular routing - the packet 10a so conventional without taking account of the identifier 14 and the corresponding description 1 3.
  • the same identifier 14 is used simultaneously in the network but for different descriptions 1 3.
  • routers may take into account additional parameters to distinguish packet flows, for example, the IP address of the source of the packets.
  • the data descriptions 13 and / or the identifiers 14 can be placed in the IP packets sent by the terminal 2 by the terminal 2 itself.
  • the terminal 2 can include a software application cooperating with the packet generator 8 to place the description 13 and / or the identifier 14 there according to the type of packet to be generated. It can also be is the packet generator 8 which places the description 13 and / or the identifier 14 in the IP packets.
  • the first router to which the terminal 2 is connected - in this case the router 4 - which adds in the IP packets coming from the terminal 2 the description 13 and / or the identifier 14 depending on the type of packet to generate.
  • the description 13 can be supplied to the first router by the terminal 2 and the router defines an identifier 14 which it matches with the description.
  • the description of data 13 can advantageously define the type of useful data transported in the packet or IP packets concerned, such as the fact that it is audio or video data, or more generally that it is data that is part of a real-time data flow or a very large data flow or that this data has a cyclic sending character.
  • the description of data can also include technical characteristics relating to the data such as for example the sampling frequency for audio data.
  • the routers will then be able to process - in particular route - the IP packets not only according to the only destination IP address placed in their header, but also according to the nature of the useful data transported and these other technical characteristics.
  • the router can use the most suitable equipment to process the type of data concerned.
  • the router or the equipment connected to it can use the most suitable algorithm to assess the quality of service provided to the end user for the audio stream concerned.
  • the router can select a specific audio stream management card to perform on-the-fly and on-demand compression in the case of audio data, or to merge several audio and video streams during an IP conference. .
  • the data description 1 3 can be supplemented - or replaced - with information concerning the source of the data or the recipient of the data other than their IP address in the network. For example, it can be the patronymic name or the corporate name of the source and / or the recipient. Therefore, the router can process the packets taking this information into account. In particular, the router can route the packets according to routing rules defined for the recipient thus defined with the description of data 13. For example, it can preferentially send packets transporting an image to one of the recipient's machines which has a display suitable for displaying it, independently of the destination IP address specified in the IP header of the packet (s) concerned. .
  • the data description 1 3 may also include information concerning the processing to be carried out by the routers traversed, in particular information relating to the quality of service QoS (from the "Quality of Service") to be provided. For example, such information can be the bandwidth to reserve for these data packets. It may also be routing parameters, for example, a preferential routing path defined by the data transmitter, in this case, the terminal 2. It is advantageous for the data descriptions 13 placed in the IP packets are written in XML. Indeed, a description 13 in XML can be interpreted by most routers, the XML schema used for the description being able to be sought on the network for example at a predetermined address thereof. This diagram can then be interpreted by the router to build an internal representation of the information contained in the XML document.
  • the routers are able to perform suitable routing, by associating the packets with a buffer size sufficient to absorb the jitter effects that can be encountered in the network, or by choosing a route or a priority of packets according to the identity of recipients and senders.
  • the various fields of such a description are preferably standardized.
  • An identifier 14 associated with this description may for example take the form of an alphanumeric code such as "voice". It will be understood that the data descriptions can also be written in coded form instead of being close to a natural language more directly understandable by humans as XML allows.
  • the present invention is not limited to the examples and embodiments described and shown, but it is susceptible of numerous variants accessible to those skilled in the art.
  • FIG. 5 illustrates an example of implementation of the first embodiment in which a description 1 3 is placed in the body 1 2 of an IP packet 1 6 while its IP header 1 1 is of the conventional type.
  • the body 12 contains at the end of it a predetermined identification code 1 6 used to indicate to a router receiving the packet that it contains a description 13.
  • the body 1 2 contains immediately before the identification code 1 6 a value 1 7 indicative of the length of the description 1 3 in the package 1 6.
  • the description 1 3 is placed in the body immediately before the value 17.
  • the rest of the body 12 contains the useful data to carry.
  • the second embodiment can be implemented in a similar manner, with the identifier 14 which comes replacing the description 13 in the body 1 2.
  • a specific predetermined code 1 7 can be defined in the case where the body 1 2 contains both the description 1 3 and the identifier 14.
  • the code 1 7 may be preceded by a value 1 7 indicative of the length of the description 13 in the package 1 6, then another value 1 7a indicative of the length of the identifier 14 in the package 1 6, then of the description 1 3 and finally from the identifier 1 -.
  • the description 13 and / or the identifier 14 are written in a language independent of the protocols of the OSI layers 5 to 7.
  • the routers are able to read the description and the identifier 14 whatever the protocols of the OSI layers 5 to 7.
  • the various embodiments have been described for IP protocol packets, it will be understood that the invention can be implemented similarly with d other protocols of the OSI 3 layer (called the network layer).
  • the implementation of the invention using the headers at the level of the OSI layer 3 is preferred because the nodes are conventionally provided for routing the packets thanks to this protocol.
  • the invention can also be implemented at the level of the headers of the protocols of the OSI 4 layer (known as the transport layer) in the case where it is possible to write therein the data description 13 and / or the identifier. 14 and that the nodes have the capacity to process this protocol or these protocols if there are several used within the same network.
  • IPv4 protocol we can refer in particular to document RFC 791.
  • IPv ⁇ protocol one can refer in particular to document RFC 2460.
  • OSI reference model one can refer in particular to standard ISO 7498.

Landscapes

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

Abstract

Le procédé de fonctionnement d'un nœud d'un réseau de communication par paquets, en particulier d'un routeur IP, comprend les étapes suivantes : a) réception par le nœud d'un paquet (10) depuis le réseau ; b) réception par le nœud d'une information (13) indépendante des protocoles des couches OSI 5 à 7 - voire des couches OSI 4 à 7 - du paquet et concernant au moins l'une des caractéristiques suivantes : le type de données transportées dans le paquet, la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet ; c) traitement du paquet (10) par le nœud en fonction de ladite description. Il est avantageux que ladite information soit contenue dans le paquet lui-même.

Description

DESCRIPTION DE CONTENU DE PAQUETS DANS UN RESEAU DE COMMUNICATION PAR PAQUETS
L'invention α trait aux réseaux de communication par paquets mettant en œuvre des protocoles organisés en couches tels que standardisées dans le modèle de référence OSI (« Open System Interconnection ») défini par l'Organisation internationale de normalisation, dit ISO ou pouvant s'y assimiler. Plus particulièrement, l'invention concerne un procédé de fonctionnement d'un noeud d'un réseau de communication par paquets, en particulier d'un routeur IP. Elle concerne aussi un paquet de données pour un réseau de communication par paquets et un générateur de paquets de données pour un réseau de communication par paquets. L'optimisation de la transmission des paquets émis dans un réseau de communication par paquets tel qu'un réseau au protocole IP (de l'anglais « Internet Protocol ») repose sur le traitement spécifique des paquets au niveau des nœuds du réseau en fonction de leur contenu. Dans le cas d'un réseau au protocole IP, les nœuds sont traditionnellement appelés routeurs. En particulier, les mécanismes de qualité de service ou QoS dans les réseaux comprennent un traitement différencié de paquets émis sur le réseau, en fonction de paramètres tels que l'expéditeur, le destinataire ou le type de données contenu dans le paquet. Les nœuds du réseau traitent les paquets en fonction de ces paramètres, par exemple en leur attribuant un routage, une bande passante, une priorité, ou toute autre caractéristique adéquate. La qualité de service est en particulier primordiale pour garantir une transmission dans de bonnes conditions de paquets contenant de la voix ou de la vidéo, notamment dans le cas de voix sur IP ou de vidéo sur IP. Il est donc nécessaire de pouvoir déterminer ces paramètres pour gérer correctement et efficacement les flux de paquets. II existe des logiciels tels que PacketShaper™ de la société américaine
Packeter, Inc. ou des processeurs tels que Content Processor 5000™ de la société américaine LeWiz Communications, Inc prévus pour être mis en œuvre dans les routeurs et qui réalisent une estimation du type de données contenues dans un paquet. Le routeur réalise cette estimation du type de données contenues dans le paquet en examinant les paquets pour déterminer les protocoles utilisés dans la partie des paquets correspondant aux couches OSI 5 à 7 (c'est-à-dire les couches 5 à 7 du modèle de référence OSI). Le routeur peut notamment déterminer que le protocole utilisé est FTP (de l'anglais « File Transfer Protocol ») ou HTTP (de l'anglais « Hypertext Transfer Protocol »). Ensuite, le routeur examine éventuellement les autres parties du paquet pour déterminer le type de données contenues dans le paquet, par exemple par reconnaissance de la signature d'une application ou d'un type de données présente parmi les données dans le corps du paquet (appelé « paylaod »). Le routeur suppose que le paquet appartient à une catégorie de traitement prédéfinie en fonction du protocole reconnu ainsi que de l'éventuelle signature reconnue. Le paquet est ensuite classé dans la catégorie prédéfinie, et le routeur lui applique les traitements correspondants à cette catégorie. Ce procédé présente cependant des inconvénients. D'une part, lors de l'utilisation d'un nouveau protocole dans les couches OSI 5 à 7 d'un paquet, le protocole n'est pas reconnu par un routeur non mis à jour. Le routeur ne peut donc plus supposer le contenu d'un tel paquet de données. Le routeur ne peut alors plus réaliser une gestion de la qualité de service en fonction du contenu d'un paquet. D'autre part, un même protocole peut être utilisé pour des types de données différentes. Par exemple, le protocole HTTP est utilisé à la fois pour le transport de contenus interactifs et pour le transfert de fichiers statiques, et ne permet de transporter des informations que sur les données qui sont transportées dans une séquence de paquets (typiquement un flux TCP) et pas par un paquet seul. Ainsi, le routeur ne peut pas déterminer précisément le type de données uniquement en fonction du protocole de transmission utilisé. Par ailleurs, il n'est pas possible de programmer le routeur pour reconnaître de façon exhaustive les signatures de toutes les applications ou de tout type de données qui peuvent être présentes dans le paquet. De plus, il se pose le problème de la mise à jour des routeurs avec les signatures de nouvelles applications ou de données à un nouveau format. Le routeur n'est donc pas toujours capable de reconnaître correctement le type de données contenues dans les paquets. La qualité de service n'est alors pas optimale car les différents types de données peuvent requérir des exigences techniques différentes. Une autre possibilité pour fournir les paramètres utiles aux routeurs consisterait à utiliser un protocole de signalisation connu qui soit prévu pour fournir des informations de ce type. Ainsi, il est envisageable de recourir au protocole SIP (de l'anglais « Session Initiation Protocol ») qui permet d'envoyer des messages contenant le type de données transporté dans un flux de paquets. Néanmoins, cette solution présente des inconvénients car les messages sont émis d'un élément réseau émetteur vers un élément réseau destinataire et ne sont pas conçu pour faciliter leur interprétation par les routeurs. En particulier, ils sont transportés dans une séquence de paquets qui doivent être le cas échéant ré-ordonnancés avant de pouvoir interpréter leur contenu. De plus, le protocole de signalisation étant différent du protocole de transmission des paquets de données décrits, la probabilité que le message et les paquets de données empruntent des trajets différents est extrêmement élevée. Ainsi, les routeurs empruntés par les paquets de données ne disposent pour la plupart pas de la description contenue dans le message. Ces routeurs ne peuvent donc pas gérer de façon optimale la transmission des paquets de données. Il existe donc un besoin pour un procédé de transmission qui résolve un ou plusieurs des inconvénients cités auparavant. L'invention a ainsi pour objet un procédé de fonctionnement d'un nœud d'un réseau de communication par paquets, en particulier d'un routeur IP, comprenant les étapes de : a) réception par le nœud d'un paquet depuis le réseau ; b) réception par le nœud d'une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes : '" - le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et - le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet ; c) traitement du paquet par le nœud en fonction de ladite description. Il est plus avantageux encore que l'information reçue dans l'étape b) soit indépendante des protocoles des couches OSI 4 à 7 du paquet. Selon un mode de réalisation préféré, ladite information est contenue dans le paquet, l'étape b) comprenant la lecture de ladite information dans le paquet par le nœud. Ladite information peut notamment être contenue dans l'en-tête au protocole de la couche OSI 3 du paquet, l'étape b) comprenant alors la lecture par le nœud de ladite information dans l'en-tête au protocole de la couche OSI 3 du paquet. Selon un autre mode de réalisation préféré, le paquet contient un identifiant de ladite information, l'étape a) comprenant la lecture de l'identifiant par le nœud. L'identifiant peut notamment être contenu dans l'en-tête au protocole de la couche OSI 3 du paquet, l'étape a) comprenant la lecture par le nœud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 du paquet. Par ailleurs, il est avantageux que l'étape b) comprenne la réception par le nœud d'un autre paquet depuis le réseau, ledit autre paquet contenant ladite information. Ladite information peut notamment être contenue dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet, l'étape b) comprenant alors la lecture par le nœud de ladite information dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet. En variante, Procédé selon ladite information peut être contenue dans le corps selon le protocole de la couche OSI 3 dudit autre paquet, l'étape b) comprenant alors la lecture par le nœud de ladite information dans le corps selon le protocole de la couche OSI 3 dudit autre paquet. Il est avantageux que ledit autre paquet contienne en outre l'identifiant, l'étape b) comprenant également la lecture par le nœud de l'identifiant dans ledit autre paquet. L'identifiant peut notamment être contenu dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet auquel cas l'étape b) comprend la lecture par le nœud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet. Le procédé peut encore avantageusement comprendre après l'étape b), une étape d'envoi par le nœud vers une base de données, de l'identifiant et de ladite information. Selon un autre mode de réalisation préféré, le procédé comprend après l'étape a) et avant l'étape b), une étape d'interrogation par le nœud d'une base de données avec l'identifiant. Selon un autre aspect, l'invention propose aussi un paquet de données pour un réseau de communication par paquets, comprenant une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes : - le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et - le destinataire des données- transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet. Il est plus avantageux encore que ladite information soit indépendante des protocoles des couches OSI 4 à 7 du paquet. Selon un mode de réalisation préféré, ladite information est contenue dans l'en-tête au protocole de la couche OSI 3 du paquet. De façon préférentielle, le paquet est au protocole IP, ladite information étant contenue dans l'en-tête IP. Selon un autre aspect encore, l'invention propose un générateur de paquets selon l'invention tels que définis précédemment. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit de modes de réalisation de l'invention, donnée à titre d'exemple et en référence aux dessins annexés qui montrent : -figure 1 , une représentation schématique d'un exemple de réseau de transmission dans lequel l'invention est mise en œuvre ; -figure 2, une structure d'un paquet de données contenant une description de données ; -figure 3, une structure d'un paquet de données contenant un identifiant de description de données ; -figure 4a, une structure d'un paquet de données contenant à la fois un identifiant de données et une description de données dans l'entête du paquet ; -figure 4b, une structure d'un paquet de données contenant un identifiant de description de données placée dans l'en-tête du paquet et une description de données placée dans le corps du paquet ; -figure 5, une structure d'un paquet de données contenant une description de données dans le corps du paquet. Selon l'invention, le procédé de fonctionnement d'un nœud d'un réseau de communication par paquets, comprend les étapes de : α) réception par le nœud d'un paquet depuis le réseau ; b) réception par le nœud d'une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes : - le type de données transportées dans le paquet, la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet ; c) traitement du paquet par le nœud en fonction de ladite description. L'on comprendra que l'ordre dans le temps des étapes a) et b) est indifférent. Autrement dit, l'étape a) peut être postérieure ou antérieure à l'étape b). Les étapes a) et b) peuvent également être concomitante notamment dans le cas où ladite information est contenue dans le paquet lui-même. L'on comprendra que ladite information peut concerner uniquement l'une quelconque des caractéristiques indiquées dans l'étape b), ou deux quelconques d'entre elles ou encore les trois. Elles peut encore comporter d'autres informations concernant par exemple le traitement à effectuer par le nœud sur les paquets. Le fait que ladite information est fournie au nœud permet donc à ce dernier de traiter le paquet - par exemple de choisir un chemin dans le réseau - en fonction de ladite information. Autrement dit, le traitement du paquet ne dépend plus seulement des informations contenues conventionnellement dans le paquet à cette fin telles que l'adresse réseau de la source du paquet et l'adresse réseau du destinataire final du paquet. Du fait que ladite information est indépendante des protocoles des couches OSI 5 à 7 utilisés dans le paquet, le nœud peut lire et comprendre ladite information sans connaître ces protocoles. Autrement dit, le nœud est capable de traiter le paquet en fonction de ladite information sans connaître les protocoles des couches 5 à 7. Il est encore plus avantageux que ladite information soit indépendante du protocole de la couche OSI 4 utilisé dans le paquet, ce qui permet au nœud de traiter le paquet en fonction de ces informations indépendamment de ce protocole. En effet, un nœud de réseau peut ne pas être capable d'analyser la couche correspondante des paquets qu'il reçoit ou encore il n'est pas souhaitable qu'il doive pouvoir le faire pour des raisons de vitesse de traitement. Ladite information est avantageusement écrite selon un code ou langage que le nœud est capable de comprendre. Ce code ou langage peut toujours être le même quel que soit le paquet concerné. De façon préférée, ladite information peut être incluse dans la paquet lui- même. Ceci permet de faire parvenir de façon simple et fiable ladite information au nœud du réseau pour traiter le paquet de données correspondant. Il est avantageux que ladite information soit complètement contenue dans le paquet concerné par l'information car il 'agit d'une manière simple d'assurer que le nœud reçoive toujours ladite information pour chacun des paquets. Si, au contraire, ladite information était répartie dans plusieurs paquets, le nœud doit la reconstituer à partir de la pluralité de paquets en les ordonnançant de façon adéquate, ce qui rend l'opération plus complexe. De plus, le nœud peut être dans l'impossibilité de reconstituer l'information s'il ne reçoit pas l'un d'entre eux par exemple en cas de changement de chemin de routage dans le réseau. Etant donnée que les données envoyées d'un terminal émetteur vers un terminal destinataire dans un réseau sont généralement transportées dans un flux constitués de nombreux paquets contenant chacun le même type de données par exemple audio, chaque paquet peut simplement contenir - au lieu de ladite information - un identifiant de ladite information, l'identifiant étant indépendant des protocoles des couches OSI 5 à 7, voire des couches OSI 4 à 7, utilisés dans le paquet. Le nœud détermine alors ladite information qui correspond à l'identifiant pour traiter chaque paquet en fonction de ladite information. Ladite information peut être fourni au nœud par différents moyens telles que par un paquet qui la contient ou par une base de donnée qu'il interroge. L'invention est particulièrement adaptée à être mise en œuvre dans un réseau au protocole IP (qui correspond à la couche OSI 3). On rappelle qu'un réseau IP est organisé typiquement en quatre couches : la couche Internet au protocole IP correspondant à la couche OSI 3, la couche transport (typiquement au protocole TCP ou UDP) correspondant à la couche OSI 4, et la couche application correspondant aux couches OSI 5 à 7. La figure 1 représente schématiquement un exemple de réseau de communication par paquets 1 , en l'occurrence un réseau au protocole IP. Le réseau
I comprend un terminal 2 envoyant des paquets de données par l'intermédiaire d'un sous-réseau 3 vers un destinataire final non représenté. On désignera dans la suite par données utiles d'un paquet les données transportées dans ce paquet qui sont à transmettre au destinataire final du paquet soit en l'état, soit éventuellement sous forme modifiée (dans le cas de traitement effectué par le réseau sur les données transportées). Le sous-réseau 3 est muni de routeurs 4 à 7 fournissant plusieurs trajets de routage aux paquets de données à travers le sous-réseau 3. Le terminal 2 comprend un générateur 8 de paquets de données pouvant être d'un type quelconque connu, par exemple une application logicielle de transmission de voix ou de vidéo sur IP. Le générateur 8 génère des paquets de données au protocole IP qui sont envoyés vers le destinataire final à travers le sous- réseau 3 grâce à une interface 9 adéquate du terminal 2. Pour assurer un traitement correct d'un paquet émis par le générateur 8, il est souhaitable que le routeur qui reçoit ce paquet puisse connaître des informations concernant les données utiles transportées, leur source ou leur destinataire. Dans ce but, l'on fait parvenir au routeur des informations à ce sujet pour lui permettre de traiter le paquet de façon adéquate. Pour la suite, nous prendrons en exemple la fourniture au routeur d'informations concernant les données transportées que l'on désignera par commodité de description de données. Selon un premier mode de réalisation, cette description de données est placée dans le paquet transportant ces données. Plus particulièrement, il est avantageux que la description de données soit placée dans l'en-tête IP de ce paquet comme illustré par la figure 2. La figure 2 représente la structure d'un paquet 10 comprenant un en-tête IP
I I et un corps 1 2 (aussi communément appelé « payload » en anglais). L'en-tête 1 1 comprend une description 1 3 des données utiles contenues dans le corps 1 2 du paquet. Le corps 1 2 contient les données utiles à transmettre au destinataire final du paquet et qui peuvent être au format d'un protocole d'une couche OSI supérieure à la couche IP, ce dernier étant un protocole correspondant à la couche OSI 3. En particulier, le corps 1 2 peut classiquement contenir un en-tête à un protocole correspondant à la couche OSI 4 (dite couche transport) tel que TCP (de l'anglais « Transmission Control Protocol ») ou UDP (de l'anglais « User Datagram Protocol ») encapsulant les données utiles à transmettre au destinataire du paquet. Les données sont au format d'un protocole de la couche application du modèle IP qui correspond aux couches OSI 5 à 7 comme mentionné plus haut. Ces données peuvent par exemple être de la voix sur IP ou de la vidéo sur IP. Les routeurs 4 à 7 sont prévus pour lire la description de données 13 placée dans l'en-tête IP 1 1 des paquets qu'ils reçoivent et traiter chaque paquet en fonction de la description 1 3 contenue dans son en-tête IP. Le fait que la description de données 13 soit placée dans l'en-tête IP du paquet 10 est avantageuse puisque le routeur peut la lire en analysant uniquement l'en-tête IP 1-1 du paquet. Or, un routeur est classiquement capable d'analyser les en-têtes IP. Au contraire, il n'a pas besoin de traiter le corps 1 2 du paquet. Ainsi, le routeur n'a pas besoin de connaître le ou les protocoles des couches OSI 4 à 7 qui sont éventuellement utilisées dans le corps 1 2 du paquet. Par conséquent, l'on évite que le routeur ait à faire des traitements sur les données dans le corps 1 2 du paquet et en particulier sur les données utiles transportées, le routeur n'étant pas destiné à effectuer ce type de traitement. D'autre part, le routeur est en mesure de traiter la description de données 13 quel que soient le ou les protocoles des couches OSI 4 à 7 utilisés dans le corps 12 du paquet. Enfin, la description 13 complète étant contenue dans le paquet à traiter, le routeur n'a pas besoin de reconstituer préalablement la description en lisant plusieurs paquets différents qu'il réordonnance avant de pouvoir traiter un paquet en fonction de la description de données. Ce mode de réalisation est particulièrement adapté à être mis en œuvre avec les paquets au protocole IPvό car un tel paquet présente une en-tête 1 1 de taille suffisante pour inclure une description de donnée. Dans ce cas, la description de données 1 3 peut notamment être placée dans une extension d'en-tête (appelée « extension header » en anglais) de l'en-tête IPvό, par exemple une extension d'en- tête du type dit « Hop-by-Hop Options ». Mais ce mode de réalisation peut également être mis en œuvre avec les paquets au protocole IPv4 par exemple en inscrivant la description de données 1 3 dans une option de l'en-tête 1 1 . Par ailleurs, il est avantageux d'avoir une information dans l'en-tête 1 1 du paquet indiquant au routeur le fait qu'il contient une description de données. II peut notamment s'agir d'un marqueur prédéterminé dans l'en-tête IP. Sous IPvό, dans le cas cité où la description de données 13 est placée dans une extension d'en-tête, il peut par exemple s'agir d'un code prédéterminé placé dans l'extension d'en-tête immédiatement à la suite de son propre en-tête. Sous IPv4, dans le cas cité où la description de données 13 est placée dans une option d'en-tête, il peut notamment s'agir de l'octet codant le type d'option. Concernant les traitements à effectuer par un routeur donné en fonction de la description de données 13, le routeur peut être configuré par un gestionnaire de routage 20 (appelé en anglais « Policy Décision Point » ou PDP) par exemple via le réseau IP lui-même. Bien entendu, dans le cas d'un routeur non prévu pour interpréter la description de données 13, il peut se borner à traiter - en particulier router - le paquet 1 0 de façon conventionnelle sans tenir compte de la description 1 3. Dans ce premier mode de réalisation, chaque paquet 1 0 est traité par les routeurs en fonction de la description de données 13 qui est placée dans ce paquet. Selon un deuxième mode de réalisation, un identifiant de la description de données est placée dans le paquet IP envoyé par le terminal 2. Plus précisément, à un identifiant placé dans un paquet de données correspond une description des données utiles transportées dans le paquet contenant cet identifiant. Là-encore, l'identifiant peut avantageusement être inclus dans l'en-tête IP du paquet. La figure 3 illustre la structure d'un tel paquet 1 0a avec un identifiant 14 de la description de données qui est placée dans l'en-tête IP 1 1 , le corps (ou « payload ») du paquet étant référencé 1 2. Sous IPvό ou IPv4, l'identifiant peut par exemple être placée dans une extension d'en-tête ou une option respectivement de façon similaire à celle décrite pour la description de données 1 3 dans le premier mode de réalisation. Par ailleurs, il est avantageux d'avoir une information dans l'en-tête 1 1 du paquet indiquant au routeur le fait qu'il contient un identifiant 14. Sous IPv4 ou IPvό, cela peut être mis en œuvre de façon similaire aux exemples données pour l'indication de la présence de la description de données 1 3 dans le premier mode de réalisation. Les routeurs 4 à 7 peuvent être prévus pour lire l'identifiant 14 dans l'entêtes IP 1 1 des paquets qu'ils reçoivent et déterminer la description de données qui correspond à l'identifiant 14 . Ensuite, le routeur traite le paquet en fonction de la description de données correspondante à l'identifiant 14 contenu dans son en-tête IP 1 1 . Ce mode de réalisation est avantageux par rapport au précédent dans la mesure où la taille de l'identifiant 14 peut être moindre en comparaison de la description de données, ce qui laisse donc plus de place disponibles dans les paquets pour les données utiles à transporter. II existe différente manière de mettre à disposition d'un routeur la description de données correspondant à un identifiant 14. Une manière avantageuse consiste à envoyer sur le réseau un paquet IP contenant à la fois l'identifiant 14 et la description de données correspondant à l'identifiant 14. Ce paquet est préférentiellement envoyé le long du chemin à travers le réseau qui sera emprunté subséquemment par les paquets 1 0a contenant l'identifiant 14 sans la description de données. Ainsi, la description de données est mise à la disposition des routeurs concernés par ce flux de paquets. Il peut par exemple s'agir d'un paquet envoyé par le terminal 2 vers le destinataire final qui contient donc à la fois l'identifiant 14 et la description de données. La figure 4a illustre un exemple de structure d'un tel paquet, référencé 15a, dans lequel l'identifiant 14 et la description de données 13 correspondant à l'identifiant 14 sont tous les deux placés dans l'en-tête IP du paquet 1 5a. Le corps 1 2 du paquet peut contenir des données utiles. Sous IPvό, l'identifiant 14 peut par exemple être placée dans une extension d'en-tête et la description 1 3 dans une autre extension d'en-tête. En variante, l'identifiant 14 et la description 1 3 peuvent être placée dans une même extension d'entêté. Sous IPv4, l'identifiant 14 peut par exemple être placée dans une option d'en-tête et la description 13 dans une autre option d'en-tête. En variante, l'identifiant 14 et la description 1 3 peuvent être placée dans une même option d'entêté. La figure 4b illustre un autre exemple de structure d'un tel paquet, référencé 1 5b, dans lequel l'identifiant 1 4 est placé dans l'en-tête IP 1 1 et la description de données 1 3 correspondant à l'identifiant 14 est placée dans le corps 1 2 du paquet. Le reste de place disponible dans le corps 1 2 du paquet peut contenir des données utiles. Sous IPvό, l'identifiant 14 peut par exemple être placé dans une extension d'en-tête. La description 1 3 peut être placée à un endroit prédéterminé dans le corps 1 2 du paquet. Sous IPv4, l'identifiant 14 peut par exemple être placée dans une option d'en-tête. La description 13 peut aussi être placée à un endroit prédéterminé dans le corps 1 2 du paquet. La structure de paquet de la figure 4b est particulièrement adaptée au cas où la taille de la description 1 3 est trop importante pour être contenue dans l'en-tête IP 1 1 . Par ailleurs, il est avantageux d'avoir une information dans l'en-tête 1 1 du paquet indiquant au routeur le fait qu'il contient à la fois un identifiant 14 et une description 13. Sous IPv4 ou IPvό, cela peut être mis en œuvre de façon similaire aux exemples données pour l'indication de la présence de la description de données 1 3 dans le premier mode de réalisation. Lorsque le routeur reçoit un tel paquet contenant à la fois l'identifiant 14 et la description 15, il lit ces derniers. Le routeur peut alors traiter ce paquet 1 5 en fonction de la description 13. Par ailleurs, le routeur garde en mémoire l'identifiant 14 et la description 13 correspondante. Ainsi, lorsque le routeur reçoit subséquemment des paquets de type 10a contenant l'identifiant 14, il traite ces paquets en fonction de la description 13 correspondant à l'identifiant 14 précédemment mémorisés. Dans le cas où la mise à disposition des routeurs la description de données correspondant à un identifiant se fait par l'envoi d'un paquet IP contenant à la fois l'identifiant 14 et la description de données 13 correspondante, il est préférable d'assurer que ce paquet emprunte le même chemin à travers le réseau que les paquets subséquents incluant l'identifiant 14. Ainsi, tous les routeurs sur le chemin des paquets subséquents auront eu la possibilité de mémoriser au préalable la description 13. En particulier, les routeurs peuvent être prévus pour appliquer le même routage à tous les paquets comportant un même identifiant 14, qu'il comprenne en outre la description 13 ou non. En variante, sous IPvό, tous les paquets de ce flux de paquets sont affectés d'un même « Flow Label » et les routeurs sont prévus pour appliquer toujours le même routage à tout paquet présentant un même « Flow Label ». Un paquet contenant à la fois l'identifiant 14 et la description 1 3 peut être envoyé une seule fois préalablement aux autres paquets du flux du type 1 0a incluant l'identifiant 14 sans la description 13. Mais il est plus avantageux d'envoyer un paquet contenant à la fois l'identifiant 14 et la description 1 3 régulièrement, par exemple à chaque fois après qu'un certain nombre de paquets du type 10a ont été envoyés. Ainsi, un routeur qui a accidentellement perdu de sa mémoire le descriptif de données 1 3 correspondant à l'identifiant 14 peut le remettre en mémoire. De préférence, le routeur met à jour sa mémoire avec la description de donnée 13 pour l'identifiant 14 concerné à chaque fois qu'il reçoit un tel paquet. Il peut en outre être prévu que le routeur n'utilise la description 13 qu'il a en mémoire pour un identifiant 14 donné que pendant une durée prédéterminée depuis la réception du dernier paquet contenant à la fois cet identifiant 14 et cette description 13. Cette durée d'expiration est préférentiellement définie pour être supérieure au temps séparant un paquet contenant à la fois l'identifiant 14 et la description 1 3 du prochain paquet contenant également à la fois l'identifiant 14 et la description 1 3 pour un même flux de paquets. De la sorte, il est inutile de gérer la fin du flux de paquets - présentant tous l'identifiant 14 - envoyés par le terminal 2 pour pouvoir éventuellement réaffecter ultérieurement l'identifiant à une autre description de données 13. Concernant le deuxième mode de réalisation, une autre possibilité de mettre à la disposition d'un routeur la description de données 13 correspondant à un identifiant 14 consiste à donner accès au routeur à une base de données 21 qui stocke les identifiants 14 et les descriptions de données 13 correspondantes. La communication entre le routeur et la base de données 21 peut être assurée via le réseau IP lui-même comme illustré sur la figure 1 . Bien entendu, la même base de données 21 peut être avantageusement accessible à une pluralité de routeurs, voire à l'ensemble des routeurs du sous-réseau 3. Ainsi, lorsqu'il reçoit un paquet 10a, le routeur lit l'identifiant 14 contenu dans le paquet. Il interroge alors la base de données 21 avec cet identifiant 14 et la base de données 21 lui retourne la description de données 13 correspondante. Le routeur traite ensuite le paquet en fonction de la description de données 1 3 fournie par la base de données 21 . En outre, le routeur peut stocker en mémoire l'identifiant 14 et la description 1 3 correspondante. Dans ce cas, lorsque le routeur reçoit subséquemment des paquets de type 10a contenant le même identifiant 14, il traite ces paquets en fonction de la description 1 3 correspondante précédemment mémorisés. Autrement dit, le routeur vérifie s'il n'a pas déjà en mémoire une description 1 3 associée à l'identifiant 14 lu dans le paquet et interroge la base de données 21 uniquement si la vérification est négative. Par conséquent, le traitement des paquets subséquents est plus rapide puisqu'il ne perd pas le temps lié à l'interrogation de la base de données 21 . Le recours à la base de données 21 est avantageuse car un routeur a toujours la possibilité de connaître la description 1 3 pour un identifiant quelconque même si le chemin emprunté par les différents paquets varient ou encore si la description 1 3 correspondant à un identifiant 14 est accidentellement effacée dans la mémoire du routeur. Il existe différentes manières de mettre à jour la base de données 21 . Par exemple, le terminal 2 peut envoyer un paquet IP contenant à la fois l'identifiant 14 et la description 13 correspondante vers la base de données 21 - La base de données 21 en accuse réception au terminal 2 par un message en retour. Après réception de l'accusé de réception, le terminal 2 envoie les paquets IP avec les données utiles et comportant l'identifiant 14 vers le destinataire final. Suivant une mise en œuvre particulièrement avantageuse, on combine l'utilisation de la base de données 21 et le procédé décrit précédemment pour mettre à la disposition des routeurs la description de données correspondant à un identifiant 14 qui comprend l'envoi sur le réseau d'un paquet IP contenant à la fois l'identifiant 14 et la description de données correspondante. Toute la description faite concernant l'envoi d'un paquet contenant à la fois un identifiant 14 et la description de données 13 correspondante pour mettre à disposition des routeurs ladite description 13 est applicable ici avec les explications complémentaires suivantes. Lorsqu'un routeur reçoit un tel paquet contenant à la fois l'identifiant 14 et la description 1 3 correspondante, il lit ces derniers. Le routeur envoie à la base de données 21 l'identifiant 14 et la description 13, ce qui assure la mise à jour de la base de données 21 . Par ailleurs, le routeur traite ce paquet en fonction de la description 13. Enfin, le routeur peut avantageusement garder en mémoire l'identifiant 1 4 et la description 1 3 correspondante. Ainsi, lorsque le routeur reçoit subséquemment des paquets de type 10a contenant l'identifiant 1 4, il traite ces paquets en fonction de la description 13 correspondant à l'identifiant 14 précédemment mémorisés. Mais il peut arriver qu'un routeur n'ait pas en mémoire la description 1 3 correspondant à un identifiant 14 contenu dans un paquet de type 10a. Ce peut être le cas du fait que le routeur l'a perdu accidentellement de sa mémoire ou encore parce qu'il n'a pas reçu le paquet contenant à la fois l'identifiant 14 et la description 1 3 correspondante. Cette dernière situation peut notamment survenir lorsque les routeurs ont changé le chemin de routage postérieurement à l'envoi du paquet contenant à la fois l'identifiant 14 et la description 13 correspondante. Dans ce cas, le routeur interroge la base de données 21 avec l'identifiant 14. La base de données 21 lui fournit en réponse la description 13 correspondante. Le routeur traite alors le paquet en fonction de la description 13 fournie et la mémorise pour le traitement des paquets reçus subséquemment et présentant le même identifiant 14. Bien entendu, similairement au premier mode de réalisation, un routeur peut être configuré par un gestionnaire de routage 20 (appelé en anglais « Policy Décision Point » ou PDP), par exemple via le réseau IP lui-même, pour définir les traitements à effectuer sur un paquet 10a par le routeur en fonction de la description de données 13 qui y correspond. La base de données 21 peut éventuellement faire partie du gestionnaire de routage 20. Par ailleurs, dans le cas d'un routeur non prévu pour lire les identifiants 14, il peut se borner à traiter - en particulier router - le paquet 1 0a de façon conventionnelle sans tenir compte de l'identifiant 14 et de la description 1 3 correspondante. Dans le cas où il n'est pas prévu un contrôle centralisé de la définition des identifiants 14 dans le réseau, il est possible qu'un même identifiant 14 soit utilisé simultanément dans le réseau mais pour des descriptions 1 3 différentes. Pour éviter la confusion, les routeurs peuvent prendre en compte des paramètres supplémentaires pour distinguer les flux de paquets, par exemple, l'adresse IP de la source des paquets. Quel que soit le mode de réalisation considéré, les descriptions de données 13 et/ou les identifiants 14 peuvent être placés dans les paquets IP envoyés par le terminal 2 par le terminal 2 lui-même. Dans ce but, le terminal 2 peut comprendre une application logicielle coopérant avec le générateur de paquets 8 pour y placer la description 13 et/ou l'identifiant 14 en fonction du type de paquet à générer. Ce peut aussi être est le générateur de paquets 8 qui place la description 13 et/ou l'identifiant 14 dans les paquets IP. En variante, c'est le premier routeur auquel est connecté le terminal 2 - en l'occurrence le routeur 4 - qui ajoute dans les paquets IP provenant du terminal 2 la description 13 et/ou l'identifiant 14 en fonction du type de paquet à générer. Dans ce cas, la description 1 3 peut être fournie au premier routeur par le terminal 2 et le routeur défini un identifiant 14 qu'il fait correspondre à la description. Quel que soit le mode de réalisation considéré, la description de données 1 3 peut avantageusement définir le type des données utiles transportées dans le paquet ou les paquets IP concernés, tel que le fait qu'il s'agisse de données audio ou vidéo, ou plus généralement qu'il s'agit de données faisant partie d'un flux de données temps réel ou d'un flux de données de très grande taille ou encore que ces données ont un caractère d'envoi cyclique. La description de données peut également comprendre des caractéristiques techniques concernant les données telles que par exemple la fréquence d'échantillonnage pour des données audio. Les routeurs pourront alors traiter - en particulier router - les paquets IP non seulement en fonction de la seule adresse IP de destination placée dans leur en-tête, mais aussi en fonction de la nature des données utiles transportées et de ces autres caractéristiques techniques. Le routeur peut notamment utiliser l'équipement le plus adapté pour traiter le type de données concerné. Par exemple, le routeur ou les équipements connectés à lui peuvent utiliser l'algorithme le plus adéquat pour évaluer la qualité de service fournie à l'utilisateur finale pour le flux audio concerné. Par exemple, le routeur peut sélectionner une carte spécifique de gestion de flux audio pour réaliser de la compression à la volée et à la demande dans le cas de données audio, ou encore pour fusionner plusieurs flux audio et vidéo lors d'une conférence sur IP. Par ailleurs, la description de données 1 3 peut être complétée - ou remplacer - avec des informations concernant la source des données ou le destinataire des données autres que leur adresse IP dans le réseau. A titre d'exemple, il peut s'agir du nom patronymique ou de la dénomination sociale de la source et/ou du destinataire. Par conséquent, le routeur peut traiter les paquets en tenant compte de cette information. En particulier, le routeur peut router les paquets en fonction de règles de routage définies pour le destinataire ainsi définie avec la description de données 13. Par exemple, il peut préférentiellement envoyer des paquets transportant une image vers une des machines du destinataire qui présente un afficheur adapté pour l'afficher, indépendamment de l'adresse IP de destination spécifiée dans l'entête IP du ou des paquets concernés. Enfin, la description de données 1 3 peut encore inclure des informations concernant le traitement à effectuer par les routeurs traversés, notamment des informations relatives à la qualité de service QoS (de l'anglais « Quality of Service ») à fournir. Par exemple, une telle information peut être la bande passante à réserver à ces paquets de données. Il peut encore s'agir de paramètres de routage, par exemple, un chemin de routage préférentiel défini par l'émetteur des données, en l'occurrence, le terminal 2. Il est avantageux que les descriptions de données 13 placés dans les paquets IP soient écrits en XML. En effet, une description 13 en XML peut être interprétée par la plupart des routeurs, le schéma XML utilisé pour la description pouvant être recherché sur le réseau par exemple à une adresse prédéterminée de celui-ci. Ce schéma peut être ensuite interprété par le routeur pour construire une représentation interne des informations contenues dans le document XML. A titre d'exemple, un descriptif associé à des données du type voix, peut être rédigé en XML de la façon suivants : <flow xmlns=«http://www.alcatel.com/Routing/Flow/Voice»> <source> <user> Durand </user> </source> < destination > <user> Dupond </user> </destination> <sampling> 8kbits </sampling> <direction> full-duplex </direction> Cette description spécifie le contenu de type voix (« Voice »), le nom patronymique de l'émetteur (« Durand ») et du destinataire (« Dupond »), l'échantillonnage (« δkbits ») et la direction de l'échange (« full-duplex »). En fonction de ces informations, les routeurs sont à même de réaliser un routage adapté, en associant aux paquets une taille de mémoire tampon suffisante pour absorber les effets de gigues qu'on peut rencontrer dans le réseau, ou bien en choisissant une route ou une priorité des paquets en fonction de l'identité des destinataires et émetteurs. Les différents champs d'une telle descriptif sont de préférence normalisés. Un identifiant 14 associé à ce descriptif peut par exemple prendre la forme d'un code alphanumérique tel que « voice ». L'on comprendra que les descriptions de données peuvent aussi être écrites sous une forme codée au lieu d'être proche d'un langage naturel plus directement compréhensible par l'homme comme le permet XML. Bien entendu, la présente invention n'est pas limitée aux exemples et modes de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. Bien qu'on ait décrit auparavant des paquets contenant une description 1 3 et/ou un identifiant 14, il est bien clair que l'invention s'applique également à des paquets munis de plusieurs descriptions 13 et/ou identifiants 14. Par ailleurs, les premier et deuxième modes de réalisation de l'invention décrits plus haut peuvent être mis en œuvre sans que la description de données 1 3 ni l'identifiant de description 14 ne soient inscrits dans l'en-tête IP du paquet, ni même que l'en-tête IP contienne une quelconque information indiquant que le paquet contienne une description 1 3 et/ou un identifiant 14. A titre d'exemple, la figure 5 illustre un exemple de mise en œuvre du premier mode de réalisation dans lequel un la description 1 3 est placée dans le corps 1 2 d'un paquet IP 1 6 alors que son en-tête IP 1 1 est du type conventionnel. En l'occurrence, le corps 12 contient à la fin de celui- ci un code d'identification prédéterminé 1 6 servant à indiquer à un routeur recevant le paquet le fait qu'il contient une description 13. Le corps 1 2 contient immédiatement avant le code d'identification 1 6 une valeur 1 7 indicative de la longueur de la description 1 3 dans le paquet 1 6. La description 1 3 est placée dans le corps immédiatement avant la valeur 17. Le reste du corps 12 contient les données utiles à transporter. Lorsqu'un routeur reçoit un paquet IP, il lui suffit de lire la fin du paquet pour vérifier la présence du code 1 2. Dans l'affirmative, il lit ensuite la valeur 1 7. Ensuite, le routeur lit la description 1 3 contiguë à la valeur 1 7 dans le paquet 1 6 et délimitée par la longueur définie par la valeur 1 7. Ensuite, le routeur traite le paquet comme décrit précédemment. Bien évidemment, le deuxième mode de réalisation peut être mis en œuvre de façon similaire, avec l'identifiant 14 qui vient en remplacement de la description 13 dans le corps 1 2. Un code 1 7 spécifique prédéterminé peut être définie au cas où le corps 1 2 contient à la fois la description 1 3 et l'identifiant 14. Dans ce cas, le code 1 7 peut être précédé par une valeur 1 7 indicative de la longueur de la description 13 dans le paquet 1 6, puis une autre valeur 1 7a indicative de la longueur de l'identifiant 14 dans le paquet 1 6, puis de la description 1 3 et enfin de l'identifiant 1 -. Dans une telle mise en œuvre du premier et du deuxième mode de réalisation, la description 13 et/ou l'identifiant 14 sont écrits dans un langage indépendant des protocoles des couches OSI 5 à 7. Ainsi, les routeurs sont capables de lire la description et l'identifiant 14 quel que soit les protocoles des couches OSI 5 à 7. Bien que les différents modes de réalisations aient été décrit pour des paquets au protocole IP, l'on comprendra que l'invention peut être mise en œuvre similairement avec d'autres protocoles de la couche OSI 3 (dite couche réseau). La mise en œuvre de l'invention à l'aide des en-têtes au niveau de la couche OSI 3 est préférée car les nœuds sont classiquement prévus pour router les paquets grâce à ce protocole. Mais l'invention peut aussi être mise en œuvre au niveau des en-têtes des protocoles de la couche OSI 4 (dite couche transport) dans le cas où il est possible d'y inscrire la description de données 13 et/ou l'identifiant 14 et que les nœuds ont la capacité de traiter ce protocole ou ces protocoles s'il y en a plusieurs utilisées au sein du même réseau. Concernant la mise en œuvre du protocole IPv4, l'on peut se reporter notamment au document RFC 791 . Concernant la mise en œuvre du protocole IPvό, l'on peut se reporter notamment au document RFC 2460. Concernant le modèle de référence OSI, l'on peut se reporter notamment à la norme ISO 7498.

Claims

REVENDICATIONS
1 . Procédé de fonctionnement d'un nœud d'un réseau de communication par paquets, en particulier d'un routeur IP, comprenant les étapes de : a) réception par le nœud d'un paquet (10 ; 10a) depuis le réseau ; b) réception par le nœud d'une information (13) indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes : - le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et - le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet ; c) traitement du paquet (10 ; 10a) par le nœud en fonction de ladite description.
2. Procédé selon la revendication 1 , caractérisé en ce que l'information reçue dans l'étape b) est indépendante des protocoles des couches OSI 4 à 7 du paquet.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite information (1 3) est contenue dans le paquet (10), l'étape b) comprenant la lecture de ladite information dans le paquet par le nœud.
4. Procédé selon la revendication 3, caractérisé en ce que ladite information (1 3) est contenue dans l'en-tête ( 1 1 ) au protocole de la couche OSI 3 du paquet (1 0), l'étape b) comprenant la lecture par le nœud de ladite information dans l'en-tête au protocole de la couche OSI 3 du paquet.
5. Procédé selon la revendication 1 ou 2, caractérisé en ce que le paquet (10a) contient un identifiant ( 14) de ladite information, l'étape a) comprenant la lecture de l'identifiant par le nœud.
6. Procédé selon la revendication 5, caractérisé en ce que l'identifiant (14) est contenu dans l'en-tête ( 1 1 ) au protocole de la couche OSI 3 du paquet (10a), l'étape a) comprenant la lecture par le nœud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 du paquet.
7. Procédé selon la revendication 5 ou 6, caractérisé en ce que l'étape b) comprend la réception par le nœud d'un autre paquet (1 5a ; 15b) depuis le réseau, ledit autre paquet contenant ladite information (1 3).
8. Procédé selon la revendication 7, caractérisé en ce que ladite information ( 13) est contenue dans l'en-tête (1 1 ) au protocole de la couche OSI 3 dudit autre paquet (1 5a), l'étape b) comprenant la lecture par le nœud de ladite information dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet.
9. Procédé selon la revendication 7, caractérisé en ce que ladite information (1 3) est contenue dans le corps (1 2) selon le protocole de la couche OSI 3 dudit autre paquet (15b), l'étape b) comprenant la lecture par le nœud de ladite information dans le corps selon le protocole de la couche OSI 3 dudit autre paquet.
10. Procédé selon la revendication 7, 8 ou 9, caractérisé en ce que ledit autre paquet (15a ;15b) contient en outre l'identifiant (14), l'étape b) comprenant la lecture par le noeud de l'identifiant dans ledit autre paquet-
1 1 . Procédé selon la revendication 10, caractérisé en ce que l'identifiant (14) est contenu dans l'en-tête (1 1 ) au protocole de la couche OSI 3 dudit autre paquet ( 1 5a ; 15b), l'étape b) comprenant la lecture par le nœud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet.
12. Procédé selon la revendication 1 0 ou 1 1 , caractérisé en ce qu'il comprend après l'étape b), une étape de : - envoi par le nœud vers une base de données (21 ) de l'identifiant (14) et de ladite information.
13. Procédé selon la revendication 5 ou 6, caractérisé en ce qu'il comprend après l'étape a) et avant l'étape b), une étape de : - interrogation par le nœud d'une base de données (21 ) avec l'identifiant (14).
14. Paquet de données (10) pour un réseau de communication par paquets, comprenant une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes : - le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et - le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet.
1 5. Paquet de données selon la revendication 14, caractérisé en ce que ladite information est indépendante des protocoles des couches OSI 4 à 7 du paquet.
16. Paquet de données selon la revendication 14 ou 1 5, caractérisé en ce que ladite information est contenue dans l'en-tête (1 1 ) au protocole de la couche OSI 3 du paquet.
1 7. Paquet de données selon la revendication 1 ό, caractérisé en ce que le paquet est au protocole IP, ladite information étant contenue dans l'en-tête IP.
18. Générateur de paquets tels que définis par l'une quelconque des revendications 14 à 1 7.
EP04767614A 2003-07-11 2004-07-08 Description de contenu de paquets dans un reseau de communication par paquets Withdrawn EP1647125A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0308524A FR2857539B1 (fr) 2003-07-11 2003-07-11 Description de contenu de paquets dans un reseau de communication par paquets
PCT/FR2004/001781 WO2005008992A1 (fr) 2003-07-11 2004-07-08 Description de contenu de paquets dans un reseau de communication par paquets

Publications (1)

Publication Number Publication Date
EP1647125A1 true EP1647125A1 (fr) 2006-04-19

Family

ID=33522971

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04767614A Withdrawn EP1647125A1 (fr) 2003-07-11 2004-07-08 Description de contenu de paquets dans un reseau de communication par paquets

Country Status (5)

Country Link
US (1) US20060221929A1 (fr)
EP (1) EP1647125A1 (fr)
CN (1) CN1836421A (fr)
FR (1) FR2857539B1 (fr)
WO (1) WO2005008992A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7471669B1 (en) * 2004-09-30 2008-12-30 Nortel Networks Limited Routing of protocol data units within a communication network
KR20120019475A (ko) * 2009-05-08 2012-03-06 세이블 네트웍스 인코포레이티드 데이터 통신 세션을 제어하기 위한 방법 및 장치
US8711743B2 (en) 2010-06-17 2014-04-29 Iminds Vzw Node and wireless sensor network comprising the node
CN103401877A (zh) * 2013-08-09 2013-11-20 上海斐讯数据通信技术有限公司 获取驱动层数据包控制信息的方法及系统
US11055222B2 (en) * 2019-09-10 2021-07-06 Mellanox Technologies, Ltd. Prefetching of completion notifications and context

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6275861B1 (en) * 1996-09-27 2001-08-14 Pmc-Sierra, Inc. Method and apparatus to identify flows in data systems
US6226680B1 (en) * 1997-10-14 2001-05-01 Alacritech, Inc. Intelligent network interface system method for protocol processing
US6188674B1 (en) * 1998-02-17 2001-02-13 Xiaoqiang Chen Method and apparatus for packet loss measurement in packet networks
US7058027B1 (en) * 1998-09-16 2006-06-06 Scientific Research Corporation Systems and methods for asynchronous transfer mode and internet protocol
US6389468B1 (en) * 1999-03-01 2002-05-14 Sun Microsystems, Inc. Method and apparatus for distributing network traffic processing on a multiprocessor computer
US6356951B1 (en) * 1999-03-01 2002-03-12 Sun Microsystems, Inc. System for parsing a packet for conformity with a predetermined protocol using mask and comparison values included in a parsing instruction
US6704794B1 (en) * 2000-03-03 2004-03-09 Nokia Intelligent Edge Routers Inc. Cell reassembly for packet based networks
US7218632B1 (en) * 2000-12-06 2007-05-15 Cisco Technology, Inc. Packet processing engine architecture
US20020126672A1 (en) * 2001-01-10 2002-09-12 Nelson Chow Method and apparatus for a flexible and reconfigurable packet classifier using content addressable memory
US20020181400A1 (en) * 2001-05-30 2002-12-05 Nokia Corporation Method of communicating a flow of data packets across a network
US20020188871A1 (en) * 2001-06-12 2002-12-12 Corrent Corporation System and method for managing security packet processing
JP3489573B2 (ja) * 2001-07-11 2004-01-19 日本電気株式会社 パケット処理装置
FR2827726B1 (fr) * 2001-07-19 2003-12-19 Cit Alcatel Prise en compte d'informations relatives a l'environnement des noeuds actifs pour la determination du code associe a une application active
US7236488B1 (en) * 2001-08-10 2007-06-26 Gautam Kavipurapu Intelligent routing switching system
US20030084186A1 (en) * 2001-10-04 2003-05-01 Satoshi Yoshizawa Method and apparatus for programmable network router and switch
US7573876B2 (en) * 2002-12-05 2009-08-11 Intel Corporation Interconnecting network processors with heterogeneous fabrics
US7460531B2 (en) * 2003-10-27 2008-12-02 Intel Corporation Method, system, and program for constructing a packet

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005008992A1 *

Also Published As

Publication number Publication date
FR2857539B1 (fr) 2005-09-30
US20060221929A1 (en) 2006-10-05
FR2857539A1 (fr) 2005-01-14
CN1836421A (zh) 2006-09-20
WO2005008992A1 (fr) 2005-01-27

Similar Documents

Publication Publication Date Title
EP3087701B1 (fr) Procede de diagnostic de fonctions service dans un reseau ip
EP2064853B1 (fr) Procédé d&#39;optimisation du contrôle du trafic dans un réseau de télécommunication par paquets
EP2793431B1 (fr) Méthode distribuée d&#39;acquisition de données dans un réseau afdx
FR2857538A1 (fr) Systeme et methode de compression d&#39;en-tete de paquets bases sur la creation dynamique d&#39;un gabarit
FR2909241A1 (fr) Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d&#39;interconnexion de reseaux.
EP2436155B1 (fr) Procédé de gestion de chemins entre un noeud source et un noeud destinataire au niveau de la couche de liaison, noeud source et table correspondants
CN107231269B (zh) 一种集群精确限速方法和装置
FR2954029A1 (fr) Procede de transmission de paquets d&#39;un flux de donnees bidirectionnel passager, dispositif gestionnaire, produit programme d&#39;ordinateur et moyen de stockage correspondants
US20060106583A1 (en) Method for protocol recognition and analysis in data networks
EP3637845B1 (fr) Procédé de communication basé sur un protocole de transmission par trames
WO2005008992A1 (fr) Description de contenu de paquets dans un reseau de communication par paquets
EP2469793B1 (fr) Dispositif de transmission de paquets de données, et procédé, programme d&#39;ordinateur et moyens de stockage correspondants
EP1432210B1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d&#39;un reseau de communications
WO2008145901A1 (fr) Procede et dispositif d&#39;interface entre les protocoles udp ou tcp et sctp
FR2845544A1 (fr) Support actif de reservation de ressources dans un reseau de communication
EP1447948A2 (fr) Requête à traitement anticipé pour un routeur actif
EP1427167A2 (fr) Dispositif d&#39;accés à un réseau de télécommunication pour la dégradation sélective des flots de données
EP4142251A1 (fr) Procede de traitement d&#39;une requete d&#39;interet dans un reseau ndn
EP3146681B1 (fr) Procédé de distribution pour une liaison à liens multiples et hétérogènes
FR2873254A1 (fr) Encapsulation pour paquets a adresses etendues compatibles avec des pare-feux existants
WO2022200703A1 (fr) Emission d&#39;un signal par un premier composant electronique d&#39;un vehicule a destination d&#39;au moins un second composant electronique du vehicule
FR3100908A1 (fr) Procédé de communication entre des entités logicielles via une API
WO2019020582A1 (fr) Adressage pour réseau de télécommunications utilisant la multidiffusion
FR2951045A1 (fr) Procede de gestion de la taille de paquets de donnees d&#39;un flux de donnees, produit programme d&#39;ordinateur, moyen de stockage, et tete de tunnel correspondants.
WO2005086455A2 (fr) Procede, systeme et dispositif de temporisation d&#39;un flux de paquets de donnees

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060213

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ALCATEL LUCENT

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LE MOIGNE, OLIVIER

Inventor name: MARCE, OLIVIER

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100202