US20170142010A1 - Network operation rule - Google Patents
Network operation rule Download PDFInfo
- Publication number
- US20170142010A1 US20170142010A1 US15/127,445 US201415127445A US2017142010A1 US 20170142010 A1 US20170142010 A1 US 20170142010A1 US 201415127445 A US201415127445 A US 201415127445A US 2017142010 A1 US2017142010 A1 US 2017142010A1
- Authority
- US
- United States
- Prior art keywords
- network
- rule
- legacy
- rules
- 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.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- 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/74—Address processing for routing
- H04L45/745—Address table lookup; Address filtering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/20—Network management software packages
Definitions
- one or more network controllers may manage the control plane of network devices, such as switches, bridges and routers.
- the network controller may also manage the data plane of the switches by providing flow rules to the switches.
- the flow rules may have various attributes, such as match fields, meters, go-to instructions, and actions.
- the match fields of a flow rule establish a corresponding flow by setting commonalities shared by packets of the flow. During operation, if a match field is met by a packet then the network device performs the action on the packet. Accordingly, the match field establishes the action performed by device on the flow.
- Match fields may include various criteria, such as source or destination IP or MAC address, port numbers, transport protocol type, frame type, class of service indicators, or frame control information.
- Actions may include various operations that the switch can perform on packets, such as forwarding the packet to a specified port, dropping the packet, or forwarding the packet to the controller.
- FIG. 1 illustrates an example method of using a rule received from a network device to generate an SDN policy corresponding to the rule
- FIG. 2 illustrates an example method of collecting rules from a plurality of network devices and using the rules to generate an SDN policy
- FIG. 3 illustrates an example network device having a non-transitory computer readable medium storing instructions to transmit a rule for a legacy network operation to a network controller;
- FIG. 4 illustrates an example network device executing an SDN agent and a legacy rule reporting agent
- FIG. 5 illustrates an example controller including a rule collector, policy analyzer, and flow programmer.
- Network devices may perform various operations on received packets.
- network operations may include switching, bridging, routing, filtering, access control list (ACL) processing, quality-of-service (QoS) processing, packet header field rewriting, packet inspection, or data collection.
- ACL access control list
- QoS quality-of-service
- These network operations may be implemented as SDN operations using flow rules, or as non-SDN legacy operations.
- These legacy operations may be implemented using various agents executed on the network devices in non-standard or platform specific ways using platform specific rules.
- the legacy operation may be layer 2 Ethernet switching, virtual local area network (VLAN) isolation, layer 3 routing such as IPv4 or IPv6 routing, access control list (ACL) processing, filtering, or quality-of-service (QoS) processing.
- VLAN virtual local area network
- QoS quality-of-service
- Some network devices may capable of operating in a hybrid manner supporting both SDN operation and legacy operations.
- a hybrid network device may perform a legacy operation in a network slice implemented without SDN.
- the network slice may be defined by any network parameters that isolate packets on the network slice from other packets on the network.
- a network slice may be defined by a topology of connected network devices, a set of ports, a VLAN, a set of addresses, or by one or more match fields supported by an SDN flow rule.
- the network slice may be the entire network.
- a default flow rule is programmed in the network devices' flow tables to send all packets of the slice to a network controller.
- the OPENFLOW switches are programmed with a PKT_IN command for packets having match fields corresponding to the network slice.
- the controller determines a policy for how the packet and other packets of the same flow should be treated.
- the controller programs a more specific flow rule in all appropriate network devices to implement the policy. Large numbers of incoming flows may overwhelm the controller. Accordingly, the transition may be forced to proceed slower than desired to overwhelm the network controller. Additionally, each unknown flow will incur latency equal to the roundtrip delay to the controller plus the policy resolution delay at the network controller. This delay may negatively impact network performance and may cause packet drops caused by buffer overload at the controller.
- a network controller may obtain rules from the network devices under its control that reflect current operations, such as existing legacy network operations. These rules may be used by the controller to generate policies that implement the existing network operations. These policies may be implemented by SDN flow rules provided to the network devices. Accordingly, after proactively programming the network devices of a slice, the transition to SDN may occur with fewer unknown flows being forwarded to the network controller.
- FIG. 1 illustrates an example method of using a rule received from a network device to generate an SDN policy corresponding to the rule.
- the method may be performed by an SDN network controller, such as an OPENFLOW controller, to proactively program controlled network devices during transition from legacy operations to SDN controlled operations.
- the network device may be a hybrid network device capable of legacy operations as well as SDN operations.
- Block 101 may include obtaining a match field.
- the match field may be one of a set of match fields available for flow rules in an SDN protocol.
- the match field may be an input port field, an Ethernet destination or source address field, an Ethernet frame type, a VLAN identification (ID) or priority field, or an IP source or target address.
- block 101 may include obtaining one or more match fields.
- the match fields may be obtained from a network administrator.
- the match fields may define a network slice selected by an administrator to be transitioned to an SDN.
- block 101 may include obtaining a set of match fields with associated values or bitmasks.
- block 101 may include obtaining a set of port numbers for connected network devices or a specific VLAN ID.
- block 101 may include obtaining a set of match fields without associated values.
- the set of match fields may define a type of network slice and may correspond to a plurality of network slices of that type.
- Block 102 may include providing the match field to a network device.
- block 102 may include providing the match field over an SDN management connection to an SDN agent executed by the network device.
- block 102 may include providing the match field to an OPENFLOW agent executed at the control plane of an OPENFLOW switch.
- block 102 may include providing the match field to legacy operations executed by the network device.
- the match field may be provided by requesting a report for information corresponding to the match field.
- block 102 may include providing an identification of legacy applications that the network device should query for operations related to the match fields.
- a network administrator may be transitioning an ACL to an SDN implementation.
- the ACL operations on the network may involve fields overlapping with other legacy operations, such as routing operations.
- the identification of legacy applications may limit information received back from the network device to information pertinent to the network transition. For example, the identification of legacy applications may be included in the report request.
- Block 103 may include receiving a rule from the network device.
- the rule may correspond to an operation of the network device related to the match field.
- the operation may be an existing operation performed in a non-SDN manner that is based on the same parameters as reflected in the match field.
- the operation may be a routing decision, an ACL/QoS decision, a layer 2 forwarding decision, or a filtering rule such as a multicast filtering rule.
- the rule received in block 103 may be a flow rule formatted in accordance with an SDN protocol.
- the network device may generate a flow rule that reflects the existing operation.
- the rule received in block 103 may be a flow rule with source and destination MAC address match fields set to X and Y, and a forwarding action set to port Z.
- Receiving the rule in block 103 as a flow rule may allow rules received from different platforms to be compared in a normalized manner.
- the method may further include block 104 .
- Block 104 may include using the rule to generate an SDN policy corresponding to the operation.
- the SDN policy may be a set of flow rules that implement the operation in an SDN-compliant manner. For example, if the rule received in block 103 is a QoS rule setting the priority of packets matching certain source, destination, and type information, the SDN policy may be a flow rule having the corresponding source, destination, and type match fields and an action that reflects the priority.
- block 104 may include providing the SDN policy to a network administrator. For example, the policy may be provided as an option for programming an SDN network to maintain existing behavior.
- FIG. 2 illustrates an example method of collecting rules from a plurality of network devices and using the rules to generate an SDN policy.
- the method of FIG. 2 may be performed as an implementation of the method of FIG. 1 .
- the example method may include block 201 .
- Block 201 may include obtaining a set of match fields corresponding to a network slice.
- Block 201 may also include obtaining an identification of legacy applications or operations that correspond to the network slice.
- the match fields and legacy application or operation identification may be provided by a network administrator as part of transitioning a legacy network slice into SDN operation.
- the example method may further include block 202 .
- Block 202 may include providing the set of match fields to a plurality of network devices.
- block 202 may be an implementation of block 101 of FIG. 1 .
- block 202 may broadcasting the match fields to all network devices connected to a network controller implementing the method.
- block 202 may include individually sending or multicasting a request including the match fields to network devices in the network slice.
- the example method may also include block 203 .
- Block 203 may include receiving a plurality of rules from a subset of the plurality of network devices.
- the subset may be all network devices having a legacy operation corresponding to the set of match fields.
- the subset may be the entire plurality of network devices.
- Each rule may correspond to an operation of a network device of the subset and may be related to the match field or fields sent in block 201 .
- block 203 may be an implementation of block 103 of FIG. 1 .
- the example method may also include block 204 .
- Block 204 may include receiving a statistic related to the operation.
- the statistic may be a count of how many times the operation has been performed in an interval.
- the statistic may be a hit count of how many times the operation is performed in a day or an indication of when the operation was last performed.
- block 204 may include receiving statistics for the corresponding rules from each of network device of the subset of network devices.
- the example method may also include block 205 .
- Block 205 may include using the rules obtained in block 203 to generate an SDN policy.
- block 205 may be an implementation of block 104 of FIG. 1 .
- the rules may be used to identify flows that can be proactively programmed.
- flows that can be proactively preprogrammed may be any flow that can be implemented using the SDN protocol of the network.
- flows that can be proactively programmed may correspond to obtained rules that traverse the network slice.
- SDN policies may be determined based on the received rules in a prioritized manner.
- the statistics may be used to identify which flows to proactively preprogram.
- the SDN policy may be generated if the statistic or statistics for the operation exceeds a threshold.
- an administrator may define which rules have higher priorities for determining SDN policies. For example, SDN policies may be for rules having higher hit counts than other rule, for rules that correspond to more recent operations, or for rules that are identified as high priority by the administrator.
- the SDN policy corresponding to the operation may replicate the network behavior created by the operation.
- block 205 may include identifying an existing network path within the network slice from a subset of the received rules.
- Block 205 may include generating an SDN policy as a set of flow rules to implement the existing network path.
- block 205 may include identifying a network device that performs ACL or QoS operations.
- the SDN policy may be a rule for the same network device so that it continues to perform the ACL or QoS operations after being programmed with the rule.
- block 205 may include generating an SDN policy as a set of flow rules to implement a new network path derived from the existing network path.
- the new network path may take into consideration overriding requirements provided by a network administrator or the new network path may be generated using the existing path as a cost parameter in a routing application.
- block 205 may include identifying a new network device to perform ACL or QoS operations.
- the controller may determine that multiple network devices are performing ACL or QoS operations redundantly, and the policy may eliminate such redundancy.
- an administrator may identify a different network device that is responsible for ACL or QoS, and the controller may determine a network policy as a rule for the different network device that replicates the ACL or QoS behavior of the previous network device.
- the method may also include block 206 .
- Block 206 may include transmitting flow rules to network devices to implement the SDN policy. As described above, implementing the SDN policy may involve the same network devices performing the existing operations, or may involve different network devices. Accordingly, block 206 may include transmitting the flow rules to the same network devices providing the rules in block 203 . Block 206 may also include transmitting the flow rules to different network devices than the ones providing the rules in block 203 .
- the flow rules are transmitted to the network devices prior to SDN operations. Accordingly, after a transition to SDN-controlled operations, only flows that do not match the proactively instantiated flows will arrive at the controller. This may prevent the controller from being overloaded, reduce network congestion, and reduce the load on the network devices to send packets to the controller.
- the flow rules are transmitted during SDN operations after the controller receives a packet matching the flow rule from a network device.
- blocks 201 - 205 may be performed to proactively determine flow rules to implement the existing network behavior.
- those flow rules may only be provided to network devices when needed. This may reduce latency and reduce the computational load on the network controller.
- some flow rules are transmitted prior to SDN operation and some flow rules are provided on an as-needed basis.
- statistics used received in block 204 are used to determine whether to transmit a flow rule to implement the SDN policy. For example, flow rules may be sent to the devise if the hit count for the corresponding operation exceeds a certain threshold.
- flow table size limitations may prevent flow rules from being sent to implement SDN policies for all existing operations.
- the threshold may be set according to the flow table size limitations. For example, the threshold may be a percentage of the number of table entries, with some entries reserved for new operations.
- FIG. 3 illustrates an example network device 300 having a non-transitory computer readable medium 302 storing instructions to transmit a rule for a legacy network operation to a network controller.
- the network device 300 may be a hybrid device capable of performing legacy operations and SDN operations.
- the legacy operations may include a routing decision, an ACL/QoS decision, a layer 2 forwarding decision, or a filtering rule such as a multicast filtering rule.
- the SDN operations may include executing flow rules complying with an SDN protocol.
- the network device 300 may be capable of operating as an OPENFLOW switch.
- the example network device 300 may include a processor 301 .
- the processor 301 may execute various control plane applications.
- the control plane applications may include SDN applications including an SDN agent, such as an OPENFLOW agent, and a legacy flow reporting agent.
- the control plane applications may also include legacy applications, such as route managers, L2 address managers, ACL managers, QoS managers, or other non-SDN function-related applications. These applications may be stored as software instructions on a non-transitory computer readable medium, such as random access memory (RAM), read only memory (ROM), flash memory, or storage.
- the network device 300 may also include a network interface 303 .
- the network interface 303 may be used by the processor 301 to communicate with a network controller over an SDN management channel, such as an OPENFLOW channel.
- the medium 302 may store instructions 304 executable by the processor 301 to receive a match field from a network coordinator.
- the instructions 304 may be executable to receive a set of match fields from the network coordinator.
- the match fields may define a network slice to be transitioned from legacy operation to SDN operation.
- the instructions 304 may be executable to receive an identification of which legacy application to query for legacy operations.
- the match field and legacy application identification may be received in an information request packet sent by the network controller.
- the medium 302 may store instructions 305 executable by the processor 301 to query a legacy application to obtain a legacy network operation related to the received match field.
- the instructions 305 may be executed as part of execution of a legacy rule reporting agent and the legacy application may be executed on the processor 301 as well.
- the processor 301 may query the legacy application using inter-application communications.
- the legacy application queried may be an application identified in the transmission received in FIG. 3 .
- the instructions 305 may be executable to determine which legacy applications on the network device 300 may include rules applicable to the match field.
- the instructions 305 may be executable by the processor 301 to obtain identification of legacy network operations related to the match field from the legacy applications.
- the legacy network operations may be obtained as legacy rules, such as routing rules, bridging rules, ACL rules, or QoS rules.
- the instructions 305 may be further executable to obtain statistics related to the legacy network operations, such as hit counts or timestamps of last execution of the operations.
- the medium 302 may store further instructions 306 executable by the processor 301 to transmit a rule for the legacy network operation to the network controller.
- the transmitted rule is a flow rule
- the instructions 306 are executable to convert a legacy rule for the network operation into a flow rule.
- Instructions 306 may be further executable to transmit any statistics collected from the legacy applications to the network controller.
- FIG. 4 illustrates an example network device 401 executing an SDN agent 405 and a legacy rule reporting agent 404 .
- the network device 401 may be an implementation of the network device 300 of FIG. 3 .
- the example network device 401 may be capable of hybrid network operations, including legacy, non-SDN, network operations and SDN operations. Accordingly, the device 401 may include an SDN control plane 402 and a legacy control plane 403 . In some implementations, the control planes 402 , 403 may be executed as hardware functions, software applications stored on a non-transitory computer readable medium and executed by a processor, or combinations thereof.
- the device 401 may further include hardware resources 411 and ports 416 - 418 .
- the hardware resources 411 may include control application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), ternary content addressable memory (TCAM), or other hardware.
- Applications executed on the control planes 402 , 403 may control how packets received from hosts 419 - 421 on the ports 416 - 418 are treated by the device.
- the hosts 419 - 421 may be end devices or other network devices.
- the SDN control plane 402 may include an SDN agent 405 .
- the SDN agent 405 may connect to a network controller 415 over a management channel.
- the SDN agent 405 may receive flow rules from the controller 415 and program those flow rules into a flow table 414 .
- a flow table 414 may be implemented using hardware resources 411 .
- a flow table 414 may be implemented in software as instructions executed by a processor and stored on a computer readable medium.
- the a network device 401 may include a flow pipeline including flow tables implemented in software and flow tables implemented in hardware.
- the SDN control plane 402 may further include a legacy rule reporting agent 404 .
- Execution of the legacy rule reporting agent 404 may involve execution of the instructions 304 - 306 of FIG. 3 .
- the controller 415 may inform the reporting agent 404 on the network device 402 , and any other devices 402 in the network, about an impending network slice and match fields defining the slice.
- the agent 404 may query legacy applications 406 - 410 on the legacy control plane 402 to provide rules that they have configured that are related to the parameters on which the network slicing will be done.
- the legacy applications 410 may include a route manager 406 managing routes on a routing table 412 , a layer 2 address manager 407 managing a MAC table 413 , an ACL manager 408 , a QoS manager 409 , or other legacy application 410 .
- the legacy applications 406 - 410 may search their respective hardware or software agents and reply to the agent 404 with platform specific rules that they have programmed.
- the legacy applications 406 - 410 may further respond with rule priorities or statistics, if available.
- the agent 404 may convert the platform specific rules into SDN protocol-compliant flow rules and provide them to the network controller 415 via the SDN agent 405 .
- FIG. 5 illustrates an example controller 500 including a rule collector 501 , policy analyzer 502 , and flow programmer 503 .
- the controller 500 may be an SDN network controller able to connect to a network device, such as a network device 401 of FIG. 4 , and perform a method of generating an SDN policy, such as the method of FIG. 1 or 2 .
- the module 501 , 502 , 503 may be implemented as instructions stored on a non-transitory computer readable medium and executable by a processor.
- the controller 500 may include a rule collector 501 .
- the rule collector 501 may be configured to collect a rule for a legacy network operation corresponding to a match field from a first network device.
- the legacy network operation may be an access control operation, a quality of service operation, a forwarding operation, a filtering operation, or a multicast operation.
- the rule collector 501 may be able to query legacy rule reporting agents executed by network devices using a network interface 504 .
- the rule collector 501 may be able to perform block 101 - 103 of FIG. 1 .
- the rule collector 501 may collect a plurality of legacy rules corresponding to the match field from a corresponding plurality of network devices.
- the rule collector 501 may transmit a set of match fields corresponding to a network slice to a plurality of network devices and collect a set of rules from the plurality of network devices.
- the rule collector 501 may perform blocks 201 - 203 of FIG. 2 .
- the rule collector 501 may collect statistics related to legacy rules from network devices. For example, the rule collector 501 may collect a hit count for the legacy rule from a network device. The rule collector 501 may collect such statistics as described with respect to block 204 of FIG. 2 .
- the controller 500 may also include a policy analyzer 502 .
- the policy analyzer 502 may perform block 104 of FIG. 1 or block 205 of FIG. 2 .
- the policy analyzer may use the rule or rules provided by the rule collector 501 to determine a policy for packets matching the match field.
- the policy analyzer 502 may collate all rules received by the rule collector 501 , and determine a final set of SDN rules that can be programmed onto a set of network devices.
- the policy analyzer 502 may obtain an overriding requirement and determine the policy to meet the overriding requirement.
- the final set of SDN rules may implement a network behavior resulting from the legacy rules.
- the policy may mimic the operation of the network under the legacy rules consistent with any overriding requirements.
- the policy analyzer 502 may determine the policy from a subset of the rules meeting a rule priority requirement. In some cases, the policy analyzer 502 may receive a rule priority requirement from a network administrator. For the rule priority requirement may instruct the analyzer 502 to determine SDN rules based on which collected rules have a higher hit count, the most recently hit rules, or any other configured priority.
- the controller 500 may also include a flow programmer 503 .
- the flow programmer 503 may be configured to perform block 206 of FIG. 2 .
- the flow programmer may transmit a flow rule to implement the policy determined by the policy analyzer 502 .
- the flow programmer may transmit flow rules to all or a subset of network devices connected to the controller 500 via an interface 504 .
- the flow programmer 503 may use statistics related to the legacy rules to determine whether to transmit a flow rule to a network device.
- the flow programmer 503 may transmit a flow rule to a network device if the hit count for a corresponding legacy rule meets a threshold condition.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- In networks using software defined networking (SDN), one or more network controllers may manage the control plane of network devices, such as switches, bridges and routers. The network controller may also manage the data plane of the switches by providing flow rules to the switches. The flow rules may have various attributes, such as match fields, meters, go-to instructions, and actions. The match fields of a flow rule establish a corresponding flow by setting commonalities shared by packets of the flow. During operation, if a match field is met by a packet then the network device performs the action on the packet. Accordingly, the match field establishes the action performed by device on the flow. Match fields may include various criteria, such as source or destination IP or MAC address, port numbers, transport protocol type, frame type, class of service indicators, or frame control information. Actions may include various operations that the switch can perform on packets, such as forwarding the packet to a specified port, dropping the packet, or forwarding the packet to the controller.
- Certain examples are described in the following detailed description and in reference to the drawings, in which:
-
FIG. 1 illustrates an example method of using a rule received from a network device to generate an SDN policy corresponding to the rule; -
FIG. 2 illustrates an example method of collecting rules from a plurality of network devices and using the rules to generate an SDN policy; -
FIG. 3 illustrates an example network device having a non-transitory computer readable medium storing instructions to transmit a rule for a legacy network operation to a network controller; -
FIG. 4 illustrates an example network device executing an SDN agent and a legacy rule reporting agent; and -
FIG. 5 illustrates an example controller including a rule collector, policy analyzer, and flow programmer. - Network devices may perform various operations on received packets. For example, network operations may include switching, bridging, routing, filtering, access control list (ACL) processing, quality-of-service (QoS) processing, packet header field rewriting, packet inspection, or data collection. These network operations may be implemented as SDN operations using flow rules, or as non-SDN legacy operations. These legacy operations may be implemented using various agents executed on the network devices in non-standard or platform specific ways using platform specific rules. As examples, the legacy operation may be layer 2 Ethernet switching, virtual local area network (VLAN) isolation, layer 3 routing such as IPv4 or IPv6 routing, access control list (ACL) processing, filtering, or quality-of-service (QoS) processing.
- Some network devices, such as switches like bridges and routers, may capable of operating in a hybrid manner supporting both SDN operation and legacy operations. A hybrid network device may perform a legacy operation in a network slice implemented without SDN. The network slice may be defined by any network parameters that isolate packets on the network slice from other packets on the network. For example, a network slice may be defined by a topology of connected network devices, a set of ports, a VLAN, a set of addresses, or by one or more match fields supported by an SDN flow rule. In some cases, the network slice may be the entire network.
- In some cases, when transitioning a network slice to SDN-controlled operation is performed in a reactive manner. In a reactive transition, a default flow rule is programmed in the network devices' flow tables to send all packets of the slice to a network controller. For example, in an OPENFLOW SDN, the OPENFLOW switches are programmed with a PKT_IN command for packets having match fields corresponding to the network slice. After receiving a forwarded packet, the controller determines a policy for how the packet and other packets of the same flow should be treated. The controller then programs a more specific flow rule in all appropriate network devices to implement the policy. Large numbers of incoming flows may overwhelm the controller. Accordingly, the transition may be forced to proceed slower than desired to overwhelm the network controller. Additionally, each unknown flow will incur latency equal to the roundtrip delay to the controller plus the policy resolution delay at the network controller. This delay may negatively impact network performance and may cause packet drops caused by buffer overload at the controller.
- Aspects of the disclosed technology may allow transition a network slice to SDN in a proactive manner. A network controller may obtain rules from the network devices under its control that reflect current operations, such as existing legacy network operations. These rules may be used by the controller to generate policies that implement the existing network operations. These policies may be implemented by SDN flow rules provided to the network devices. Accordingly, after proactively programming the network devices of a slice, the transition to SDN may occur with fewer unknown flows being forwarded to the network controller.
-
FIG. 1 illustrates an example method of using a rule received from a network device to generate an SDN policy corresponding to the rule. For example, the method may be performed by an SDN network controller, such as an OPENFLOW controller, to proactively program controlled network devices during transition from legacy operations to SDN controlled operations. The network device may be a hybrid network device capable of legacy operations as well as SDN operations. - The example method may include
block 101. Block 101 may include obtaining a match field. For example, the match field may be one of a set of match fields available for flow rules in an SDN protocol. For example, the match field may be an input port field, an Ethernet destination or source address field, an Ethernet frame type, a VLAN identification (ID) or priority field, or an IP source or target address. In further implementations,block 101 may include obtaining one or more match fields. In some cases, the match fields may be obtained from a network administrator. For example, the match fields may define a network slice selected by an administrator to be transitioned to an SDN. - In some implementations,
block 101 may include obtaining a set of match fields with associated values or bitmasks. For example,block 101 may include obtaining a set of port numbers for connected network devices or a specific VLAN ID. In other implementations,block 101 may include obtaining a set of match fields without associated values. For example, the set of match fields may define a type of network slice and may correspond to a plurality of network slices of that type. - The example method may further include
block 102.Block 102 may include providing the match field to a network device. In some cases,block 102 may include providing the match field over an SDN management connection to an SDN agent executed by the network device. For example,block 102 may include providing the match field to an OPENFLOW agent executed at the control plane of an OPENFLOW switch. In other cases,block 102 may include providing the match field to legacy operations executed by the network device. For example, the match field may be provided by requesting a report for information corresponding to the match field. - In some implementations,
block 102 may include providing an identification of legacy applications that the network device should query for operations related to the match fields. For example, a network administrator may be transitioning an ACL to an SDN implementation. The ACL operations on the network may involve fields overlapping with other legacy operations, such as routing operations. The identification of legacy applications may limit information received back from the network device to information pertinent to the network transition. For example, the identification of legacy applications may be included in the report request. - The example method may further include
block 103.Block 103 may include receiving a rule from the network device. The rule may correspond to an operation of the network device related to the match field. The operation may be an existing operation performed in a non-SDN manner that is based on the same parameters as reflected in the match field. For example, depending on match fields providing inblock 102, the operation may be a routing decision, an ACL/QoS decision, a layer 2 forwarding decision, or a filtering rule such as a multicast filtering rule. In some implementations, the rule received inblock 103 may be a flow rule formatted in accordance with an SDN protocol. In these implementations, the network device may generate a flow rule that reflects the existing operation. For example, if the existing operation is a layer 2 forwarding decision to forward packets from MAC address X to MAC address Y on port Z, the rule received inblock 103 may be a flow rule with source and destination MAC address match fields set to X and Y, and a forwarding action set to port Z. Receiving the rule inblock 103 as a flow rule may allow rules received from different platforms to be compared in a normalized manner. - The method may further include
block 104.Block 104 may include using the rule to generate an SDN policy corresponding to the operation. The SDN policy may be a set of flow rules that implement the operation in an SDN-compliant manner. For example, if the rule received inblock 103 is a QoS rule setting the priority of packets matching certain source, destination, and type information, the SDN policy may be a flow rule having the corresponding source, destination, and type match fields and an action that reflects the priority. In some cases, block 104 may include providing the SDN policy to a network administrator. For example, the policy may be provided as an option for programming an SDN network to maintain existing behavior. -
FIG. 2 illustrates an example method of collecting rules from a plurality of network devices and using the rules to generate an SDN policy. For example, the method ofFIG. 2 may be performed as an implementation of the method ofFIG. 1 . - The example method may include block 201.
Block 201 may include obtaining a set of match fields corresponding to a network slice.Block 201 may also include obtaining an identification of legacy applications or operations that correspond to the network slice. For example, the match fields and legacy application or operation identification may be provided by a network administrator as part of transitioning a legacy network slice into SDN operation. - The example method may further include
block 202.Block 202 may include providing the set of match fields to a plurality of network devices. In some cases, block 202 may be an implementation ofblock 101 ofFIG. 1 . For example, block 202 may broadcasting the match fields to all network devices connected to a network controller implementing the method. As another example, block 202 may include individually sending or multicasting a request including the match fields to network devices in the network slice. - The example method may also include
block 203.Block 203 may include receiving a plurality of rules from a subset of the plurality of network devices. For example, the subset may be all network devices having a legacy operation corresponding to the set of match fields. In some case, the subset may be the entire plurality of network devices. Each rule may correspond to an operation of a network device of the subset and may be related to the match field or fields sent inblock 201. For example, block 203 may be an implementation ofblock 103 ofFIG. 1 . - The example method may also include
block 204.Block 204 may include receiving a statistic related to the operation. In some cases, the statistic may be a count of how many times the operation has been performed in an interval. For example, the statistic may be a hit count of how many times the operation is performed in a day or an indication of when the operation was last performed. In some cases, block 204 may include receiving statistics for the corresponding rules from each of network device of the subset of network devices. - The example method may also include
block 205.Block 205 may include using the rules obtained inblock 203 to generate an SDN policy. For example, block 205 may be an implementation ofblock 104 ofFIG. 1 . In some cases, the rules may be used to identify flows that can be proactively programmed. For example, flows that can be proactively preprogrammed may be any flow that can be implemented using the SDN protocol of the network. As another example, flows that can be proactively programmed may correspond to obtained rules that traverse the network slice. - In some implementations, SDN policies may be determined based on the received rules in a prioritized manner. In some cases, the statistics may be used to identify which flows to proactively preprogram. For example, the SDN policy may be generated if the statistic or statistics for the operation exceeds a threshold. In a further example, an administrator may define which rules have higher priorities for determining SDN policies. For example, SDN policies may be for rules having higher hit counts than other rule, for rules that correspond to more recent operations, or for rules that are identified as high priority by the administrator.
- In some implementations, the SDN policy corresponding to the operation may replicate the network behavior created by the operation. For example, block 205 may include identifying an existing network path within the network slice from a subset of the received rules.
Block 205 may include generating an SDN policy as a set of flow rules to implement the existing network path. As another example, block 205 may include identifying a network device that performs ACL or QoS operations. The SDN policy may be a rule for the same network device so that it continues to perform the ACL or QoS operations after being programmed with the rule. - In other implementations, the SDN policy corresponding to the operation may change the behavior of the network. For example, block 205 may include generating an SDN policy as a set of flow rules to implement a new network path derived from the existing network path. In some cases, the new network path may take into consideration overriding requirements provided by a network administrator or the new network path may be generated using the existing path as a cost parameter in a routing application. As another example, block 205 may include identifying a new network device to perform ACL or QoS operations. In some cases, the controller may determine that multiple network devices are performing ACL or QoS operations redundantly, and the policy may eliminate such redundancy. In other cases, an administrator may identify a different network device that is responsible for ACL or QoS, and the controller may determine a network policy as a rule for the different network device that replicates the ACL or QoS behavior of the previous network device.
- The method may also include
block 206.Block 206 may include transmitting flow rules to network devices to implement the SDN policy. As described above, implementing the SDN policy may involve the same network devices performing the existing operations, or may involve different network devices. Accordingly, block 206 may include transmitting the flow rules to the same network devices providing the rules inblock 203.Block 206 may also include transmitting the flow rules to different network devices than the ones providing the rules inblock 203. - In some implementations, the flow rules are transmitted to the network devices prior to SDN operations. Accordingly, after a transition to SDN-controlled operations, only flows that do not match the proactively instantiated flows will arrive at the controller. This may prevent the controller from being overloaded, reduce network congestion, and reduce the load on the network devices to send packets to the controller.
- In other implementations, the flow rules are transmitted during SDN operations after the controller receives a packet matching the flow rule from a network device. For example, during transition to SDN, blocks 201-205 may be performed to proactively determine flow rules to implement the existing network behavior. However, those flow rules may only be provided to network devices when needed. This may reduce latency and reduce the computational load on the network controller.
- In still further implementations, some flow rules are transmitted prior to SDN operation and some flow rules are provided on an as-needed basis. In some cases, statistics used received in
block 204 are used to determine whether to transmit a flow rule to implement the SDN policy. For example, flow rules may be sent to the devise if the hit count for the corresponding operation exceeds a certain threshold. For example, flow table size limitations may prevent flow rules from being sent to implement SDN policies for all existing operations. The threshold may be set according to the flow table size limitations. For example, the threshold may be a percentage of the number of table entries, with some entries reserved for new operations. -
FIG. 3 illustrates anexample network device 300 having a non-transitory computerreadable medium 302 storing instructions to transmit a rule for a legacy network operation to a network controller. In some implementations, thenetwork device 300 may be a hybrid device capable of performing legacy operations and SDN operations. For example, the legacy operations may include a routing decision, an ACL/QoS decision, a layer 2 forwarding decision, or a filtering rule such as a multicast filtering rule. The SDN operations may include executing flow rules complying with an SDN protocol. For example, thenetwork device 300 may be capable of operating as an OPENFLOW switch. - The
example network device 300 may include aprocessor 301. Theprocessor 301 may execute various control plane applications. For example, the control plane applications may include SDN applications including an SDN agent, such as an OPENFLOW agent, and a legacy flow reporting agent. The control plane applications may also include legacy applications, such as route managers, L2 address managers, ACL managers, QoS managers, or other non-SDN function-related applications. These applications may be stored as software instructions on a non-transitory computer readable medium, such as random access memory (RAM), read only memory (ROM), flash memory, or storage. Thenetwork device 300 may also include anetwork interface 303. Thenetwork interface 303 may be used by theprocessor 301 to communicate with a network controller over an SDN management channel, such as an OPENFLOW channel. - The medium 302 may store
instructions 304 executable by theprocessor 301 to receive a match field from a network coordinator. In some implementations, theinstructions 304 may be executable to receive a set of match fields from the network coordinator. For example, the match fields may define a network slice to be transitioned from legacy operation to SDN operation. In some implementations, theinstructions 304 may be executable to receive an identification of which legacy application to query for legacy operations. For example, the match field and legacy application identification may be received in an information request packet sent by the network controller. - The medium 302 may store
instructions 305 executable by theprocessor 301 to query a legacy application to obtain a legacy network operation related to the received match field. For example, theinstructions 305 may be executed as part of execution of a legacy rule reporting agent and the legacy application may be executed on theprocessor 301 as well. Theprocessor 301 may query the legacy application using inter-application communications. In some implementations, the legacy application queried may be an application identified in the transmission received inFIG. 3 . In further implementations, theinstructions 305 may be executable to determine which legacy applications on thenetwork device 300 may include rules applicable to the match field. - The
instructions 305 may be executable by theprocessor 301 to obtain identification of legacy network operations related to the match field from the legacy applications. For example, the legacy network operations may be obtained as legacy rules, such as routing rules, bridging rules, ACL rules, or QoS rules. Theinstructions 305 may be further executable to obtain statistics related to the legacy network operations, such as hit counts or timestamps of last execution of the operations. - The medium 302 may store
further instructions 306 executable by theprocessor 301 to transmit a rule for the legacy network operation to the network controller. In some cases, the transmitted rule is a flow rule, and theinstructions 306 are executable to convert a legacy rule for the network operation into a flow rule.Instructions 306 may be further executable to transmit any statistics collected from the legacy applications to the network controller. -
FIG. 4 illustrates anexample network device 401 executing anSDN agent 405 and a legacyrule reporting agent 404. For example, thenetwork device 401 may be an implementation of thenetwork device 300 ofFIG. 3 . - The
example network device 401 may be capable of hybrid network operations, including legacy, non-SDN, network operations and SDN operations. Accordingly, thedevice 401 may include anSDN control plane 402 and alegacy control plane 403. In some implementations, the control planes 402, 403 may be executed as hardware functions, software applications stored on a non-transitory computer readable medium and executed by a processor, or combinations thereof. Thedevice 401 may further includehardware resources 411 and ports 416-418. For example, thehardware resources 411 may include control application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), ternary content addressable memory (TCAM), or other hardware. Applications executed on the control planes 402, 403 may control how packets received from hosts 419-421 on the ports 416-418 are treated by the device. The hosts 419-421 may be end devices or other network devices. - The
SDN control plane 402 may include anSDN agent 405. TheSDN agent 405 may connect to anetwork controller 415 over a management channel. For example, theSDN agent 405 may receive flow rules from thecontroller 415 and program those flow rules into a flow table 414. In some cases, a flow table 414 may be implemented usinghardware resources 411. In some cases, a flow table 414 may be implemented in software as instructions executed by a processor and stored on a computer readable medium. In still further cases, the anetwork device 401 may include a flow pipeline including flow tables implemented in software and flow tables implemented in hardware. - The
SDN control plane 402 may further include a legacyrule reporting agent 404. Execution of the legacyrule reporting agent 404 may involve execution of the instructions 304-306 ofFIG. 3 . For example, thecontroller 415 may inform thereporting agent 404 on thenetwork device 402, and anyother devices 402 in the network, about an impending network slice and match fields defining the slice. Theagent 404 may query legacy applications 406-410 on thelegacy control plane 402 to provide rules that they have configured that are related to the parameters on which the network slicing will be done. For example, thelegacy applications 410 may include aroute manager 406 managing routes on a routing table 412, a layer 2address manager 407 managing a MAC table 413, anACL manager 408, aQoS manager 409, orother legacy application 410. When receiving a query, the legacy applications 406-410 may search their respective hardware or software agents and reply to theagent 404 with platform specific rules that they have programmed. The legacy applications 406-410 may further respond with rule priorities or statistics, if available. Theagent 404 may convert the platform specific rules into SDN protocol-compliant flow rules and provide them to thenetwork controller 415 via theSDN agent 405. -
FIG. 5 illustrates anexample controller 500 including arule collector 501, policy analyzer 502, andflow programmer 503. For example, thecontroller 500 may be an SDN network controller able to connect to a network device, such as anetwork device 401 ofFIG. 4 , and perform a method of generating an SDN policy, such as the method ofFIG. 1 or 2 . In some implementations, themodule - The
controller 500 may include arule collector 501. Therule collector 501 may be configured to collect a rule for a legacy network operation corresponding to a match field from a first network device. In some cases, the legacy network operation may be an access control operation, a quality of service operation, a forwarding operation, a filtering operation, or a multicast operation. For example, therule collector 501 may be able to query legacy rule reporting agents executed by network devices using anetwork interface 504. For example, therule collector 501 may be able to perform block 101-103 ofFIG. 1 . - In some cases, the
rule collector 501 may collect a plurality of legacy rules corresponding to the match field from a corresponding plurality of network devices. Therule collector 501 may transmit a set of match fields corresponding to a network slice to a plurality of network devices and collect a set of rules from the plurality of network devices. For example, therule collector 501 may perform blocks 201-203 ofFIG. 2 . - Additionally, the
rule collector 501 may collect statistics related to legacy rules from network devices. For example, therule collector 501 may collect a hit count for the legacy rule from a network device. Therule collector 501 may collect such statistics as described with respect to block 204 ofFIG. 2 . - The
controller 500 may also include a policy analyzer 502. In some implementations, the policy analyzer 502 may perform block 104 ofFIG. 1 or block 205 ofFIG. 2 . The policy analyzer may use the rule or rules provided by therule collector 501 to determine a policy for packets matching the match field. For example, the policy analyzer 502 may collate all rules received by therule collector 501, and determine a final set of SDN rules that can be programmed onto a set of network devices. In some cases, the policy analyzer 502 may obtain an overriding requirement and determine the policy to meet the overriding requirement. The final set of SDN rules may implement a network behavior resulting from the legacy rules. For example, the policy may mimic the operation of the network under the legacy rules consistent with any overriding requirements. - The policy analyzer 502 may determine the policy from a subset of the rules meeting a rule priority requirement. In some cases, the policy analyzer 502 may receive a rule priority requirement from a network administrator. For the rule priority requirement may instruct the analyzer 502 to determine SDN rules based on which collected rules have a higher hit count, the most recently hit rules, or any other configured priority.
- The
controller 500 may also include aflow programmer 503. In some implementations, theflow programmer 503 may be configured to perform block 206 ofFIG. 2 . The flow programmer may transmit a flow rule to implement the policy determined by the policy analyzer 502. For example, the flow programmer may transmit flow rules to all or a subset of network devices connected to thecontroller 500 via aninterface 504. In some cases, theflow programmer 503 may use statistics related to the legacy rules to determine whether to transmit a flow rule to a network device. For example, theflow programmer 503 may transmit a flow rule to a network device if the hit count for a corresponding legacy rule meets a threshold condition. - In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.
Claims (15)
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IN1499CH2014 | 2014-03-20 | ||
IN1499/CHE/2014 | 2014-03-20 | ||
PCT/US2014/040331 WO2015142372A1 (en) | 2014-03-20 | 2014-05-30 | Network operation rule |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170142010A1 true US20170142010A1 (en) | 2017-05-18 |
Family
ID=54145121
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/127,445 Abandoned US20170142010A1 (en) | 2014-03-20 | 2014-05-30 | Network operation rule |
Country Status (2)
Country | Link |
---|---|
US (1) | US20170142010A1 (en) |
WO (1) | WO2015142372A1 (en) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170033997A1 (en) * | 2015-07-31 | 2017-02-02 | Vmware, Inc. | Binding Policies to Computing Resources |
US20180048561A1 (en) * | 2015-03-12 | 2018-02-15 | Nec Europe Ltd. | Method for forwarding data in a network, forwarding element for forwarding data and a network |
US20180176143A1 (en) * | 2016-12-15 | 2018-06-21 | At&T Intellectual Property I, L.P. | Application-Based Multiple Radio Access Technology and Platform Control Using SDN |
US10097457B1 (en) * | 2015-12-28 | 2018-10-09 | Juniper Networks, Inc. | Resolving a mismatch among control plane parameter values received from multiple routing control devices |
US20190007862A1 (en) * | 2016-01-13 | 2019-01-03 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting control message in software defined network-based mobile communication system |
US20190075467A1 (en) * | 2016-03-07 | 2019-03-07 | Orange | Selection of a network slice instantiation for transmitting uplink packets |
US10243778B2 (en) * | 2015-08-11 | 2019-03-26 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for debugging in a software-defined networking (SDN) system |
WO2020034839A1 (en) * | 2018-08-15 | 2020-02-20 | 中国移动通信有限公司研究院 | Network slicing management method and system |
KR20200058816A (en) * | 2018-11-20 | 2020-05-28 | 광주과학기술원 | Apparatus and method deploying firewall on SDN, and network using the same |
US11184289B2 (en) * | 2015-06-01 | 2021-11-23 | Huawei Technologies Co., Ltd. | Systems and methods for managing network traffic with a network operator |
US11202231B2 (en) * | 2019-01-08 | 2021-12-14 | Samsung Electronics Co., Ltd. | Management device and method for controlling end-to-end network in wireless communication system |
US11240644B2 (en) | 2015-06-01 | 2022-02-01 | Huawei Technologies Co., Ltd. | Method and apparatus for dynamically controlling customer traffic in a network under demand-based charging |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017113100A1 (en) * | 2015-12-29 | 2017-07-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Network nodes and methods performed therein for enabling communication in a communication network |
US9961713B2 (en) * | 2016-02-23 | 2018-05-01 | Motorola Mobility Llc | Procedures to support network slicing in a wireless communication system |
US10129894B2 (en) | 2016-03-04 | 2018-11-13 | Huawei Technologies Co., Ltd. | Systems and methods for performing traffic engineering through network slices |
CN107222318A (en) * | 2016-03-21 | 2017-09-29 | 中兴通讯股份有限公司 | The performance data processing method and device and NMS of a kind of network element |
CN107347205B (en) * | 2016-05-05 | 2019-08-23 | 电信科学技术研究院 | A kind of network slice selection method, apparatus and system |
CN107347202B (en) * | 2016-05-06 | 2019-12-13 | 电信科学技术研究院 | initial access method and device of terminal under network slice architecture |
CN107360598B (en) * | 2016-05-10 | 2019-08-02 | 电信科学技术研究院 | A kind of network fragment selection method and device |
CN107396406B (en) * | 2016-05-17 | 2019-08-30 | 电信科学技术研究院 | The method, apparatus and system of network fragment selection based on business |
FR3052324A1 (en) * | 2016-06-07 | 2017-12-08 | Orange | METHOD FOR CONNECTING A TERMINAL TO A NETWORK TRENCH |
US20190313467A1 (en) * | 2016-07-08 | 2019-10-10 | Ntt Docomo, Inc. | Radio communication system and communication method |
CN109076446B (en) * | 2016-09-07 | 2020-09-29 | 华为技术有限公司 | Access control method and device |
US10439958B2 (en) | 2017-02-28 | 2019-10-08 | At&T Intellectual Property I, L.P. | Dynamically modifying service delivery parameters |
US10498666B2 (en) | 2017-05-01 | 2019-12-03 | At&T Intellectual Property I, L.P. | Systems and methods for allocating end device reources to a network slice |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130272305A1 (en) * | 2012-04-16 | 2013-10-17 | Telefonaktiebolaget L M Ericsson (Publ) | Chaining of inline services using software defined networking |
US20150109967A1 (en) * | 2013-10-17 | 2015-04-23 | Openet Telecom Ltd. | Method and System for Dynamically Creating Tunnels suitable for Metering and Managing Usage Data for Applications and Services |
US9258742B1 (en) * | 2013-09-30 | 2016-02-09 | Juniper Networks, Inc. | Policy-directed value-added services chaining |
US20170034058A1 (en) * | 2014-04-08 | 2017-02-02 | Hewlett Packard Enterprise Development Lp | Pipeline table identification |
US9979638B2 (en) * | 2013-06-19 | 2018-05-22 | Hcl Technologies Limited | Systems and methods to construct engineering environment supporting API enablement for software defined networking |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8611352B2 (en) * | 2010-04-20 | 2013-12-17 | Marvell World Trade Ltd. | System and method for adapting a packet processing pipeline |
US9178833B2 (en) * | 2011-10-25 | 2015-11-03 | Nicira, Inc. | Chassis controller |
US9225635B2 (en) * | 2012-04-10 | 2015-12-29 | International Business Machines Corporation | Switch routing table utilizing software defined network (SDN) controller programmed route segregation and prioritization |
US9705918B2 (en) * | 2012-05-22 | 2017-07-11 | Sri International | Security mediation for dynamically programmable network |
US9325569B2 (en) * | 2012-06-29 | 2016-04-26 | Hewlett Packard Enterprise Development Lp | Implementing a software defined network using event records that are transmitted from a network switch |
-
2014
- 2014-05-30 US US15/127,445 patent/US20170142010A1/en not_active Abandoned
- 2014-05-30 WO PCT/US2014/040331 patent/WO2015142372A1/en active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130272305A1 (en) * | 2012-04-16 | 2013-10-17 | Telefonaktiebolaget L M Ericsson (Publ) | Chaining of inline services using software defined networking |
US9979638B2 (en) * | 2013-06-19 | 2018-05-22 | Hcl Technologies Limited | Systems and methods to construct engineering environment supporting API enablement for software defined networking |
US9258742B1 (en) * | 2013-09-30 | 2016-02-09 | Juniper Networks, Inc. | Policy-directed value-added services chaining |
US20150109967A1 (en) * | 2013-10-17 | 2015-04-23 | Openet Telecom Ltd. | Method and System for Dynamically Creating Tunnels suitable for Metering and Managing Usage Data for Applications and Services |
US20170034058A1 (en) * | 2014-04-08 | 2017-02-02 | Hewlett Packard Enterprise Development Lp | Pipeline table identification |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180048561A1 (en) * | 2015-03-12 | 2018-02-15 | Nec Europe Ltd. | Method for forwarding data in a network, forwarding element for forwarding data and a network |
US10432511B2 (en) * | 2015-03-12 | 2019-10-01 | Nec Corporation | Method for forwarding data in a network, forwarding element for forwarding data, and a network for forwarding data |
US11240644B2 (en) | 2015-06-01 | 2022-02-01 | Huawei Technologies Co., Ltd. | Method and apparatus for dynamically controlling customer traffic in a network under demand-based charging |
US11184289B2 (en) * | 2015-06-01 | 2021-11-23 | Huawei Technologies Co., Ltd. | Systems and methods for managing network traffic with a network operator |
US10263847B2 (en) | 2015-07-31 | 2019-04-16 | Vmware, Inc. | Policy validation |
US20170033996A1 (en) * | 2015-07-31 | 2017-02-02 | Vmware, Inc. | Policy Store |
US10025810B2 (en) | 2015-07-31 | 2018-07-17 | Vmware, Inc. | Policy composition language |
US10075343B2 (en) * | 2015-07-31 | 2018-09-11 | Vmware, Inc. | Policy store |
US20170033997A1 (en) * | 2015-07-31 | 2017-02-02 | Vmware, Inc. | Binding Policies to Computing Resources |
US10116510B2 (en) | 2015-07-31 | 2018-10-30 | Vmware, Inc. | Resource categorization for policy framework |
US10198467B2 (en) | 2015-07-31 | 2019-02-05 | Vmware, Inc. | Policy framework user interface |
US10243778B2 (en) * | 2015-08-11 | 2019-03-26 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for debugging in a software-defined networking (SDN) system |
US10097457B1 (en) * | 2015-12-28 | 2018-10-09 | Juniper Networks, Inc. | Resolving a mismatch among control plane parameter values received from multiple routing control devices |
US11109265B2 (en) * | 2016-01-13 | 2021-08-31 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting control message in software defined network-based mobile communication system |
US20190007862A1 (en) * | 2016-01-13 | 2019-01-03 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting control message in software defined network-based mobile communication system |
US10588022B2 (en) * | 2016-03-07 | 2020-03-10 | Orange | Selection of a network slice instantiation for transmitting uplink packets |
US20190075467A1 (en) * | 2016-03-07 | 2019-03-07 | Orange | Selection of a network slice instantiation for transmitting uplink packets |
US11818585B2 (en) | 2016-03-07 | 2023-11-14 | Orange | Selection of a network slice instantiation for transmitting uplink packets |
US10959102B2 (en) | 2016-03-07 | 2021-03-23 | Orange | Selection of a network slice instantiation for transmitting uplink packets |
US11716631B2 (en) | 2016-03-07 | 2023-08-01 | Orange | Selection of a network slice instantiation for transmitting uplink packets |
US20180176143A1 (en) * | 2016-12-15 | 2018-06-21 | At&T Intellectual Property I, L.P. | Application-Based Multiple Radio Access Technology and Platform Control Using SDN |
US10965621B2 (en) * | 2016-12-15 | 2021-03-30 | At&T Intellectual Property I, L.P. | Application-based multiple radio access technology and platform control using SDN |
WO2020034839A1 (en) * | 2018-08-15 | 2020-02-20 | 中国移动通信有限公司研究院 | Network slicing management method and system |
KR20200058816A (en) * | 2018-11-20 | 2020-05-28 | 광주과학기술원 | Apparatus and method deploying firewall on SDN, and network using the same |
US11336622B2 (en) | 2018-11-20 | 2022-05-17 | Gwangju Institute Of Science And Technology | Apparatus and method for deploying firewall on SDN and network using the same |
KR102160187B1 (en) * | 2018-11-20 | 2020-09-25 | 광주과학기술원 | Apparatus and method deploying firewall on SDN, and network using the same |
US11202231B2 (en) * | 2019-01-08 | 2021-12-14 | Samsung Electronics Co., Ltd. | Management device and method for controlling end-to-end network in wireless communication system |
Also Published As
Publication number | Publication date |
---|---|
WO2015142372A1 (en) | 2015-09-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20170142010A1 (en) | Network operation rule | |
US9197568B2 (en) | Method for providing quality of service in software-defined networking based network and apparatus using the same | |
EP3709573A1 (en) | Satisfying service level agreement metrics for unknown applications | |
US11245631B2 (en) | Bum traffic control method, related apparatus, and system | |
US10091166B2 (en) | Sequentially serving network security devices using a software defined networking (SDN) switch | |
EP2904745B1 (en) | Method and apparatus for accelerating forwarding in software-defined networks | |
US9736057B2 (en) | Forwarding packet fragments using L4-L7 headers without reassembly in a software-defined networking (SDN) system | |
US9276852B2 (en) | Communication system, forwarding node, received packet process method, and program | |
KR101755138B1 (en) | Communication system, control device, and method for managing network topology | |
US8787388B1 (en) | System and methods for forwarding packets through a network | |
US11522784B2 (en) | Routing and forwarding method for multi-homed network based on programmable network technology | |
WO2016162833A1 (en) | Method and system for traffic pattern generation in a software-defined networking (sdn) system | |
US20140241349A1 (en) | Openflow switch and packet processing method thereof | |
US11595315B2 (en) | Quality of service in virtual service networks | |
EP3070879A1 (en) | Oam performance monitoring method and apparatus | |
US9985878B2 (en) | Processing rule modification method, apparatus and device | |
JP7313480B2 (en) | Congestion Avoidance in Slice-Based Networks | |
US9800508B2 (en) | System and method of flow shaping to reduce impact of incast communications | |
KR20140052847A (en) | Method and apparatus for providing quality of service in software defiend neworking network | |
US10554556B2 (en) | Network element with congestion-aware match tables | |
US9537764B2 (en) | Communication apparatus, control apparatus, communication system, communication method, method for controlling communication apparatus, and program | |
Ren et al. | A reactive traffic flow estimation in software defined networks | |
Roy et al. | Opportunities and challenges in software defined networking and network function virtualization |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MATHEW, SUBIN CYRIAC;CHANDRAN, SUGESH;REEL/FRAME:039792/0819 Effective date: 20140318 |
|
AS | Assignment |
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:040895/0065 Effective date: 20151027 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: APPEAL BRIEF (OR SUPPLEMENTAL BRIEF) ENTERED AND FORWARDED TO EXAMINER |
|
STCV | Information on status: appeal procedure |
Free format text: ON APPEAL -- AWAITING DECISION BY THE BOARD OF APPEALS |
|
STCV | Information on status: appeal procedure |
Free format text: BOARD OF APPEALS DECISION RENDERED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |