CN107979500B - Method for realizing path detection based on Openflow protocol, network system and Openflow switch - Google Patents
Method for realizing path detection based on Openflow protocol, network system and Openflow switch Download PDFInfo
- Publication number
- CN107979500B CN107979500B CN201610918493.6A CN201610918493A CN107979500B CN 107979500 B CN107979500 B CN 107979500B CN 201610918493 A CN201610918493 A CN 201610918493A CN 107979500 B CN107979500 B CN 107979500B
- Authority
- CN
- China
- Prior art keywords
- openflow
- message
- switch
- openflow switch
- controller
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/10—Packet switching elements characterised by the switching fabric construction
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention relates to a method for realizing path detection based on an Openflow protocol, a network system and an Openflow switch. The first Openflow switch generates a TraceBack message and sends the TraceBack message to the controller, and the controller sends the TraceBack message to the second Openflow switch. And the second Openflow switch initiates backhaul path detection based on the traceBack message, generates a traceResult message containing a backhaul path detection result, and sends the traceResult message to the controller. The controller sends a TraceResult message containing the backhaul path probing result to the first Openflow switch.
Description
Technical Field
The present invention relates to the field of Software Defined Networking (SDN) and Network Function Virtualization (NFV), and more particularly, to implementing bidirectional path probing of a packet transmission path based on an Openflow protocol in a centralized network environment.
Background
In recent years, the industry has proposed a new network innovation architecture called SDN. SDN separates the control plane and data plane of a network, and directly controls underlying network devices (e.g., switches) through a software platform in a controller, thereby making the network more intelligent as a pipeline. The Openflow protocol is a main interaction protocol between the SDN controller and the switch, and the controller realizes centralized control over forwarding of data streams on the switch based on the Openflow protocol.
The Openflow protocol supports three types of messages: controller-to-switch messages, asynchronous messages, and symmetric messages, most of which are initiated by the controller, but also support the switches to actively report relevant information, such as PortStatus, Error, TableStatus, etc.
Meanwhile, in order to know network transmission conditions in end-to-end communication, a transmission path of a data packet needs to be detected, and even bidirectional path detection is needed to know network conditions of both a forward path (from a source endpoint to a destination endpoint) and a backhaul path (from the destination endpoint to the source endpoint). In a conventional network environment, path probing is generally implemented by a TraceRoute or Tracert command, but this can only implement unidirectional path probing. Backhaul path probing generally requires notifying peers to initiate in an out-of-band manner.
However, in the current network architecture based on the Openflow protocol, there are no mechanisms and messages actively initiated by the switch to request the peer device to perform backhaul path probing. The mechanism and the message are key links for realizing end-to-end bidirectional path detection based on the Openflow protocol.
Disclosure of Invention
In order to solve the above-mentioned problems, the invention provides a method for realizing automatic detection of a bidirectional transmission path based on an extended Openflow message under an SDN architecture, and providing basic data for service-oriented bidirectional quality assurance.
According to an aspect of the present invention, there is provided a method for implementing path probe based on an Openflow protocol, configured to obtain information of backhaul path probe from a second Openflow switch to a first Openflow switch, where the method includes: generating, by a first Openflow switch, a first Openflow message and sending the first Openflow message to a controller, where the first Openflow message includes address information of the first Openflow switch and a second Openflow switch, and information indicating initiation of the backhaul path probe; sending, by the controller, the first Openflow message to a second Openflow switch; in response to receiving the first Openflow message, the second Openflow switch initiates backhaul path probing to the first Openflow switch; generating and sending a second Openflow message to the controller by the second Openflow switch, wherein the second Openflow message contains a result of the backhaul path probing; sending, by the controller, the second Openflow message to the first Openflow switch.
Preferably, the first Openflow message contains a type field indicating that the second Openflow switch is requested to initiate the backhaul path probing.
Preferably, the second Openflow message contains a type field indicating that the result of the backhaul path probing is contained.
Preferably, the second Openflow switch initiates backhaul path probing to the first Openflow switch in response to detecting the information indicating initiation of the backhaul path probing after receiving the first Openflow message.
Preferably, backhaul path probing is achieved by a Traceroute or Tracert command.
Preferably, the address information is an IP address.
Preferably, the information about the result of the backhaul probing comprises one or more of: the number of hops; time delay and jitter of each hop; the address reached by each hop.
According to another aspect of the present invention, there is provided an Openflow protocol-based network system, including a first Openflow switch, a second Openflow switch, and a controller, wherein the first Openflow switch is configured to generate and send a first Openflow message to the controller, wherein the first Openflow message includes address information of the first Openflow switch and the second Openflow switch, and information indicating initiation of backhaul path probing from the second Openflow switch to the first Openflow switch; the second Openflow switch is configured to: receiving a first Openflow message from a controller; in response to receiving the first Openflow message, initiating backhaul path probing to the first Openflow switch; generating a second Openflow message and sending the second Openflow message to the controller, wherein the second Openflow message contains the result of the backhaul detection; and the controller is configured to send the first Openflow message to the second Openflow switch and to send the second Openflow message to the first Openflow switch.
According to another aspect of the present invention, there is provided an Openflow switch, including: a processor; a memory having stored thereon executable instructions that, when executed by the processor, cause the processor to perform the steps of: a first Openflow message is generated and sent to the controller, where the first Openflow message contains address information of the Openflow switch and another Openflow switch and information indicating initiation of backhaul path probing from the another Openflow switch to the Openflow switch.
According to another aspect of the present invention, there is provided an Openflow switch, including: a processor; a memory having stored thereon executable instructions that, when executed by the processor, cause the processor to perform the steps of: receiving a first Openflow message from a controller, wherein the first Openflow message includes address information of another Openflow switch and the Openflow switch and information indicating initiation of backhaul path probing from the Openflow switch to the another Openflow switch; initiating, in response to receiving the first Openflow message, backhaul path probing to the another Openflow switch; a second Openflow message is generated and sent to the controller, wherein the second Openflow message contains a result of the backhaul path probing.
Drawings
FIG. 1 illustrates an Openflow protocol based network architecture;
FIG. 2 illustrates the encapsulation of Openflow messages;
fig. 3 illustrates a message interaction flow for backhaul path probing according to an embodiment;
FIG. 4 illustrates the type fields of a TraceBack message and a TraceResult message according to an embodiment;
FIG. 5 illustrates an example of encapsulation of a TraceBack message according to an embodiment; and
figure 6 illustrates an example of encapsulation of a TraceResult message according to an embodiment.
Detailed Description
Embodiments according to the present invention will be described below with reference to the accompanying drawings.
Fig. 1 illustrates the basic architecture of an Openflow protocol based network. As shown in fig. 1, the Openflow protocol-based network is mainly composed of a controller and an Openflow switch. The Openflow protocol implements a separation of a data plane and a control plane, where an Openflow switch performs a forwarding function of the data plane and a controller performs a control function of the control plane. And the Openflow switch and the controller interact according to an Openflow protocol.
An Openflow switch is a core component of the entire network. It should be noted that the term "Openflow switch" used herein refers to a switch defined in the Openflow protocol, which may be a dedicated Openflow switch or a general switch supporting the Openflow protocol. Dedicated Openflow switches, which may not typically support layer two and layer three processing, are "dumb" data path elements that forward packets between ports as controlled by a controller. Some general purpose ethernet switches and routers may also obtain Openflow features by adding flow tables, secure channels, and the Openflow protocol (described in detail below).
An Openflow switch consists of at least three parts:
1. the flow table comprises a plurality of flow table entries, each flow table entry is a forwarding rule in essence and is used for telling the Openflow switch how to process the data packet entering the switch, and the Openflow switch only forwards the data according to the flow table;
2. the secure channel is connected with the Openflow switch and the controller and allows commands and message packets to be sent between the Openflow switch and the controller according to an Openflow protocol;
3. the Openflow protocol is used for describing an interactive message standard and an interface standard between the Openflow switch and the controller.
The controller controls the flow table in the Openflow switch (for example, adding, removing or modifying a flow table entry) through the standard interface of the Openflow protocol, thereby implementing centralized control over the Openflow switch.
The Openflow protocol defines the encapsulation of interactive messages between the controller and the Openflow switch.
As shown in fig. 2, the Openflow message begins with an Openflow header. The Openflow header contains the following fields:
version (version): version of the Openflow protocol;
type (type): indicated by a constant of 8 bits, indicating the type of Openflow message, such as "HELLO", "FLOW _ MOD", etc.;
length (length): indicating the length of the entire message packet containing the header;
xid: the transaction id (transaction id) associated with the message packet.
The Openflow message also includes a payload portion. The structure of the payload portion is related to the specific message type.
As will be described below, one aspect of the present invention is to extend Openflow messages and utilize the extended Openflow messages to enable convenient, reliable bidirectional transmission path probing.
Conventionally, if a particular endpoint (hereinafter referred to as a source endpoint) wants to know the network condition of a bidirectional transmission path between the particular endpoint and another endpoint (hereinafter referred to as a destination endpoint), on one hand, the source endpoint can directly initiate unidirectional path detection from the source endpoint to the destination endpoint (forward path detection), and on the other hand, the source endpoint needs to inform the destination endpoint in an out-of-band manner to initiate unidirectional path detection from the destination endpoint to the source endpoint (backhaul path detection), thereby implementing bidirectional path detection. Since there are already many implementations of forward path probing in the art, the present document will focus on the implementation of backhaul path probing, especially under a network architecture based on the Openflow protocol.
A flow of implementing backhaul path probing with the extended Openflow message will be described below with reference to fig. 3. In the embodiment of the present invention, for the purpose of aspect description, it is assumed that the source endpoint is Openflow switch a and the destination endpoint is Openflow switch B. However, depending on the scenario in which the invention is applied, the source and/or destination end points of the path probe may also be other devices in the network, e.g. end point devices connected to an Openflow switch.
As described in fig. 3, in step S1, Openflow switch a generates a TraceBack message and sends the message to the associated controller.
The TraceBack message is an extended Openflow message that contains source address information of the source endpoint, destination address information of the destination endpoint, and information indicating that backhaul path probing is initiated.
In an embodiment, the TraceBack message contains, in its payload portion, address information of the Openflow switch a and the Openflow switch B, for example, IP addresses of the Openflow switch a and the Openflow switch B. However, the source and destination address information may also be management addresses or other types of address information that can be used to address the source and destination endpoints.
In addition to address information, the TraceBack message contains information about the initiation of the backhaul path probe, based on which the controller can send the TraceBack message to Openflow switch B after receiving it, and Openflow switch B can initiate the backhaul path probe to Openflow switch a. In an embodiment, information related to the initiation of backhaul sounding is contained in the header of the TraceBack message. For example, the type field of the TraceBack message is defined to have a specific value Vtb to identify the type of the message.
In step S2, the controller receives the TraceBack message from the Openflow switch a and sends it to the Openflow switch B.
The controller parses the received TraceBack message. The controller detects that the type field in the header of the TraceBack message is a particular value Vtb and, in response to this detection, the controller determines that the message is to be forwarded. The controller may also detect destination address information contained in the payload portion of the TraceBack message. Typically, the controller stores routing information to the switch or retrieves routing information to the switch. Thus, the controller may send a TraceBack message to Openflow switch B.
There may be cases where the controller controlling Openflow switch a and the controller controlling Openflow switch B are different. In this case, the transmission of messages between the controllers may occur. For example, a controller that receives a TraceBack message may route the message to another controller that controls Openflow switch B according to the address information of Openflow switch B, and send the TraceBack message to Openflow switch B by the controller.
In step S3, the Openflow switch B initiates backhaul path probing in response to receiving the TraceBack message.
The Openflow switch B receives the TraceBack message from the controller and analyzes the received message. Switch B detects that the type field in the header of the TraceBack message is a particular value Vtb. In response to this detection, Openflow switch B will determine to initiate backhaul path probing. Openflow switch B may also detect source address information contained in the payload portion of the TraceBack message and, based on the source address information, initiate backhaul path probing to the source endpoint (Openflow switch a).
Path detection may be performed in various ways. For example, in the Linux environment, Traceroute command may be used. For example, in a Windows environment, a Tracert command may be employed for implementation. It should be noted that in the present invention, various path detection methods may be applied as long as the network condition regarding the transmission path from the destination end point to the source end point can be acquired. Results obtained by path exploration include, but are not limited to: total number of hops from Openflow switch B to Openflow switch a, time delay and jitter of each hop, and passed switch address.
In step S4, the Openflow switch B generates a TraceResult message and sends the message to the controller.
Openflow switch B uses TraceResult messages to communicate the results of backhaul path probing. In addition to the results of the backhaul path probing, the TraceResult message may also include address information, in particular source address information, in order to send the message to the source endpoint, Openflow switch a, that desires to obtain the backhaul path probing results. Switch B sends the generated TraceResult message to the controller.
Finally, in step S5, the controller sends a TraceResult message to Openflow switch a.
The controller parses the received TraceResult message. The controller detects that the type field in the header of the TraceResult message is a particular value Vtr. In response to the detection, the controller determines that the message is to be forwarded. The controller may also identify source address information contained in the payload portion of the TraceResult message. And according to the identified source address information, the controller sends a TraceResult message to the Openflow switch A.
After receiving the TraceResult message from the controller, the Openflow switch a may obtain a result of backhaul path probing from the Openflow switch B to the Openflow switch a.
Openflow switch a may also perform forward path probing to Openflow switch B. Thereby, the network condition of the bidirectional transmission path between the Openflow switch a and the Openflow switch B can be obtained at the Openflow switch a. Based on the probing situation of the bidirectional transmission path, for example, a corresponding QoS report may be generated, providing useful information for service-oriented bidirectional transmission quality assurance.
The process of implementing backhaul path probing is described above with reference to the message interaction flow of fig. 3. It is noted that only the matters most closely related to the present invention have been described above, and some technical details have not been described in detail herein. For example, the transmission of messages between an Openflow switch and a controller may also involve the packetization and depacketization of message packets, and so on.
The TraceBack message and the TraceResult message used in the present embodiment will be described below with reference to fig. 4 to 6.
As shown in fig. 4, the Openflow message is extended by the TraceBack message and the TraceResult message of the present invention. In an embodiment, the TraceBack message and the TraceResult message are defined by defining/assigning a type field of the Openflow message. For example, the TraceBack message is defined by assigning a type field to a specific value Vtb. As another example, the TraceResult message is defined by assigning a type field to a specific value Vtr. Where Vtb and Vtr are both well-defined constants.
Fig. 5 and 6 illustrate examples of encapsulation of the TraceBack message and the TraceResult message, respectively.
As shown in fig. 5, the payload portion of the TraceBack message contains the following fields:
field AT: indicating the address family to which the source and destination addresses belong, such as IPv4 or IPv 6;
and field SA: indicating a source address, 4 bytes or 16 bytes;
a field DA: indicating the destination address, 4 bytes or 16 bytes.
In addition to the above fields, the TraceBack message may also contain other information about the source endpoint and/or the destination endpoint.
As shown in fig. 6, the payload portion of the TraceResult message contains the following fields:
field AT: indicating the address family to which the source and destination addresses belong, such as IPv4 or IPv 6;
field Hop Num: indicating the total number of hops taken by the detection path;
and field SA: indicating a source address, 4 bytes or 16 bytes;
a field DA: indicating the destination address, 4 bytes or 16 bytes;
field Hop No.: indicating the hop count number;
field Delay: indicating the time delay of the current hop;
field Jitter: jitter indicating the current hop;
a field HA: indicating the address (e.g., IP address) that the current hop arrives at.
In the above fields, Hop Num, Hop No., Delay, Jitter, HA represent the result of backhaul path probing. However, the result of the backhaul path probing may also contain other information, such as bandwidth, packet loss rate, etc.
The invention has been described above with reference to embodiments. According to the embodiment of the invention, the bidirectional transmission path detection between the source end point and the destination end point can be realized based on the Openflow protocol. Especially for backhaul path probing, with the extended Openflow message, the peer can be easily informed to initiate backhaul path probing and return backhaul path probing results. This can conveniently obtain the network quality of the service-oriented bidirectional transmission path, thereby providing end-to-end path quality guarantee for specific services. This improves the scheduling and optimization capabilities of the operator or service provider for the traffic in the network.
In a preferred embodiment of the present invention, it is proposed to extend both signaling messages by defining the type field of the Openflow message header. Therefore, the existing network based on the Openflow protocol can be applied with the method only by making a slight extension, so that the method has good compatibility. In addition, the invention only needs the edge network devices (e.g., Openflow switches a and B) to support the extension of the Openflow protocol, while the intermediate network devices only need to support the traditional path probing commands such as TraceRoute, Tracert, etc., which makes the invention adaptable to various network deployment environments.
Embodiments of the present invention may be implemented by software, hardware or a combination thereof. For example, a controller, an Openflow switch, may perform actions as described in the embodiments above by a processor reading and executing program instructions stored on a computer readable storage medium. For example, embodiments of the invention may also be implemented in suitably programmed hardware (e.g., FPGA, ASII).
The embodiments of the present invention have been described, but it should be noted that various modifications may be made without departing from the scope of the present invention. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all modifications and equivalent structures and functions.
Claims (16)
1. A method for realizing path detection based on an Openflow protocol is used for obtaining information of backhaul path detection from a second Openflow switch to a first Openflow switch, and is characterized by comprising the following steps:
generating, by a first Openflow switch, a first Openflow message and sending the first Openflow message to a controller, where the first Openflow message includes address information of the first Openflow switch, address information of a second Openflow switch, and information indicating initiation of the backhaul path probe, and the first Openflow message is an extended Openflow message;
sending, by the controller, the first Openflow message to a second Openflow switch;
after receiving the first Openflow message, in response to detecting the information indicating to initiate the backhaul path probing, the second Openflow switch initiates backhaul path probing to the first Openflow switch;
generating and sending a second Openflow message to the controller by the second Openflow switch, wherein the second Openflow message contains a result of the backhaul path probing;
sending, by the controller, the second Openflow message to the first Openflow switch.
2. The method of claim 1, wherein the first Openflow message contains a type field indicating that the second Openflow switch is requested to initiate the backhaul path probing.
3. The method of claim 2, wherein the second Openflow message comprises a type field indicating that the result of the backhaul sounding is contained.
4. The method of any of claims 1-3, wherein the backhaul path probing is implemented via a Traceroute command.
5. The method according to any of claims 1-3, wherein the backhaul path probing is implemented by a Tracert command.
6. A method according to any of claims 1-3, characterized in that the address information is an IP address.
7. The method according to any of claims 1-3, wherein the information about the result of the backhaul path probing comprises one or more of: the number of hops; time delay and jitter of each hop; the address reached by each hop.
8. A network system based on Openflow protocol, the network system comprises a first Openflow switch, a second Openflow switch and a controller,
the first Openflow switch is configured to generate and send a first Openflow message to the controller, wherein the first Openflow message includes address information of the first Openflow switch, address information of the second Openflow switch, and information indicating initiation of backhaul path probing from the second Openflow switch to the first Openflow switch, and the first Openflow message is an extended Openflow message;
the second Openflow switch is configured to: receiving a first Openflow message from a controller; after receiving the first Openflow message, initiating backhaul path probing to a first Openflow switch in response to detecting the information indicating initiation of the backhaul path probing; generating a second Openflow message and sending the second Openflow message to the controller, wherein the second Openflow message contains the result of the backhaul detection; and is
The controller is configured to send the first Openflow message to the second Openflow switch and to send the second Openflow message to the first Openflow switch.
9. The networking system of claim 8, wherein the first Openflow message contains a type field indicating that the second Openflow switch is requested to initiate the backhaul path probing.
10. The network system of claim 9, wherein the second Openflow message comprises a type field indicating that the backhaul path probing result is included.
11. The network system according to any of claims 8-10, wherein the backhaul path probing is implemented by a Traceroute command.
12. The network system according to any of claims 8-10, wherein the backhaul path probing is implemented by a Tracert command.
13. Network system according to any of claims 8-10, characterized in that the address information is an IP address.
14. The network system according to any of claims 8-10, wherein the information about the result of the backhaul path probing comprises one or more of: the number of hops; time delay and jitter of each hop; the address reached by each hop.
15. An Openflow switch, comprising:
a processor;
a memory having stored thereon executable instructions that, when executed by the processor, cause the processor to perform the steps of:
generating a first Openflow message and sending the first Openflow message to a controller, wherein the first Openflow message includes address information of the Openflow switch, address information of another Openflow switch, and information indicating initiation of backhaul path probing from the other Openflow switch to the Openflow switch, and the first Openflow message is an extended Openflow message.
16. An Openflow switch, comprising:
a processor;
a memory having stored thereon executable instructions that, when executed by the processor, cause the processor to perform the steps of:
receiving a first Openflow message from a controller, wherein the first Openflow message includes address information of another Openflow switch, the address information of the Openflow switch, and information indicating initiation of backhaul path probing from the Openflow switch to the another Openflow switch, and the first Openflow message is an extended Openflow message;
after receiving the first Openflow message, initiating a backhaul path probe to the another Openflow switch in response to detecting the information indicating to initiate the backhaul path probe;
a second Openflow message is generated and sent to the controller, wherein the second Openflow message contains a result of the backhaul path probing.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610918493.6A CN107979500B (en) | 2016-10-21 | 2016-10-21 | Method for realizing path detection based on Openflow protocol, network system and Openflow switch |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610918493.6A CN107979500B (en) | 2016-10-21 | 2016-10-21 | Method for realizing path detection based on Openflow protocol, network system and Openflow switch |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107979500A CN107979500A (en) | 2018-05-01 |
| CN107979500B true CN107979500B (en) | 2020-04-17 |
Family
ID=62003746
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610918493.6A Active CN107979500B (en) | 2016-10-21 | 2016-10-21 | Method for realizing path detection based on Openflow protocol, network system and Openflow switch |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107979500B (en) |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5488841B2 (en) * | 2011-09-20 | 2014-05-14 | 日本電気株式会社 | Storage device |
| CN102918807B (en) * | 2012-07-12 | 2015-04-08 | 华为技术有限公司 | Method and routing equipment for BFD session establishment |
| WO2014055400A1 (en) * | 2012-10-05 | 2014-04-10 | Nec Laboratories America, Inc. | Network management |
| CN103401726B (en) * | 2013-07-19 | 2016-12-07 | 华为技术有限公司 | Network path detection method and device, system |
| CN104283738B (en) * | 2014-10-11 | 2018-07-17 | 新华三技术有限公司 | A kind of chain circuit detecting method and equipment |
| CN104780095A (en) * | 2015-04-30 | 2015-07-15 | 杭州华三通信技术有限公司 | Path detection method and device in SDN |
| CN105227393B (en) * | 2015-08-25 | 2019-05-31 | 上海斐讯数据通信技术有限公司 | A kind of bidirectional forwarding detection (BFD) method |
-
2016
- 2016-10-21 CN CN201610918493.6A patent/CN107979500B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN107979500A (en) | 2018-05-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11095546B2 (en) | Network device service quality detection method and apparatus | |
| US9503344B2 (en) | Data path performance measurement using network traffic in a software defined network | |
| KR100454502B1 (en) | Apparatus for providing QoS on IP router and method for forwarding VoIP traffic | |
| WO2019128950A1 (en) | Packet processing method, network node, and system | |
| US9667537B2 (en) | Transport system, packet transport apparatus, and packet transport method | |
| US9537741B2 (en) | Data path performance measurement using test messages in a software defined network | |
| US20190230039A1 (en) | Method and system for extracting in-tunnel flow data over a virtual network | |
| US10021023B2 (en) | Packet forwarding method, controller, forwarding device, and network system | |
| JP4033773B2 (en) | Method and apparatus for performing network routing | |
| CN105723657B (en) | Switch, controller, system and link quality detection method | |
| CN110943924B (en) | Method for segmenting source routing in a network and storage medium | |
| EP3742683B1 (en) | Method and device for processing packet by using unified sr label stack | |
| US10812373B2 (en) | Data network | |
| EP3142303A1 (en) | Network control method and apparatus | |
| GB2570697A (en) | Network testing | |
| EP4344137A2 (en) | Fast forwarding re-convergence of switch fabric multi-destination packets triggered by link failures | |
| TWI625050B (en) | Sdn-enabled network communication method and system | |
| WO2018219300A1 (en) | Method and apparatus for packet exchange in sdn | |
| US20190173776A1 (en) | Switch-enhanced short loop congestion notification for TCP | |
| CN107979500B (en) | Method for realizing path detection based on Openflow protocol, network system and Openflow switch | |
| JP6042838B2 (en) | Management system, management server, and management method | |
| CN110830373B (en) | Method and device for realizing QOS service quality differentiation of service in SDN network | |
| EP3224997A1 (en) | Communication path switching apparatus, method for controlling communication path switching apparatus, and computer program product | |
| KR101544106B1 (en) | method for access to SDN using single Ethernet port | |
| JP6472942B2 (en) | Switching control device, switching control method, and switching control program |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |