WO2017121471A1 - Règles de transfert dynamique dans un sdn - Google Patents

Règles de transfert dynamique dans un sdn Download PDF

Info

Publication number
WO2017121471A1
WO2017121471A1 PCT/EP2016/050549 EP2016050549W WO2017121471A1 WO 2017121471 A1 WO2017121471 A1 WO 2017121471A1 EP 2016050549 W EP2016050549 W EP 2016050549W WO 2017121471 A1 WO2017121471 A1 WO 2017121471A1
Authority
WO
WIPO (PCT)
Prior art keywords
forwarding
forwarding rule
rule
unit
match
Prior art date
Application number
PCT/EP2016/050549
Other languages
English (en)
Inventor
Qing Wei
David Perez
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/EP2016/050549 priority Critical patent/WO2017121471A1/fr
Publication of WO2017121471A1 publication Critical patent/WO2017121471A1/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/54—Organization of routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering

Definitions

  • the present invention relates to the technical field of data transmission networks, in particular to components used in software defined networks, SDN. Specifically, the present invention relates to a forwarding unit (may also be referred to as switch or switching unit) for a SDN system, a control unit (may also be referred to as controller) for a SDN system, an SDN system, and a method for applying forwarding rules to data packets.
  • a forwarding unit may also be referred to as switch or switching unit
  • control unit may also be referred to as controller
  • SDN system an SDN system
  • Software defined networking, SDN is an approach that basically relates to decoupling the management and controlling tasks from data packet forwarding tasks.
  • the management and controlling tasks are usually referred to as control plane whereas the forwarding tasks are referred to as data plane.
  • This decoupling can simplify the structure of a network and can standardize interfaces between individual components and between the control and data plane.
  • the data plane is configured such that it requires control commands from the control plane in order to meet the forwarding tasks.
  • the ' intelligence ' of an SDN system is provided in the control plane whereas the data plane simply carries out commands and instructions received from the control plane.
  • OpenFlow One mechanism which relates to and defines the communication between the control plane and the data plane is OpenFlow. It should be understood that any reference to OpenFlow in the following is of exemplary nature and may generally relate to any mechanisms and interfaces which define the communication between the control plane and the data plane in SDN. Reference to OpenFlow is made representative for any of these mechanisms and interfaces.
  • a typical SDN network is composed of simple switches (or forwarding elements) in the forwarding plane and an intelligent SDN controller that configures how those switches behave by installing flow (or forwarding) rules on the switches.
  • forwarding rules and flow rules are used herein as synonyms.
  • the forwarding rules can be thought of as match-action pairs.
  • the context information (such as the incoming switch port), header and/or other parts of an incoming data flow, frame, packet, datagram or segment (in the following called packet for simplicity) may be matched to the contents of the flow table of the switch, and, in case of a match, the switch may trigger actions, such as forwarding to a certain port, dropping the packet altogether, redirecting the packet to the controller and so on.
  • the switch can send what is called a PACKETJN consisting of the incoming packet as well as some switch context information (such as incoming port) to the controller.
  • the controller may analyze this PACKETJN (or an application on top of the controller), which consequently typically will result in either i) installation of new forwarding rules on some switches, e.g. to handle future packets somehow corresponding to the initial one and/or ii) sending out of some packets, e.g. relaying the originally received one.
  • the controller is a logical entity that gathers and keeps an up-to-date per-flow network state. However, such centralization introduces obvious scalability issues as a result of congestion at the control plane and overload of the controller.
  • Having a centralized controller in the SDN architecture may have many advantages. However, the performance of such controller may decrease in a big scale network or in a highly dynamic environment. More specifically, the limitation of current SDN architecture appears in the following aspects:
  • Latency The response time to dynamic changes depends on the distance between the controller and SDN switches as well as the number of dynamic events to be processed at the controller simultaneously;
  • Open vSwitch (see http://openswitch.0rg/support/dist-docs/ovs-ofctl.8.txt) provides an action "learn” that allows modifying a flow table based on the content of the flow currently being processed.
  • the switch must have the processing capability to perform a set of logical operations (e.g. store/load values in an internal switch registry).
  • the processing of "learn” action is software based. Whenever the switch gets the "learn” command from the controller, it will always perform expensive “learn” action regardless whether “learn” is needed or not.
  • a forwarding unit for a software defined networking (SDN) system comprises a storage module for storing at least one forwarding rule, wherein each of the at least one forwarding rule comprises a match field comprising at least one reconfigurable element and an instruction set comprising at least one reconfiguration action.
  • the forwarding unit is configured to apply a forwarding rule of the at least one forwarding rule to a received data packet by comparing the received data packet with the match field of the forwarding rule.
  • the forwarding unit is further configured to carry out the at least one reconfiguration action of the forwarding rule if the received data packet does not match one or more of the at least one reconfigurable element of the forwarding rule.
  • the forwarding unit can be described as a switch, i.e., an element of the data plane of the SDN.
  • a switch may have at least one or more than one forwarding rule or generally any number of forwarding rules.
  • the forwarding rule(s) is (are) stored in a storage module which can be generally referred to as a memory of the forwarding unit and which in particular can comprise a persistent memory.
  • the match field is a part of the forwarding rule, wherein the match field comprises at least one condition (this condition can be referred to as "elements" of the match field in the following) which must be met in order to carry out the actions defined by the forwarding rule.
  • this condition can be referred to as "elements” of the match field in the following
  • the reconfigurable element is part of the match field and triggers the reconfiguration action if the reconfigurable element is not met by a data packet.
  • the match field may comprise n (with n equal to or greater than 1 ) reconfigurable elements where the reconfiguration action is carried out if at least one of the reconfigurable elements is not met. Not meeting a reconfigurable element may also be referred to as a mismatch.
  • a forwarding rule is applied to a received data packet, i.e., the content of fields of the data packet is compared with the match field of a forwarding rule which can also be described as examining the data packet in view of the conditions defined in the match field of a forwarding rule.
  • the match field may comprise one or more elements, i.e., conditions. In case of a rule match, all conditions of the match field are met by definition.
  • a partial match (which necessarily is a partial mismatch), will be referred to as a mismatch in the following.
  • a reconfiguration action defined in the instruction set of a forwarding rule does not contribute to forwarding data packet but relates to an internal configuration action of the forwarding unit.
  • the reconfiguration action can be applied to that forwarding rule which contains the reconfiguration action and/or to another forwarding rule stored in the storage module.
  • the reconfiguration is used to carry out any configuration or reconfiguration of the forwarding unit and the forwarding rules contained in the forwarding unit.
  • the forwarding unit described herein enables carrying out reconfiguration actions, which are in particular related to a forwarding rule. Therefore, the forwarding unit must not generate and send a PACKETJN message to the controller in case of a rule mismatch, for example if the forwarding unit does not contain any forwarding rule which can be applied to a data packet. As a result, communication between the forwarding unit and a controller can be reduced and the data traffic and the risk of network congestion on the control plane as well as the load of the controller may be reduced. In other words, simple forwarding rule modification tasks are outsourced from the controller to the forwarding unit which can be carried out with low computational power such that the forwarding unit still meets the requirements of SDN.
  • the condition for initiating the reconfiguration action being carried out is a mismatch between the data packet and the reconfigurable element of the match field.
  • the reconfiguration action does not necessarily amend the content of the reconfigurable element but may do so.
  • the reconfiguration action is carried out if the data packet does not match at least one reconfigurable element of the match field.
  • the match field of the forwarding rule comprises at least one static element, wherein the forwarding unit is configured to carry out the at least one reconfiguration action of the forwarding rule if the received data packet additionally matches the at least one static element of the forwarding rule.
  • the static elements define a minimum set of criteria which must be met by a data packet in order to match the forwarding rule. If the reconfigurable elements are additionally met, the forwarding rule as a whole (all conditions of the match field) is met and the reconfiguration action of the instruction set is not carried out. In this case, a forwarding action of the forwarding unit will be carried out typically, if the forwarding rule contains such a forwarding action. On the contrary, in case of a mismatch of the reconfigurable element (if the reconfigurable element is not met), the reconfiguration action is carried out.
  • a forwarding rule can be defined such that the reconfiguration actions can react on an amended content of specific fields of data packets.
  • a forwarding rule can be defined such that the reconfiguration action is carried out under very specific conditions, i.e. when the static elements are met and when at least one of the reconfigurable elements is not met.
  • the static elements in the match field are required to identify a flow entry (a specific flow rule or forwarding rule) in the flow table. If the match field does not comprise any static elements, the incoming packets will be treated as a grasptable miss"-suitno matching" and trigger the
  • a forwarding rule can comprise only reconfiguration action without any forwarding action
  • the match field of the forwarding rule comprises more than one reconfigurable elements and the forwarding unit is configured to carry out the at least one reconfiguration action of the forwarding rule if the received data packet does not match all of the at least one reconfigurable elements of the forwarding rule.
  • the match field of the forwarding rule comprises a forwarding action
  • the forwarding unit is configured to carry out the forwarding action of the forwarding rule if a received data packet matches the match field of the forwarding rule.
  • the forwarding unit is configured to determine whether or not there is a match of a data packet to a forwarding rule. In case of a match, the forwarding action is carried out while in case of mismatching at least one reconfigurable element of the match field, the reconfiguration action is carried out while the forwarding action is not carried out.
  • the forwarding unit is configured to modify at least one reconfigurable element of the at least one forwarding rule (in one embodiment: all forwarding rules stored in the storage unit) when carrying out the at least one reconfiguration action of the forwarding rule (and/or of other forwarding rules) if a received data packet does not match one or more
  • the forwarding unit can by itself modify a forwarding rule and no PACKETJN to the controller is required.
  • the reconfiguration action can be formulated such that in case of a mismatch a reconfigurable element of a match field of the mismatched rule can be adapted and/or reconfigurable elements of one or more forwarding rules can be adapted, where these forwarding rules may be identified in the reconfiguration action.
  • the reconfiguration action can be defined when configuring the forwarding rule, i.e. the reconfiguration action is part of the forwarding rule when being transmitted from the control unit to the forwarding unit.
  • the forwarding unit is configured to delete at least one of the at least one forwarding rule if a received data packet does not match one or more reconfigurable elements of the forwarding rule.
  • the storage space in the storage module is limited and the number of active forwarding rules is limited due to that space limitation, too. Deleting a rule may release storage space in the storage module and other forwarding rules can be activated or stored therein alternatively.
  • the forwarding unit is configured to modify at least one or a forwarding rule if a received data packet does not match one or more reconfigurable elements of the forwarding rule.
  • Modifying a forwarding rule may include duplicating an existing rule (optionally with subsequent modifications of at least one field of the forwarding rule) or modifying an existing forwarding rule (this may be the forwarding rule containing the
  • the copied/duplicated forwarding rule can be used to modify one of these forwarding rules while the other one is kept as it is. This may be useful under certain conditions where the data packets of a data flow alternate in time, thus resulting in a first type and second type of data packet.
  • Duplication and modification of one of the forwarding rules enables that there is a forwarding rule for both types of data packets while at the configuration time of the switch only one forwarding rule is transmitted to it.
  • the specific forwarding rule for the second type of data packets is dynamically created by the switch based on the reconfiguration instructions and by using simple operations like replacing the content of existing fields.
  • the forwarding unit is configured to generate at least one forwarding rule if a received data packet does not match one or more reconfigurable elements of the forwarding rule.
  • the reconfiguration action may contain all relevant information for generating a forwarding rule.
  • the reconfiguration action of the forwarding rule contains an association instruction and the forwarding unit is configured to associate the forwarding rule to at least a second forwarding rule.
  • a first forwarding rule can refer to at least one second forwarding rule, which can be any forwarding rule in the same forwarding unit.
  • the forwarding rule association can be applied to existing forwarding rules or to newly generated forwarding rules. If a new forwarding rule is generated based on the reconfiguration information of a first forwarding rule, the new forwarding rule is associated to the first forwarding rule. This may simplify the forwarding rule management.
  • Forwarding rule association may be a general feature of the forwarding unit as described herein. Forwarding rule association may particularly be used to point to the object of reconfiguration action (e.g., the forwarding rule containing said reconfiguration action or any other forwarding rule).
  • a forwarding rule may be referred to as dynamic forwarding rule (DFR).
  • DFR dynamic forwarding rule
  • This terminology indicates that the forwarding rule, or DFR, can be modified dynamically.
  • Forwarding rule association may be used to show the parent/child relationship between the modifying DFR and modified/generated DFR. This relationship can be used for the forwarding rule management afterwards, e.g., when the parent DFR changes, the child DFR may be changed as well.
  • the reconfiguration action of a first forwarding rule may act on a second forwarding rule (which is the associated forwarding rule, while there may be more than one associated forwarding rules to the first forwarding rule).
  • reconfiguration action may contain a reference to a second forwarding rule.
  • the association of a forwarding rule to a second one is decided by the controller unit or the forwarding unit in case it generates a forwarding rule based on an existing forwarding rule.
  • a first forwarding rule's reconfiguration action may act on a second forwarding rule (which is the associated forwarding rule, the second forwarding rule can be more than one).
  • a reconfiguration action may contain a reference to a second forwarding rule. The association of a forwarding rule to another one is decided by the controller unit or the forwarding unit in case it generates a forwarding rule based on an existing forwarding rule.
  • the forwarding unit is configured to generate a forwarding rule having a match field and an action field, wherein the match field has at least one static element and at least one reconfigurable element and wherein the action field has at least one forwarding action and at least one reconfiguration action.
  • the reconfiguration action can generate dynamic forwarding rules and the generated forwarding rules themselves are reconfigurable.
  • the forwarding unit is configured to adapt an output port of a forwarding rule when carrying out the at least one reconfiguration action of the forwarding rule, wherein the output port is adapted based on an input port of a received data packet.
  • the reconfiguration action can adapt the forwarding rule for the reverse data flow to use the incoming port of data packets of the mobile host A (the data packets sent from mobile host A to host B) as the outgoing port for the response data packets (the data packets from host B sent to the mobile host A).
  • the reconfiguration action can be formulated such that the forwarding unit uses information of the received data packets to reconfigure existing forwarding rules.
  • the incoming port of a data packet is used to adapt an existing forwarding rule.
  • the forwarding unit is configured to adapt the output port of a forwarding rule based on a source address and the input port of a received data packet.
  • a flow path can be established without asking the controller of the SDN.
  • the static fields contain at least the destination address where the reconfigurable fields contain the source address and the incoming port and where the reconfiguration action is defined.
  • the reconfiguration action contains the new output port while the source address and/or the input port of the data packet are reconfigurable match fields.
  • the forwarding unit can act as a bridge without asking the controller.
  • the forwarding unit is configured to report result of the at least one reconfiguration action to a control unit of the SDN system.
  • the forwarding unit updates the controller so that the controller is aware of the current status of the SDN. At least the content of the forwarding rules of the forwarding units of a SDN are used for defining the status of the SDN.
  • the processing capability of a switch determines how a DFR will be implemented. For instance, if a switch is DFR-enabled, the controller can install a DFR as is in such switch. If the switch is not DFR-enabled, the controller needs first to
  • This step can decouple the definition of DFR at the controller from the actual implementation of DFR at the switch and provide a general solution for heterogeneous SDN networks with different types of SDN switches.
  • a control unit for a software defined networking (SDN) system is provided.
  • the control unit is configured to configure at least one forwarding unit of the SDN system.
  • the control unit comprises a configuration module for generating configuration commands for a forwarding unit, wherein the configuration command comprises at least one forwarding rule having a match field with at least one reconfigurable element and an instruction set comprising at least one reconfiguration action to be applied to a forwarding rule by the forwarding unit in case a data packet received by the forwarding unit does not match one or more of the at least one reconfigurable element.
  • control unit configures the forwarding unit, as described above.
  • control unit configures the forwarding unit such that the control unit provides at least some ability of reconfiguration to the forwarding unit and the control unit does not need to be involved in any reconfiguration action.
  • the configuration commands used by the control unit for configuring the forwarding unit must therefore contain at least the match field of at least one forwarding rule and the instruction set with the reconfiguration action.
  • structure of the forwarding rule reference is made to the details provided above relating to the forwarding unit.
  • the forwarding unit carries out the reconfiguration action in case of a mismatch while, prior to carrying out data packet forwarding, the control unit provides specific configuration commands to the forwarding unit.
  • the control commands may comprise the reconfigurable forwarding rules.
  • the configuration commands of the control unit are functionally interrelated with the forwarding rules of the forwarding unit.
  • the configuration commands may be provided to the forwarding unit via a configuration interface.
  • a software defined network, SDN, system comprises at least one control unit as described above and at least one forwarding unit as described in any one of the embodiments above, wherein the at least one control unit is configured to configure at least one forwarding rule of the at least one forwarding unit.
  • a method for applying forwarding rules of a software defined networking, SDN, system comprises the steps of:
  • At least one forwarding rule which comprises a match field with at least one reconfigurable element and an instruction set with at least one reconfiguration action
  • the forwarding unit receives forwarding rules provided by the control unit and applies the forwarding rules to data packets. In case the conditions for carrying out a reconfiguration action are met (at least one reconfiguration action is not met), said reconfiguration action is carried out.
  • the SDN system supports Dynamic Forwarding Rules (DFR), wherein the controller defines the DFRs and selects the candidate SDN switches to install the DFRs, where the DFR includes in one embodiment: two different match fields, where one can be a fixed match field and the other one can be a reconfigurable match field, reconfiguration actions and forwarding actions, wherein the SDN switches are enhanced to execute the DFRs.
  • DFR Dynamic Forwarding Rules
  • a DFR can have different implementation at the SDN switches, e.g., two flow entries with different priority and flow entries in linked flow tables or one flow entry with both fixed and reconfigurable match field.
  • the DFR can be converted into a set of configuration messages according to the capability of target SDN switches by the controller; or DFR can be converted into a set of flow entries by target SDN switches according to their capability.
  • the fixed match field may be used also as the trigger for the reconfiguration actions.
  • the reconfiguration actions include modifying the DFR itself and/or associated forwarding rules at the same SDN switch and/or generate associated forwarding rules at the same SDN switch.
  • the SDN switch may be configured to detect the trigger of DFR (two steps/priority based matching/parallel matching), perform reconfiguration actions, gather the required information, identify the associated forwarding rules, identify the reconfigurable match fields, modify the reconfigurable match fields of itself or associated forwarding rules, generate associated forwarding rules, notify the controller on the modification of the DFRs and generated associated forwarding rules.
  • DFR two steps/priority based matching/parallel matching
  • the SDN switch may be configured to detect the trigger of DFR (two steps/priority based matching/parallel matching), perform reconfiguration actions, gather the required information, identify the associated forwarding rules, identify the reconfigurable match fields, modify the reconfigurable match fields of itself or associated forwarding rules, generate associated forwarding rules, notify the controller on the modification of the DFRs and generated associated forwarding rules.
  • the associated forwarding rules/DFRs may be removed as well.
  • the approach described herein does not require complex logical operations, as it relays on standard matching operations. So it can be easily accelerated by hardware or implemented in the kernel space instead of user space, and thus providing increased performance.
  • the approach described herein is highly flexible in the sense that it allows a first forwarding rule to perform
  • a forwarding rule based mechanism which gives certain flexibility to the SDN switches to adapt their forwarding behaviour according to local dynamic information. This approach is based on processing capabilities of SDN switches, it does not require a local agent. It is also independent of the control architecture and can avoid the need for complex control architecture in some case.
  • DFRs are computed and installed by the controller. However, different from static forwarding rule, a DFR includes a triggering condition and additional reconfigure actions to the normal (for example forwarding) actions. This enables DFR to modify itself and/or generate/modify associated forwarding rules, providing a fast response to local changes.
  • DFR Downlink Control Function
  • DFR Compared to static forwarding rules, DFR provides a mechanism to reconfigure the switch flow table locally and automatically, which reduces the configuration time for the SDN switches as well as the computation load at the controller. Comparing to the "learn" capability of virtual SDN switches, DFR does not depend on the intelligent processing capability (i.e., programming) of a virtual SDN switch. It uses a fixed format of forwarding rules and the actual implementation can be easily adapted to the capability of different target SDN switch. This enables the general usage of DFR in a big scale network with different types of SDN switches and improves the performance of the data plane processing.
  • DFR provides short reconfiguration time and fast response to changes at the switch level. It increases the scalability of SDN networks, as it delegates processing from controller to SDN switches and reduces the signaling from the controller. The difference is that DFR reuses the existing matching and configuration capability of the SDN switch. It has low complexity compared to agent based approach or hierarchical/distributed controller approach. No additional trigger signal is needed due to the smart combination of fixed and reconfigurable match field. Meanwhile, the flow table size is reduced by local forwarding rule adaptation/generation. DFR thus provides a general mechanism which makes the SDN network more flexible and dynamic. It increases the dimension of programming space in SDN networks.
  • Fig. 1 schematically shows an SDN system according to an exemplary embodiment of the invention
  • Fig. 2 schematically shows a forwarding unit according to an exemplary
  • Fig. 3 schematically shows a control unit and a forwarding unit according to an exemplary embodiment of the invention
  • Fig. 4 schematically shows the underlying infrastructure of an SDN system based on a global network view
  • Fig. 5 shows a schematic functional overview of a forwarding unit according to the OpenFlow specification
  • Fig. 6 schematically shows a flow table processing pipeline of a control unit
  • Fig. 7 schematically shows the structure of a forwarding rule in a forwarding unit according to an exemplary embodiment of the invention
  • Fig. 8 schematically shows the steps carried out by a control unit according to an exemplary embodiment of the invention.
  • Fig. 9 schematically shows the steps carried out by a forwarding unit according to an exemplary embodiment of the invention
  • Fig. 10 schematically shows a scenario for applying forwarding rule reconfiguration according to an embodiment of the invention
  • Fig. 1 1 schematically shows a scenario for applying forwarding rule reconfiguration according to an embodiment of the invention.
  • Fig. 1 provides an overview of the structure of an SDN system 10.
  • the control plane 100 is separated from the data plane 200.
  • the control plane 100 is formed by at least one control unit 1 10 which controls the configuration and the functioning of the data plane, in particular the configuration of forwarding rules on the forwarding unit 210, 220 of the data plane.
  • the SDN system 10 and its components are configured to carry out the functions as described above with reference to the forwarding unit, the control unit, the SDN system and the method for applying forwarding rules to data packets.
  • Fig. 2 shows a forwarding unit 210 comprising a first port 21 1 A, a second port 21 1 B, and a storage module 212.
  • the first port may be an incoming port (receiving data packets) and the second port may be an outgoing port (transmitting outgoing data).
  • the forwarding unit may comprise more than two ports and any one of these ports can be configured to receive and transmit data packets.
  • a forwarding rule may be configured to determine the outgoing port for any received data packet thus defining the route of the data packet through the data plane.
  • Fig. 3 illustrates the relation between a control unit 100 which comprises a configuration module 1 12 and a forwarding unit 210.
  • the control unit is configured to send configuration commands to the forwarding unit 210, wherein the configuration commands define the forwarding rules at the forwarding unit including the match field and the instruction set as described above and hereinafter.
  • Figs. 4, 5, and 6 provide a schematic overview of SDN.
  • SDN Software Defined Networking
  • control and data plane are decoupled, as can be seen in Fig. 4.
  • a logically centralized controller defines the packet forwarding and processing behaviour of SDN switches in the data plane by installing forwarding rules in their flow tables.
  • SDN is a dynamic and manageable architecture. It decouples the network control and forwarding planes from each other.
  • the network can be now programmed from a logically centralized controller.
  • Such controller can host many control applications that decide the forwarding behaviour of the underlying infrastructure based on a global network view as shown in Fig. 4.
  • the desired behaviour is installed in the network forwarding elements (e.g. SDN switches) by means of forwarding rules by the controller.
  • One of the most widely used protocols to perform this kind of configuration in SDN switches is OpenFlow (see Fig. 5).
  • forwarding rules are static, i.e., a forwarding rule does not change its content.
  • the organization of the flow tables in the SDN switch is shown in Fig. 6. Except for the group table, the SDN switch maintains a chain of flow tables (pipeline processing). Forwarding rules are specified in the flow table as table entries that include match fields and actions (instruction set). The set of possible actions include sending the incoming packet to the controller, packet header modification, sending the packet to another flow table, output the packet to a given switch port, etc. An incoming packet will be processed by the table pipeline according to the match fields and actions.
  • the forwarding rules are statically installed at the SDN switches. If a forwarding rule needs to be modified (e.g. change match fields or actions), the controller needs to interact again with the given switch in order to reconfigure it.
  • the switch In case the matching condition of a packet changes (e.g., packet coming from a different port in the switch due to User Equipment (UE) mobility), if there are no forwarding rules installed for this new condition, the switch will send the incoming packet to the controller wrapped into an SDN control message (PACKETJN message). The controller will analyse the incoming packet and update the existing forwarding rule accordingly. This round trip of control signalling to the controller consumes time and introduces signalling overhead.
  • a network with many moving UEs e.g., one eNB (ENodeB, Evolved Node B) of a mobile communication network has 3-6 cells and each cell can support ca.
  • the response latency to the local changes includes the processing time at the controller, queuing time at the control channel, round-trip time of the control signalling and the configuration time of individual SDN switch.
  • the response latency may be lower bounded by several milliseconds. Such latency may not be acceptable for certain time critical applications (e.g., Tactile internet may require less than 1 ms end to end delay) and limits the space of the SDN architecture.
  • Fig. 7 schematically shows a forwarding rule 300 comprising a match field 305 and an instruction set 330.
  • the match field 305 comprises a static element 310 and a reconfigurable element 320, wherein the reconfigurable element 320 can be reconfigured by a reconfiguration action stored in the instruction set 330 of the same or another forwarding rule.
  • DFR reconfigurable forwarding rules
  • static forwarding rules consists of two main elements, match fields 305 and instruction set 330.
  • DFR can be installed in any flow table where static forwarding rule is installed.
  • DFR can also be installed or partially installed in different flow table as in the case of static forwarding rules.
  • the DFR 300 of Fig. 7 includes two types of match fields: fixed match fields (static element 310) and reconfigurable match fields (reconfigurable element 320).
  • the match field 305 is being applied to an incoming data packet in order to determine if the matching criteria are met.
  • the reconfigurable match fields 320 follow the same format as the fixed match fields.
  • the initial values of the reconfigurable match fields are specified by the controller. Both fixed and reconfigurable match fields match one or several packet header fields, e.g. source IP address, the metadata value added by the SDN switch, e.g., the packet ingress port, and other pipeline fields.
  • the SDN switch triggers some actions (describe below) when a change in the current value of the reconfigurable match field(s) is detected, e.g., a change in the input port (set as reconfigurable match field) of a packet matching the fixed match fields triggers an action that modifies another forwarding rule in the flow table.
  • the instruction set 330 includes normal (forwarding) actions, e.g., forward the packet to a port, modify the packet by decrementing the TTL field, or change its state, etc.
  • normal (forwarding) actions e.g., forward the packet to a port, modify the packet by decrementing the TTL field, or change its state, etc.
  • reconfigure actions which act on the flow table of the SDN switch, e.g., modification of the reconfigurable match fields, or
  • a DFR 300 can have an associated forwarding rule e.g., the downlink forwarding rule belonging to a mobile node can be associated with its uplink forwarding rule.
  • a new generated forwarding rule can be associated with the DFR which generates it.
  • Such associated forwarding rule can be changed or installed as specified in the reconfigure action of the DFR.
  • the associated forwarding rule can be either a normal forwarding rule or a DFR. In static forwarding rules, there is no explicit rule association concept but rule identification method.
  • the controller uses cookie field to identify a certain/group of forwarding rules for certain action. While for DFR case, forwarding rule association may provide a hierarchical forwarding rule relationship chart, e.g., DFR which generates a forwarding rule is the parent and a forwarding rule generated by that DFR is the child. An uplink DFR can be the parent of a downlink DFR. Such a chart facilitates the local control of the forwarding rules at the SDN switches.
  • Fig. 8 shows the procedure at the controller side to prepare using the approach of DFR.
  • the controller After receipt of a DFR request (e.g., from a service), the controller specifies the DFR (the fixed and reconfigurable match fields, normal actions if any, and reconfigure actions) and associated forwarding rules (if any).
  • the associated forwarding rules can be DFRs as well.
  • the controller selects the candidate SDN switches to install the DFR (and associated forwarding rules if any).
  • the capability of the candidate SDN switches (e.g., whether it can do parallel matching of several match fields), affects the actual implementation of DFR at the SDN switch. Therefore, there are three options here: Option 1 : the controller converts the DFR and associated forwarding rules (if any) into a set of flow table configuration messages according to the capability of the candidate SDN switches, e.g. a DFR is converted into several flow entries that are to be installed in one or several flow tables at the candidate SDN switch. The converted flow entries provide the same behavior of such DFR
  • the candidate SDN switch converts the DFR into the correspondent flow entries in its flow tables according to its own capability.
  • the SDN switch interprets the DFR sent by the controller and decides how it is decomposed into forwarding rules and in which flow tables they are installed.
  • Option 3 there is no need to convert the DFR into correspondent configuration messages (e.g., assume all SDN switch will support DFR in the future).
  • the controller has an additional conversion step before distributing the configuration messages to the candidate SDN switches as shown in Fig. 8. In case of option 2 and 3, this step is not needed.
  • the distribution procedure of the flow table configuration message may use the existing data path configuration procedures.
  • Fig. 9 schematically shows the procedure at the forwarding unit to execute the DFR.
  • the DFR Before execution, the DFR must be installed.
  • a forwarding unit SDN switch
  • receives the DFR related configuration messages from the controller (option 1 mentioned above), it installs the related flow entries in its flow tables.
  • an SDN switch receives the DFR directly from the controller (options 2 and 3 mentioned above), it may convert the DFR into the correspondent flow entries before installs them in its flow tables (option 2), or install DFR directly into its flow tables (option 3).
  • reconfigurable match fields (branch 2 in Fig. 9), it executes the normal forwarding actions in the instruction set.
  • the SDN switch detects the match of the fixed match fields and mismatch of the reconfigurable match fields (branch 3 in Fig. 9), it executes the reconfigure actions (optionally in addition to normal forwarding actions) in the instruction set.
  • the normal action can be optional and the SDN switch will do nothing in branch 2 and perform only reconfigure actions related tasks in branch 3.
  • the SDN detects the mismatch of both match fields (branch 1 in Fig. 9), it executes the "flow table miss" action, which normally is (but not limited to) either "drop packet" or "send to controller".
  • the SDN switch needs to gather the required information which will be used to modify the reconfigurable match fields of the DFR/or the associated forwarding rules, and/or generate associated forwarding rules. In case of existence of associated forwarding rules, the associated forwarding rules need to be identified. In case of generation of an associate forwarding rule, the new generated forwarding rule should be associated with the DFR which generates it. After SDN switch performs the reconfigure actions, the local modification may be reported to the controller.
  • Fig. 10 and 1 1 describe different use cases with DFR. While Fig. 10 schematically shows the aspect of mobility management, Fig. 1 1 illustrates local bridging.
  • DFR can be used in mobility management to automatically reconfigure the flow path of a UE after a mobility event.
  • DFR reduces the load at the controller when multiple mobility events happen simultaneously and also the flow path reconfiguration latency, as the SDN switch does not need to wait for instructions from the controller in order to redirect the UE flow path.
  • Step 0 The controller computes a DFR to be installed in s1 to handle traffic between ml (IP ' ⁇ ') and an external host (IP 'B') in certain Packet Data Network (PDN).
  • DFR Packet Data Network
  • Such DFR is installed in s1 during the configuration process of the attach procedure of ml and is described as follows: Fixed match fields: [src: IP A, dst: IP B];
  • Trigger for reconfigure action incoming packet with [src: IP A, dst: IP B] and different in port;
  • Step 2 ml moves to a new location and reattaches to a neighbour access point.
  • Step 3 Incoming packet in s1 from ml [IP src: ' ⁇ ', IP dst: 'B', in port: 's3'].
  • the installed DFR in s1 detects that a changed on the input port for the flow IP 'A' -> IP 'B' occurred.
  • Step 4 [optional] The update in the flow table of s1 is reported to the controller by s1 .
  • Another use case for DFR is enabling local bridging at the SDN switch, as shown in Fig. 1 1 .
  • Bridging here refers to the connection of two traffic flows at the SDN switch.
  • DFR can be used to automatically set up a flow path between m2 and ml without asking the controller.
  • Step 0 The controller computes a DFR to be installed in s1 for a flow between IP 'B' and IP 'A' with the following characteristics: Fixed match fields: [dst: IP 'A'];
  • Trigger for reconfigure action incoming packet with [dst: IP ' ⁇ '] and different values for [src, in port];
  • Step 1 m2 sends a packet to ml , but no flow is set up in s1 .
  • Step 2 Incoming packet in s1 from m2: [IP src: 'C, IP dst: ' ⁇ ', in port: 's3'].
  • the installed DFR in s1 detects a change in [IP src, in port].
  • Step 3 [optional] The installation of the new flow entry is reported to the controller by s1 .
  • DFR can be implemented in different flavours.
  • the controller is responsible to translate DFR into a set of configuration message recognized by the target SDN switch.
  • DFR implementation in the SDN switch is to leverage on forwarding rule priorities.
  • Priority based implementation installs DFRs as multiple flow entries with different priorities in the SDN switch flow table:
  • the second one matches only the fixed match fields. It includes a configure action that installs or modifies the specified associated flow entries with the values of the reconfigurable match fields that were not matched by the high priority flow entry.
  • IP 'A' has established connection to a server in an external network (IP 'B') via s2.
  • IP 'B' external network
  • step 2 ml moves to a neighbouring access point, and such connection needs to be redirected to s3 in step 3.
  • a DFR can be installed in s1 to automatically perform the required redirection when ml moves as described below.
  • the DFR that needs to be installed in s1 is defined as:
  • IP arc IP A in_por [R]
  • Such DFR can be implemented as two flow entries (e.g., #A-B-1/2) with different priorities as follows:
  • Flow entry #A-B-2 will only be matched when the input port changes with regards to #A-B-1 's.
  • the input port in #A-B-1 is updated to the new value registered by #A-B-2 and, at the same time, the associated flow entry #B-A is updated with the new value as output port.
  • DFR implementation can also leverage on pipeline processing.
  • the fixed match fields are matched by a flow entry installed in a first flow table, as action, the packet is forwarded to a second table for further processing.
  • this second table only the reconfigurable match fields are matched following the approach already described herein.
  • Pipeline based implementation separates the fixed match field and reconfigurable match field into different tables. Therefore, it can be used to improve the performance of SDN switch by leverage the flow entry (re)configuration frequency and latency in different tables.
  • DFR could be implemented in an SDN switch as a pipeline of flow tables as shown below:
  • IP src IP A
  • IP dst IP B go to Table 2
  • IP src IP B
  • DFR can also be implemented as a single flow entry in the flow table of a SDN switch.
  • the SDN switch needs to explicitly differentiate between fixed and reconfigurable match fields.
  • the SDN switch keeps track of the values of reconfigurable match fields and checks the matching results of both the fixed and reconfigurable match fields. If the fixed fields match while the reconfigurable fields do not, the SDN switch executes the reconfigure action associated to that flow entry. If the use case shown in Fig. 10 is considered, the DFR defined in the section relating to priority based implementation can be implemented as follows:
  • the reconfigure action in #A-B is executed when the value of the input port for the same entry changes.
  • the reconfigure action updates the value of the input port in flow entry #A-B and sets such value as output port in flow entry #B-A.

Abstract

La présente invention concerne une unité de transfert (210, 220) pour un système de réseau piloté par logiciel, SDN (10). L'unité de transfert comprend un module de stockage (212) pour stocker au moins une règle de transfert (300), chacune de ladite au moins une règle de transfert comprend un champ de correspondance (305) comprenant au moins un élément reconfigurable (320) et un jeu d'instructions (330) comprenant au moins une action de reconfiguration. L'unité de transfert (210, 220) est configurée pour appliquer une règle de transfert de ladite au moins une règle de transfert à un paquet de données reçu en comparant le paquet de données reçu avec le champ de correspondance de la règle de transfert (300). L'unité de transfert est en outre configurée pour exécuter ladite au moins une action de reconfiguration de la règle de transfert si le paquet de données reçu ne correspond pas à un ou plusieurs dudit au moins un élément reconfigurable de la règle de transfert.
PCT/EP2016/050549 2016-01-13 2016-01-13 Règles de transfert dynamique dans un sdn WO2017121471A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/050549 WO2017121471A1 (fr) 2016-01-13 2016-01-13 Règles de transfert dynamique dans un sdn

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2016/050549 WO2017121471A1 (fr) 2016-01-13 2016-01-13 Règles de transfert dynamique dans un sdn

Publications (1)

Publication Number Publication Date
WO2017121471A1 true WO2017121471A1 (fr) 2017-07-20

Family

ID=55085681

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/050549 WO2017121471A1 (fr) 2016-01-13 2016-01-13 Règles de transfert dynamique dans un sdn

Country Status (1)

Country Link
WO (1) WO2017121471A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111314498A (zh) * 2020-01-21 2020-06-19 山东汇贸电子口岸有限公司 网络地址转换方法和nat网关
US10848420B2 (en) 2018-02-12 2020-11-24 Cisco Technology, Inc. Dynamic forwarding features in network elements
EP4073992A4 (fr) * 2019-12-10 2023-11-29 Amyna Systems Inc. Dispositif de commutation programmable pour infrastructures de réseau

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130163426A1 (en) * 2011-12-22 2013-06-27 Ludovic Beliveau Forwarding element for flexible and extensible flow processing in software-defined networks
US20140098669A1 (en) * 2012-10-08 2014-04-10 Vipin Garg Method and apparatus for accelerating forwarding in software-defined networks
CN104009921A (zh) * 2014-04-28 2014-08-27 开网科技（北京）有限公司 基于任意字段匹配的数据报文转发方法
US20150078386A1 (en) * 2013-09-15 2015-03-19 Nicira, Inc. Performing a Multi-Stage Lookup to Classify Packets
US20150163151A1 (en) 2013-12-06 2015-06-11 Algoblu Holdings Limited Hierarchical control in software-defined network (sdn)

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130163426A1 (en) * 2011-12-22 2013-06-27 Ludovic Beliveau Forwarding element for flexible and extensible flow processing in software-defined networks
US20140098669A1 (en) * 2012-10-08 2014-04-10 Vipin Garg Method and apparatus for accelerating forwarding in software-defined networks
US20150078386A1 (en) * 2013-09-15 2015-03-19 Nicira, Inc. Performing a Multi-Stage Lookup to Classify Packets
US20150163151A1 (en) 2013-12-06 2015-06-11 Algoblu Holdings Limited Hierarchical control in software-defined network (sdn)
CN104009921A (zh) * 2014-04-28 2014-08-27 开网科技（北京）有限公司 基于任意字段匹配的数据报文转发方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PAT BOSSHART ET AL: "Forwarding metamorphosis", SIGCOMM, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 27 August 2013 (2013-08-27), pages 99 - 110, XP058030628, ISBN: 978-1-4503-2056-6, DOI: 10.1145/2486001.2486011 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10848420B2 (en) 2018-02-12 2020-11-24 Cisco Technology, Inc. Dynamic forwarding features in network elements
EP4073992A4 (fr) * 2019-12-10 2023-11-29 Amyna Systems Inc. Dispositif de commutation programmable pour infrastructures de réseau
CN111314498A (zh) * 2020-01-21 2020-06-19 山东汇贸电子口岸有限公司 网络地址转换方法和nat网关
CN111314498B (zh) * 2020-01-21 2022-05-24 浪潮云信息技术股份公司 网络地址转换方法和nat网关

Similar Documents

Publication Publication Date Title
US11134012B2 (en) Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
US20180241621A1 (en) Forwarding unit and controller unit for sdn
CN108306777B (zh) 基于sdn控制器的虚拟网关主备切换方法及装置
EP2974180B1 (fr) Réseau de données en paquets, méthode d'exploitation d'un réseau de données en paquets et dispositif de réseau programmable dépendant du flux
US20170048157A1 (en) Intelligent Software-Defined Networking Based Service Paths
US10530669B2 (en) Network service aware routers, and applications thereof
EP3345341A1 (fr) Actions de réponse directe dans des commutateurs de réseau partagé de transmission de données (rptd)
WO2017121471A1 (fr) Règles de transfert dynamique dans un sdn
US5949780A (en) Integration of intelligence with communications in a switching node
KR101478944B1 (ko) 복수의 컨트롤러를 구비한 소프트웨어 정의 네트워크에서 스위치 접속 변경 방법
CN111130910A (zh) 一种应用于物联网平台的sdn控制器
US7860090B2 (en) Method for processing LMP packets, LMP packet processing unit and LMP packet processing node
US8964596B1 (en) Network service aware routers, and applications thereof
WO2017121475A1 (fr) Gestion de mobilité dans des systèmes sdn
Wei et al. Dynamic flow rules in software defined networks
KR101576518B1 (ko) 소프트웨어 정의 네트워크에서 오픈플로우 프로토콜을 확장하여 활용하는 방법 및 장치
KR102116245B1 (ko) 분산 클라우드 환경에서 오픈플로우 스위치 기반 전송 경로 설정을 위한 방법 및 장치
EP3391597A1 (fr) Procédé pour gérer la configuration d'un élément de réseau et élément de réseau
Saadoon OLSR Protocol based on Fog Computing and SDN in VANet

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

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

Country of ref document: EP

Kind code of ref document: A1