KR20150056035A - SDN-based Network Device with extended function and method of processing a packet in the same device - Google Patents

Abstract

The present invention relates to a software-defined networking (SDN) technology. More specifically, the invention relates to the extension of the functionality of an SDN-based networking device. The networking device in accordance with the present invention comprises: multiple flow tables; multiple functional modules performing different functions for each packet; and an entry functional module which determines operations to be performed first out of a multitude of operations including table search and functional module operations corresponding to each packet when the packet are received. Once the entry functional module assigns the table search or functional module operation to be run next as a performance result of the operation determined by the entry functional module, and the assignment repeats itself until a different set of instructions is given to the packet.

Description

[0001] The present invention relates to an SDN-based network device having an extended function and a packet processing method in the apparatus,

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to software defined networking (SDN), and more specifically, to extension of functions of an SDN network device.

The existing SDN architecture seeks a clear distinction between the control plane and the data plane. The data plane performs a simple function of forwarding packets to the path specified by the control plane after performing actions (eg, encapsulation, decapsulation, etc.) specified by the control plane on the packets do. In such a structure, however, all intelligence is given to the control plane and the applications running on it. Therefore, since most tasks requiring intelligence except for simple processing for packet processing must be performed in the control plane, delay issues in packet processing and performance issues due to exchange of data and control flags and frequent packets / messages It is being raised.

Therefore, the present invention intends to improve the inefficient packet processing process caused by the complete separation of the control plane and the data plane of the existing SDN structure and hence the simple packet processing of the data plane.

To achieve the above object, a network apparatus according to an embodiment of the present invention includes: a plurality of flow tables; A plurality of functional modules, each of which performs different processing for this packet; And an entry function module for, when the packet is received, determining an operation to be performed first among the table search operation and the function module execution operation for the packet. A table search or a function module execution operation to be performed next is designated as a result of performing the operation determined by the entry function module, and the designation can be repeated until the output instruction for the packet is given.

In one embodiment, the function module may include operation information to be performed next after the function module is executed.

In one embodiment, the next operation to be performed when the table lookup operation is performed may be specified by instructions included in the flow entry matched to the packet.

In one embodiment, the instruction is configurable by the controller via a control channel that performs an open-flow channel or the like.

In one embodiment, the instructions may specify one or more table lookups to be performed next, or one or more function module executions.

In one embodiment, the instructions may specify another function module execution or other table search to be performed subsequent to the function module execution, with the function module execute operation to be performed next.

In one embodiment, the instructions may specify a set of combined table lookup and function module execution action lists to be performed next.

In one embodiment, the first flow table search among the plurality of flow tables is performed when the operation determined by the entry function module is a table search.

In one embodiment, when the operation determined by the entry function module is a function module execution, the first one of the plurality of function modules is executed.

According to an embodiment of the present invention, a method of processing a packet in a network device having a plurality of flow tables, an entry module and a plurality of function modules is provided. The method includes receiving a packet; Determining a table search or function module execution as an operation to be performed next for the received packet by executing the entry module; Processing the packet by performing the determined table search or function module execution; And subsequently processing the packet by performing another table search or other function module execution operation designated as a result of the table search or the execution of the function module. Another table search or another function module execution operation may be designated as a result of the other table search or the execution of the other function module, and the designation is repeated until the output instruction for the packet is given.

In one embodiment, the function module may include operation information to be performed next after the function module is executed.

In one embodiment, the next performing operation specified as a result of the table lookup may be specified by instructions included in the flow entry matched to the packet.

In one embodiment, the instructions may be set by the controller via a control channel that performs an open-flow channel or the like.

In one embodiment, the instructions may specify one or more table lookups to be performed next, or one or more function module executions.

In one embodiment, the instructions may specify execution of another function module to be performed subsequent to execution of the function module, together with execution of the next function module to be performed, or search of another table.

In one embodiment, the instructions may specify a set of combined table lookup and function module execution action lists to be performed next.

According to an embodiment of the present invention, the existing SDN concept that enables programming for a network device (e.g., an SDN switch) is followed so that the network device can perform various more intelligent functions. The present invention can effectively improve the delay problem of the SDN switch and the SDN control period which are pointed out as disadvantages of the conventional SDN structure, and it is possible to differentiate the function of the SDN switch according to the manufacturer.

Figure 1 shows the structure of an SDN based on OpenFlow.
2 is a flowchart illustrating a process of processing packets in the switch of FIG.
FIG. 3 conceptually illustrates the structure of an SDN network device according to an embodiment of the present invention.
FIG. 4 illustrates a structure in which information is transferred between a plurality of tables and functional modules shown in FIG.
5 is a flowchart illustrating a packet processing process performed in a network device according to an embodiment of the present invention.
FIG. 6 illustrates an example of an operation interworking between a function module and a table search in a network device according to an exemplary embodiment of the present invention.

While the present invention has been described in connection with certain exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and similarities. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

In addition, the singular phrases used in the present specification and claims should be interpreted generally to mean "one or more " unless otherwise stated.

Also, the terms "module,""part,""interface," and the like, used in the present specification generally mean computer-related objects and may mean, for example, hardware, software and combinations thereof.

Figure 1 shows the structure of an SDN based on OpenFlow. As shown, the control plane (e.g., controller 110) and the data plane (e.g., switch 120) are separated and the separate control plane and data plane can be interlocked via the open flow protocol have. The switch 120 includes an open flow control channel 121 for communicating with the controller, a plurality of flow tables 122a to 122n in the form of a pipeline, and an action set according to the final search result of the flow tables 122a to 122n and an action execution module 123 for executing the action set. The switch 120 searches the one or more flow tables 122a to 122n for a flow matched with a packet input thereto and processes the packet by executing an action set according to the search result.

2 is a flowchart illustrating a process of processing packets in the switch of FIG. When a packet is input, the switch searches for an entry matching the packet from the first flow table (S210). At this time, the search key may be changed according to the definition of the table. For example, a packet header field such as an IP source address, an IP destination address, and input port information may be used as a search key. If there is an entry matching the table (S220), if there is an entry to be matched, the count for the entry is updated and the designated instruction is performed (S230). The instructions may include an action set update, packet header information, or match field updates to be used to retrieve the next table, update metadata, and the like. It is determined whether the instruction of the matched entry includes the next table search (Goto-Table n) instruction (S240), and then the next table search is attempted. If the next table search (Goto-Table n) instruction is not given (that is, if the last table search is performed), the final determined action set is performed through several table searches (S260).

On the other hand, when there is no matching entry for the table search, it is checked whether a table-miss entry (or a default entry) exists (S250). If the entry exists, an instruction of the entry is performed (S230), but if the entry does not exist, the packet is discarded (S270).

The packet processing described above is described in detail in the OpenFlow Specification 1.4 official release, so a detailed description thereof will be omitted.

Meanwhile, the instructions defined in the open-flow specification of the current point of time are divided into essential instructions and optional instructions. A detailed description of each instruction is described in the specification, and a brief description thereof is as follows.

Required instructions

- Goto-Table next-table-id: a table search request corresponding to the next table identifier (next-table-id)

Optional instruction

- Meter meter id: Performs a meter based meter that is defined.

- Apply-Actions action (s): Perform action (action (s))

- Clear-Actions: Clears all actions set in the action-set.

- Write-Actions action (s): Added action to action set

- Write-Metadata metadata / mask: Added masked metadata to the metadata field passed to the following table.

As can be seen from the Open Flow Specification, the SDN data flow function performs an operation of searching for a table, searching for another table, performing a specific action (output, header modification, QoS processing, ), Metering application, metadata modification, and the like. However, in such a case, most of the tasks requiring intelligence other than the simple task for packet processing must be performed in the control plane, thereby delaying packet processing.

The SDN architecture according to the present invention allows a variety of packet processing functions to be modularized on the data plane and provides a modularized packet processing instead of an existing simple packet header change or forwarding from the control plane to the data plane as a flow- Function can be specified to overcome the disadvantages caused by the complete separation of the control plane and the data plane in the existing SDN structure.

For example, in the current SDN architecture, there is no way to directly specify IPsec processing in the SDN data plane (SDN switch) when processing IPsec for a packet, so either forwarding the packet to a separate IPsec device The OpenFlow switch instructs the IPsec device to forward the packet to the port to which it is connected, without performing any operation on IPsec) to operate as an application of the SDN control plane. However, in the SDN structure according to the present invention, when the IPsec processing function is defined as one modular function and the execution of the "IPsec processing" function module is designated as an instruction in the entry of the flow table, Module "to be IPsec-processed.

Here, it is assumed that the control plane and the application operating on it know in advance that the data plane includes a function module supporting IPsec. For example, the OF-CONFIG extension allows you to see a list of function modules included in the data plane. In addition, if the data plane chipset supports it, the data plane can dynamically download and install the necessary function modules. Thus, based on the identified functional modules, the control plane and the applications running on it can easily implement various packet processing functions by programming the functional modules supported by the data plane.

Hereinafter, the SDN structure according to the present invention will be described in more detail with reference to FIGS. 3 to 5. FIG.

FIG. 3 conceptually illustrates the structure of an SDN network device according to an embodiment of the present invention.

As shown in the figure, the SDN structure proposed in the present invention is also divided into a controller 310 corresponding to a control plane and a network device corresponding to a data plane (e.g., a switch 320) (320) communicates via a protocol such as open flow is the same as the conventional one. However, the network device 320 according to an embodiment of the present invention is characterized in that it includes an entry module and a plurality of function modules in addition to a plurality of flow tables.

Specifically, the network device 320 according to an embodiment of the present invention includes a plurality of flow tables 323-1 to 323-3 interconnected through an open flow control channel 321, an entry module 322, and a communication channel 325. [ 323-n, a plurality of function modules 324-1 through 324-n, and an action execution module 326. [

The entry module 322 is a kind of function module, and performs basic processing on an input packet to determine whether the next operation to be performed is a table search or a function module execution. According to the determination of the entry module 322, a search for the first table 323a will be performed or the first functional module 324a will be executed.

The flow tables 323-1 to 323-n are tables for defining processing operations for each flow. In one embodiment, the flow tables 323-1 through 323-n may include instructions to specify another table lookup and / or function module execution in the flow entry.

In one embodiment, the instruction may be set by the controller via an open flow channel.

In one embodiment, the instruction may specify one or more table lookups to be performed next, or one or more function module runs. For example, the instruction may be in the form of an 'nth table search (Goto-Table n)' or an 'm-th function module run (Run-Function m)'.

In another embodiment, the instruction may specify another function module execution or another table search to be performed subsequent to the execution of the function module in conjunction with the next execution of the function module to be performed. For example, the instruction may be of the form 'Run-Function x before Goto-Table n', 'Run-Function x before Run-Function y'

In yet another embodiment, the instruction may specify a set of combined table lookup and function module execution action lists to be performed next. For example, the instruction can be of the form 'Run-Function 1-> Goto-Table 1-> Run-Function 2-> Run-Function 3-> Goto-Table 2'.

Each of the function modules 324-1 through 324-n may perform various functions related to packet processing. Function modules can perform complex functions such as packet header modification, IPsec, Deep Packet Instruction (DPI), and load balancing functions as well as simple functions to support table lookups. The SDN structure according to the present invention can differentiate each network device according to which function is added at the time of SDN data plane development (for example, a network device such as an SDN switch). According to the present invention, the concept of a dummy switch that performs an existing simple packet manipulation and forwarding is removed, and a basic concept (a structure for placing most of the intelligence on the SDN control plane) It is possible to implement an intelligent SDN switch to enable packet processing.

In one embodiment, the function modules 324-1 through 324-n may include operation information to be performed next after the function module is executed. The functional module may include information on single / multiple table retrieval or single / multiple other functional module execution as the next operation to be performed.

The functional modules 324-1 through 324-n may be implemented in a hardware manner in the switch chipset, or in a dynamically installable software module. Functional modules implemented in software may be dynamically loaded into a number of independent processing units that are programmable, for example, in a switch chipset, or dynamically loaded into a separate external processing unit connected to the switch chipset via an external interface, Function can be performed. The present invention is not limited to the physical location and specific implementation of a functional module, but is characterized by an interlocking structure and operation in which one functional module is associated with the retrieval of one or more tables and / or the execution of other functional modules.

In one embodiment, control for functional modules 324-1 through 324-n (including control of operation information to be performed next after the functional module is executed) may be extended through an open flow protocol or the like or via a separate interface have. Also, in order to enable the differentiated functions of the chipset for each switch chipset vendor, an API of an easily usable form can be provided so as to facilitate control of the function module in the control plane and the application.

FIG. 4 illustrates a structure in which information is transferred between a plurality of tables and functional modules shown in FIG.

When a packet is received, the entry module 321 is performed first. The entry module 321 determines whether a table search or functional module execution is to be performed as the next operation by performing basic processing on the input packet.

As a result of the table search or function module execution determined by the entry module 321, the next operation to be performed, i.e., another table search or other function module execution, can be specified. The designation of this next operation to be performed will be repeated until an output instruction for the packet is given. That is, the next operation to be performed is repeated until no further table search or function module execution request is made, and the packet processing is ended through the final table search performed or the final action set performed according to the result of the functional module execution .

In one embodiment, the instructions set by default can be performed if an instruction specifying a table lookup or a function module execution is not calculated as a result of executing a table search or a function module. On the other hand, if no table search or function module execution result instruction is computed and no instruction set to default exists, the packet can be discarded.

In one embodiment, the instructions computed as a result of table lookup or function module execution may be instructions specifying a single table or single function module execution, or may be instructions that require consecutive execution of multiple tables and / or multiple function modules have. That is, as a series of combinational instructions specifying one table search and / or function module execution to be performed before a packet is transmitted to the output port, the table search / function module is sequentially executed according to the specified order . The present invention refers to such a process as a "source routed function" process.

Referring again to FIG. 4, an example of information transferred between tables, between functional modules, or between a table and functional modules over a communication channel 325 is shown. As shown, the information transferred between the tables, between the functional modules, or between the table and the functional module basically includes the information shown in FIG. 2, that is, the packet, the incoming port information, the metadata and the action set, A message field may be added as the characteristic information by the message field. The present invention can convey an Next Table or Function that specifies the next action (or action list) to be performed next as a result of an action (table lookup or function module execution) performed now using the message field. That is, instructions can be passed that specify a single table lookup or a single function module execution, or a combination of successive runs of multiple table lookups and multiple function module executions.

5 is a flowchart illustrating a packet processing process performed in a network device according to an embodiment of the present invention.

As shown in the figure, when a packet is received (S501), an entry module for performing a basic process for a packet is executed to determine whether the next operation to be performed is a table search or a function module execution (S502).

If it is determined that the table is searched, the first table search is performed to check whether there is an entry matched to the corresponding table (S503). If there is an entry to be matched, it updates the count information for the entry, updates the action set according to the instruction, updates the match field to be used for retrieving the packet header information or the next table, is used for transferring information between tables, (Step S504). If there is no matching entry, it is determined whether there is a table-miss entry (or a default entry) (S509). If there is a default entry, the instruction specified in the entry is executed (S504) If not, the corresponding packet can be discarded (S510).

As a result of the determination in step S502, if it is determined that the function module is executed, the first function module is executed (S508), and as a process for the packet, an action set update, a packet header information / , Metadata update and the like may be performed (S504).

If a "Goto-Table n instruction" is given as a result of the table search result or the execution of the function module, the search for the next table is performed (S505-> S503) m) "is given, the" function module "designated by the instruction is executed (S506-> S507). As a result of the table search result or the execution of the function module, another table search may be designated or another function module execution may be designated, and a series of table search and / or function module execution may be performed until the packet output instruction is finally given And the packet can be processed.

After a series of table searches and a function module execution are performed through the above-described processes, if it is determined that a function module to be further retrieved or executed is not designated, the set of actions performed through the table search and the function module execution is performed.

In one embodiment, the next table information or next functional module information given as a result after the functional module is executed may be included in the corresponding functional module or included in the message delivered with the "functional module execution instruction " .

In addition, a series of table information or other function module information to be used for execution of a specific function module and retrieval after execution of the corresponding function module may be specified as a result of performing a table search or a function module execution. As an example of the implementation of such a series of table search and function module execution, an open flow of the form "Run-Function x before Goto-Table n & Additional instructions may be defined. For example, "Run-Function x before Goto-Table n" means to search table n after executing function module x. In actual instruction execution, function module x according to "Run-Function x" Table n "is transferred to the function module x in the form of a message, and the function module x executes the" Goto-Table n "instruction after processing the packet.

As another example, "Run-Function x before Run-Function y" means to execute another function module y after executing the function module x. The function module x according to "Run- -Function y "is transmitted to the function module x in the form of a message. Accordingly, the function module x executes the "Run-Function y" instruction after packet processing. In addition, the "Run-Function y" instruction combines the table information or the function module information to be searched after the execution of the function module y and outputs the "Run-Function x before Goto- And so on.

In the above-described example, the table search or the execution of the other function module is described only for executing the function module immediately after the execution of the corresponding function module. However, according to another embodiment of the present invention, Do. For example, if an instruction is expanded in the form of an instruction list specifying a plurality of operations, such as "Run-Function 1-> Goto-Table 1-> Run-Function 2-> Run-Function 3-> Goto-Table 2" . The instruction list searches the table 1 after executing the function module 1, instructs the function module 2 and 3 to execute again, and finally searches the table 2.

Such an instruction list is merely an example of the present invention, and may be any table information to be searched next as a result of an arbitrary table search, a table list, a function module, or a function module list, Other types of instructions for achieving the purpose of performing a combined list of a table to be executed and a function module to be executed are also within the scope of the present invention.

In the meantime, the " Run-Function x before Goto-Table n ", "Run-Function x before Run-Function y ", or a series of instructions In order to be able to specify the list "Run-Function 1-> Goto-Table 1-> Run-Function 2-> Run-Function 3-> Goto-Table 2", the SDN control plane is connected to the SDN data plane You should be able to identify the set of implemented functional modules in advance. This can be achieved by OF-Config defined in the Open Networking Forum (ONF), such as open flow, or by exchanging information between the SDN data plane and the control plane via a separate protocol. The present invention is not limited in how the SDN control plane obtains functional module information of the data plane.

FIG. 6 illustrates an example of an operation interworking between a function module and a table search in a network device according to an exemplary embodiment of the present invention. As shown in the drawing, a first table (Table 1, 610) in a series of table structures including two tables, Table 1 (610) and Table 2 (620) is a flow table having a large flow granularity A flow table having an input port number and a 4th layer (TCP or UDP) destination port number as a match field) and a second table (Table 2,620) is a microflow-specific hash table 5-tuple A flow table having a destination address, a protocol number, a TCP or UDP source port number, and a hash value for a TCP or UDP destination port number as a match field). In order to process a packet, a network device according to an embodiment of the present invention searches a first table (Table 1, 610), and a second table (Table 2, 620) to obtain information about the final output port, it will need a hash value for the 5-tuple as the key to retrieve the second table. In the present invention, the operation of extracting such a hash value can be defined using one function module 630. [ The hash value extracted through the execution of the function module 630 may be transferred through a metadata field when transmitting information for the second table search 620. [

The embodiments of the present invention as described above may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer readable medium may include program instructions, data files, data structures, and the like, alone or in combination.

Program instructions to be recorded on a computer-readable medium may be those specially designed and constructed for the present invention or may be available to those skilled in the computer software arts. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Includes hardware devices specifically configured to store and execute program instructions such as magneto-optical media and ROM, RAM, flash memory, and the like. The above-mentioned medium may also be a transmission medium such as a light or metal wire, wave guide, etc., including a carrier wave for transmitting a signal designating a program command, a data structure and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like.

The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

The embodiments of the present invention have been described above. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

Claims (16)

In a network device,
A plurality of flow tables;
A plurality of functional modules, each of which performs different processing for this packet; And
And an entry function module that, when a packet is received, determines an operation to be performed first among the table search operation and the function module execution operation for the packet,
Wherein the table search or function module execution operation to be performed next is designated as a result of performing the operation determined by the entry function module, and the designation is repeated until an output instruction for the packet is given. The network device according to claim 1, wherein the function module includes operation information to be performed next after the function module is executed. The network device according to claim 1, wherein the operation to be performed next when the table search operation is performed is specified by an instruction included in a flow entry matched with the packet. 4. The network device according to claim 3, wherein the instruction is set by a controller via a control channel performing an open-flow channel or a similar function. The method of claim 3,
Wherein the instructions specify searching for one or more tables to be performed next or executing one or more function modules. 4. The network device according to claim 3, wherein the instruction specifies execution of another function module to be performed subsequent to execution of the function module, or search of another table, together with a function module execution operation to be performed next. 4. The network device according to claim 3, wherein the instruction specifies a series of combined table lookup and function module execution action lists to be performed next. The network device according to claim 1, wherein when the operation determined by the entry function module is a table search, a first flow table search among the plurality of flow tables is performed. The network device according to claim 1, wherein when the operation determined by the entry function module is a function module execution, the first function module of the plurality of function modules is executed. A method for processing a packet in a network device having a plurality of flow tables, an entry module and a plurality of function modules,
Receiving a packet;
Determining a table search or function module execution as an operation to be performed next for the received packet by executing the entry module;
Processing the packet by performing the determined table search or function module execution; And
Further processing the packet by performing another table search or other function module execution operation designated as a result of the table search or the function module execution,
Wherein another table search or another function module execution operation can be designated as a result of the other table search or the execution of the other function module, and the designation is repeated until an output instruction for the packet is given. 11. The method of claim 10, wherein the functional module comprises operational information to be performed next after the functional module is executed. 11. The method of claim 10, wherein the next performing operation specified as a result of the table lookup is specified by instructions contained in a flow entry matched to the packet. 11. The method of claim 10, wherein the instructions are set by a controller via a control channel that performs an open-flow channel or a similar function. 13. The method of claim 12,
Wherein the instructions specify searching for one or more tables to be performed next or executing one or more function modules. 13. The method of claim 12, wherein the instructions specify execution of another function module to be performed subsequent to execution of the function module together with execution of the next function module to be performed. 13. The method of claim 12, wherein the instructions specify a set of combined table lookup and function module execution action lists to be performed next.

Images