Dynamic Forwarding Rules in SDN TECHNICAL FIELD

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.

BACKGROUND

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. Usually, the data plane is configured such that it requires control commands from the control plane in order to meet the forwarding tasks. Simply speaking, 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. 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. For the sake of clarity it should be noted that the terms forwarding rules and flow rules are used herein as synonyms. In the simplest view, 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. In case an incoming packet does not match any of the forwarding rules defined on the switch then 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:

Scalability: The performance of the controller is closely related to the number of flows to be managed in parallel;

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;

Resiliency: Since the controller is the brain of the SDN network, resilience of the controller and control channel greatly affects the correct operation of the complete SDN network

There have been described several attempts to solve the problems stated above. US 2015/163151 A1 describes a hierarchical control architecture at the expense of increasing the synchronization signaling between the distributed controllers. Other approaches focus on agent based solutions, where a local agent is installed in the SDN switch and takes over some of the tasks from the applications sitting on the central controller. SoftOffload: "A programmable approach toward collaborative mobile traffic offloading", MobiSys Ί 4, describes, for instance, delegating some of the offloading functionalities to local agents to reduce the redundant signaling and the processing overhead at the controller. However, agent based approaches require additional application layer processing capability at the SDN switch, which might not always be possible.

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. In this case, 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. Open vSwitch manual suggests not use "learn" mechanism in the main flow table (table=0) of the switch because of performance reasons. The "learn" action can only operate on forwarding rules that were produced by the same action.

SUMMARY

There may be a need of reducing the load of the control plane in an SDN system.

This object is achieved by the features of the independent claim. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to an aspect of the invention, a forwarding unit for a software defined networking (SDN) system is provided. The forwarding unit 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. In the following, the terms forwarding unit and switch shall be interpreted as synonyms, unless stated otherwise. Such 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. In other words, there is a conditional relation between the match field and the actions of a forwarding rule.

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.

It is understood that when discussing a single condition, matching a condition is equivalent to mismatching an opposite condition. 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. In other words, 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.

According to an embodiment of the invention, 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. Thus, 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„table miss"-„no matching" and trigger the

reconfiguration action. A forwarding rule can comprise only reconfiguration action without any forwarding action

According to a further embodiment of the invention, 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.

According to a further embodiment of the invention, the match field of the forwarding rule comprises a forwarding action, wherein 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.

In case a data packet matches the match field (both static and reconfigurable elements), the data packet is forwarded according to the forwarding action and the reconfiguration action will not be carried out.

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.

According to a further embodiment of the invention, 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

reconfigurable elements of the forwarding rule.

In case of a rule mismatch, 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. According to a further embodiment of the invention, 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.

According to a further embodiment of the invention, 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

reconfiguration action and/or another forwarding rule stored in the storage module). 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.

According to a further embodiment of the invention, 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. By generating a forwarding rule from the scratch, the forwarding table of the forwarding unit can be adapted to a specific data transmission scenario (type of data packets transmitted to and handled by the switch) or to a varying data transmission scenario without requiring additional commands from the controller.

According to a further embodiment of the invention, 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. In other words, 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).

In the following, a forwarding rule may be referred to as dynamic forwarding rule (DFR). 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.

For example, 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). A

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.

According to a further embodiment of the invention, 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.

Thus, the reconfiguration action can generate dynamic forwarding rules and the generated forwarding rules themselves are reconfigurable. According to a further embodiment of the invention, 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.

For example, in case of data communication between two hosts A and B and if one of these hosts is a mobile host (say for example host A) and its connection port to a forwarding unit (this is the input port or incoming port of the forwarding unit at which the data packet from host A is received) changes, 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. In the example above, the incoming port of a data packet is used to adapt an existing forwarding rule.

According to a further embodiment of the invention, 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. Thus, 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. Thus, depending on the source address and the input port, the forwarding unit can act as a bridge without asking the controller.

According to a further embodiment of the invention, the forwarding unit is configured to report result of the at least one reconfiguration action to a control unit of the SDN system.

By reporting the reconfiguration result to a controller (control unit), 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

decompose a DFR into one or several flow mod operations. Such decomposition also depends on other processing capabilities of the target switch, such as pipeline processing, or version of OpenFlow, for example. 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.

According to a further aspect of the invention, 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.

Generally, in an SDN the control unit configures the forwarding unit, as described above. In respect of DFR, the 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. In respect of the structure of the forwarding rule, reference is made to the details provided above relating to the forwarding unit.

During runtime (when the SDN and its components are used to forward data packets), 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. In other words, the configuration commands of the control unit are functionally interrelated with the forwarding rules of the forwarding unit. Thus, reference can be made to the details provided above relating to the function of the forwarding unit, while these details are not repeated herein. The configuration commands may be provided to the forwarding unit via a configuration interface.

According to a further aspect of the invention, a software defined network, SDN, system is provided. The 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.

According to a further aspect of the invention, a method for applying forwarding rules of a software defined networking, SDN, system is provided. The method comprises the steps of:

receiving 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;

applying a forwarding rule of the at least one forwarding rule to a received data packet by comparing the received data packets with the match field of the forwarding rule;

carrying 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.

For details relating to the method according to this aspect, reference is made to the details provided above when describing the function of the forwarding unit. Summed up, 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.

In other words, the SDN system and its components, i.e., the forwarding unit and the control unit, may be described as follows: 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. 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. When the DFR is removed or expired, 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. In addition, the approach described herein is highly flexible in the sense that it allows a first forwarding rule to perform

modifications on associated forwarding rules that were not installed by the first forwarding rule. The goal is to increase the programmability of SDN switches and increase the efficiency of SDN network in large scale, dynamic environments (e.g., mobile network). A forwarding rule based mechanism is described 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.

