WO2017138952A1 - Générations d'instructions spécifiques à un protocole pour un comportement d'acheminement ambigu - Google Patents

Générations d'instructions spécifiques à un protocole pour un comportement d'acheminement ambigu Download PDF

Info

Publication number
WO2017138952A1
WO2017138952A1 PCT/US2016/017700 US2016017700W WO2017138952A1 WO 2017138952 A1 WO2017138952 A1 WO 2017138952A1 US 2016017700 W US2016017700 W US 2016017700W WO 2017138952 A1 WO2017138952 A1 WO 2017138952A1
Authority
WO
WIPO (PCT)
Prior art keywords
protocol
forwarding
specific
specific instructions
instructions
Prior art date
Application number
PCT/US2016/017700
Other languages
English (en)
Inventor
Shaun Wackerly
Duane Edward Mentze
Original Assignee
Hewlett Packard Enterprise Development Lp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
Priority to PCT/US2016/017700 priority Critical patent/WO2017138952A1/fr
Publication of WO2017138952A1 publication Critical patent/WO2017138952A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing

Definitions

  • Networks can include a plurality of resources connected by
  • An example network can include a software-defined network (SDN).
  • SDN software-defined network
  • Figure 1 a illustrates a flow chart of an example method for generating protocol-specific instructions, according to an example.
  • Figure 1 b illustrates a flow chart of an example method for generating protocol-specific instructions, according to an example.
  • Figure 2a illustrates an example environment with devices for generating and implementing protocol-specific instructions, according to an example.
  • Figure 2b illustrates an example of generating unambiguous protocol- specific instructions from an ambiguous protocol-specific instruction, according to an example.
  • Figure 3 illustrates an example computer for generating protocol- specific instructions, according to an example. Detailed Description
  • Networks can include a plurality of resources such as network devices and databases to connect endpoint devices via communication links.
  • Networks can be used to connect people, provide services (e.g., internally and/or externally via the Internet and/or intranet), and organize information, among other activities.
  • Examples of endpoint devices include computers, tablets, phones, printers, cameras, door locks, HVAC controller, among other endpoint devices capable of operating on a network.
  • An example network can include a software- defined network (SDN).
  • SDN software- defined network
  • SDN controllers can direct network devices such as servers, SDN- capable switches and routers, and other computing devices, on how to forward network traffic.
  • SDN applications may execute on or interface with the SDN controller to provide input to the SDN controller and influence how the SDN controller forwards traffic.
  • SDN applications might provide services on the network, including observing network traffic and conditions and taking one or more actions as a result. For instance, one application may look for infected hosts on the network, while another application may attempt to optimize voice over internet protocol (VoIP) calls on the network.
  • VoIP voice over internet protocol
  • Both applications may run on the same SDN controller, and use the SDN controller to communicate down to network devices in a protocol-specific format, such as according to the OpenFlow protocol.
  • Instructions from applications may be characterized as network policies to be applied to the network.
  • Network policies from different applications may be compiled together to yield a cohesive set of non-overlapping policies to be applied to the network.
  • This set of non-overlapping policies are referred to herein as "orthogonal policies”.
  • An orthogonal policy is a policy generated from one or more original/source policies (e.g., policies that are received from an application) that does not conflict with any other orthogonal policy in a set of orthogonal policies. This means that all policies from the source set of policies to be applied to any single packet in the network would be implemented by a single orthogonal policy.
  • These orthogonal policies may then be transformed into protocol-specific instructions (i.e., instructions in a protocol understood and implementable by a network device) for implementation by network devices.
  • policies may specify unambiguous forwarding behavior for a given set of network traffic. For example, a policy may specify that matching flows be dropped, forwarded to a specific device for application of a network service (e.g., deep packet inspection, load balancing, etc.), quarantined, or forwarded to a specific destination device.
  • a policy may specify ambiguous forwarding behavior. For example, a policy may specify that matching flows be handled by a native forwarding function of the network device or that matching flows be forwarded to the SDN controller for determination of a
  • Such forwarding behavior is referred to as
  • Example implementations relate to generating protocol-specific instructions for ambiguous forwarding behavior.
  • a method includes generating protocol-specific instructions to implement a plurality of policies and identifying a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior.
  • the method determines unambiguous forwarding behavior associated with the respective protocol-specific instruction and generates additional protocol-specific instructions to implement the unambiguous forwarding behavior.
  • the unambiguous forwarding behavior can be determined using a forwarding engine of an SDN controller.
  • the method may then include instructing a network device to create flow entries in a flow table corresponding to (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol-specific instructions (which were created based on the subset of protocol-specific instructions).
  • the generated protocol-specific instructions may specify all forwarding behavior for the network device, rather than requiring the network device to obtain input on forwarding behavior from a forwarding engine, such as a forwarding engine of an SDN controller or a non-SDN forwarding pipeline of the network device.
  • a forwarding engine such as a forwarding engine of an SDN controller or a non-SDN forwarding pipeline of the network device.
  • This technique also allows an SDN controller to override the forwarding behavior that would otherwise be dictated by a non-SDN forwarding pipeline of the network device, if desired.
  • this technique can ensure that protocol-specific instructions that require reliance on a non-SDN forwarding pipeline are not forwarded to the network device and are instead converted into explicit, unambiguous protocol-specific instructions that can be implemented by the network device.
  • FIGS. 1 a-b illustrate methods to generate protocol-specific
  • Methods 100 and 120 may be performed by a computing device, computer, server, or the like, such as SDN controller 210 or computer 310.
  • Computer-readable instructions for implementing methods 100 and 120 may be stored on a computer readable storage medium. These instructions as stored on the medium are referred to herein as "modules" and may be executed by a computer.
  • Environment 200 may include SDN controller 210 and network devices 220, 230.
  • SDN controller 210 may be a computer configured to manage the control plane of a software defined network.
  • SDN controller 210 may
  • Network devices 220, 230 may be network infrastructure devices, such as a switch or router, of the software defined network.
  • the network devices 220, 230 may thus be part of the data plane of the software defined network, which may include multiple network devices.
  • SDN controller 210 may communicate with network devices 220, 230 via an SDN protocol, such as the OpenFlow protocol.
  • SDN controller 210 may program rules in the flow tables 222, 232 of network devices 220, 230.
  • Network devices 220, 230 may use these rules to process and forward network traffic.
  • Flow tables 222, 232 may be implemented by multiple hardware elements (e.g., Tertiary Content Addressable Memory (TCAM), Application Specific Integrated Circuit (ASIC)) within network devices 220, 230, and each flow table may include multiple tables. While both network devices 220, 230 have a flow table, which enables packet forwarding in accordance with the OpenFlow protocol, only network device 230 has a non-SDN forwarding pipeline 234.
  • TCAM Tertiary Content Addressable Memory
  • ASIC Application Specific Integrated Circuit
  • Network device 230 can be referred to as a hybrid SDN device because it supports both SDN forwarding and traditional forwarding (which may be in accordance with other network protocols).
  • network device 220 can be referred to as a pure SDN device because it supports only SDN forwarding (and thus relies on SDN controller 210 to configure its forwarding function).
  • SDN applications may run on or interface with SDN controller 210. These SDN applications may be part of the application plane of the software defined network.
  • SDN controller 210 and network devices 220, 230 may include one or more controllers and one or more machine-readable storage media.
  • a controller may include a processor and a memory for implementing machine readable instructions.
  • the processor may include at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one digital signal processor (DSP) such as a digital image processing unit, other hardware devices or processing elements suitable to retrieve and execute instructions stored in memory, or combinations thereof.
  • the processor can include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or combinations thereof.
  • the processor may fetch, decode, and execute instructions from memory to perform various functions.
  • the processor may include at least one integrated circuit (IC), other control logic, other electronic circuits, or
  • the controller may include memory, such as a machine-readable storage medium.
  • the machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions.
  • the machine-readable storage medium may comprise, for example, various Random Access Memory (RAM), Read Only Memory (ROM), flash memory, and combinations thereof.
  • the machine-readable medium may include a Non-Volatile Random Access Memory (NVRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a NAND flash memory, and the like.
  • NVRAM Non-Volatile Random Access Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • the machine- readable storage medium can be computer-readable and non-transitory.
  • SDN controller 210 and network devices 220, 230 may include one or more machine-readable storage media separate from the one or more controllers, as well as additional hardware elements, such as TCAMs and ASICs.
  • method 100 may be used to generate protocol- specific instructions, according to an example.
  • instruction module 212 may generate protocol-specific instructions to implement a plurality of network policies.
  • the protocol-specific instructions may be instructions in accordance with a protocol supported by network devices 220, 230, such as the OpenFlow protocol.
  • the protocol-specific instructions may thus be instructions suitable for the network devices 220, 230 to implement the policies when processing and forwarding traffic.
  • the protocol-specific instructions may be instructions for creating or modifying flow entries in flow tables 222, 232, where the flow tables are consulted by the respective network devices to determine how to process and forward a received packet.
  • Protocol-specific instructions including precursor steps such as grouping the network policies and compiling them into orthogonal polices, is described in more detail in PCT Application No. US2015/015122, entitled “Network Policy Conflict Detection and Resolution”, PCT Application No. US2015022074, entitled “Implementing Policy Instructions in Multiple Tables”, and PCT Application No. US20155/022068, entitled “Compiling Network Policies”.
  • identification module 214 may identify a subset of protocol- specific instructions within the generated protocol-specific instructions that specify ambiguous forwarding behavior. In some cases, policies may specify
  • a policy may specify that matching flows be dropped, forwarded to a specific device for application of a network service (e.g., deep packet inspection, load balancing, etc.), quarantined, or forwarded to a specific destination device.
  • a policy may specify ambiguous forwarding behavior.
  • a policy may specify that matching flows be handled by a native forwarding function of the network device or that matching flows be forwarded to the SDN controller for determination of a forwarding decision for the flow. Such forwarding behavior is ambiguous because the ultimate forwarding decision is not clear from the instruction itself and instead relies on input from the native forwarding function of the network device or the forwarding engine of the SDN controller.
  • the ultimate forwarding decision may depend on one or more parameters associated with the packet, such as its source address or destination address.
  • the forwarding behavior may eventually become unambiguous after the network device or SDN controller determines the appropriate forwarding action, it is considered ambiguous until that point.
  • some of the generated protocol-specific instructions may specify ambiguous forwarding behavior. It is these instructions that are identified by identification module 214.
  • Ambiguous forwarding behavior may be identified in various ways. At a high-level, if the ultimate forwarding decision depends on input from another device, whether it be a forwarding engine of an SDN controller (e.g., forwarding engine 216) or a non-SDN forwarding function of a network device (e.g., non-SDN forwarding pipeline 234), then the forwarding behavior may be identified as ambiguous.
  • identification module 214 can identify whether a given protocol-specific instruction relies on input from another entity by examining the action associated with the instruction.
  • the protocol-specific instructions (which may be in the form of flow table modification messages) will have a match field and an action field (among others fields).
  • the match field provides parameters for matching network packets to the flow table rule.
  • the match parameters may be a source or destination address, for example.
  • the action field specifies what do with a matching packet, including which port in the network device to forward the packet (referred to as the destination port).
  • identification instructions can determine whether the instruction relies on an SDN controller or non-SDN forwarding pipeline of the network device. If the instruction relies on the SDN controller, the destination port will be a port dedicated to communication between the network device and the controller (referred to as a controller port).
  • the destination port will be a reserved port called "NORMAL", which is a reserved port according to the OpenFlow protocol that causes the network device to send any matching packets through the non-SDN forwarding pipeline of the network device.
  • NVMAL a reserved port according to the OpenFlow protocol that causes the network device to send any matching packets through the non-SDN forwarding pipeline of the network device.
  • an instruction relies on a non-SDN forwarding pipeline
  • certain classes of network devices may be trusted (e.g., devices provided by a particular company) while others are not.
  • a blacklist may be created for the untrusted devices, and the protocol-specific instructions that both rely on a non-SDN forwarding pipeline and are destined for such devices on the blacklist may be flagged. This will enable another forwarding engine, such as the forwarding engine of the controller, to make the ultimate forwarding decisions.
  • identification module 214 could be configured to consider one or more of these criteria when deciding which protocol-specific instructions to add to the subset.
  • block 101 of method 100 could be performed such that any generated protocol-specific instruction that relies on another entity for the ultimate forwarding decision (e.g., whether it be a forwarding engine of a SDN controller or a non-SDN forwarding pipeline of a network device) is provided with a common indicator in the action field that signals such reliance.
  • the indicator could be forwarding to the NORMAL port, forwarding to the controller port, or some other indicator such as "Allow".
  • block 102 could identify all such instructions based on the common indicator.
  • Method 120 depicted in FIG. 1 b illustrates this case.
  • protocol-specific instructions are identified where an associated action indicates that a matching packet should be forwarded to the NORMAL port (of course, a different indicator could be used, as described above).
  • method 120 determines whether a network device the instruction is destined for has a non-SDN forwarding capability (e.g., non-SDN forwarding pipeline 234), and includes the instruction in the subset only if the network device does not have a non-SDN forwarding capability. If the network device has a non-SDN forwarding capability, the instruction can be left as is such that the network device will make the ultimate forwarding decision using its non- SDN forwarding capability. Since the action already specifies the NORMAL port, the instruction need not be changed. However, if a different indicator were used, the action would need to be updated to indicate forwarding to the non-SDN forwarding pipeline through the NORMAL port.
  • method 100 may determine unambiguous forwarding behavior for each protocol-specific instruction identified in 102 and added to the subset.
  • the unambiguous forwarding behavior may be determined by a forwarding engine, such as forwarding engine 216 of SDN controller 210.
  • the forwarding engine 216 may be a module configured to determine forwarding paths through a network according to the topology of the network and in accordance with various network protocols implemented by the network.
  • the forwarding engine 216 may generate multiple forwarding decisions for a given protocol-specific instruction in the subset. These multiple forwarding decisions constitute the determined unambiguous forwarding behavior for the given protocol-specific instruction.
  • Instruction module 212 may then generate additional protocol-specific instructions based on the determined unambiguous behavior.
  • FIG. 2b illustrates an example of generating unambiguous forwarding behavior from ambiguous forwarding behavior 242 specified by a protocol-specific instruction.
  • the unambiguous forwarding behavior is translated into additional protocol-specific instructions 244, 246, 248.
  • Instruction 242 may be flagged by identification module as specifying ambiguous forwarding behavior.
  • Forwarding engine 216 determines that there are three possible forwarding decisions associated with instruction 216, each result depending on the Media Access Control address of the source device and resulting in a different forwarding decision (i.e., sending a matching packet to port 5, 6, or 8).
  • Instruction module 212 then generates protocol-specific instructions 244, 246, 248 to implement the forwarding decisions determined by the forwarding engine 216. These protocol-specific instructions may then be forwarded to the appropriate network device instead of ambiguous protocol-specific instruction 216.
  • Instruction generation module 218 may then send the protocol- specific instructions (e.g., as flow table modification messages) to the appropriate network devices (e.g., network device 220, 230).
  • module 218 may send (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol-specific instructions to the appropriate network devices.
  • the network devices may then add flow table entries to their flow tables in accordance with the received instructions.
  • a threshold could be applied to block 103.
  • SDN controller 210 could be configured to generate forwarding decisions using forwarding engine 216 only up to a threshold.
  • the threshold could take many forms, such as a specific value (e.g., only generate up to 10 entries per instruction) or a percentage (e.g., generate entries per instruction may not exceed 5% of the network device's flow table).
  • the associated protocol-specific instruction could be completely removed from the set of protocol-specific instructions to be communicated to the network device. In other words, neither the original protocol-specific instruction that was identified for the subset nor any additional protocol-specific instructions generated based on the instruction would be communicated to the network device.
  • a default protocol-specific instruction could be created for the network device to be stored as the last, lowest priority entry in the device's flow table that matches all packets and causes the device to forward any matched packets to the SDN controller for handling.
  • FIG. 3 illustrates a computer to compile and implement policies, according to an example.
  • Computer 310 may be part of SDN controller 210.
  • the computer may include one or more controllers and one or more machine-readable storage media, as described with respect to SDN controller 210, for example.
  • Processor 320 may be at least one central processing unit (CPU), at least one semiconductor-based microprocessor, other hardware devices or processing elements suitable to retrieve and execute instructions stored in machine-readable storage medium 330, or combinations thereof.
  • Processor 320 can include single or multiple cores on a chip, multiple cores across multiple chips, multiple cores across multiple devices, or combinations thereof.
  • Processor 320 may fetch, decode, and execute instructions 332-338 among others, to implement various processing.
  • processor 320 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the functionality of instructions 332-338. Accordingly, processor 320 may be implemented across multiple processing units, and instructions 332-338 may be implemented by different processing units in different areas of computer 310.
  • IC integrated circuit
  • Machine-readable storage medium 330 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions.
  • the machine-readable storage medium may comprise, for example, various Random Access Memory (RAM), Read Only Memory (ROM), flash memory, and combinations thereof.
  • the machine-readable medium may include a Non-Volatile Random Access Memory (NVRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a NAND flash memory, and the like.
  • NVRAM Non-Volatile Random Access Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • storage drive a NAND flash memory, and the like.
  • the machine- readable storage medium 330 can be computer-readable and non-transitory.
  • Machine-readable storage medium 330 may be encoded with a series of executable instructions for managing processing elements.
  • the instructions 332-338 when executed by processor 320 can cause processor 320 to perform processes, for example, methods 100 and 120, and/or variations and portions thereof. Instructions 332-338 will now be briefly described, which description should be read in light of the description of methods 100, 120 and environment 200 above.
  • Computer 310 may generate protocol-specific instructions. For example, generating instructions 332 may cause processor 320 to generate protocol-specific instructions to implement a plurality of policies. Identifying instructions 334 may cause processor 320 to identify a subset of protocol-specific instructions within the protocol-specific instructions that specify ambiguous forwarding behavior. For each identified protocol-specific instruction in the subset, determining instructions 336 may cause processor 320 to determine unambiguous forwarding behavior associated with the respective protocol-specific instruction using a forwarding engine. The forwarding engine may be a forwarding engine of an SDN controller, such as forwarding engine 216. Generating instructions 332 may then cause processor 320 to generate additional protocol-specific instructions to implement the determined unambiguous forwarding behavior. Instruction instructions 338 may cause processor 320 to instruct a network device to create flow entries in a flow table corresponding to (1 ) the protocol-specific instructions except the subset of protocol-specific instructions, and (2) the additional protocol- specific instructions.
  • logic is an alternative or additional processing resource to perform a particular action and/or function, etc., described herein, which includes hardware, e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc., as opposed to computer executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor.
  • ASICs application specific integrated circuits
  • a number of something can refer to one or more such things.
  • a number of widgets can refer to one or more widgets.
  • a plurality of something can refer to more than one of such things.

Landscapes

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

Abstract

Des exemples de modes de réalisation de la présente invention concernent la génération d'instructions spécifiques à un protocole pour un comportement d'acheminement ambigu. Dans un exemple, un procédé comprend la génération d'instructions spécifiques à un protocole pour mettre en œuvre une pluralité de politiques, et l'identification d'un sous-ensemble d'instructions spécifiques à un protocole dans les instructions spécifiques à un protocole qui spécifient un comportement d'acheminement ambigu. Pour chaque instruction spécifique à un protocole dans le sous-ensemble, le procédé détermine un comportement d'acheminement non ambigu associé à chaque instruction spécifique à un protocole à l'aide d'un moteur d'acheminement, et génère des instructions spécifiques à un protocole additionnel pour mettre en œuvre le comportement d'acheminement non ambigu. Le comportement d'acheminement non ambigu peut être déterminé à l'aide d'un moteur de réacheminement d'un contrôleur SDN.
PCT/US2016/017700 2016-02-12 2016-02-12 Générations d'instructions spécifiques à un protocole pour un comportement d'acheminement ambigu WO2017138952A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2016/017700 WO2017138952A1 (fr) 2016-02-12 2016-02-12 Générations d'instructions spécifiques à un protocole pour un comportement d'acheminement ambigu

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/017700 WO2017138952A1 (fr) 2016-02-12 2016-02-12 Générations d'instructions spécifiques à un protocole pour un comportement d'acheminement ambigu

Publications (1)

Publication Number Publication Date
WO2017138952A1 true WO2017138952A1 (fr) 2017-08-17

Family

ID=59563649

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/017700 WO2017138952A1 (fr) 2016-02-12 2016-02-12 Générations d'instructions spécifiques à un protocole pour un comportement d'acheminement ambigu

Country Status (1)

Country Link
WO (1) WO2017138952A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7769873B1 (en) * 2002-10-25 2010-08-03 Juniper Networks, Inc. Dynamically inserting filters into forwarding paths of a network device
US20140241356A1 (en) * 2013-02-25 2014-08-28 Telefonaktiebolaget L M Ericsson (Publ) Method and system for flow table lookup parallelization in a software defined networking (sdn) system
US8830823B2 (en) * 2010-07-06 2014-09-09 Nicira, Inc. Distributed control platform for large-scale production networks
US20150215195A1 (en) * 2014-01-28 2015-07-30 Yaron Raps Generating optimal pathways in software-defined networking (sdn)
WO2015152930A1 (fr) * 2014-04-03 2015-10-08 Hewlett-Packard Development Company, L.P. Modification d'une priorité pour au moins une classe de flux d'une application

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7769873B1 (en) * 2002-10-25 2010-08-03 Juniper Networks, Inc. Dynamically inserting filters into forwarding paths of a network device
US8830823B2 (en) * 2010-07-06 2014-09-09 Nicira, Inc. Distributed control platform for large-scale production networks
US20140241356A1 (en) * 2013-02-25 2014-08-28 Telefonaktiebolaget L M Ericsson (Publ) Method and system for flow table lookup parallelization in a software defined networking (sdn) system
US20150215195A1 (en) * 2014-01-28 2015-07-30 Yaron Raps Generating optimal pathways in software-defined networking (sdn)
WO2015152930A1 (fr) * 2014-04-03 2015-10-08 Hewlett-Packard Development Company, L.P. Modification d'une priorité pour au moins une classe de flux d'une application

Similar Documents

Publication Publication Date Title
US9444744B1 (en) Line-rate selective load balancing of permitted network traffic
US10834085B2 (en) Method and apparatus for speeding up ACL rule lookups that include TCP/UDP port ranges in the rules
CN106605392B (zh) 用于使用控制器在网络上进行操作的系统和方法
US9432294B1 (en) Utilizing user-specified access control lists in conjunction with redirection and load-balancing on a port
US9813420B2 (en) Priority resolution for access control list policies in a networking device
US20160301603A1 (en) Integrated routing method based on software-defined network and system thereof
US20170195253A1 (en) Flexible pipeline architecture for multi-table flow processing
EP3035612B1 (fr) Procédé de création de plusieurs niveaux de table de flux, et dispositif et procédé de traitement de table de flux à niveaux mulitples
US20190075079A1 (en) Security cluster for performing security check
EP3193477A1 (fr) Apprentissage de plan de données de chaînes de service bidirectionnelles
WO2016106480A1 (fr) Dispositif de surveillance de sécurité de contrôleur de réseau
US9635119B2 (en) Communication flow control system, communication flow control method, and communication flow processing program
US11095518B2 (en) Determining violation of a network invariant
CN104821890A (zh) 一种基于普通交换芯片的OpenFlow多级流表的实现方法
KR20160042441A (ko) 애플리케이션-인식 네트워크 관리
US20170063696A1 (en) Data packet flow rule field range of an application specific integrated circuit
US10154062B2 (en) Rule lookup using predictive tuples based rule lookup cache in the data plane
CN111801911B (zh) 业务功能链拥塞跟踪
US20150341267A1 (en) Control apparatus, communication apparatus, communication system, switch control method, and program
US20190364102A1 (en) Selective load balancing of network traffic
CN110278152B (zh) 一种建立快速转发表的方法及装置
US20180167337A1 (en) Application of network flow rule action based on packet counter
US20160352637A1 (en) Client-based port filter table
US10469349B2 (en) Conflict detection in a hybrid network device
US10554563B2 (en) Generating a packet processing pipeline definition

Legal Events

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

Ref document number: 16890067

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16890067

Country of ref document: EP

Kind code of ref document: A1