CN106790318B - Network function abstraction method and device in software defined network - Google Patents
Network function abstraction method and device in software defined network Download PDFInfo
- Publication number
- CN106790318B CN106790318B CN201510799830.XA CN201510799830A CN106790318B CN 106790318 B CN106790318 B CN 106790318B CN 201510799830 A CN201510799830 A CN 201510799830A CN 106790318 B CN106790318 B CN 106790318B
- Authority
- CN
- China
- Prior art keywords
- network
- network function
- type
- protocol
- function
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides a method and a device for realizing network function abstraction in a software defined network system, wherein: defining a network function abstract description model based on a rule structure, and based on the network function abstract description model, a controller interprets a customized network function and generates a configuration script supported by underlying network equipment, for example: and the controller issues the generated device configuration script to the underlying network device through a related control protocol (for example, Openflow protocol) according to the flow table entry of the Openflow protocol specification. In this manner, the complexity and variety of network devices and network functions may be masked, and only abstract network function rule entries need be created in which high level descriptions of target network functions, objects to execute, and actions to execute are specified, without requiring knowledge of the details of the underlying network.
Description
Technical Field
The invention relates to the technical field of communication, in particular to a method for processing a communication signalSoftware defined network。
Background
The SDN (software defined network) is an emerging network architecture, has the characteristics of flexibility, manageability and the like, and is more suitable for the characteristics of frequent upgrading and changing of the current network application. SDN separates control from forwarding and supports programming of the network. How to enable network programmability? Network abstraction is seen as an efficient way in which the network functions originally assumed by the underlying network elements will be abstracted, replaced and implemented by a set of uniform, configurable actions. For example, we can view the Openflow protocol as an abstraction of traditional routing, forwarding functions. A series of flow table entries are issued and configured onto the switch router. These flow table entries may serve the same function as the original routing protocol: identifies the packet and decides how to process the packet. There is no longer a need to install conventional routing or forwarding protocols on the switches or routers. A series of Openflow flow table entries replace the original route forwarding protocol and they can be easily configured or programmed, which is an abstraction of the route forwarding function.
The OpenFlow is a novel network protocol, a departure point control forwarding separation framework provided by the OpenFlow separates a control logic from network equipment, the control logic is handed to a central controller for centralized unified control, flexible deployment of network services is realized, and the OpenFlow protocols are designed as standard interfaces for communication between the controllers and switches. In recent years, OpenFlow has attracted wide attention of network equipment manufacturers and network administrators, and the OpenFlow protocol is used for realizing a software defined network, so that the network can be managed as a whole instead of a plurality of independent and scattered devices, and the network availability and the network management efficiency are greatly improved.
The network device maintains one or several flow tables and data flows are forwarded only according to these flow tables. The generation and maintenance of the flow table itself are completely managed by an external controller. The flow entry does not refer only to the normal IP five tuple, but rather a flexible rule consisting of some keys and execution actions, and each key field is wildcarded. In practical applications, a network administrator may determine what granularity of flow forwarding rules to use by configuring specific matching keywords in flow table entries. For example, if routing is only needed according to the destination IP, when a flow entry is issued, the keywords only match the destination IP field, other keywords are all matched, and only one egress port is needed in the action to implement conventional IP routing forwarding
The OpenFlow protocol is a southbound interface standard that describes information exchanged between controllers and switches. The OpenFlow protocol supports three types of message types: each type has a plurality of subtypes, and the Controller and the Switch are connected through the three types of messages to establish connection, issue flow tables and exchange information, so that all OpenFlow switches in the network are controlled.
As mentioned previously, the Openflow flow table is an abstraction of the traditional route forwarding function, and besides, there is no abstraction for other network functions.
Even the abstraction of Openflow over traditional routing has some drawbacks: the network programmer must know the details of the underlying network devices. For example, when he needs to customize a certain routing rule for certain packets, he first needs to find out the characteristics of these particular packets and find out their characteristic fields; then, the port number of the device needs to be known and the port number to be forwarded from needs to be determined; finally, he needs to create a complete flow table entry and send it to the network device through a standard interface. The whole process is very complex, and is not easy for a network administrator, and a network application developer is better. It should be noted that the network applications referred to herein do not refer to user-level applications (e.g., video, web, games, etc.), but rather refer to network-level applications (e.g., routing, DHCP, load balancing, firewalls, virtual network operations, etc.).
Another example is network leasing, where network infrastructure providers open network resources to network tenants, but the network tenants do not know any details of the network infrastructure. Ideally, a network tenant only needs to submit some high-level customization requirements regarding network functionality, but needs to know the details of the network device and generate any underlying configuration scripts. In fact, network tenants do not need to be concerned about how network functions are implemented. It can be seen that even though the routing forwarding function is abstracted, the Openflow mechanism still needs further abstraction to facilitate the operation and maintenance of the network.
Disclosure of Invention
The invention aims to provide a network function abstraction method based on rules. In order to program the network, the new network abstraction method provides a set of uniform semantic declarative abstraction rules to replace the traditional underlying command type interface, so that the network operator or the network developer can conveniently customize various network functions in a consistent manner.
According to an aspect of the present invention, there is provided a method for implementing network function abstraction in a software defined networking system, including: defining a network function abstract description model based on a rule structure; based on the network function abstract description model, the controller explains the customized network function and generates a configuration script supported by the underlying network equipment; and the controller transmits the generated configuration script to the underlying network equipment through a corresponding control protocol.
Preferably, the configuration script is a flow table entry conforming to an Openflow protocol specification, and the corresponding control protocol is an Openflow protocol.
Preferably, the aforementioned network function abstract description is used for defining a system network layer application, and the description model includes: a matching field and an action field for respectively representing a specific network function and a method for implementing the specific network function.
Preferably, the aforementioned matching domain further comprises target objects required to perform the specific network function.
Preferably, the aforementioned target object includes: source IP address SIP, destination IP address DIP, protocol, or port.
Preferably, the action field is a typical type field-value field pair, and is used for defining a specific network function implementation method in the matching field.
Preferably, the aforementioned type field represents a processing type for implementing a specific network function, and the numerical field represents parameters required for implementing the processing type of the corresponding specific network function, wherein the type field includes the following types or a combination thereof: a Flow type for those network functions that can be implemented by Flow or packet processing; a Redirect type for a particular network function to be handled by redirecting Redirect to a particular server; a quality of service type for representing a network function related to quality of service, QoS, control; a record type for representing a functional process related to a system record Log; or a node management type for indicating a functional process that needs to be implemented by a simple network management protocol SNMP protocol support.
According to another aspect of the present invention, there is provided a control apparatus in a software defined network system, comprising: receiving means for receiving a customized network function description; the interpretation device is used for interpreting the customized network function and generating a configuration script supported by the underlying network equipment based on a network function abstract description model with a rule structure; and the sending device is used for sending the generated configuration script to the underlying network equipment through a control protocol.
Preferably, the configuration script is a flow table entry conforming to an Openflow protocol specification, and the control protocol is an Openflow protocol.
Preferably, the aforementioned network function abstract description is used for defining a system network layer application, and the description model includes: a matching field and an action field for respectively representing a specific network function and a method for implementing the specific network function.
Preferably, the aforementioned matching domain further executes target objects required for the specific network function.
Preferably, the action domain is a typical type domain-value domain pair, which is used to define the specific network function implementation method in the matching domain.
Preferably, the type field represents a processing type for implementing a specific network function, and the value field represents parameters required for implementing the processing type of the corresponding specific network function, wherein the type field includes the following types or a combination thereof: a Flow type for those network functions that can be implemented by Flow or packet processing; a Redirect type for a particular network function to be handled by redirecting Redirect to a particular server; a quality of service type, the type being used to represent a network function related to quality of service Qos control; a record type for representing a functional process related to a system record Log; and the node management type is used for expressing the functional processing which needs to be realized by the support of the Simple Network Management Protocol (SNMP) protocol.
According to another aspect of the present invention, there is provided a software-defined network system including the aforementioned control apparatus; and the network equipment is used for receiving the equipment configuration script generated and issued by the control equipment and realizing the corresponding specific network function.
According to the network function abstraction method and the device thereof provided by the embodiment of the invention, the complexity and diversity of network equipment and network functions can be well shielded. An operator or an upper application developer only needs to create an abstract rule entry, and a target network function, an executed object and a high-level description of an execution action are indicated in the abstract rule entry, so that the operator or a network manager is supported to easily customize a specific network function, and a network multi-tenant scene is also well supported. Traditional network functionality can be abstracted into a set of uniform formats, high-level rule entries through which upper-level network application developers can customize a particular network without knowing the details of the underlying network. As upper-level application developers can focus their efforts on implementing the application logic itself, requiring only high-level network function customization needs to be submitted through a simple API interface.
Drawings
The features, nature, and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like elements have like numerals wherein:
FIG. 1 is a schematic diagram of a network function abstraction-rule structure provided by the present invention;
FIG. 2 is a diagram illustrating the structure of an action domain in a rule structure provided by the present invention;
FIG. 3 is a schematic diagram of a network function abstraction application, i.e., a load balancing system structure, provided by the present invention;
fig. 4 is a schematic diagram of an abstract rule structure of load balancing, which is a network function abstraction application provided by the present invention.
Fig. 5 is an OpenFlow flow table entry issued to a bottom device for load balancing, which is a network function abstraction application provided by the present invention.
Detailed Description
In the following detailed description of the preferred embodiments, reference is made to the accompanying drawings which form a part hereof. The accompanying drawings illustrate, by way of example, specific embodiments in which the invention may be practiced. The illustrated embodiments are not intended to be exhaustive of all embodiments according to the invention. It should be noted that although the steps of the methods of the present invention are described herein in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results, but rather that the steps described herein can be performed in an order that varies. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.
As shown in fig. 1, a schematic diagram of a network function abstraction model, a rule structure, a unified and formatted rule structure is used to represent different system network layer applications, and the rule structure can be edited or programmed conveniently. One rule contains two domains: matching fields and action fields, a typical rule entry is used to describe and represent a particular network function and implementation. As a high-level abstraction of network functions, rule entries are not loaded onto the underlying device as Openflow flow table entries. The network programmer or virtual network operator uses the rule entry to customize the network function, and generally, the rule entry is created and maintained on a central controller, and the central controller is responsible for parsing the rule entry and issuing an appropriate configuration script to the underlying device. The execution of these rule entries is therefore mainly done by the centralized controller, the network programmer or the virtual network operator only needs to define the creation of the rule entries themselves.
Unlike the Openflow mechanism, the ACTION domain (ACTION) in a rule uses a high-level semantic representation to describe how the network function is implemented. The action field is a Type-Value pair (Type-Value), and no specific configuration script is given in the Value field. The rule definer need only fill in the value field with some attribute parameter, usually the attribute parameter is some attribute file name of the target network function. The properties file is often a template in which a detailed representation of the target network functionality is given. Such as: a pre-defined firewall template FW1 in which details of the needs of a particular firewall and its firewall policies are given. The name FW1 of this firewall template will be filled in a value field for indicating the target network function, i.e. the firewall that needs to be executed. Thus, the rule definer does not need to know the specific underlying network details, but only needs to specify the requirements by means of parameters in the numerical domain.
A FUNCTION sub-domain (FUNCTION) in the matching domain is used to specify the target network FUNCTIONs that need abstraction, i.e., what network FUNCTIONs need to be performed or customized. In some cases, the matching domain also needs to specify the target objects needed to perform the network function, and other sub-domains in the matching domain may be used to provide selection of target objects, such as source IP address (SIP), destination IP address (DIP), protocol or port, etc. For example: a certain network application needs to perform Deep Packet Inspection (DPI) functions on data flows from a certain source IP address. Then in addition to the FUNCTION sub-domain (FUNCTION) being set to DPI to specify the particular network FUNCTION, a specific IP address needs to be specified in the source IP address field (SIP) in the matching field, which can then be used to indicate exactly which packets need to be deep-packet inspected.
Fig. 2 is a schematic diagram of an ACTION domain structure in the rule structure provided by the present invention, and an ACTION domain (ACTION) is a typical Type-Value pair, and is used to define a network function implementation method specified in the matching domain, i.e. how it should be executed and implemented. As shown in fig. 2, the Type (Type) field indicates a processing Type for implementing a specific network function, and typically may include a Flow (Flow) Type, a Redirect (Redirect) Type, a quality of service (QoS) Type, a Log (Log/Copy) Type, a node management (SNMP) Type, and the like, wherein:
the Flow (Flow) type is used for network functions that can be implemented by Flow or packet processing, which means that related data flows are processed according to an Openflow Flow table (device supporting Openflow protocol) or a routing forwarding table (legacy device). All network functions that can be resolved into Openflow flow table entries or routing table entries are set to flow type, such as routing, load balancing, firewall, etc., when abstracted. The corresponding Value field (Value) may be set to the name of a certain template for flow or packet processing.
Redirect (Redirect) type, meaning that the target network function will be handled by a specific server and thus the corresponding data stream will be redirected to some logical or physical network entity. Generally speaking, network functions implemented using client-server mode are generally classified into redirection types, such as DHCP (dynamic host configuration protocol) configuration, AAA (authentication, authorization) service, and the like. The server parameters that implement the redirection network function are typically given in the corresponding Value field, for example: the IP or domain name address of the redirect target server, and attribute parameters associated with specific functions, such as address pool configuration for DHCP, etc.
Quality of service (QoS) type, represents a network function related to QoS control, and the network function cannot be implemented by means of flow control. Likewise, the Value field is used to specify the relevant parameters. For example, if the network function to be implemented is queue scheduling, its Type field needs to be set to QoS Type, and its value field is set to parameters related to queue scheduling, such as: qs (sp) indicates a queue scheduling method using Strict Priority (strong Priority).
A Log (Log) type, which represents functional processing associated with system logging. The corresponding Value field is used to indicate the way the system record needs to be completed, for example: either locally copied or forwarded elsewhere.
The node management type is used for representing the functional processing required to be realized by the SNMP protocol support, and the corresponding Value field is used for indicating the parameters of the node management.
It should be noted that the Type field is not limited to the above-mentioned processes, and may be further extended to support more other network functions, for example, a Type such as "Netconf" is used to indicate that a function requiring Netconf protocol support is required.
In general, the network function abstraction model-rule structure and action domain in the rule structure mainly relate to: 1) unlike the Openflow flow table, a series of standard, uniform form rule items are used to represent traditional network functions, and these rule items are network function descriptions of some system network application layers, and do not require any knowledge of the details of the underlying network by the rule maker or upper application developer. 2) The corresponding network function can be realized by explaining and executing the corresponding rule item, and the rule-based network function abstraction can replace the original traditional network function realization mechanism and simultaneously achieve the effect required by the original network function. 3) The rules with the standard format can be easily edited or programmed, so that an operator can conveniently edit the network function, and different from an Openflow flow table, the domain value of each domain of the network function abstract model in the embodiment of the invention can be a variable, so that a developer can conveniently program to realize the network function customization.
The following applicant will give a concrete example of the implementation of rule-based network function abstraction, as shown in fig. 3, some operators need to route upstream data traffic to different BNG nodes in a BNG (broadband gateway) group according to network load conditions. Here we assume that the access node AN has three uplink ports (physical or logical ports) respectively connected to three different BNG nodes in the BNG group. When an operator needs to perform load balancing operations on certain traffic (visiting a particular hot site), then the need can be described as performing load balancing on data traffic targeted to a particular IP. As AN upper application developer, he does not know which access node AN has exactly several uplinks, let alone which one connects to which BNG node. Ideally, the upper application developer only needs to submit the requirements of the upper layer, namely the names of the network functions to be executed and the executed objects. Thus, abstract API interfaces such as NF _ Creation (LB, DstIP, LB1), where LB represents a specific network function class, for example: load balancing according to the present embodiment; DstIP represents the object of the specific network function execution, namely, data traffic aiming at the target address of DstIP; the last parameter LB1 represents the attribute file name of the load balancing function, which is a specific network function category, i.e. the content of the specific policy and the like describing the load balancing function in the attribute file.
The abstract API is responsible for parsing these incoming parameters and creating specific rule entries, such as the network function abstraction application shown in fig. 4-the rule structure diagram for load balancing.
In practice, the rule entries should be registered in the format shown below:
here, the Flow (Flow) parameter LB1 is actually an attribute file name of the load balancing function. Assume that it is specified in LB1 to use round robin scheduling algorithm as its implementation for load balancing and that 80% is the trigger point, i.e. meaning that when a certain BNG node is more than 80% loaded, then the traffic needs to be redirected to the next BNG node.
In order to realize the requirement of the polling algorithm through a proper flow table entry, a Rule Driver (Rule Driver) module is set in a Software Defined Network (SDN) controller to be responsible for analyzing the Rule and generating a configuration script for interacting with an underlying device. In this embodiment, we assume that the underlying device supports the OpenFlow protocol, and the following gives implementation codes related to rule parsing of polling algorithm and OpenFlow flow table generation.
And then, the SDN controller issues the generated OpenFlow flow table to AN access node AN of the underlying network equipment through a corresponding control protocol OpenFlow protocol.
Fig. 5 illustrates a network function abstraction application, i.e., a configuration script issued to a bottom device for load balancing, that is, an OpenFlow flow table entry, where the entry may replace an original implementation mechanism for load balancing deployed on a device and can achieve the same load balancing effect as the original mechanism. The OpenFlow flow table in the figure may be composed of a plurality of flow table entries, each flow table entry is a forwarding rule, and a packet entering the AN obtains a destination port for forwarding by querying the flow table. The flow table entry consists of a header field, a counter and an Action (Action), wherein: the header field is a plurality of tuple, which is an identification of a flow entry, such as a Switch Port (Switch Port), a MAC source address (MAC src), a MAC destination address (MAC dst), an ethernet Type (Eth Type), a virtual local area network identification (VLAN ID), an IP source address (IP src), an IP destination address (IP dst), an IP Port (IP Port), a TCP source Port (TCP Port), a TCP destination Port (TCP dport) in the legend; the counter is used for counting the statistical data of the flow table entry; the Action (Action) identifies the Action that should be performed by the packet matching the flow entry, for example: and forwarding the data traffic data with the DstIP destination address in the flow table entry to the corresponding port to be sent to the corresponding BNG, thereby realizing the purpose of performing load balancing on the data traffic with the IP destination address being a certain characteristic IP.
It can be understood by those skilled in the art that the foregoing embodiment is only described by taking AN example of network function abstraction application and load balancing, and it is assumed that the access node AN of the underlying network device supports the OpenFlow flow control protocol and operation, however, according to different defined network functions, the processing manner of implementing the specific network function method and the support capability of the underlying network device are different, and thus, there are many different configuration scripts and control protocols specifically issued to the underlying network device. For example: when a certain authentication function is abstracted, the authentication function is often configured as a redirection type in an action domain, that is, related data packets need to be forwarded to a specific authentication server to realize the related function; assuming that the underlying network device does not support the OpenFlow protocol, the controller needs to analyze the rule into a conventional forwarding entry and issue the conventional forwarding entry to the underlying network device through a universal remote control interface; furthermore, for the abstract latency control function, configured as QoS type in the action domain, the correlation parameter indicates the corresponding latency parameter. At this time, the controller often resolves the rule into a forwarding queue configuration parameter, and issues the forwarding queue configuration parameter to the underlying network device through the remote control interface.
As can be seen from the above description of the embodiments: 1) the traditional specific network function, namely load balance, can be represented and described only by a format rule entry which conforms to a network abstract description model, and the content of the rule entry indicates a target network function, an implementation object and related parameters in a high-level language. The upper application developer or rule maker is not concerned with how the target network functionality is implemented, nor does it need to know the details of the lower network devices. 2) Rule entries that conform to the network abstraction description model may be parsed in the controller into a specific device configuration script that may implement conventional network functions and achieve the same effect and configured to the network device, e.g., OpenFlow flow table entries in this example. 3) The content of the rules may be configurable and modifiable so that the rule entries are editable or programmable, and the network operator or upper application developer may customize a particular network function by defining a particular rule entry.
In fact, the three points mentioned above are key features of network function abstraction: a high level description of the unified format, replacement of legacy mechanisms, and programming enablement. The Openflow mechanism is an abstraction of the conventional routing forwarding function, but it requires the network operator to know the details of the network, e.g. how many ports a switch has, from which port a particular traffic is forwarded, and to assemble a specific flow table entry. The network abstraction mechanism provided by the invention can well shield the complexity and diversity of network equipment and network functions. The operator or upper application developer need only create abstract rule entries in which high level descriptions of target network functions, objects to perform, and actions to perform are specified. Therefore, the method supports operators or network managers to easily customize specific network functions, and well supports the network multi-tenant scene. As upper-level application developers can focus their efforts on implementing the application logic itself, requiring only high-level network function customization needs to be submitted through a simple API interface.
Through the above description of the embodiments, those skilled in the art will clearly understand that the present invention may be implemented by software plus a necessary hardware platform, and certainly may be implemented by hardware, but in many cases, the former is a better embodiment. With this understanding in mind, all or part of the technical solutions of the present invention that contribute to the background can be embodied in the form of a software product, which can be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods according to the embodiments or some parts of the embodiments of the present invention.
The above embodiments are only for illustrating the technical solutions of the present invention and not for limiting the same, and although the present invention is described in detail with reference to the preferred embodiments, those of ordinary skill in the art should understand that: modifications and equivalents may be made to the invention without departing from the spirit and scope of the invention.
Claims (12)
1. A network function abstract realization method in a software defined network system is characterized in that:
defining a network function abstraction description model based on a rule structure, wherein the network function abstraction description model is used for defining a system network layer application, the network function abstraction description model comprises: a matching field and an action field for respectively representing a specific network function and a method for implementing the specific network function;
based on the network function abstract description model, the controller explains the customized network function and generates a configuration script supported by the underlying network equipment;
and the controller transmits the generated configuration script to the underlying network equipment through a corresponding control protocol.
2. The method of claim 1, wherein the configuration script is a flow table entry conforming to an Openflow protocol specification, and the corresponding control protocol is an Openflow protocol.
3. The method of claim 1, wherein the matching domain further comprises target objects needed to perform the particular network function.
4. The method of claim 3, wherein the target object comprises: source IP address SIP, destination IP address DIP, protocol, or port.
5. The method according to any of claims 1-4, wherein the action domain is a typical type domain-value domain pair for defining a specific network function implementation method in the matching domain.
6. The method of claim 5, wherein the type field represents a processing type for implementing a specific network function, and the value field represents parameters required for implementing the processing type of the corresponding specific network function, wherein the type field comprises the following types or a combination thereof:
a Flow type for those network functions that can be implemented by Flow or packet processing;
a Redirect type for a particular network function to be handled by redirecting Redirect to a particular server;
a quality of service type, the type being used to represent a network function related to quality of service Qos control;
a record type for representing a functional process related to a system record Log;
and the node management type is used for expressing the functional processing which needs to be realized by the support of the Simple Network Management Protocol (SNMP) protocol.
7. A control apparatus in a software-defined networking system, characterized by comprising:
receiving means for receiving a customized network function description;
the interpretation device is used for interpreting the customized network function and generating a configuration script supported by the underlying network equipment based on a network function abstract description model of a rule structure, wherein the network function abstract description model is used for defining system network layer application, and the network function abstract description model comprises: a matching field and an action field for respectively representing a specific network function and a method for implementing the specific network function;
and the sending device is used for sending the generated configuration script to the underlying network equipment through a control protocol.
8. A control device according to claim 7, wherein the configuration script is a flow table entry conforming to the Openflow protocol specification, and the control protocol is the Openflow protocol.
9. A control device according to claim 7, characterized in that said matching domain further executes target objects required for said specific network function.
10. A control device according to claim 7 or 9, wherein the action field is a typical type field-value field pair for defining the implementation of a particular network function in the matching field.
11. A control apparatus according to claim 10, wherein the type field represents a type of process for realizing a specific network function, and the value field represents parameters required for realizing the type of process for the corresponding specific network function, wherein the type field comprises the following types or a combination thereof:
a Flow type for those network functions that can be implemented by Flow or packet processing;
a Redirect type for a particular network function to be handled by redirecting Redirect to a particular server;
a quality of service type, the type being used to represent a network function related to quality of service Qos control;
a record type for representing a functional process related to a system record Log;
and the node management type is used for expressing the functional processing which needs to be realized by the support of the Simple Network Management Protocol (SNMP) protocol.
12. A software-defined networking system, comprising:
the control device according to any one of claims 7 to 10; and
and the network equipment is used for receiving the configuration script generated and issued by the control equipment and realizing the corresponding specific network function.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510799830.XA CN106790318B (en) | 2015-11-19 | 2015-11-19 | Network function abstraction method and device in software defined network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510799830.XA CN106790318B (en) | 2015-11-19 | 2015-11-19 | Network function abstraction method and device in software defined network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106790318A CN106790318A (en) | 2017-05-31 |
| CN106790318B true CN106790318B (en) | 2020-12-11 |
Family
ID=58916248
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510799830.XA Active CN106790318B (en) | 2015-11-19 | 2015-11-19 | Network function abstraction method and device in software defined network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106790318B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107769983B (en) * | 2017-11-21 | 2020-01-03 | 华中科技大学 | Network function sharing method and system based on extended vSDN |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101384086A (en) * | 2008-10-30 | 2009-03-11 | 华为技术有限公司 | Network device configuring method apparatus and system |
| CN104065509A (en) * | 2014-07-24 | 2014-09-24 | 大连理工大学 | SDN multi-controller deployment method for reducing management load overhead |
| CN104243196A (en) * | 2013-06-21 | 2014-12-24 | 中兴通讯股份有限公司 | Virtual network mapping protection method and system under SDN architecture |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101409723B (en) * | 2008-11-27 | 2011-11-09 | 浙江工商大学 | Method for designing synthesis network management system based on ForCES protocol |
-
2015
- 2015-11-19 CN CN201510799830.XA patent/CN106790318B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101384086A (en) * | 2008-10-30 | 2009-03-11 | 华为技术有限公司 | Network device configuring method apparatus and system |
| CN104243196A (en) * | 2013-06-21 | 2014-12-24 | 中兴通讯股份有限公司 | Virtual network mapping protection method and system under SDN architecture |
| CN104243196B (en) * | 2013-06-21 | 2019-03-12 | 中兴通讯股份有限公司 | Virtual network mapping guard method and system under a kind of SDN framework |
| CN104065509A (en) * | 2014-07-24 | 2014-09-24 | 大连理工大学 | SDN multi-controller deployment method for reducing management load overhead |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106790318A (en) | 2017-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230254283A1 (en) | Methods and apparatus to provide a distributed firewall in a network | |
| CN112235123B (en) | Service function registration mechanism and capability indexing | |
| US11582115B2 (en) | Dynamic intent assurance and programmability in computer networks | |
| US20160301603A1 (en) | Integrated routing method based on software-defined network and system thereof | |
| US9203645B2 (en) | Virtual input-output connections for machine virtualization | |
| Dixon et al. | Software defined networking to support the software defined environment | |
| EP2974230B1 (en) | Common agent framework for network devices | |
| Machado et al. | Towards SLA policy refinement for QoS management in software-defined networking | |
| US11736410B1 (en) | Synchronizing device resources for element management systems | |
| CN114553689A (en) | Connecting template | |
| Davoli et al. | Implementation of service function chaining control plane through OpenFlow | |
| Machado et al. | Policy authoring for software-defined networking management | |
| Machado et al. | Arkham: an advanced refinement toolkit for handling service level agreements in software-defined networking | |
| Zope et al. | Firewall and load balancing as an application of SDN | |
| KR20180058594A (en) | Software Defined Network/Test Access Port Application | |
| CN106790318B (en) | Network function abstraction method and device in software defined network | |
| KR20180058592A (en) | Software Defined Network Controller | |
| Kriska et al. | Dynamic routing of IP traffic based on QoS parameters | |
| KR20180058593A (en) | Software Defined Network Whitebox Switch | |
| Lehocine et al. | VINEMA: Towards automated management of virtual networks in SDN infrastructures | |
| Kujur et al. | Network Functions Virtualization and SDN | |
| KR101739097B1 (en) | Service chaining method in openflow switch | |
| KR101739100B1 (en) | Method of controlling openflow switch capable of service chaining and controller thereof | |
| Grgurevic et al. | Analysis of MPLS and SD-WAN Network Performances Using GNS3 | |
| Ziri et al. | Service chaining implementation in network function virtualization with software defined networking |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 201206 Pudong New Area Jinqiao Export Processing Zone, Nanjing Road, No. 388, Shanghai Applicant after: Shanghai NOKIA Baer Limited by Share Ltd Address before: 201206 Pudong New Area Jinqiao Export Processing Zone, Nanjing Road, No. 388, Shanghai Applicant before: Shanghai Alcatel-Lucent Co., Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |