WO2017157457A1 - Support de sdn destiné à une configuration à trajets multiples disjoints - Google Patents

Support de sdn destiné à une configuration à trajets multiples disjoints Download PDF

Info

Publication number
WO2017157457A1
WO2017157457A1 PCT/EP2016/055929 EP2016055929W WO2017157457A1 WO 2017157457 A1 WO2017157457 A1 WO 2017157457A1 EP 2016055929 W EP2016055929 W EP 2016055929W WO 2017157457 A1 WO2017157457 A1 WO 2017157457A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
sender
receiver
subflows
connection
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.)
Ceased
Application number
PCT/EP2016/055929
Other languages
English (en)
Inventor
Simon Oechsner
Peer Hasselmeyer
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.)
NEC Europe Ltd
Original Assignee
NEC Europe Ltd
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 NEC Europe Ltd filed Critical NEC Europe Ltd
Priority to PCT/EP2016/055929 priority Critical patent/WO2017157457A1/fr
Publication of WO2017157457A1 publication Critical patent/WO2017157457A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/128—Shortest path evaluation for finding disjoint paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing

Definitions

  • the present invention generally relates to a method and a system for supporting a multipath connection between two connection endpoints in a network.
  • multipath communication for example standardized in the form of MPTCP (Multipath Transmission Control Protocol).
  • MPTCP Multipath Transmission Control Protocol
  • the basic idea behind multipath communication is that the reliability of a connection can be increased since link failures do not affect all paths, and that congestion can be avoided by distributing the traffic load intelligently among the paths.
  • the paths taken by the subflows of a multipath connection should be completely disjoint. This becomes clear if one imagines a jointly used link to fail, or being the bottleneck link of all paths. It is therefore of advantage to ensure that different subflows of the same multipath connection are forwarded over disjoint paths as far as possible. Since forwarding is typically not managed by the endpoints, the network entity controlling the forwarding should support multipath communication by providing this disjoint forwarding.
  • the approaches also presuppose changes in the client network stack or alternatively in the hypervisors deployed on the physical hosts. This would necessitate, among other things, a standardized protocol for the signaling, as well as support and use of particular encapsulation techniques, creating additional overhead and reducing the flexibility.
  • connection endpoints include a sender and a receiver
  • a network controller having knowledge of the network topology, determining the number of disjoint network paths available between said sender and said receiver and, based on said number, triggering the establishment of additional subflows between said sender and said receiver along network paths being at least partially disjoint to said first network path.
  • a network comprising a plurality of switches
  • At least two devices connected to one or more of the plurality of switches, wherein said at least two devices include a sender and a receiver being the two connection endpoints of a multipath connection that includes at least one subflow established between said sender and said receiver along a first network path, and a network controller being connected to one or more of the plurality of switches in the network and having knowledge of the topology of said network, wherein said network controller is configured to determine the number of disjoint network paths available between said sender and said receiver and, based on said number, to trigger the establishment of additional subflows between said sender and said receiver along network paths being at least partially disjoint to said first network path.
  • the network controller which is assumed to have knowledge of the network topology, may comprise a logic integrated with and/or executable by a processor of the network controller, wherein the logic is configured to calculate the number of available disjoint paths. Based on this number, the network controller applies an algorithm for selecting and establishing additional forwarding paths inside the network and triggers the establishment of new subflows along these paths, thereby increasing path multiplicity. It should be noted that the network paths calculated by the network controller do not necessarily have to be disjoint completely.
  • partially disjoint paths can be beneficial to use, if a bottleneck link can be augmented or replaced by multiple other paths through the network. Up until the branching points, the paths will share certain links, but will be placed on disjoint ones for other hops in the path. Such a setup can still improve throughput as congested links can be sidestepped.
  • Embodiments of the present invention allow the use of multiple networking paths with the minimum number of subflows necessary, even if the endpoints do not have multiple network interfaces or multiple (IP) addresses, and even if they do not know about the existence of the different network paths.
  • the presented method is even most useful if the clients to be connected are multipath capable, but possess only a single network interface. In this situation, multiple subflows could still be opened, but an endpoint without topology knowledge will not know what the actual number of disjoint paths available for different subflows is. Opening too many subflows incurs overhead, which can be avoided by embodiments of the present invention.
  • the implemented functions do not require any changes to the networking stacks in the connection endpoints.
  • any manual settings on the connection endpoints and/or on the network equipment in order to increase the number of network paths becomes dispensable due to the quasi automation of this process achieved by the present invention.
  • the method and system according to the present invention allow for optimal number of subflows between individual logical endpoint connections.
  • packet-based load-balancing avoids reordering and enables joint congestion control over subflows.
  • connection endpoints In comparison to solutions where connection endpoints just open a large number of subflows until all disjoint network paths are used, or perform tests by removing 'slow' subflows and trying new ones, an implementation of the present invention significantly reduces the overhead on the connection endpoints.
  • the network controller may trigger the establishment of additional subflows between two endpoints of an existing connection by creating messages that contain an option of announcing additional addresses on which said connection endpoints can be reached, and injecting these messages into the network, e.g. into data streams towards the connection endpoints.
  • a multipath protocol that allows for the extraction of the necessary information to create protocol-conformant address announcements proves to be beneficial.
  • the above mentioned option of announcing additional addresses could be, e.g., the add address option 'ADD_ADDR' as implemented in MPTCP.
  • the network paths of the additional subflows may have forwarding rules that are based on virtual destination addresses for the two connection endpoints.
  • the network controller may announce these virtual destination addresses in the network to be used by the connection endpoints for establishing the additional subflows. From the perspective of a connection endpoint, the announced additional virtual addresses seem to belong to the remote endpoint of the connection (i.e. the connection endpoints are not aware of the announced addresses being virtual), thus implicitly informing the endpoints of the number of available paths. The connection endpoints will then in turn establish new subflows between each other using said virtual addresses.
  • the virtual addresses may be translated within the network to simulate the necessary number of interfaces to both endpoints.
  • the network controller may install appropriate address translation rules in the network, for instance in those switches that are the topologically closest to the sender and to the receiver, respectively.
  • the network thus functions as a NAT (Network Address Translation) component.
  • the network controller may prevent direct establishment of additional subflows between the sender and the receiver, i.e. the 'normal' establishment of subflows following the respective multipath protocol where the connection endpoints use their known addresses. For instance, such a prevention of direct subflow establishment may be achieved by blocking signaling packets related to any additional subflow handshake, e.g. MP_JOIN packets in the case of using MPTCP).
  • the network controller generally allows direct establishment of additional subflows between the sender and the receiver.
  • the network controller may perform monitoring of those subflows established by the sender directly.
  • the network controller applies a tracking mechanism for tracking multipath protocol control packets and for retaining information about existing multipath connections and dependent subflows.
  • the tracking mechanism may identify which subflows belong to the same connection between the two connection endpoints. Subflows identified by this tracking mechanism may then be forwarded by the network controller on paths as disjoint as possible.
  • the tracking mechanism may include informing the network controller of the initial handshake packets for the connection between the sender and the receiver (e.g., in case of using MPTCP, an MPTCP SYN with MP_CAPABLE option) and storing relevant parameters of this connection (e.g., MPTCP tokens).
  • This tracking of MPTCP tokens in the controller which is not part of the data end-to-end connection, will enable the controller to know dependent subflows and to place dependent subflows on different network paths.
  • the tracking mechanism may include monitoring address announcements originating from the connection endpoints (e.g., in case of using MPTCP, ADD_ADDR packets) and performing predictions of the establishment of any new subflows to such an announced address shortly after the announcement.
  • Fig. is a schematic view illustrating exemplarily the establishment of a new subflow triggered by a network controller in accordance with embodiments of the present invention.
  • Embodiments of the present invention relate to implementations that use the MPTCP (Multipath TCP) protocol and software-defined networking (SDN) mechanisms.
  • MPTCP Multipath TCP
  • SDN software-defined networking
  • the present invention would be applicable also in the case of other protocols supporting multipath communications having similar characteristics as MPTCP, as well as with control mechanisms other than SDN that enable a controller entity to manage and control communication endpoints in the network.
  • MPTCP creates individual subflows for distinct address pairs created from the IP addresses of the two endpoints of a TCP connection. First, a single subflow is established, followed by setting up additional subflows. Alternative IP addresses of the server endpoint of a connection are communicated via MPTCP control messages to the client, which is then establishing additional subflows to these addresses based on the hope that paths to the additional addresses will follow separate network paths.
  • a data transfer network 1 having SDN capabilities is assumed.
  • the network controller 2 is managing the network 1 and therefore has knowledge of the devices that make up that network 1.
  • the controller 2 calculates all available disjoint network paths between these endpoints. Such calculation may be affected by the current load on the links participating in the network paths.
  • the controller 2 will trigger the creation of additional subflows.
  • the number of additionally triggered subflows is such that it exactly matches the difference between the calculated number of paths being available (and, possibly, being considered suitable by the network controller) and the number of existing subflows that have already been set up.
  • the triggering is achieved by generating address announcements in the network 1 and sending them to the endpoint that initiated the multipath connection, which in turn typically will try and establish a new subflow to this new address. It should be noted that the announced addresses do not need to correspond to actual interfaces on the endpoints, but can be handled transparently by the network 1.
  • this existing transport connection which is assumed to include three network switches 5 (denoted Sw1 , SwX, and Sw2), is indicated by a solid line and termed 'path P1 ⁇
  • the network controller 2 recognizes that the multipath-capable connection between sender 3 and receiver 4 (hereinafter sometimes briefly denoted 'connection S-R') has opened less subflows than there are disjoint paths available in the network 1. For instance, in the illustrated scenario it is assumed that there is the disjoint network path including the network switches 5 denoted Sw1 , SwY, and Sw2. In the figure this additional disjoint network path is indicated by a dotted line and termed 'path P2 ⁇
  • the network controller 2 establishes a new path in the network 1 , which is yet unused by any subflow of the connection S-R.
  • This path has forwarding rules based on virtual destination addresses for the two endpoints, VAS and VAR for sender 3 and receiver 4, respectively. These virtual addresses (that distinguish different subflows without the endpoints being aware of these addresses being virtual) do not need to be assigned to any actual interface of sender 3 or receiver 4, and actually must not be assigned to any other interface.
  • the controller 2 also installs header-rewrite rules in the network 1 , specifically in switches Sw1 and Sw2.
  • the controller 2 announces VAR to the sender 3. This triggers the establishment of a new subflow from the sender 3. From the perspective of the sender 3, this subflow is between AS and VAR, but in effect it will be between AS and AR. However, due to the forwarding rules installed by the controller 2, it will take a path different from the path of the already established subflows between sender 3 and receiver 4, i.e. path P2 instead of path P1 of the initial subflow.
  • connection endpoints with only one network interface that are unaware of multiple paths between themselves can be triggered to use the right number of subflows to exploit disjoint paths in the network.
  • each can increase the number of subflows based on its local observations of available paths and with a destination address selected to facilitate routing/forwarding in its own network.
  • the method described above also works if the endpoints of a connection, i.e. sender 3 and/or receiver 4, have multiple interfaces configured.
  • the controller 2 can choose between the following options: According to one implementation (option 1 ), the controller 2 can prevent the 'normal' (i.e., following standard MPTCP, for instance) establishment of subflows between the sender 3 and the receiver 4 using their known addresses, e.g., by blocking the signaling packets (such as MP_JOIN) used for this subflow handshake.
  • the controller 2 can prevent the 'normal' (i.e., following standard MPTCP, for instance) establishment of subflows between the sender 3 and the receiver 4 using their known addresses, e.g., by blocking the signaling packets (such as MP_JOIN) used for this subflow handshake.
  • the controller 2 can allow the 'normal' (i.e., following standard MPTCP, for instance) establishment of subflows (e.g., between all possible distinct pairs of addresses of the sender 3 and the receiver 4), with or without ensuring disjoint path forwarding for these flows.
  • Disjoint path forwarding can be ensured by letting the controller 2 track which subflows seen by its network 1 belong to the same bonded end-to-end connection, in order to forward them on paths as disjoint as possible, or according to other optimization criteria.
  • the controller 2 may be informed of the initial handshake packets for the connection between the sender 3 and the receiver 4 (e.g., an MPTCP SYN with MP_CAPABLE option), and the controller 2 can store relevant parameters of the connection (e.g., MPTCP tokens).
  • address announcements e.g., ADD_ADDR packets in MPTCP
  • preconfigured and known addresses may be used on both endpoints of the connection, enabling the mapping of addresses to subflows and thus disjoint forwarding. This might be possible within a datacenter environment, but is more difficult for WAN connections.
  • the controller 2 still could store the same information (i.e., tokens, IDs, keys, etc.) in order to be able to judge whether additional subflows over other paths would be beneficial for the connection S-R. Since the necessary effort is the same, the first mentioned implementation (i.e. option 1 ) would be preferable.
  • the controller 2 can always trigger the controlled establishment of new subflows using the method described above in case it recognizes this as beneficial.
  • the embodiment of the present invention described herein includes (part of) an SDN controller 2, e.g., OpenDaylight, for the use with the standardized MPTCP.
  • SDN allows for path establishment on the network elements, using e.g., OpenFlow.
  • a way of implementing the monitoring of client-established subflows includes listening to MPTCP ADD_ADDR options, with which end hosts can announce a useable address to the remote endpoint, then reactively establishing the path when a MP_JOIN packet is seen in reverse direction.
  • An alternative way includes collecting tokens exchanged between end hosts in the first handshake and storing them in a small database.
  • tokens are re-used when new subflows are established, allowing to reactively establish a new path for the new subflow and to announce new addresses in a valid fashion via existing subflows of a bundled connection.
  • the announcement of a new (virtual) address to an endpoint can be implemented by creating an OpenFlow packet_out message containing a valid TCP packet (such as a copy of an ACK) with the ADD_ADDR MPTCP option set and the known token/keys derived from the monitored initial connection handshake.

Landscapes

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

Abstract

La présente invention concerne un support de réseau défini par logiciel (SDN) destiné à une configuration à trajets multiples disjoints. L'invention permet à un module de gestion de réseau (2) comportant des fonctions de gestion de réseau et de trafic et ayant une connaissance de la topologie de réseau pour prendre en charge et commander des connexions à trajets multiples, d'optimiser la sélection de trajets et le nombre de sous-flux pour ces connexions. Ces fonctions peuvent être mises en œuvre sans aucune modification des empilements de réseaux clients. L'invention comprend l'étape selon laquelle un émetteur (3) déclenche une connexion par trajets multiples avec un récepteur (4) et établit au moins un sous-flux entre l'émetteur (3) et le récepteur (4) le long d'un premier trajet de réseau ; et l'étape selon laquelle le module de gestion de réseau (2) détermine le nombre de trajets de réseau disjoints, disponibles entre l'émetteur (3) et le récepteur (4) et, sur la base de ce nombre, déclenche l'établissement de sous-flux supplémentaires entre l'émetteur (3) et le récepteur (4) le long de trajets de réseau au moins partiellement disjoints vers le premier trajet de réseau.
PCT/EP2016/055929 2016-03-18 2016-03-18 Support de sdn destiné à une configuration à trajets multiples disjoints Ceased WO2017157457A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/055929 WO2017157457A1 (fr) 2016-03-18 2016-03-18 Support de sdn destiné à une configuration à trajets multiples disjoints

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/055929 WO2017157457A1 (fr) 2016-03-18 2016-03-18 Support de sdn destiné à une configuration à trajets multiples disjoints

