EP2695408A1 - Procédé et dispositif d'optimisation du routage d'un flux - Google Patents

Procédé et dispositif d'optimisation du routage d'un flux

Info

Publication number
EP2695408A1
EP2695408A1 EP12713071.4A EP12713071A EP2695408A1 EP 2695408 A1 EP2695408 A1 EP 2695408A1 EP 12713071 A EP12713071 A EP 12713071A EP 2695408 A1 EP2695408 A1 EP 2695408A1
Authority
EP
European Patent Office
Prior art keywords
stream
intermediate server
nodes
lma
routing
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
EP12713071.4A
Other languages
German (de)
English (en)
Inventor
Michael BOC
Christophe Janneteau
Alexandru Petrescu
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.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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 Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Publication of EP2695408A1 publication Critical patent/EP2695408A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/082—Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the invention lies in the field of telecommunication networks and more particularly relates to a method and a device for optimizing the routing of a stream exchanged between two nodes in a telecommunication network in which, during a connection to the network, each node connects to an access router connected to a central entity adapted to define a path for said stream.
  • the invention is particularly but not exclusively applicable to a Mobile IPv6 Proxy Domain ( ⁇ ) and / or Mobile IPv4 / NEMOv4 and / or Mobile IPv6 / NEMOv6 Domain.
  • a mobility management protocol aims to manage the movement of mobile devices and to prevent their communications from being lost when they change their access point to the network.
  • the IPv6 address the Internet identifier
  • the IPv6 address of a client is likely to change with each (re) -connection to the network; a communication being defined explicitly by a software interface, called socket in English, fixed between two IPv6 addresses, any communication will be lost if one of the addresses changes.
  • the Internet Engineering Task Force specifies the mobility management protocol ⁇ (for Mobile Proxy IPv6) according to which all customer mobility management is done by the network only. Management is therefore transparent to customers.
  • Other protocols such as MIPv6 (for Mobile IPv6) require active participation of the customers, for example by exchanging signaling messages with the entities making up the mobility management protocol.
  • node designate a piece of equipment of a client that connects to the network such as, for example, a laptop, a telephone, or any equipment that can communicate via the network.
  • FIG. 1 schematically illustrates an architecture making it possible to manage the mobility of nodes 4 and 6 in a network using the ⁇ protocol.
  • this architecture when the nodes 4 and 6 connect to the network, they are associated, respectively, with an access IP router called MAG 8 (for Mobile Access Gateway in English) and an access IP router called MAG 10.
  • MAG 8 for Mobile Access Gateway in English
  • MAG 10 access IP router
  • the MAG 8 and 10 and all the other MAGs to which the nodes 4 and 6 will connect during a session, will always emulate the same access (same IP address, same signaling message, etc.) in order to make transparent any change of association at the IP level.
  • each MAG 8 and 10 records the position of the node that is associated by sending a message PBU (for proxy binding update, in English) to a central entity called LMA (for Local Mobility Anchor, English) 12.
  • LMA for Local Mobility Anchor, English
  • This central entity transmits back a message PBA (for proxy binding acknowledgment , in English) to the MAG 8 (respectively 10) to validate the support of this node and assign it an IPv6 address which will remain valid as long as the communication session remains active. All communications to and from this node then transit through a bidirectional tunnel respectively 14, 16 that LMA 12 and MAG 8 (respectively 10) establish between them.
  • An object of the invention is to overcome the disadvantages of the prior art described above.
  • the objects of the invention are achieved by means of a mechanism for forcing the passage of a data stream by one or more intermediate servers (s) when a routing optimization procedure is triggered, in particular, in a network using the Mobile IPv6 Proxy protocol and / or the Mobile IPv4 / NEMOv4 protocol and / or the Mobile IPv6 / NEMOv6 protocol.
  • This is obtained by a method of optimizing the routing of a flow exchanged between two nodes in a telecommunications network in which, during a network connection, each node connects to an access router connected to a central entity adapted to define a path for said stream.
  • the method according to the invention comprises a step of rerouting said stream under the control of the operator so as to pass said stream via at least one intermediate server selected by the operator and to prevent said flow systematically going through said central entity.
  • the method according to the invention allows the operator to have control over the traffic. It can thus choose to divert traffic in a less overloaded network area and / or apply specific processing (eg filtering, listening, resource reservation, pricing).
  • each intermediate server is arranged between said nodes and is able to apply to said stream at least one predefined processing by the operator.
  • said predefined processing comprises at least one of the following functions:
  • the method according to the invention comprises a phase of selection, by the operator, of the processes to be applied to the stream and of one or more intermediate servers able to apply said processes, and a routing configuration phase optimized for this stream. function of predefined treatments.
  • An intermediate server may be a simple router, a MAG, a server, a proxy, or any other entity that can divert traffic and / or apply a specific processing to a stream.
  • the stream can be re-routed through several intermediate servers in cascade.
  • one of these servers may be an LMA.
  • the configuration of the routing consists in creating on each intermediary server the inputs and outputs of at least one tunnel by sending each intermediate server a signaling message comprising information on the IP addresses of the nodes. or the prefixes of the source and destination nodes, the identifiers of the source and destination nodes as well as the IP address of the previous server and the IP address of the next server
  • At least one node connects to an access router connected to a central entity adapted to define, for each access router, an optimized routing table according to the predefined processing by the operator in each intermediate server.
  • the method according to the invention is applied in an IP type network to fixed access routers.
  • the method according to the invention applies in an IP type network to mobile access routers.
  • the central entity creates the inputs and outputs of the tunnels on each intermediate server by sending each intermediate server a signaling message comprising information on the IP addresses of the nodes, the prefix or prefixes of the source and destination nodes, the identifiers of said source and destination nodes as well as the IP address of the previous server and the IP address of the next server. Said central entity retransmits said signaling message if no response is received during a predefined waiting time.
  • the method according to the invention is implemented by a device
  • each intermediate server comprises at least one module performing at least one of the following functions data as a non-limitative example:
  • This device also comprises a central entity capable of creating on each intermediate server the inputs and outputs of at least one tunnel by sending each intermediate server a signaling message comprising information on the IP addresses of the nodes, the prefix or prefixes of the nodes. source and destination nodes, the identifiers of the source and destination nodes as well as the IP address of the previous server and the IP address of the next server.
  • the steps of the method according to the invention are carried out by the instructions of a computer program recorded on a storage medium when it is executed on a computer.
  • FIG. 1 previously described, schematically illustrates an architecture making it possible to manage the mobility of two nodes in a network using the ⁇ protocol
  • FIG. 2 illustrates a first variant embodiment of the invention in a ⁇ domain
  • FIG. 3 schematically illustrates a second variant embodiment of the invention in a ⁇ domain
  • FIG. 4 schematically illustrates a third embodiment of the invention in a ⁇ domain
  • FIG. 5 schematically illustrates a fourth variant embodiment of the invention in a Mobile IPv4 / NEMOv4 or Mobile IPv6 / NEMOv6 domain
  • FIG. 6 illustrates the routing configuration procedure, according to the invention, of an exchanged stream, via two intermediate servers between two nodes,
  • FIG. 7 shows the update of tunnels established between the nodes during the routing configuration procedure of FIG. 6,
  • FIG. 8 schematically illustrates an embodiment of the invention in the case where the nodes that exchange the data stream are attached to different LMAs.
  • FIG. 9 illustrates the exchanges of messages between the various elements of FIG. 8 to achieve optimized routing
  • FIG. 10 schematically illustrates the format of an LRI message
  • FIG. 11 illustrates an example of organization of the options, according to the invention, to determine how to create its two tunnels
  • FIG. 12 schematically illustrates the format of an LRA message
  • Figure 13 illustrates the steps for routing optimization between two mobile routers ⁇ .
  • FIG. 2 illustrates a first variant embodiment of the invention in a domain ⁇ in which two nodes that are topologically close, namely a source node 4 and a destination node 6, are respectively associated with a MAG 8 and a MAG 10 when an IP session.
  • a first tunnel 20 is established between the MAG 8 of the source node 4 and an intermediate server 22 and a second tunnel 24 established between this intermediate server 22 and the MAG 10 of the destination node 6.
  • the intermediate server 22 is configured to apply to the flows exchanged between the nodes 4 and 6 a set of predefined services dictated by requirements, for example legal and / or economic, or others.
  • the intermediate server 22 comprises a first module 25 which is intended to apply a certain level of quality of service, a second module 26 intended to apply traffic filtering in order to block any reprehensible content, and a third module 27 intended to to duplicate the stream in order to listen to voice communications, for example.
  • FIG. 3 schematically illustrates a second variant embodiment of the invention in a domain ⁇ in which the first, second and third modules 25, 26, 27 are not hosted on the same intermediate server.
  • the first module 25 is hosted on a first intermediate server 30
  • the second module 26 is hosted on a second intermediate server 31
  • the third module 27 is hosted on a third intermediate server 32.
  • four tunnels 33, 34, 35 and 36 are established on the path that this stream must traverse respectively between the MAG 8 and the first intermediate server 30, the first intermediate server 30 and the second intermediate server 31, the second intermediate server 31 and the third intermediate server 32, the third intermediate server 32 and the MAG 10.
  • at least one of the intermediate servers 30, 31 and 32 may be an LMA.
  • the stream can be re-routed to one or more intermediate servers that can provide the same service or several different services.
  • FIG. 4 diagrammatically illustrates a third embodiment of the invention in a ⁇ domain in which the nodes connect through femtocells or Wi-Fi residential routers.
  • a femtocell is an access point providing very limited cellular connectivity (an apartment, an office floor, etc.) and sending traffic to the femtocell proprietary operator over an Internet connection.
  • the path taken by the data between a femtocell and the proprietary cellular operator can traverse a series of networks belonging to other operators.
  • a femtocell is considered to be a combination of a cellular access point and a MAG.
  • an optimized routing between two femtocells can in certain situations not go through the network of the operator.
  • the owner operator of the femtocells installs an intermediate server in the network of another operator near the nodes. Traffic between two nodes can then be re-routed by this intermediate server.
  • two nodes 4 and 6 respectively attached to two femtocells 40 and 42 of an operator A exchange a multimedia stream.
  • the stream is re-routed from the femtocell 40 through a first tunnel 46 to an intermediate server 44 hosted in the network of an operator B, then transmitted from the intermediate server 44. to the second femtocell 42 through a second tunnel 48.
  • the operator A can then apply the scheduled processing in the intermediate server 44.
  • FIG. 5 schematically illustrates a fourth variant embodiment of the invention in a Mobile IPv4 / NEMOv4 or Mobile IPv6 / NEMOv6 domain in which the nodes 4 and 6 connect through an intermediate server 58 used as a point of access. passage for direct traffic between two mobile routers 52 and 54.
  • a mobile router is a device with several network interfaces that moves with a set of other equipment and manages the mobility of this set of equipment. These are not affected by mobility events. This is the case, for example, of a mobile router installed on a train that connects to the Internet with an LTE (Long Term Evolution) interface, and which offers access to the network to passenger equipment via its WiFi interface; passenger equipment that does not implement a mobility protocol.
  • LTE Long Term Evolution
  • an HA (for Home Agent) 56 fulfills for the routers 52, 54 the function of the LMA 12 for the MAGs 8 and 10.
  • the traffic between the two mobile routers 52 and 54 can be re-routed through one or more intermediate servers and thus avoid the passage through the Home Agent 56. This may offer the flow a shorter route than the passage through the HA 56.
  • the passage through the intermediate servers 58 to the advantage of offering the network operator the opportunity to increase services offered by applying to the stream the scheduled processes in this intermediate server 56.
  • the application of the optimization procedure according to the invention comprises the three phases:
  • a detection of the need to optimize the routing results for example, from the fact that an LMA or HA of a destination node receives a first data packet indicating the establishment of a call.
  • the operator can also configure optimized routing only if the node (s) will not be mobile for some time using a prediction algorithm.
  • the operator may also decide to allow optimized routing only for a certain type of traffic, again only after a certain period of time.
  • the operator can change or disable an optimized path at any time.
  • the operator must indicate to the LMA configuration or dynamically a list of intermediate servers, their IPv6 addresses and the services provided by each of them. These servers must be authenticated by the LMA.
  • the list of services to apply to a stream, and therefore the list of Intermediate servers to cross may depend on the choice of the operator and / or options subscribed by each customer.
  • the first step in this phase is to create tunnel inputs and outputs on each intermediate server with parameters for the IPv6 address information of the nodes.
  • the LMA or the HA will initiate the creation of a tunnel by sending each intermediate server a signaling message "localized routing initiation" or LRI.
  • An LRI message will indicate the prefix (es) of the source and destination nodes, their identifiers as well as the IPv6 address of the previous server and the IPv6 address of the next server (MAG or intermediary server), and possibly the prefixes of the nodes served by routers mobile.
  • Each intermediate server returns a validation message "localized routing acknowledgment" or LRA.
  • FIG. 6 illustrates the procedure for configuring the routing of an exchanged stream, via two intermediate servers 60, 62, between the source node 4 and the source node 6 associated respectively with the first MAG 8 and the second MAG 10 during a session in a network with LMA 12.
  • Steps 62 to 68 illustrate data exchanges prior to routing optimization.
  • step 62 the source node 4 transmits the stream to the MAG 8 to which it is associated during the session.
  • the MAG 8 transmits the stream to the LMA 12. The latter transmits said stream to the MAG 10 which sends it to the destination node 6.
  • Steps 70 to 84 illustrate the configuration phase of the optimized routing according to the invention.
  • step 70 the LMA 12 transmits to the intermediate server 60 an LRI_SI60 message indicating the prefix or prefixes of the source 4 and destination 6 nodes, their identifiers and the IPv6 address of the MAG 8 and the IPv6 address of the intermediate server. 62.
  • step 72 the intermediate server 60 sends the LMA 12 an acknowledgment message LRA_SI60.
  • the LMA 12 transmits to the intermediate server 62 a LRI_SI62 message indicating the prefix or prefixes of the source 4 and destination 6 nodes, their identifiers as well as the IPv6 address of the MAG 10 and the intermediate server IPv6 address 60 .
  • step 76 the intermediate server 60 sends the LMA 12 an acknowledgment message LRA_SI62.
  • the LMA 12 creates the exit and input points of the tunnels on the MAGs 8 and 10.
  • An entry / exit point is to be created on the first MAG 8 to the first intermediate server 60 and on the second MAG 10 to the second intermediate server 62 according to the following steps.
  • step 78 the LMA 12 transmits to the MAG 8 a LRI_MAG8 message indicating the prefix or prefixes source 4 and destination nodes 6, their identifiers as well as the IPv6 address of the intermediate server 60.
  • step 80 the MAG 8 sends the LMA 12 an acknowledgment message LRA_MAG8.
  • the LMA 12 transmits to the MAG 10 a LRI_MAG10 message indicating the prefix or prefixes of the source nodes 4 and destination 6, their identifiers and the IPv6 address of the intermediate server 62.
  • step 84 the MAG 10 sends the LMA 12 an acknowledgment message LRA_MAG10.
  • Steps 90 to 98 illustrate the data exchanges after routing optimization.
  • step 90 the source node 4 transmits the stream to the MAG 8.
  • the latter transfers, at the step 92, the stream received to the intermediate server 60 via the tunnel configured during the preceding phase.
  • step 94 the intermediate server 60 sends the received stream to the intermediate server 62.
  • the latter transfers, in step 96, the stream received at the MAG 10 via the tunnel configured during the previous phase.
  • step 98 the MAG 10 sends the stream to the destination node 6.
  • the sending sequence of LRI messages can be done at a different timing without departing from the scope of the invention.
  • the LMA 12 can be configured, for example, to send the LRI messages to the MAGs 8 and 10 before sending them to the intermediate servers 60, 62, or to send everything in parallel.
  • the sequence shown in FIG. 6 of configuring intermediate servers 60, 62, then MAGs 8, 10 is preferred. because it makes it possible to ensure the availability and the good configuration of the set of intermediary servers forming the optimized routing path before configuring the MAGs so that the flow of data imprints this optimized routing path.
  • the new MAG 100 when the source node 4 moves from the MAG 8 to a new MAG 100, that is to say, during a change of association of the node 4 due to a displacement in the network for example, the new MAG 100 records the position of the node to the LMA 12, and the reception of the signaling message PBU (for proxy binding update, in English), the update of the tunnels follows the described procedure in Figure 7.
  • PBU proxy binding update
  • step 102 the new MAG 100 transmits a PBU (for proxy binding update, in English) to the LMA 12 to record the new position of the node 6.
  • PBU proxy binding update
  • step 104 the LMA sends a message LRI_SI62 to the second intermediate server 62 with IPv6 address of the MAG 100 to which the node 6 is now connected so that the intermediate server 62 updates its routing configuration in such a way that the traffic address at node 6 is now tunnelled to MAG 100 (rather than MAG8 as initially).
  • step 106 the second intermediate server 62 sends the LMA 12 an acknowledgment message LRA_SI62.
  • step 108 the LMA 12 transmits back a PBA message (for proxy binding acknowledgment, in English) to the new MAG 100.
  • the LMA 12 sends the new MAG 100 a LRI_MAG100 message indicating the prefix or prefixes of the nodes 4 and 6, their identifiers and the IPv6 address of the intermediate server 62, so that the new MAG 100 puts in place the optimized routing via the intermediate server 62.
  • step 112 the new MAG 100 sends the LMA 12 an acknowledgment message LRA_MAG100.
  • the new MAG 100 replaces the MAG 8 in steps 90 to 98 of the optimized routing.
  • FIG. 8 schematically illustrates an embodiment of the invention in the case where the nodes 4 and 6 which exchange the data stream are attached respectively to a first LMA 120 and to a second LMA 122 different from the first LMA 120 belonging to two distinct ⁇ domains.
  • the MAG 8 to which node 4 is attached transmits the data stream, via a first tunnel 124, to a first intermediate server 126 controlled by the first LMA 120.
  • the intermediate server 126 transmits the received stream via a second tunnel 128 to a second intermediate server 130 controlled by the second LMA 122.
  • the second intermediate server 130 transmits the received stream, via a third tunnel 132, MAG 10 which is attached node 6.
  • the routing optimization procedure can be initiated by one of the two LMAs 120 or 122. These two LMAs exchange specific information in order to know in advance the entry and exit points of the tunnel 128 connecting the intermediate servers 126 and 128. 130 managed by these two LMAs 120 and 122 respectively.
  • Figure 9 illustrates the message exchanges between the different elements of Figure 8 to achieve optimized routing.
  • Steps 140 to 148 illustrate data exchanges before routing optimization.
  • step 140 the source node 4 transmits the stream to the MAG 8 to which it is associated during the session.
  • step 142 the MAG 8 transmits the stream to the first LMA 120.
  • the latter transmits, at the step 144, said stream to the second LMA 122.
  • step 146 the second LMA 122 transmits the stream to the MAG 10 with which the destination node 6 is associated.
  • step 148 the MAG 10 transmits the stream to the destination node 6.
  • Steps 150 to 172 illustrate the configuration phase of the optimized routing according to the invention.
  • step 150 the first LMA 120 transmits to the second LMA 122 a message RO_init conveying information relating to the intermediate server 126.
  • step 152 the second LMA 122 transmits to the first LMA 120 an acknowledgment message RO_init_ack conveying information relating to the intermediate server 130.
  • the LMA 120 transmits to the intermediate server 126 an LRI_SI126 message indicating the prefix or prefixes of the source 4 and destination 6 nodes, their identifiers and the IPv6 address of the MAG 10 and the IPv6 address of the intermediate server. 130.
  • step 156 the intermediate server 126 sends the LMA 120 an acknowledgment message LRA_SI126.
  • the LMA 122 transmits to the intermediate server 130 a LRI_SI130 message indicating the prefix or prefixes of the source node 4 and destination 6, their identifiers as well as the IPv6 address of the MAG 10 and the IPv6 address of the intermediate server 126.
  • step 160 the intermediate server 130 sends the LMA 122 an acknowledgment message LRA_S 1130.
  • step 162 the LMA 120 sends a message LRI_MAG8 to the MAG 8.
  • step 164 the MAG 8 sends the LMA 120 an acknowledgment message LRA_ MAG8.
  • step 166 the LMA 122 sends a LRI_MAG10 message to the MAG 10.
  • step 168 the MAG 10 sends the LMA 122 an acknowledgment message LRA_ MAG10.
  • step 170 the first LMA 120 transmits to the second LMA 122 a RO_ack message confirming the implementation of the first branch of the optimized routing via the MAG 8 and the intermediate server 126 managed by the first LMA 120.
  • step 172 the second LMA 122 transmits to the first LMA 120 a RO_ack message confirming the establishment of the second branch of the optimized routing via the intermediate server 130 and the MAG 10 managed by the second LMA 122.
  • Steps 180 to 188 illustrate the steps of the optimized routing after the routing configuration performed by steps 150 to 172.
  • step 180 the source node 4 transmits the stream to the MAG 8.
  • the latter transmits (step 182) the stream received to the intermediate server 126 which in turn transmits it (step 184) to the intermediate server 130.
  • step 186 the intermediate server 130 transmits the stream to the MAG 10 which in turn transmits it (step 188) to the destination node 6.
  • FIG. 10 schematically illustrates the format of an LRI message.
  • This message includes:
  • Mobility options Suite of options of variable size.
  • the LMA provides all the information needed to detect the flow of customers.
  • the information that must be included is: Client ID 1 (MN1-ID), one or more prefixes (MN1-HNP) assigned to Client 1, Client ID 2 (MN2-ID), one or more prefixes assigned to client 2 (MN2-HNP) and the IPv6 address of the MAG or intermediate server on the other side of the tunnel.
  • the format of the option with the IPv6 address can be based on the packet format "MAG IPv6 address".
  • an intermediate server Upon receipt of an LRI message, an intermediate server first verifies that the bit I is set to 1. Otherwise, the message is ignored. The intermediate server then retrieves the mobility options and establish tunnels to MAGs and / or Sis (intermediate servers). It is important that the options be organized in such a way that the IS can determine how to create its two tunnels. Indeed, there is a sense of communication depending on where the clients are and the IS must correctly update its routing table.
  • Figure 11 shows an example where the options are organized in a specific order.
  • the SI can in this case sequentially interpret the options.
  • the SI to update its routing table for the MN1-ID node, the SI considers the prefix MN1-HNP and transfers the data to the IPv6 address of the IS or MAG.
  • MN2-ID the other communication direction
  • Figure 12 schematically illustrates the format of an LRA message.
  • This message includes:
  • Lifetime bits (16 bits): The time in second of the lifetime of the tunnel. When all bits are 1, the duration is infinite. By default, the value specified in the LRI.
  • the LRI packets may include parameters to indicate to intermediate servers and MAGs the type of processing to be applied to one or more data streams.
  • Intermediate servers can thus provide multiple functionalities / services.
  • LMAs are configurable to dynamically indicate to intermediate servers (during the configuration phase of optimized routing by sending LRI messages) which service it must specifically enable for a given flow.
  • the stream is also indicated in the LRI message.
  • the method according to the invention can be applied to other mobility management protocols.
  • it is also important to reduce the paths traversed by the data between two mobile routers so as not to cross the Home Agent systematically.
  • the Home Agent is then considered as a control point, and is configured by the mobile network operator to define the optimized path (through intermediate servers) that the data flows must take between two mobile routers.
  • This path may include one or more Intermediate Server (s) for implementing services according to the needs of the operator.
  • Figure 13 illustrates the steps for routing optimization between two mobile routers ⁇ .
  • the exchange of messages is similar to that described with reference to FIG. 6, replacing the LMA 12 by the HA 190 (Home Agent), the source nodes 4 and destination 6 respectively by the fixed nodes LFN 200 and 202 (for (Local Fixed Nodes), which may be portable equipment of the passengers of a mobile vehicle respectively connected to the mobile routers MR 204 and 206.
  • two intermediate servers 208 and 210 are defined by the operator.
  • the Home Agent 190 sends "LRI_SI" messages to the Intermediate Servers and "LRI_MR” messages to the Mobile Routers. Once these messages are sent and acknowledged, the data traffic between the two mobile routers 204 and 206 will no longer pass through the HA 190, but through the optimized path through the Intermediate Servers 208 and 210.
  • the LRI_SI and LRI_MR messages comprise information and instructions relating to the addresses of the LFN Clients 200 and 202 respectively connected to the mobile routers 204 and 206.
  • This information can be grouped in the form of a "prefix" covering several valid IPv6 addresses. under the same Mobile Router (it is called mobile network prefix, or MR-MNP "Mobile Network Prefix of a Mobile Router").
  • This MR-MNP information may, for example, be carried in the LRI messages using an option having the same format as the MN-HNP option in Figure 10.
  • the two Home Agents will communicate with each other to allow the establishment of optimized routing via intermediate servers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé d'optimisation du routage d'un flux échangé entre deux nœuds dans un réseau de télécommunications d'un opérateur. Ce procédé comporte une étape consistant à re-router ledit flux via au moins un serveur intermédiaire agencé entre lesdits nœuds apte à appliquer audit flux au moins un traitement prédéfini par l'opérateur.

Description

PROCEDE ET DISPOSITIF D'OPTIMISATION DU ROUTAGE D'UN
FLUX
DESCRIPTION
DOMAINE TECHNIQUE
L' invention se situe dans le domaine des réseaux de télécommunication et concerne plus particulièrement un procédé et un dispositif d'optimisation du routage d'un flux échangé entre deux nœuds dans un réseau de télécommunication dans lequel, lors d'une connexion au réseau, chaque nœud se connecte à un routeur d'accès relié à une entité centrale adaptée pour définir un chemin pour ledit flux.
L'invention s'applique particulièrement mais non exclusivement dans un domaine Proxy Mobile IPv6 (ΡΜΙΡνβ) et/ou Mobile IPv4/NEMOv4 et/ou Mobile IPv6/NEMOv6.
ÉTAT DE LA TECHNIQUE ANTÉRIEURE
Dans un réseau de télécommunication tel que l'Internet, un protocole de gestion de mobilité a pour but de gérer le déplacement des équipements mobiles et d' éviter que leurs communications ne soient perdues quand ils changent de point d'accès au réseau. En effet, sans protocole de gestion de mobilité, l'adresse IPv6 (l'identifiant Internet) d'un client est susceptible de changer à chaque ( re ) -connexion au réseau; une communication étant définie explicitement par une interface logicielle, appelée socket en anglais, figée entre deux adresses IPv6, toute communication sera donc perdue si une des adresses change .
L' IETF (Internet Engineering Task Force) spécifie le protocole de gestion de mobilité ΡΜΙΡνβ (pour Proxy Mobile IPv6) selon lequel toute la gestion de la mobilité des clients se fait uniquement par le réseau. La gestion est donc transparente pour les clients. D'autres protocoles tels que MIPv6 (pour Mobile IPv6) nécessitent une participation active des clients consistant par exemple à échanger des messages de signalisation avec les entités composant le protocole de gestion de mobilité.
Dans le reste de ce document, nous utiliserons le terme nœud pour désigner un équipement d'un client qui se connecte au réseau tel que par exemple un ordinateur portable, un téléphone, ou tout équipement susceptible de communiquer via le réseau.
La figure 1 illustre schématiquement une architecture permettant de gérer la mobilité des nœuds 4 et 6 dans un réseau utilisant le protocole ΡΜΙΡνβ. Dans cette architecture, quand les nœuds 4 et 6 se connectent au réseau, ils se retrouvent associés, respectivement, à un routeur IP d'accès appelé MAG 8 (pour Mobile Access Gateway en anglais) et à un routeur IP d'accès appelé MAG 10. Les MAG 8 et 10 et tous les autres MAGs auxquels les nœuds 4 et 6 se connecteront pendant une session, émulerons toujours le même accès (même adresse IP, même message de signalisation, etc.) afin de rendre transparent toute changement d'association au niveau IP. A cet effet, chaque MAG 8 et 10 enregistre la position du nœud qui lui est associé par l'envoi d'un message PBU (pour proxy binding update, en anglais) à une entité centrale appelée LMA (pour Local Mobility Anchor, an anglais) 12. Cette entité centrale transmet en retour un message PBA (pour proxy binding acknowledgment , en anglais) au MAG 8 (respectivement 10) pour valider la prise en charge de ce nœud et lui assigner une adresse IPv6 qui restera valide tant que la session de communication restera active. Toutes les communications de et vers ce nœud transitent alors par un tunnel bidirectionnel respectivement 14, 16 que le LMA 12 et le MAG 8 (respectivement 10) établissent entre eux.
Du fait que dans cette architecture toutes communications dans le domaine ΡΜΙΡνβ transitent par le LMA 12, il peut arriver que le (s) flux entre deux nœuds proches subissent un détour important en passant par un LMA distant. Il est donc souhaitable d'optimiser le routage du trafic entre les nœuds.
Le document "Localized Routing for Proxy Mobile IPv6, draft-ietf-netext-pmip-lr-01 Octobre 2010" décrit un ensemble de procédures permettant l'optimisation du routage en établissant un tunnel direct entre les MAGs des nœuds.
Avec ce type d'approche, les flux échangés entres les nœuds ne passent plus par le LMA 12. Il devient alors difficile de fournir aux nœuds des services personnalisés à fortes valeurs ajoutées tel que la qualité de service ou de mettre en place des services propres à l'opérateur qui nécessite l'accès au flux (ex. interception légale, inspection de trafic et vérification de sa conformité au contrat, etc.) car ces services de traitements sont localisés dans le LMA. De ce fait, l'opérateur perd globalement en flexibilité.
Le document "Internet Protocol, DARPA Internet Program Protocol Spécification." RFC791. Septembre 1981 décrit la méthode de « source routing » qui est une technique développée dans la spécification d'IPv4, ainsi que dans la spécification d' IPv6 à travers le routing header (de type 0) décrit dans le document "Internet Protocol, Version 6 (IPv6) Spécification." RFC2460, Décembre 1998. Cette méthode permet à un nœud source de définir partiellement ou totalement une séquence de routeurs qu'un flux doit traverser pour atteindre un nœud destination.
Un inconvénient majeur de cette méthode provient du fait que les flux échangés ne sont pas sécurisés dans la mesure où la définition de la séquence de routeurs n' est pas contrôlée par 1 ' opérateur .
Un but de l'invention est de pallier les inconvénients de l'art antérieur décrit ci-dessus.
EXPOSÉ DE L' INVENTION
Les buts de l'invention sont atteints au moyen d'un mécanisme permettant de forcer le passage d'un flux de données par un ou plusieurs serveurs intermédiaire ( s ) quand une procédure d'optimisation de routage est déclenchée, notamment, dans un réseau utilisant le protocole Proxy Mobile IPv6 et/ou le protocole Mobile IPv4/NEMOv4 et/ou le protocole Mobile IPv6/NEMOv6. Ceci est obtenu par un procédé d'optimisation du routage d'un flux échangé entre deux nœuds dans un réseau de télécommunications dans lequel, lors d'une connexion au réseau, chaque nœud se connecte à un routeur d'accès relié à une entité centrale adaptée pour définir un chemin pour ledit flux.
Le procédé selon l'invention comporte une étape consistant à re-router ledit flux sous le contrôle de l'opérateur de manière à faire passer ledit flux via au moins un serveur intermédiaire sélectionné par l'opérateur et à éviter que ledit flux passe systématiquement par ladite entité centrale.
Le procédé selon l'invention permet à l'opérateur d'avoir une maîtrise sur les trafics. Il peut ainsi choisir de dérouter un trafic dans une zone du réseau moins surchargée et/ou y appliquer des traitements spécifiques (ex. filtrage, écoute, réservation de ressources, tarification) .
Selon une autre caractéristique de l'invention, chaque serveur intermédiaire est agencé entre lesdits nœuds et est apte à appliquer audit flux au moins un traitement prédéfini par l'opérateur.
Selon un mode préféré de réalisation, ledit traitement prédéfini comporte au moins l'une des fonctions suivantes:
filtrer les contenus du flux,
appliquer une tarification aux différentes composantes du flux,
mesurer la bande passante consommée, fournir une qualité de service différenciée en fonction du client ou du type de flux.
Analyser les contenus des flux (par exemple pour des écoutes légales) . Le procédé selon l'invention comporte une phase de sélection, par l'opérateur, des traitements à appliquer au flux et d'un ou de plusieurs serveurs intermédiaires aptes à appliquer lesdits traitements, et une phase de configuration du routage optimisé pour ce flux en fonction des traitements prédéfinis.
Un serveur intermédiaire peut être un simple routeur, un MAG, un serveur, un proxy, ou toute autre entité susceptible de détourner un trafic et/ou d'appliquer un traitement spécifique à un flux.
Notons que le flux peut-être re-routé à travers plusieurs serveurs intermédiaires en cascade. Dans ce cas, l'un de ces serveurs peut être un LMA.
Dans le procédé selon l'invention, la configuration du routage consiste à créer sur chaque serveur intermédiaire les entrées et sorties d'au moins un tunnel en envoyant à chaque serveur intermédiaire un message de signalisation comportant des informations sur les adresses IP des nœuds, le ou les préfixes des nœuds source et destination, les identifiants desdits nœuds source et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant
En outre, lors d'une connexion au réseau, au moins un nœud se connecte à un routeur d'accès relié à une entité centrale adaptée pour définir, pour chaque routeur d'accès, une table de routage optimisée en fonction des traitements prédéfinis par l'opérateur dans chaque serveur intermédiaire.
Dans une première variante, le procédé selon l'invention s'applique dans un réseau de type IP à des routeurs d'accès fixes. Dans une deuxième variante, le procédé selon l'invention s'applique dans un réseau de type IP à des routeurs d'accès mobiles.
Dans les deux variantes, l'entité centrale crée les entrées et sorties des tunnels sur chaque serveur intermédiaire en envoyant à chaque serveur intermédiaire un message de signalisation comportant des informations sur les adresses IP des nœuds, le ou les préfixes des nœuds source et destination, les identifiants desdits nœuds source et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant. Ladite entité centrale retransmet ledit message de signalisation si aucune réponse n'est reçue pendant un temps d'attente prédéfini.
Le procédé selon l'invention est mis en œuvre par un dispositif
comportant des moyens pour re-router ledit flux via un ou plusieurs serveurs intermédiaires configurés pour appliquer audit flux au moins un traitement prédéfini par l'opérateur, et dans lequel chaque serveur intermédiaire comporte au moins un module réalisant au moins l'un des fonctions suivantes données à titre d'exemple non limitatif:
filtrage des contenus du flux,
- application d'une tarification aux différentes composantes du flux,
mesure de la bande passante consommée, fourniture d'une qualité de service différenciée en fonction du client ou du type de flux.
- Analyser les contenus des flux (p. ex. écoute légale) . Ce dispositif comporte en outre une entité centrale apte à créer sur chaque serveur intermédiaire les entrées et sorties d' au moins un tunnel en envoyant à chaque serveur intermédiaire un message de signalisation comportant des informations sur les adresses IP des nœuds, le ou les préfixes des nœuds source et destination, les identifiants desdits nœuds source et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant.
Les étapes du procédé selon l'invention sont réalisées par les instructions d'un programme d'ordinateur enregistré sur un support de stockage lorsqu'il est exécuté sur un ordinateur.
BRÈVE DESCRIPTION DES DESSINS
D'autres caractéristiques et avantages de l'invention ressortiront de la description qui va suivre, prise à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles :
la figure 1, décrite précédemment, illustre schématiquement une architecture permettant de gérer la mobilité de deux nœuds dans un réseau utilisant le protocole ΡΜΙΡνβ,
la figure 2 représente illustre une première variante de réalisation de l'invention dans un domaine ΡΜΙΡνβ,
la figure 3 illustre schématiquement une deuxième variante de réalisation de l'invention dans un domaine ΡΜΙΡνβ, la figure 4 illustre schématiquement une troisième variante de réalisation de l'invention dans un domaine ΡΜΙΡνβ,
la figure 5 illustre schématiquement une quatrième variante de réalisation de l'invention dans un domaine Mobile IPv4/NEMOv4 ou Mobile IPv6/NEMOv6, la figure 6 illustre la procédure de configuration du routage, selon l'invention, d'un flux échangé, via deux serveurs intermédiaires entre deux nœuds ,
la figure 7 représente la mise à jour de tunnels établis entre les nœuds lors de la procédure de configuration du routage de la figure 6,
la figure 8 illustre schématiquement un mode de réalisation de l'invention dans le cas où les nœuds qui échangent le flux de données sont attachés des LMA différents
la figure 9 illustre les échanges de messages entre les différents éléments de la figure 8 pour réaliser un routage optimisé,
la figure 10 illustre schématiquement le format d'un message LRI,
la figure 11 illustre un exemple d'organisation des options, selon l'invention, pour déterminer comment créer ses deux tunnels,
la figure 12 illustre schématiquement le format d'un message LRA,
la figure 13 illustre les étapes pour l'optimisation de routage entre deux routeurs mobiles ΝΕΜΟνβ. EXPOSE DE TAILLE DE MODES DE REALISATION PARTICULIERS
L'invention sera décrite, par références aux figures 2-8 pour optimiser le routage d'un flux de données multimédia échangé, via un réseau utilisant le protocole ΡΜΙΡνβ, entre un nœud source et un nœud destination. Dans la suite de cette description, les éléments communs aux différentes figures seront désignés par des références identiques.
La figure 2 illustre une première variante de réalisation de l'invention dans un domaine ΡΜΙΡνβ dans laquelle deux nœuds topologiquement proche, soit un nœud source 4 et un nœud destination 6 sont associés, respectivement, à un MAG 8 et à un MAG 10 lors d'une session IP. Dans ce cas, un premier tunnel 20 est établi entre le MAG 8 du nœud source 4 et un serveur intermédiaire 22 et un deuxième tunnel 24 établi entre ce serveur intermédiaire 22 et le MAG 10 du nœud destination 6. Le serveur intermédiaire 22 est configuré pour appliquer aux flux échangés entre les nœuds 4 et 6 un ensemble de services prédéfinis dictés par des exigences, par exemple légales et/ou économiques, ou autres. Ainsi par exemple, le serveur intermédiaire 22 comporte un premier module 25 qui est destiné à appliquer un certain niveau de qualité de service, un deuxième module 26 destiné à appliquer un filtrage du trafic afin de bloquer tout contenu répréhensible, et un troisième module 27 destiné à dupliquer le flux afin de procéder à une écoute de communications vocales par exemple.
La figure 3 illustre schématiquement une deuxième variante de réalisation de l'invention dans un domaine ΡΜΙΡνδ dans laquelle les premier, deuxième et troisième modules 25, 26, 27 ne sont pas hébergés sur le même serveur intermédiaire. Dans ce cas, le premier module 25 est hébergé sur un premier serveur intermédiaire 30, le deuxième module 26 est hébergé sur un deuxième serveur intermédiaire 31, et le troisième module 27 est hébergé sur un troisième serveur intermédiaire 32. Pour que chaque module puisse appliquer son traitement sur le flux, quatre tunnels 33, 34, 35 et 36 sont établis sur le chemin que doit parcourir ce flux respectivement entre le MAG 8 et le premier serveur intermédiaire 30, le premier serveur intermédiaire 30 et le deuxième serveur intermédiaire 31, le deuxième serveur intermédiaire 31 et le troisième serveur intermédiaire 32, le troisième serveur intermédiaire 32 et le MAG 10. Notons que dans cette variante, l'un au moins des serveurs intermédiaires 30, 31 et 32 peut être un LMA.
Bien entendu, le flux peut être re-routé vers un ou plusieurs serveurs intermédiaires pouvant fournir un même service ou plusieurs services différents .
La figure 4 illustre schématiquement une troisième variante de réalisation de l'invention dans un domaine ΡΜΙΡνδ dans laquelle les nœuds se connectent à travers des femtocells ou routeurs résidentiels Wi- Fi . Une femtocell est un point d'accès fournissant une connectivité cellulaire d'une portée très limité (un appartement, un étage de bureau, etc.) et qui envoi le trafic à l'opérateur propriétaire de la femtocell à travers une connexion Internet. Le chemin emprunté par les données entre une femtocell et l'opérateur cellulaire propriétaire peut traverser une série de réseaux appartenant à d'autres opérateurs.
Dans une autre variante de réalisation de l'invention illustrée par la figure 4, on considère une femtocell comme une combinaison d'un point d'accès cellulaire et d'un MAG. Dans ce cas, un routage optimisé entre deux femtocells peut dans certaines situations ne pas passer par le réseau de l'opérateur. Dans ce scénario, l'opérateur propriétaire des femtocells installe un serveur intermédiaire dans le réseau d'un autre opérateur proche des nœuds. Le trafic entre deux nœuds peut alors être re-routé par ce serveur intermédiaire.
Ainsi en référence à la figure 4, deux nœuds 4 et 6 attaché respectivement à deux femtocell 40 et 42 d'un opérateur A échangent un flux multimédia. Afin d'optimiser le routage du flux échangé entre ces nœuds, le flux est re-routé de la femtocell 40 à travers un premier tunnel 46 vers un serveur intermédiaire 44 hébergé dans le réseau d'un opérateur B, puis transmis du serveur intermédiaire 44 vers la deuxième femtocell 42 à travers un deuxième tunnel 48. Ainsi, le flux ne passe pas par le LMA 12, l'opérateur A peut alors lui appliquer les traitements programmés dans le serveur intermédiaire 44.
La figure 5 illustre schématiquement une quatrième variante de réalisation de l'invention dans un domaine Mobile IPv4/NEMOv4 ou Mobile IPv6/NEMOv6 dans laquelle les nœuds 4 et 6 se connectent à travers un serveur intermédiaire 58 utilisé comme point de passage pour le trafic direct entre deux routeurs mobiles 52 et 54.
Rappelons qu'un routeur mobile est un équipement doté de plusieurs interfaces réseaux qui se déplace avec un ensemble d' autres équipements et gère la mobilité de cet ensemble d'équipements. Ces derniers ne sont pas affectés par les événements de mobilité. C'est le cas par exemple d'un routeur mobile installé sur un train qui se connecte à Internet avec une interface LTE (Long Term Evolution) , et qui offre accès au réseau aux équipements des passagers par son interface WiFi ; les équipements des passager n' implémentant pas de protocole de mobilité.
En référence à la figure 5, un HA (pour Home Agent) 56 remplit pour les routeurs 52, 54 la fonction du LMA 12 pour les MAG 8 et 10. Partant de cette analogie, le trafic entre les deux Routeurs Mobiles 52 et 54 peut être re-routé à travers un ou plusieurs serveurs intermédiaires et éviter ainsi le passage par le Home Agent 56. Ceci peut offrir au flux une route plus courte que le passage par le HA 56. En outre, même si ce n'est pas le chemin le plus court, c'est-à-dire, le chemin direct entre les routeurs 52 et 54, le passage par le serveurs intermédiaires 58 à l'avantage d'offrir à l'opérateur du réseau la possibilité d'augmenter les services offerts en appliquant au flux les traitements programmés dans ce serveur intermédiaire 56.
Dans les différentes variantes de réalisation de l'invention, l'application de la procédure d'optimisation selon l'invention comporte les trois phases suivantes :
- Détection de la nécessité d'optimiser le routage pour un flux de données,
Sélection des services à appliquer au flux et des serveurs associés par lesquels il faut faire transiter le flux pour réaliser un routage optimisé,
- Configuration du routage optimisé pour ce flux .
Une détection de la nécessité d'optimiser le routage résulte, par exemple, du fait qu'un LMA ou un HA d'un nœud destinataire reçoit un premier paquet de donnée indiquant l'établissement d'une communication .
L'opérateur peut également configurer le routage optimisé seulement si le ou les nœuds ne seront pas mobiles pendant un certain temps en utilisant un algorithme de prédiction.
L'operateur peut aussi décider de permettre le routage optimisé seulement pour un certain type de trafic, en encore seulement après un certain laps de temps .
Notons que quel que soit l'élément déclencheur du processus d'optimisation du routage, l'opérateur peut modifier ou désactiver un chemin optimisé à tout moment. L'opérateur doit indiquer à la configuration du LMA ou de manière dynamique une liste de serveurs intermédiaires, leurs adresses IPv6 et les services fournies par chacun d'eux. Ces serveurs doivent être authentifiés par le LMA. La liste des services à appliquer à un flux, et donc la liste de serveurs intermédiaires à traverser peut dépendre du choix de l'opérateur et/ou des options souscrites par chaque client.
La phase de configuration du routage optimisé sera maintenant décrite en référence aux figues 6-9.
La première étape de cette phase consiste à créer les entrées et sorties des tunnels sur chaque serveur intermédiaire avec comme paramètres des informations sur les adresses IPv6 des nœuds. Pour cela, le LMA ou le HA va initier la création d'un tunnel en envoyant à chaque serveur intermédiaire un message de signalisation « localized routing initiation » ou LRI . Un message LRI indiquera le ou les préfixes des nœuds source et destination, leurs identifiants ainsi que l'adresse IPv6 du serveur précédent et l'adresse IPv6 du serveur suivant (MAG ou serveur intermédiaire) , et éventuellement les préfix des nœuds servis par des routeurs mobiles. Chaque serveur intermédiaire retourne un message de validation « localized routing acknowledgment » ou LRA.
La figure 6 illustre la procédure de configuration du routage d'un flux échangé, via deux serveurs intermédiaires 60, 62, entre le nœud source 4 et le nœud source 6 associés respectivement au premier MAG 8 et au deuxième MAG 10 lors d'une session dans un réseau comportant le LMA 12.
Les étapes 62 à 68 illustrent les échanges des données avant l'optimisation du routage.
A l'étape 62, le nœud source 4 transmet le flux au MAG 8 auquel il est associé pendant la session. A l'étape 64, le MAG 8 transmet le flux au LMA 12. Ce dernier transmet ledit flux au MAG 10 qui l'envoie au nœud destination 6.
Les étapes 70 à 84 illustrent la phase de configuration du routage optimisé selon l'invention.
A l'étape 70, le LMA 12 transmet au serveur intermédiaire 60 un message LRI_SI60 lui indiquant le ou les préfixes des nœuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 8 et l'adresse IPv6 du serveur intermédiaire 62.
A l'étape 72, le serveur intermédiaire 60 envoie au LMA 12 un message d'accusé réception LRA_SI60.
A l'étape 74, le LMA 12 transmet au serveur intermédiaire 62 un message LRI_SI62 lui indiquant le ou les préfixes des nœuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 10 et l'adresse IPv6 serveur intermédiaire 60.
A l'étape 76, le serveur intermédiaire 60 envoie au LMA 12 un message d'accusé réception LRA_SI62.
Une fois les points d'entrées et de sorties des tunnels établis sur les serveurs intermédiaires 60, 62, le LMA 12 crée les points de sorties et d'entrées des tunnels sur les MAGs 8 et 10. Un point d'entrée/sortie va être créé sur le premier MAG 8 vers le premier serveur intermédiaire 60 et sur le deuxième MAG 10 vers le deuxième serveur intermédiaire 62 selon les étapes qui suivent.
A l'étape 78, le LMA 12 transmet au MAG 8 un message LRI_MAG8 lui indiquant le ou les préfixes des nœuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du serveur intermédiaire 60.
A l'étape 80, le MAG 8 envoie au LMA 12 un message d'accusé réception LRA_MAG8.
A l'étape 82, le LMA 12 transmet au MAG 10 un message LRI_MAG10 lui indiquant le ou les préfixes des nœuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du serveur intermédiaire 62.
A l'étape 84, le MAG 10 envoie au LMA 12 un message d'accusé réception LRA_MAG10.
Les étapes 90 à 98 illustrent les échanges des données après l'optimisation du routage.
A l'étape 90, le nœud source 4 transmet le flux au MAG 8. Ce dernier transfère, à l'étape 92, le flux reçu au serveur intermédiaire 60 via le tunnel configuré lors de la phase précédente.
A l'étape 94, le serveur intermédiaire 60 envoie le flux reçu au serveur intermédiaire 62. Ce dernier transfère, à l'étape 96, le flux reçu au MAG 10 via le tunnel configuré lors de la phase précédente.
A l'étape 98, le MAG 10 envoie le flux au nœud destination 6.
Notons que la séquence d'envoi des messages LRI peut se faire selon un cadencement différent sans sortir du cadre de l'invention. En effet, le LMA 12 peut être configuré, par exemple, pour envoyer les messages LRI aux MAGs 8 et 10 avant de les envoyer aux serveurs intermédiaires 60, 62, ou encore de tout envoyer en parallèle. Toutefois, la séquence présentée dans la figure 6 consistant à configurer les serveurs intermédiaires 60, 62, puis les MAGs 8, 10 est préférée car elle permet de s'assurer de la disponibilité et de la bonne configuration de l'ensemble des serveurs intermédiaires formant le chemin de routage optimisé avant de configurer les MAGs pour que le flux de donnée empreinte ce chemin de routage optimisé.
Notons également que tant que les MAGs 8 et 10 ne sont pas configurés avec l'information de routage optimisé contenue dans les messages LRI, le flux de donnée continue à être routé par le LMA 12, évitant ainsi toute interruption potentielle de service pendant la phase de configuration des serveurs intermédiaires 60, 62.
Dans un cas particulier de mise en œuvre de l'invention, lorsque le nœud source 4 se déplace du MAG 8 vers un nouveau MAG 100, c'est-à-dire, lors d'un changement d'association du nœud 4 dû à un déplacement dans le réseau par exemple, le nouveau MAG 100 enregistre la position du nœud au LMA 12, et à la réception du message de signalisation PBU (pour proxy binding update, en anglais), la mise à jour des tunnels suit la procédure décrite par la figure 7.
Sur cette figure 7, les étapes 90 à 98, sont celles décrites par référence à la figure 6.
A l'étape 102, le nouveau MAG 100 transmet un PBU (pour proxy binding update, en anglais) au LMA 12 pour enregistrer la nouvelle position du nœud 6.
A l'étape 104, le LMA renvoie un message LRI_SI62 au deuxième serveur intermédiaire 62 avec adresse IPv6 du MAG 100 auquel le nœud 6 est maintenant connecté afin que le serveur intermédiaire 62 mette à jour sa configuration de routage de telle manière que le traffic adresse au nœud 6 soit maintenant tunnele vers le MAG 100 (plutôt que MAG8 comme initialement) .
A l'étape 106, le deuxième serveur intermédiaire 62 envoie au LMA 12 un message d'accusé réception LRA_SI62.
A l'étape 108, le LMA 12 transmet en retour un message PBA (pour proxy binding acknowledgment , en anglais) au nouveau MAG 100.
A l'étape 110, le LMA 12 envoie au nouveau MAG 100 un message LRI_MAG100 lui indiquant le ou les préfixes des nœuds 4 et 6, leurs identifiants ainsi que l'adresse IPv6 du serveur intermédiaire 62, ceci afin que le nouveau MAG 100 mette en place le routage optimisé via le serveur intermédiaire 62.
A l'étape 112, le nouveau MAG 100 envoie au LMA 12 un message d'accusé réception LRA_MAG100.
Après la mise à jour des tunnels décrite par les étapes 102 à 112, le nouveau MAG 100 remplace le MAG 8 dans les étapes 90 à 98 du routage optimisé.
La figure 8 illustre schématiquement un mode de réalisation de l'invention dans le cas où les nœuds 4 et 6 qui échangent le flux de données sont attachés respectivement à un premier LMA 120 et à un deuxième LMA 122 différent du premier LMA 120 appartenant à deux domaines ΡΜΙΡνδ distincts.
Lors d'une session d'échange de données multimédia, le MAG 8 auquel est attaché le nœud 4 transmet le flux de données, via un premier tunnel 124, à un premier serveur intermédiaire 126 contrôlé par le premier LMA 120. Le serveur intermédiaire 126 transmet le flux reçu, via un deuxième tunnel 128, à un deuxième serveur intermédiaire 130 contrôlé par le deuxième LMA 122. Le deuxième serveur intermédiaire 130 transmet le flux reçu, via un troisième tunnel 132, au MAG 10 auquel est attaché nœud 6.
La procédure d'optimisation du routage peut être initiée par un des deux LMAs 120 ou 122. Ces deux LMAs échangent des informations spécifiques afin de connaître à l'avance les points d'entrées et de sorties du tunnel 128 reliant les serveurs intermédiaires 126 et 130 géré par respectivemet ces deux LMA 120 et 122.
La figure 9 illustre les échanges de messages entre les différents éléments de la figure 8 pour réaliser un routage optimisé.
Les étapes 140 à 148 illustrent les échanges des données avant l'optimisation du routage.
A l'étape 140, le nœud source 4 transmet le flux au MAG 8 auquel il est associé pendant la session.
A l'étape 142, le MAG 8 transmet le flux au premier LMA 120. Ce dernier transmet, à l'étape 144, ledit flux au deuxième LMA 122.
A l'étape 146, le deuxième LMA 122 transmet le flux au MAG 10 auquel est associé le nœud destination 6.
A l'étape 148, le MAG 10 transmet le flux au nœud destination 6.
Les étapes 150 à 172 illustrent la phase de configuration du routage optimisé selon l'invention.
A l'étape 150, le premier LMA 120 transmet au deuxième LMA 122 un message RO_init véhiculant des informations relatives au serveur intermédiaire 126. A l'étape 152, le deuxième LMA 122 transmet au premier LMA 120 un message RO_init_ack d'accusé réception véhiculant des informations relatives au serveur intermédiaire 130.
A l'étape 154, le LMA 120 transmet au serveur intermédiaire 126 un message LRI_SI126 lui indiquant le ou les préfixes des nœuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 10 et l'adresse IPv6 du serveur intermédiaire 130.
A l'étape 156, le serveur intermédiaire 126 envoie au LMA 120 un message d'accusé réception LRA_SI126.
A l'étape 158, le LMA 122 transmet au serveur intermédiaire 130 un message LRI_SI130 lui indiquant le ou les préfixes des nœuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 10 et l'adresse IPv6 du serveur intermédiaire 126.
A l'étape 160, le serveur intermédiaire 130 envoie au LMA 122 un message d'accusé réception LRA_S 1130.
A l'étape 162, le LMA 120 envoie un message LRI_MAG8 au MAG 8.
A l'étape 164, le MAG 8 envoie au LMA 120 un message d'accusé réception LRA_ MAG8.
A l'étape 166, le LMA 122 envoie un message LRI_MAG10 au MAG 10.
A l'étape 168, le MAG 10 envoie au LMA 122 un message d'accusé réception LRA_ MAG10. A l'étape 170, le premier LMA 120 transmet au deuxième LMA 122 un message RO_ack confirmant la mise en place de la première branche du routage optimisé via le MAG 8 et le serveur intermédiaire 126 gérés par le premier LMA 120.
A l'étape 172, le deuxième LMA 122 transmet au premier LMA 120 un message RO_ack confirmant la mise en place de la seconde branche du routage optimisé via le serveur intermédiaire 130 et le MAG 10 gérés par le deuxième LMA 122.
Les étapes 180 à 188 illustrent les étapes du routage optimisé après la configuration du routage effectuée par les étapes 150 à 172.
A l'étape 180, le nœud source 4 transmet le flux au MAG 8. Ce dernier transmet (étape 182) le flux reçu au serveur intermédiaire 126 qui le transmet à son tour (étape 184) au serveur intermédiaire 130.
A l'étape 186, le serveur intermédiaire 130 transmet le flux au MAG 10 qui le transmet à son tour (étape 188) au nœud destination 6.
Notons qu'un système d' authenti fication des serveurs intermédiaires entre les deux domaines ΡΜΙΡνδ permet de garantir l' authentification et la protection des données échangées.
La figure 10 illustre schématiquement le format d'un message LRI .
Ce message comporte :
- Numéro de séquence (16 bits) : C'est un nombre qui s'incrémente linéairement et qui permet d'identifier un message. - un bit R (1 bit) : Quand il est à 0, il identifie le message comme étant un LRI.
- un bit S (1 bit) : Quand il est à 1, il demande la désactivation du routage optimisé locale.
- un bit I (1 bit) : Quand il est à 1, il indique que ce message est destiné à un serveur intermédiaire .
Une suite de bits Reserved (13 bits) : Champs réservé. Il doit être mis à 0.
- Une suite de bits Lifetime (16 bits) : Le temps en seconde de la durée de vie du tunnel. Quand tous les bits sont à 1, la durée est infinie.
Mobility options : Suite d'options de taille variable. Le LMA indique toutes les informations utiles pour détecter le flux des clients. Les informations qui doivent être incluses sont : L'identifiant du client 1 (MN1-ID) , un ou plusieurs préfix (MN1-HNP) attribués au client 1, l'identifiant du client 2 (MN2-ID) , un ou plusieurs préfix attribués au client 2 (MN2-HNP) et l'adresse IPv6 du MAG ou du serveur intermédiaire de l'autre côté du tunnel. Le format de l'option avec l'adresse IPv6 peut se baser sur le format du paquet « MAG IPv6 address ». Quand ce message est destiné à un serveur intermédiaire (bit I à 1), deux adresses IPv6 (de MAG ou SI) associé aux MN- IDs des deux clients sont fournies pour les deux tunnels afin d'établir correctement les routes dans les tables de routages. Les options MN-ID et MN-HNP sont définies dans la RFC5213.
À la réception d'un message LRI, un serveur intermédiaire vérifie dans un premier temps que le bit I est mis à 1. Dans le cas contraire, le message est ignoré. Le serveur intermédiaire récupère ensuite les options de mobilités et établir les tunnels vers les MAGs et/ou les Sis (serveurs intermédiaires) . Il est important que les options soient organisées de telles sortes que le SI puisse déterminer comment créer ses deux tunnels. En effet, il y a un sens de communication en fonction d'où se trouvent les clients et le SI doit correctement mettre à jour sa table de routage.
La figure 11 illustre un exemple où les options sont organisées selon un ordre précis. Le SI, peut dans ce cas interprétés séquentiellement les options. Dans ce cas, pour mettre à jour sa table de routage pour le nœud MN1-ID, le SI considère le préfixe MN1-HNP et transfère les données vers l'adresse IPv6 du SI ou MAG. De même pour l'autre sens de communication (MN2-ID, etc. ) .
La figure 12 illustre schématiquement le format d'un message LRA.
Ce message comporte :
- un Numéro de séquence (16 bits) : C'est un nombre qui s'incrémente linéairement et qui permet d'identifier un message.
- un bit R (1 bit) : Quand il est à 1, il indique que c'est un LRA.
- un bit U (1 bit) : Doit être mis à 0.
- un bit I (1 bit) : Quand il est à 1, indique qu'il est envoyé par un serveur intermédiaire.
une série de bits Reserved (5 bits) : Champs réservé. Il doit être mis à 0. - une série de bits Status (8 bits) : Quand il est à 0, ce champ indique un succès. Quand le bit I est à 0 (LRA envoyé par un MAG) , et que la valeur du statut vaut 129, il indique que le client n'est plus associé au MAG. Quand le bit I est à 1 (LRA envoyé par un serveur intermédiaire) , et que la valeur du statut vaut 129, il indique que l'opération a échoué.
- une série de bits Lifetime (16 bits) : Le temps en seconde de la durée de vie du tunnel. Quand tous les bits sont à 1, la durée est infinie. Par défaut, la valeur indiqué dans le LRI .
- Mobility options : Dans tout les cas, est retourné le contenu du même champ provenant du message LRI .
En plus des paramètres de base présentés ci-dessus, les paquets LRI peuvent comporter des paramètres pour indiquer aux serveurs intermédiaires et aux MAG le type de traitement à appliquer à un ou plusieurs flux de données. Les serveurs intermédiaires peuvent ainsi assurer de multiples fonctionnalités/services .
Les LMA sont configurables pour indiquer dynamiquement aux serveurs intermédiaires (lors de la phase de configuration du routage optimisé par envoi des messages LRI) quel service il doit spécifiquement activer pour un flux donné. Le flux étant aussi indiqué dans le message LRI.
Le procédé selon l'invention peut être appliqué à d'autres protocoles de gestion de la mobilité. Ainsi, dans le cas des protocoles Mobile IPv4 [ref ] et Mobile IPv6 [ref ] , et en particulier de leurs extensions respectives NEMOv4 [ref] et ΝΕΜΟνβ [ref] pour le support des routeurs mobiles, il est aussi important de réduire les chemins parcourus par les données entre deux Routeurs Mobiles afin de ne pas traverser le Home Agent systématiquement.
Aucune extension spécifique au protocole ΝΕΜΟνβ n'a été définie pour permettre un routage optimal (par exemple, via un tunnel direct) entre 2 routeurs mobile IPv6.
En ce qui concerne le protocole NEMOv4 , une extension connue, intitulée « HAARO » [ref] , propose de faire de l'optimisation de routage entre des routeurs mobiles IPv4. Ce mécanisme offre des routes directes (sous la forme de tunnels) entre deux routeurs mobiles associés à un même Home Agent (HA) . Cette solution se base sur l'échange de messages Registration Request et Reply directement entre les deux routeurs mobiles, afin d'échanger les informations nécessaires à l'établissement d'un tunnel direct (pour le routage optimisé) entre eux. Cette solution a toutefois deux inconvénients majeurs : d'une part la mise en place du routage optimisé doit être initiée par l'un des deux routeurs mobiles, aucun mécanisme n'étant prévu pour permettre un déclanchement à l'initiative de l'operateur du réseau (via une entité centralisé) . D'autre part, seul un tunnel direct entre les deux routeurs mobiles peut être établi, ne permettant donc pas de rediriger le trafic optimisé vers un ou plusieurs serveurs intermédiaires sous le contrôle d'un operateur. Afin de résoudre ces problèmes, la solution décrite précédemment en détail dans le cadre d'un domaine ΡΜΙΡνβ peut s'appliquer pour optimiser le routage entre routeurs mobiles permettant ainsi à une entité réseau sous le contrôle de l'operateur, ici le Home Agent (de manière analogue au LMA) , de configurer un chemin de routage optimisé passant par des serveurs intermédiaires pour router le trafic entre deux routeurs mobiles (de manière analogue aux MAGs) .
Le Home Agent est alors considéré comme point de contrôle, et est configuré par l'opérateur du réseau mobile afin de définir le chemin optimisé (passant par des serveurs intermédiaires) que les flux de données doivent prendre entre deux routeurs mobiles. Ce chemin peut inclure un ou plusieurs Serveur Intermédiaire ( s ) pour la mise en œuvre de services selon les besoins de l'opérateur.
La figure 13 illustre les étapes pour l'optimisation de routage entre deux routeurs mobiles ΝΕΜΟνβ. L'échange de messages est similaire à celui qui est décrit par référence à la figure 6 en remplaçant le LMA 12 par le HA 190 (Home Agent) , les nœuds source 4 et destination 6 respectivement par les nœuds fixes LFN 200 et 202 (pour (Local Fixed Nodes) , qui peuvent être des équipements portables des passagers d'un véhicule mobile connectés respectivement aux routeurs mobiles MR 204 et 206.
Dans l'exemple de la figure 13, deux serveurs intermédiaires 208 et 210 sont définis par l'opérateur. Dans ce contexte, pour configurer le routage optimisé, le Home Agent 190 envoie des messages « LRI_SI » vers les Serveurs Intermédiaires et des messages « LRI_MR » vers les Routeurs Mobiles. Une fois ces messages envoyés et acquittés, le trafic de données entre les deux routeurs mobiles 204 et 206 ne passera plus par le HA 190, mais par le chemin optimisé traversant les Serveurs Intermédiaires 208 et 210.
Pour réaliser cela, les messages LRI_SI et LRI_MR comportent des informations et instructions relatives aux adresses des Clients LFN 200 et 202 connectés respectivement aux routeurs mobiles 204 et 206. Ces informations peuvent être groupées sous forme d'un « prefix » couvrant plusieurs adresses IPv6 valides sous un même Routeur Mobile (on parle alors de préfix de réseau mobile, ou MR-MNP « Mobile Network Prefix of a Mobile Routeur ») . Cette information MR-MNP peut, par exemple, être transportée dans les messages LRI en utilisant une option ayant le même format que l'option MN-HNP la figure 10.
Dans un scénario où les deux routeurs mobiles 204 et 206 sont associés à des Home Agents différents, les deux Home Agents (HA) communiqueront entre eux afin de permettre l'établissement du routage optimisé via des serveurs intermédiaires.
Enfin, le même principe peut aussi être utilisé pour optimiser le routage (via des serveurs intermédiaires) entre deux terminaux mobiles utilisant les protocoles Mobile IPv4 et Mobile IPv6. Dans ce cas, ces nœuds n'ayant pas véritablement de préfix mais uniquement des adresses IP dites « home », ces adresses sont transportées dans les messages LRI (en lieu des préfix MN-HNP ou MR-MNP) .

Claims

REVENDICATIONS
1. Procédé d'optimisation du routage d'un flux échangé entre deux nœuds (4, 6) dans un réseau de télécommunications, procédé dans lequel, lors d'une connexion au réseau, au moins un nœud (4, 6) se connecte à un routeur d'accès (8, 10, 52, 54, 60, 62, 126, 130, 204, 206) relié à une entité centrale (12, 56, 122, 190) adaptée pour définir un chemin pour ledit flux, procédé caractérisé par une étape consistant à re-router ledit flux sous le contrôle de l'opérateur de manière à faire passer ledit flux via au moins un serveur intermédiaire (22, 25, 26, 27, 44, 58) sélectionné par l'opérateur et à éviter que ledit flux ne passe systématiquement par ladite entité centrale (12, 56, 122, 190) .
2. Procédé selon la revendication 1 dans lequel ledit serveur intermédiaire (22, 25, 26, 27, 44, 58) est agencé entre lesdits nœuds et est apte à appliquer audit flux au moins un traitement prédéfini par l'opérateur.
3. Procédé selon la revendication 2 dans lequel ledit traitement prédéfini comporte au moins l'une des fonctions suivantes : filtrer les contenus du flux,
appliquer une tarification aux différentes composantes du flux,
- mesurer la bande passante consommée, fournir une qualité de service différenciée en fonction du client ou du type de flux.
4. Procédé selon la revendication 3 comportant en outre une phase de sélection, par l'opérateur, des traitements à appliquer au flux et d'un ou de plusieurs serveurs intermédiaires (22, 25, 26, 27, 44, 58) aptes à appliquer lesdits traitements, et une phase de configuration du routage optimisé pour ce flux en fonction des traitements prédéfinis.
5. Procédé selon la revendication 4 dans lequel la configuration du routage consiste à créer, entre les nœuds (4, 6, 200, 202), au moins un tunnel (20, 24, 33, 34, 35, 36, 46, 48) passant par un ou plusieurs serveurs intermédiaires (22, 25, 26, 27, 44, 58, 208, 210) .
6. Procédé selon la revendication 5 dans lequel on définit, pour chaque routeur d'accès (8, 10,
52, 54, 204, 206), une table de routage optimisée en fonction des traitements prédéfinis par l'opérateur dans chaque serveur intermédiaire.
7. Procédé selon la revendication 6 dans lequel lesdits routeurs d'accès sont des routeurs fixes (8, 10) .
8. Procédé selon la revendication 6 dans lequel lesdits routeurs d'accès sont des routeurs mobiles (52, 54, 204, 206) .
9. Procédé selon l'une des revendications 7 ou 8 dans lequel le réseau de télécommunication est un réseau de type IP.
10. Procédé selon la revendication 9 dans lequel l'entité centrale crée les entrées et sorties des tunnels sur chaque serveur intermédiaire (22, 25, 26, 27, 44, 58, 208, 210) en envoyant à chacun desdits serveurs intermédiaires un message de signalisation comportant des informations sur les adresses IP des nœuds (4, 6, 200, 202), le ou les préfixes des nœuds source et destination, les identifiants desdits nœuds source (4, 6, 200, 202) et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant.
11. Procédé selon la revendication 10 dans lequel l'entité centrale retransmet ledit message de signalisation si aucune réponse n'est reçue pendant un temps d'attente prédéfini.
12. Procédé selon l'une des revendications 5 à 11 comportant en outre une étape de mise à jour des tunnels à la suite d'un changement d'association d'un nœud à un nouveau un routeur d'accès dans laquelle ledit nouveau routeur d'accès enregistre la position dudit nœud à un LMA (pour Local Mobility Anchor) (12) à la réception du message de signalisation PBU (pour proxy binding update, en anglais) .
13. Procédé selon la revendication 1 dans lequel les nœuds (4) et (6) sont attachés respectivement à un premier LMA (120) et à un deuxième LMA (122) différent du premier LMA (120) appartenant à deux domaines ΡΜΙΡνβ distincts, et, lors d'une session d'échange de données multimédia, le routeur d'accès (8) auquel est attaché le nœud (4) transmet le flux de données, via un premier tunnel (124), à un premier serveur intermédiaire (126) contrôlé par le premier LMA (120), le serveur intermédiaire (126) transmet le flux reçu, via un deuxième tunnel (128), à un deuxième serveur intermédiaire (130) contrôlé par le deuxième LMA (122), le deuxième serveur intermédiaire (130) transmet le flux reçu, via un troisième tunnel (132), au routeur d'accès (10) auquel est attaché nœud (6) .
14. Dispositif d'optimisation du routage d'un flux échangé entre deux nœuds (4, 6, 200, 202) dans un réseau de télécommunications dans lequel, lors d'une connexion au réseau, au moins un nœud (4, 6, 200, 202) se connecte à un routeur d'accès (8, 10, 52, 54, 60, 62, 126, 130, 204, 206) relié à une entité centrale (12, 56, 122, 190) adaptée pour définir un chemin pour ledit flux, , caractérisé en ce qu' il comporte au moins une table de routagecontrôlée par l'opérateur adaptée pour re-router ledit flux pour le faire passer via au moins un serveur intermédiaire (22, 25, 26, 27, 44, 58) sélectionné par l'opérateur et à éviter qu' il ne passe systématiquement par ladite entité centrale (12, 56, 122, 190) .
15. Dispositif selon la revendication
14 caractérisé en ce que ladite entité centrale est apte à créer sur chaque serveur intermédiaire (22, 25, 26, 27, 44, 58) des entrées et sorties d'au moins un tunnel en envoyant à chaque serveur intermédiaire (22,
25, 26, 27, 44, 58) un message de signalisation comportant des informations sur les adresses IP des nœuds (4, 6, 200, 202), le ou les préfixes des nœuds source et destination, les identifiants desdits nœuds source et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant.
16. Dispositif selon la revendication 15 dans lequel, chaque serveur intermédiaire (22, 25,
26, 27, 44, 58) comporte au moins un module réalisant au moins l'un des fonctions suivantes données à titre d'exemple non limitatif: filtrage des contenus du flux,
application d'une tarification aux différentes composantes du flux,
mesure de la bande passante consommée, fourniture d'une qualité de service différenciée en fonction du client ou du type de flux.
Analyser les contenus des flux (p. ex. écoute légale) .
17. Programme d'ordinateur enregistré sur un support de stockage lorsqu' il est exécuté sur un ordinateur et comportant des instructions pour réaliser les étapes du procédé selon l'une des revendications 1 à 14 lorsqu'il est exécuté sur un ordinateur.
EP12713071.4A 2011-04-07 2012-03-28 Procédé et dispositif d'optimisation du routage d'un flux Withdrawn EP2695408A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1153022A FR2973977B1 (fr) 2011-04-07 2011-04-07 Procede et dispositif d'optimisation du routage d'un flux
PCT/EP2012/055545 WO2012136541A1 (fr) 2011-04-07 2012-03-28 Procédé et dispositif d'optimisation du routage d'un flux

Publications (1)

Publication Number Publication Date
EP2695408A1 true EP2695408A1 (fr) 2014-02-12

Family

ID=45937315

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12713071.4A Withdrawn EP2695408A1 (fr) 2011-04-07 2012-03-28 Procédé et dispositif d'optimisation du routage d'un flux

Country Status (4)

Country Link
US (1) US20140029436A1 (fr)
EP (1) EP2695408A1 (fr)
FR (1) FR2973977B1 (fr)
WO (1) WO2012136541A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9843505B2 (en) * 2015-05-28 2017-12-12 Cisco Technology, Inc. Differentiated quality of service using tunnels with security as a service
WO2017014759A1 (fr) * 2015-07-21 2017-01-26 Nokia Technologies Oy Acheminement localisé dans des réseaux mobiles
US20180198781A1 (en) * 2017-01-06 2018-07-12 International Business Machines Corporation Digital frame authentication through crowdsourcing
US10673649B2 (en) * 2017-10-24 2020-06-02 Cisco Technology, Inc. Method and device for quality of service regulation
CN112636992B (zh) * 2021-03-10 2021-06-22 腾讯科技（深圳）有限公司 一种动态路由方法、装置、设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2099189A1 (fr) * 2008-03-03 2009-09-09 Panasonic Corporation Échange d'informations entre des passerelles pour une optimisation de route avec gestion de mobilité basée sur un réseau

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6633542B1 (en) * 1999-12-29 2003-10-14 3Com Corporation Method of establishing a flow in an ATM based MPOA network
US7039641B2 (en) * 2000-02-24 2006-05-02 Lucent Technologies Inc. Modular packet classification
US20040095913A1 (en) * 2002-11-20 2004-05-20 Nokia, Inc. Routing optimization proxy in IP networks
JP4334379B2 (ja) * 2004-03-12 2009-09-30 富士通株式会社 ネットワークシステム
US8571011B2 (en) * 2004-08-13 2013-10-29 Verizon Business Global Llc Method and system for providing voice over IP managed services utilizing a centralized data store
US7475424B2 (en) * 2004-09-02 2009-01-06 International Business Machines Corporation System and method for on-demand dynamic control of security policies/rules by a client computing device
CN100426815C (zh) * 2004-09-08 2008-10-15 华为技术有限公司 一种ngn中的资源和准入控制子系统及方法
US20060168273A1 (en) * 2004-11-03 2006-07-27 Ofir Michael Mechanism for removing data frames or packets from data communication links
US8625551B2 (en) * 2006-12-22 2014-01-07 Telcordia Technologies, Inc. Flexible mobility framework for heterogeneous roaming in next generation wireless networks
US20080240020A1 (en) * 2007-03-29 2008-10-02 Nokia Corporation Routing support in heterogeneous communications networks
EP1986392B1 (fr) * 2007-04-26 2012-10-03 Motorola Solutions, Inc. Procédé d'optimisation d'acheminement entre entités mobiles
JP4794520B2 (ja) * 2007-05-16 2011-10-19 Ｋｄｄｉ株式会社 ネットワーク主導型移動管理プロトコルにおける通信経路を最適化するシステム、アクセスゲートウェイ、ホームエージェント、およびプログラム
US8634344B2 (en) * 2007-08-06 2014-01-21 Marvell World Trade Ltd. Dynamic internet protocol addressing solutions with network-based mobility
US8085793B2 (en) * 2007-09-24 2011-12-27 Telefonaktiebolaget Lm Ericsson (Publ) Traffic localization with proxy mobility
US8279807B2 (en) * 2007-10-05 2012-10-02 Panasonic Corporation Communication control method, network node, and mobile terminal
EP2058998A1 (fr) * 2007-11-09 2009-05-13 Panasonic Corporation Continuité d'optimisation de route lors du transfert d'une mobilité basée sur réseau à une mobilité basée sur hôte
WO2009101780A1 (fr) * 2008-02-12 2009-08-20 Panasonic Corporation Dispositif de gestion d'informations de position, dispositif de périphérie de réseau et terminal mobile
US8040845B2 (en) * 2008-09-12 2011-10-18 Telefonaktiebolaget L M Ericsson (Publ) Efficient routing between a mobile node and a correspondent node in a proxy mobile IP network
US8599843B2 (en) * 2009-03-02 2013-12-03 Futurewei Technologies, Inc. Apparatus and method for route optimization for proxy mobile internet protocol version six local routing
EP2244495B1 (fr) * 2009-04-20 2012-09-19 Panasonic Corporation Optimisation de route d'un chemin de données entre des noeuds de communication utilisant un agent d'optimisation

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2099189A1 (fr) * 2008-03-03 2009-09-09 Panasonic Corporation Échange d'informations entre des passerelles pour une optimisation de route avec gestion de mobilité basée sur un réseau

Also Published As

Publication number Publication date
WO2012136541A1 (fr) 2012-10-11
FR2973977A1 (fr) 2012-10-12
US20140029436A1 (en) 2014-01-30
FR2973977B1 (fr) 2014-04-25

Similar Documents

Publication Publication Date Title
JP4869235B2 (ja) 減少レートでワイヤレスアクセスを与える方法及びシステム
EP2225663B1 (fr) Fourniture de services à des flux de paquets dans un réseau
EP2695408A1 (fr) Procédé et dispositif d'optimisation du routage d'un flux
EP1863306A1 (fr) Procédé de gestion d'un interfonctionnement entre au moins un réseau local sans fil et un réseau mobile, station mobile, noeud SGSN et passerelle TTG correspondants
JP5528328B2 (ja) プッシュ・メールなどの料金請求サービスのための方法
EP3138358B1 (fr) Procede de traitement d'un paquet de donnees relatif a un service
WO2007088300A1 (fr) Dispositif de radiocommunication a moyens d'acces conformes aux technologies gan et 3gpp-wlan interworking, et controleur de reseau d'acces correspondant
FR2906426A1 (fr) Systeme pour securiser l'acces a une destination d'un reseau prive virtuel
EP1267530A1 (fr) Procédé de transmission de paquets IP à travers un système cellulaire de radiocommunication, et equipements du système cellulaire pour la mise en oeuvre de ce procédé
CN113497759A (zh) 网络服务功能链中的sla分组操纵
CN117643022A (zh) 用于控制合作伙伴网络和wan之间路径的网络诊断
FR2834846A1 (fr) Systeme de gestion de reseau avec validation de regles
WO2019076765A1 (fr) Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en oeuvre l'agregation de liens
US7292558B2 (en) Method and apparatus for a centralized home agent function
EP3539318B1 (fr) Equipement mandataire dans un système de télécommunication cellulaire
EP2206384B1 (fr) Procede de commutation de noeud d'acces
WO2016097534A1 (fr) Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants
EP2007111A1 (fr) Procédé de filtrage de paquets en provenance d'un réseau de communication
EP1998515B1 (fr) Procédés de gestion d'interfonctionnement entre un réseau 3GPP visité disposant de réseaux d'accès 3GPP et WLAN et un réseau 3GPP de domicile pour une station mobile itinérante, et noeud SGSN et passerelle TTG correspondants
KR101099034B1 (ko) 네트워크 엘리먼트들에서 과금 프로세스들을 구성하기 위한 방법
EP2039207B1 (fr) Redirection de trafic dans un reseau de telephonie mobile
CN117678203A (zh) 通过边缘云路径编排保证sla
US9838108B2 (en) IP based real-time communications over a mobile network
FR3079995A1 (fr) Equipement orchestrateur dans un systeme de telecommunication cellulaire
WO2014188136A1 (fr) Dispositif et procede de controle d'un coeur de reseau ip

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: 20131008

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170213

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: 20170624