Below, different procedures to install a DFR at the SDN switches are described. Furthermore, the procedure to process the DFR at the SDN switches using their existing processing capabilities (i.e., matching, forwarding rule configuration) and three possible implementations thereof are described.

The usage of DFR is exemplified using two use cases: UE mobility management and local bridging. Basically, DFR can be applied to all use cases where it is beneficial to have forwarding rules adaptation locally at the SDN switch without asking the controller.

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.

Similar to other approaches to overcome the limitations of SDN networks, 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.

BRIEF DESCRIPTION OF THE FIGURES

Embodiments of the invention will be described with respect to the following figures, in which:

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

embodiment of the invention;

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. DETAILED DESCRIPTION OF EMBODIMENTS

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. In Software Defined Networking (SDN), 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). Usually, 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.

After the forwarding rules are specified by the controller, they 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.

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. In case of 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. 200 active UEs, and one mobile network could have 100,000+ eNBs), the control signalling to the controller due to simultaneous UE mobility events could generate congestion of the control channel and huge processing load at the controller. 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.

Using such reconfigurable forwarding rules (also referred to as DFR) may have several advantages, as described in the following. Similar to static forwarding rules, DFR consists of two main elements, match fields 305 and instruction set 330. Basically, 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. In addition, it includes reconfigure actions, which act on the flow table of the SDN switch, e.g., modification of the reconfigurable match fields, or

modification/generation of an associated forwarding rule. If a packet matches fixed and reconfigurable match fields, but no change in the reconfigurable match field(s) is detected by the SDN switch, normal actions (if specified) are executed. 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. E.g., 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.

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. Afterwards, 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

Option 2: the candidate SDN switch converts the DFR into the correspondent flow entries in its flow tables according to its own capability. In this case, 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). In case of option 1 , 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. Before execution, the DFR must be installed. When 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. When 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).

When the SDN switch detects the match of both fixed match fields and

reconfigurable match fields (branch 2 in Fig. 9), it executes the normal forwarding actions in the instruction set. When 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. When 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".

To perform the reconfigure actions, 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. In this use case, 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. Taking as a reference the scenario shown in Fig. 10, a procedure using DFR to handle mobility events in the data plane is explained below. The numbering of the steps described below is used in the figures as reference, while the number of each step is circled in the drawing. 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). 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];

Reconfigurable match fields: [in port]; Action: [output => PDN];

Associated flow entry: Downlink flow IP B ->\P A, Match fields: [src: IP B, dst: IP A] Action: [output => s2];

Trigger for reconfigure action: incoming packet with [src: IP A, dst: IP B] and different in port;

Reconfigure action: Update current flow entry with new value of in port [in port => R'], and change the Action of the associated flow entry IP B -> IP A to [output => R'], where R' is the new in port. Step 1 : Incoming packet in s1 from ml [IP src: 'Α', IP dst: 'B', in port: 's2']. The packet is forwarded to PDN as specified in the flow table of s1 [output => PDN].

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. DFR updates the current flow entry to match the tuple [IP src: 'Α', IP dst: 'B', in port: 's3'] and also the associated downlink flow entry IP 'B' -> IP 'A' with the action [output => 's3'];

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.

Taking as a reference the scenario shown in Fig. 1 1 when ml communicates with m2, S1 "bridges" the traffic between ml and m2. DFR can be used to automatically set up a flow path between m2 and ml without asking the controller. The detailed procedure is the following:

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'];

Reconfigurable match fields: [src: IP 'B', in port: 'PDN']; Action: [output => s2];

Trigger for reconfigure action: incoming packet with [dst: IP 'Α'] and different values for [src, in port];

Reconfigure action: Install a new flow entry with the new values of [src, in port] and action [output => s2];

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]. The DFR reconfigure action is executed and a new flow entry is installed with the match fields [IP src: 'C, IP dst: 'Α', in port: 's3'] and action [output => s2].

Step 3: [optional] The installation of the new flow entry is reported to the controller by s1 .

In the following, examples of implementing DFR in SDN shall be briefly described. Depending on the actual capability of target SDN switch, 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.

Priority based implementation

One option for 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 high priority one matches all the specified match fields, including both fixed and reconfigurable match fields;

With a lower priority than the previous entry, 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. Considering the use case shown in Fig. 10, ml , with IP 'A' has established connection to a server in an external network (IP 'B') via s2. In step 2, ml moves to a neighbouring access point, and such connection needs to be redirected to s3 in step 3. In this case, 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:

DFR ID: ffA-B

Noimal action: output■> PDN

IP arc: IP A in_por [R] Reconf action: Update fkmr A-B (new in_port = R'|

I ds IP B Update now #B-A (r>» twd action: tHrtptrt■> R') where the input port [R] is the reconfigurable match field. Let R be the old value of input port and R' be the current value of the input port of the matched packet. As reconfiguration actions, the DFR will update its reconfigurable match field from R to R', and the associated flow entry with ID #B-A with R' as output action. 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. As action, 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.

Pipeline based implementation

DFR implementation can also leverage on pipeline processing. In this case, 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. In 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.

If this implementation option is applied to the use case shown in Fig. 10, DFR could be implemented in an SDN switch as a pipeline of flow tables as shown below:

Table 1

Instruction set

Flow ID Prio Match fields

Normal Action Reconfigure Action

#A-B 1 IP src: IP A, IP dst: IP B go to Table 2

#B-A 2 IP src: IP B, IP dst: IP A output => s2

in_port]

Parallel matching implementation

DFR can also be implemented as a single flow entry in the flow table of a SDN switch. In this approach, 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:

where the reconfigure action in #A-B is executed when the value of the input port for the same entry changes. As in the previous implementation proposal, 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.