Publications (1)

Publication Number Publication Date
WO2017157457A1 true WO2017157457A1 (fr) 2017-09-21

Family

ID=55699606

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/055929 Ceased WO2017157457A1 (fr) 2016-03-18 2016-03-18 Support de sdn destiné à une configuration à trajets multiples disjoints

Country Status (1)

Country Link
WO (1) WO2017157457A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10659569B1 (en) 2019-01-18 2020-05-19 Hewlett Packard Enterprise Development Lp End-to-end multipath TCP through network gateways
US10708170B2 (en) 2018-03-14 2020-07-07 At&T Intellectual Property I, L.P. Transferring data over multiple network paths using decoupled sub-flows
CN114567582A (zh) * 2022-02-24 2022-05-31 南京航空航天大学 一种基于路径跟踪反馈的sdn网络可信路由调度方法
US12342259B2 (en) 2019-11-07 2025-06-24 Nokia Solutions And Networks Oy Core network support for transport network path diversity for URLLC user plane

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140362765A1 (en) * 2013-06-06 2014-12-11 Apple Inc. Multipath TCP Subflow Establishment and Control
US9112794B2 (en) * 2013-11-05 2015-08-18 International Business Machines Corporation Dynamic multipath forwarding in software defined data center networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140362765A1 (en) * 2013-06-06 2014-12-11 Apple Inc. Multipath TCP Subflow Establishment and Control
US9112794B2 (en) * 2013-11-05 2015-08-18 International Business Machines Corporation Dynamic multipath forwarding in software defined data center networks

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
GREGORY D ET AL.: "Revisiting Flow-Based Load Balancing: Stateless Path Selection in Data Center Networks", COMPUTER NETWORKS, vol. 57, no. 5, 7 April 2013 (2013-04-07), pages 1204 - 1216, XP028527013, DOI: doi:10.1016/j.comnet.2012.12.011
JINGPU DUAN; ZHI WANG; CHUAN WU: "Responsive Multipath TCP in SDN-based Datacenters", PROCEEDINGS OF IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS (IEEE ICC 2015, 8 June 2015 (2015-06-08)
MATTHIEU COUDRON; STEFANO SECCI; GUIDO MAIER; GUY PUJOLLE; ACHILLE PATTAVINA: "Boosting Cloud Communications through a Crosslayer Multipath Protocol Architecture", 2013 IEEE SDN FOR FUTURE NETWORKS AND SERVICES (SDN4FNS), 11 November 2013 (2013-11-11), pages 1 - 8, XP032540939, DOI: 10.1109/SDN4FNS.2013.6702535 *
MATTHIEU COUDRON; STEFANO SECCI; GUIDO MAIER; GUY PUJOLLE; ACHILLE PATTAVINA: "Boosting Cloud Communications through a Crosslayer Multipath Protocol Architecture", 2013 IEEE SDN FOR FUTURE NETWORKS AND SERVICES (SDN4FNS, November 2013 (2013-11-01)
MATTHIEU COUDRON; STEFANO SECCI; GUY PUJOLLE; PATRICK RAAD; PASCAL GALLARD: "Cross-layer Cooperation to Boost Multipath TCP Performance in Cloud Networks", 2013 IEEE 2ND INTERNATIONAL CONFERENCE ON CLOUD NETWORKING (CLOUDNET), 11 November 2013 (2013-11-11), pages 58 - 66, XP032550296, DOI: 10.1109/CloudNet.2013.6710558 *
MATTHIEU COUDRON; STEFANO SECCI; GUY PUJOLLE; PATRICK RAAD; PASCAL GALLARD: "Cross-layer Cooperation to Boost Multipath TCP Performance in Cloud Networks", CLOUD NETWORKING (CLOUDNET, 2013
SAVVAS ZANNETTOU ET AL: "Exploiting path diversity in datacenters using MPTCP-aware SDN", 2016 IEEE SYMPOSIUM ON COMPUTERS AND COMMUNICATION (ISCC), 30 November 2015 (2015-11-30), pages 539 - 546, XP055318143, ISBN: 978-1-5090-0679-3, Retrieved from the Internet <URL:https://arxiv.org/pdf/1511.09295v1.pdf> [retrieved on 20161110], DOI: 10.1109/ISCC.2016.7543794 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10708170B2 (en) 2018-03-14 2020-07-07 At&T Intellectual Property I, L.P. Transferring data over multiple network paths using decoupled sub-flows
US10659569B1 (en) 2019-01-18 2020-05-19 Hewlett Packard Enterprise Development Lp End-to-end multipath TCP through network gateways
DE102020100211B4 (de) 2019-01-18 2023-08-31 Hewlett Packard Enterprise Development Lp End-To-End Multipath TCP durch Netzwerk Gateways
US12342259B2 (en) 2019-11-07 2025-06-24 Nokia Solutions And Networks Oy Core network support for transport network path diversity for URLLC user plane
CN114567582A (zh) * 2022-02-24 2022-05-31 南京航空航天大学 一种基于路径跟踪反馈的sdn网络可信路由调度方法
CN114567582B (zh) * 2022-02-24 2022-11-22 南京航空航天大学 一种基于路径跟踪反馈的sdn网络可信路由调度方法

Similar Documents

Publication Publication Date Title
CN111886833B (zh) 重定向控制信道消息的方法和用于实现该方法的设备
US10218629B1 (en) Moving packet flows between network paths
EP3295654B1 (fr) Configuration d&#39;éléments de réseau pour le routage fondé sur des directives automatisé
US9065768B2 (en) Apparatus for a high performance and highly available multi-controllers in a single SDN/OpenFlow network
JP6527880B2 (ja) フロールーティング、スケーラビリティおよびセキュリティの向上を伴う、自律システム内および自律システム間のトラフィックのソフトウェア定義ルーティングのためのシステムならびに方法
US9215175B2 (en) Computer system including controller and plurality of switches and communication method in computer system
US9806994B2 (en) Routing via multiple paths with efficient traffic distribution
EP2157746B1 (fr) Système de commande de routage dans un L3VPN réseau de service
US9331941B2 (en) Traffic flow redirection between border routers using routing encapsulation
US10938724B2 (en) Flow rate based network load balancing
US20140192645A1 (en) Method for Internet Traffic Management Using a Central Traffic Controller
US11831549B2 (en) Device and method for load balancing
WO2014194423A1 (fr) Procédé et appareil pour assurer une distribution de flux de réseau défini par logiciel
EP3474504B1 (fr) Publicité de bande passante de liaison montante leaf-to-spine vers des serveurs connectés leaf
US10382323B1 (en) Flooding-based routing protocol having label switched path session information
US9736066B2 (en) Method, apparatus and system for establishing optical bypass
WO2017157457A1 (fr) Support de sdn destiné à une configuration à trajets multiples disjoints
WO2017144123A1 (fr) Équilibreur de charge pour clients et serveurs ayant des capacités de chemins multiples
US10326663B2 (en) Fabric-wide bandth management
JP2022510306A (ja) 信号中継局（ｓｔｐ）のメッセージプロセッサ間でｓｉｇｔｒａｎ接続を分散させる方法、システム、および読み取り可能な媒体
JP6466595B2 (ja) パケット処理における適応負荷バランシング
EP3621251A1 (fr) Traitement de paquets
US12425472B2 (en) Method to prioritize and offload mobile edge cloud traffic in 5G
CN112585910B (zh) 在广域网中建立安全、低延迟、优化路径的方法和装置
CN109067608A (zh) 一种测算ip包从设备到公网网关之间跳数的方法

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 16715251

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16715251

Country of ref document: EP

Kind code of ref document: A1